コンピューティングにおいて、データ変換とは、ある形式または構造のデータを別の形式または構造に変換するプロセスです。これは、ほとんどのデータ統合[ 1 ]や、データラングリング、データウェアハウジング、データ統合、アプリケーション統合などのデータ管理タスクの基本的な側面です。
データ変換は、ソース(初期)データとターゲット(最終)データの間の必要な変更に基づいて、単純なものから複雑なものまであります。データ変換は通常、手動と自動の手順を組み合わせて実行されます。[ 2 ]データ変換に使用されるツールとテクノロジーは、変換されるデータの形式、構造、複雑さ、および量に基づいて大きく異なります。
マスターデータの再キャストは、データベースからデータを抽出することなく、データベース全体のデータ値を変換または再キャストするデータ変換の一種です。適切に設計されたデータベース内のすべてのデータは、外部キー制約のネットワークによって、限られた数のマスターデータベーステーブルに直接的または間接的に関連付けられています。各外部キー制約は、親データベーステーブルの一意のデータベースインデックスに依存しています。したがって、適切なマスターデータベーステーブルが異なる一意のインデックスで再キャストされると、直接的および間接的に関連付けられたデータも再キャストまたは再記述されます。元の一意のインデックスはマスターデータに引き続き存在するため、直接的および間接的に関連付けられたデータは元の形式で表示することもできます。また、データベースの再キャストは、アプリケーションアーキテクチャソフトウェアに影響を与えないように実行する必要があります。
データマッピングが仲介データモデルを介して間接的に行われる場合、そのプロセスはデータ仲介とも呼ばれます。
データ変換は、以下の手順に分けることができ、それぞれの手順は、必要な変換の複雑さに基づいて必要に応じて適用されます。
これらの手順は、多くの場合、開発者や技術データアナリストが重点的に取り組み、彼らはタスクを実行するために複数の専門ツールを使用する場合があります。
手順は以下のとおりです。
データディスカバリーは、データ変換プロセスの最初のステップです。通常、データの構造と特性をより深く理解し、どのように変換する必要があるかを決定するために、プロファイリングツールを使用するか、場合によっては手動でプロファイリングスクリプトを作成してデータをプロファイリングします。
データマッピングとは、最終的な目的の出力を生成するために、個々のフィールドがどのようにマッピング、変更、結合、フィルタリング、集計されるかを定義するプロセスです。開発者やテクニカルデータアナリストは、変換ルールを定義するための特定のテクノロジー(ビジュアルETLツール、[ 3 ]変換言語など)を使用するため、従来データマッピングを実行します。
コード生成とは、目的および定義されたデータマッピングルールに基づいてデータを変換する実行可能コード(SQL、Python、R、またはその他の実行可能命令など)を生成するプロセスです。[ 4 ]通常、データ変換テクノロジーは、開発者によって定義された定義またはメタデータに基づいてこのコードを生成します。 [ 5 ]
コード実行とは、生成されたコードをデータに対して実行し、目的の出力を生成するステップのことです。実行されるコードは変換ツールに密接に統合されている場合もあれば、開発者が生成されたコードを手動で実行するための別のステップが必要な場合もあります。
データレビューはプロセスの最終段階であり、出力データが変換要件を満たしていることを確認することに重点を置いています。通常、このステップを実行するのは、データのビジネスユーザーまたは最終エンドユーザーです。データに異常やエラーが見つかった場合は、開発者またはデータアナリストに新しい要件としてフィードバックし、変換プロセスに実装します。[ 1 ]
従来、データ変換は一括処理またはバッチ処理であり、[ 6 ]開発者はデータ統合ツールでコードを記述するか変換ルールを実装し、その後、そのコードまたはルールを大量のデータに対して実行します。[ 7 ]このプロセスは、上記のデータ変換プロセスで説明されている一連の直線的な手順に従うことができます。
バッチデータ変換は、データウェアハウジング、データ移行、アプリケーション統合など、事実上すべてのデータ統合技術の基盤となるものです。[ 1 ]
データを低遅延で変換および配信する必要がある場合、「マイクロバッチ」という用語がよく使用されます。[ 6 ] これは、非常に迅速に処理して必要に応じてターゲットシステムに配信できる、小さなデータバッチ(たとえば、少数の行または少数のデータオブジェクトのセット)を指します。
従来のデータ変換プロセスは、数十年にわたり企業に役立ってきました。さまざまなツールやテクノロジー(データプロファイリング、データ可視化、データクレンジング、データ統合など)は成熟し、ほとんどすべての企業が、内部および外部アプリケーション、データウェアハウス、その他のデータストアに供給される膨大な量のデータを変換しています。[ 8 ]
この従来のプロセスには、全体的な効率と有効性を妨げる限界もあります。[ 1 ] [ 2 ] [ 7 ]
データを使用する必要のある人々(ビジネスユーザーなど)は、データ変換プロセスに直接関与しません。[ 9 ]通常、ユーザーは、変換を定義してデータに対して実行するために必要なコーディングまたは技術スキルを持つ開発者にデータ変換タスクを委任します。[ 8 ]
このプロセスでは、必要な変換を定義する作業の大部分が開発者に委ねられますが、開発者はビジネスユーザーと同じドメイン知識を持っているとは限りません。開発者はビジネスユーザーの要件を解釈し、関連するコード/ロジックを実装します。これにより、(要件の誤解を通じて)プロセスにエラーが混入する可能性があり、また、解決策に到達するまでの時間も長くなります。[ 9 ] [ 10 ]
この問題により、データ統合における俊敏性とセルフサービスの必要性が生じました(つまり、データの利用者に権限を与え、対話的にデータを変換できるようにする)。[ 7 ] [ 10 ]
セルフサービス型のデータ変換ツールを提供する企業があります。これらの企業は、現在存在する技術的な知識やプロセスの複雑さを必要とせずに、大量のデータを効率的に分析、マッピング、変換することを目指しています。これらの企業は従来型のバッチ変換を使用していますが、そのツールはビジュアルプラットフォームと簡単に繰り返し実行できるスクリプトを通じて、ユーザーとのインタラクティブ性を高めています。[ 11 ]
しかし、データガバナンス、準備、監査の慣行の違いにより、互換性の問題(例えば、IoTのような新しいデータソースが古いツールと正しく動作しない可能性がある)やコンプライアンス上の制限が生じる可能性がある。[ 12 ]
対話型データ変換(IDT)[ 13 ]は、ビジネスアナリストやビジネスユーザーがビジュアルインターフェースを介して大規模なデータセットと直接対話したり[ 9 ] 、データの特性を理解したり(自動データプロファイリングや視覚化を介して)、データの特定の要素をクリックまたは選択するなどの簡単な操作でデータを変更または修正したりできる、新しい機能です。[ 2 ]
対話型データ変換はバッチデータ統合と同じデータ統合プロセス手順に従いますが、重要な違いは、手順が必ずしも直線的に実行されるわけではなく、通常は完了するために高度な技術スキルを必要としないことです。[ 14 ]
Trifacta、Alteryx、Paxataなど、インタラクティブなデータ変換ツールを提供する企業は数多く存在する。これらの企業は、大量のデータを効率的に分析、マッピング、変換すると同時に、内部で行われる技術的な複雑さやプロセスの一部を抽象化することを目指している。
対話型データ変換ソリューションは、これまで別々に行われていたデータ分析、データマッピング、コード生成/実行、データ検査といったステップを統合したビジュアルインターフェースを提供します。[ 8 ]つまり、あるステップで変更(例えば名前の変更)が行われた場合、ソフトウェアはそれに応じて前または後のステップを自動的に更新します。対話型データ変換のインターフェースには、ユーザーが誤った値や外れ値を特定できるように、データのパターンや異常を示す視覚化機能が組み込まれています。[ 9 ]
データの変換が完了すると、システムは実行可能なコード/ロジックを生成し、それを実行したり、後続の同様のデータセットに適用したりすることができる。
対話型データ変換システムは、開発者をプロセスから排除することで、データの準備と変換に必要な時間を短縮し、ユーザー要件の解釈におけるコストのかかるエラーを排除し、ビジネスユーザーとアナリストがデータを制御し、必要に応じてデータとやり取りできるようにします。[ 10 ]
データ変換を実行するための言語は数多く存在します。多くの変換言語では、文法を提供する必要があります。多くの場合、文法はバッカス・ナウア記法(BNF)によく似た構造になっています。このような目的のために利用できる言語は数多くあり、そのアクセシビリティ(コスト)や一般的な有用性は様々です。[ 15 ]このような言語の例としては、以下のようなものがあります。
さらに、TrifactaやPaxataなどの企業は、データセットのサービスと変換のためのドメイン固有変換言語(DSL)を開発しました。ドメイン固有言語の開発は、生産性の向上と非技術系ユーザーのアクセシビリティ向上と関連付けられています。[ 16 ] Trifactaの「Wrangle」は、そのようなドメイン固有言語の一例です。[ 17 ]
最近のドメイン固有変換言語のトレンドのもう 1 つの利点は、ドメイン固有変換言語が、ドメイン固有変換言語で定義されたロジックの基盤となる実行を抽象化できることです。また、同じロジックをSpark、MapReduce、Dataflowなどのさまざまな処理エンジンで利用することもできます。言い換えれば、ドメイン固有変換言語では、変換言語は基盤となるエンジンに縛られません。[ 17 ]
変換言語は通常、変換に最適ですが、正規表現のような単純なものでも有用な変換を実現できます。vim 、emacs、TextPadなどのテキストエディタは、引数付きの正規表現の使用をサポートしています。これにより、特定のパターンのすべてのインスタンスを、元のパターンの一部を使用した別のパターンに置き換えることができます。例:
foo(「some string」、42、gCommon) bar (someObj, anotherObj); foo(「別の文字列」、24、gCommon) bar (myObj, myOtherObj);
どちらも以下のようなよりコンパクトな形に変換できる。
foobar("some string", 42, someObj, anotherObj); foobar("別の文字列", 24, myObj, myOtherObj);つまり、3つの引数を持つ関数fooの呼び出しに続いて、2つの引数を持つ関数呼び出しが続くすべてのインスタンスは、元の引数セットの一部またはすべてを使用する単一の関数呼び出しに置き換えられます。
{{cite web}}: CS1 maint: 複数の名前: 著者リスト (リンク)