Loading article…
抽出、変換、ロード（ETL ）は、入力ソースからデータを抽出し、変換（クリーニングを含む）を行い、出力データコンテナにロードする3段階のコンピューティングプロセスです。データは1つまたは複数のソースから収集でき、1つまたは複数の出力先に出力できます。ETL処理は通常、ソフトウェアアプリケーションを使用して実行されますが、システムオペレーターが手動で行うことも可能です。ETLソフトウェアは通常、プロセス全体を自動化し、手動または定期的なスケジュールで、単一のジョブとして、あるいは複数のジョブをまとめてバッチ処理として実行できます。
適切に設計されたETLシステムは、ソースシステムからデータを抽出し、データ型とデータ妥当性の基準を適用し、出力の要件に構造的に適合することを保証します。一部のETLシステムは、アプリケーション開発者がアプリケーションを構築し、エンドユーザーが意思決定を行えるように、プレゼンテーションに適した形式でデータを提供することもできます。[ 1 ]
ETLプロセスはデータウェアハウスでよく使用されます。[ 2 ] ETLシステムは、通常、異なるベンダーによって開発およびサポートされている、または別のコンピュータハードウェアでホストされている複数のアプリケーション（システム）からのデータを統合します。元のデータを含む個別のシステムは、多くの場合、異なる利害関係者によって管理および運用されます。たとえば、原価計算システムは、給与、販売、および購買からのデータを組み合わせることができます。
データ抽出は、同種または異種のソースからデータを抽出することを含みます。データ変換は、クエリと分析の目的で、データのクリーニングと適切なストレージ形式/構造への変換によってデータを処理します。最後に、データロードは、運用データストア、データマート、データレイク、データウェアハウスなどの最終的なターゲットデータベースへのデータの挿入について説明します。[ 3 ] [ 4 ]
ETLとその派生技術であるELT（抽出、ロード、変換）は、クラウドベースのデータウェアハウスにおいてますます広く利用されるようになっている。その用途は、バッチ処理だけでなく、リアルタイムストリーミングにも及ぶ。
ETL処理では、ソースシステムからデータを抽出します。多くの場合、これはETLの最も重要な側面であり、データを正しく抽出することで、後続の処理が成功するための基盤が整います。ほとんどのデータウェアハウスプロジェクトでは、異なるソースシステムからのデータを組み合わせます。各システムは、異なるデータ構成やフォーマットを使用する場合もあります。[ 5 ]一般的なデータソースフォーマットには、リレーショナルデータベース、フラットファイルデータベース、XML、JSONなどがありますが、 IBM Information Management Systemなどの非リレーショナルデータベース構造や、 Virtual Storage Access Method (VSAM)やIndexed Sequential Access Method (ISAM)などの他のデータ構造、あるいはWebクローラーやデータスクレイピングなどの手段で外部ソースから取得したフォーマットも含まれる場合があります。[ 5 ]中間データストレージが不要な場合、抽出したデータソースをストリーミングして、オンザフライで宛先データベースにロードすることも、ETLを実行するもう1つの方法です。[ 6 ]
抽出の本質的な部分として、ソースから取得したデータが特定のドメイン（パターン/デフォルト値や値のリストなど）で正しい/期待される値を持っているかどうかを確認するデータ検証があります。データが検証ルールに違反した場合、データは全体または一部が拒否されます。[ 7 ]拒否されたデータは、理想的にはソースシステムに報告され、さらに分析して誤ったレコードを特定して修正したり、データラングリングを実行したりします。
データ変換段階では、抽出されたデータに対して一連のルールまたは関数が適用され、最終ターゲットへのロードの準備が行われます。[ 5 ] [ 6 ]
変換の重要な機能の1つはデータクレンジングであり、これは「適切な」データのみをターゲットに渡すことを目的としています。異なるシステムが相互作用する場合の課題は、関連システムのインターフェースと通信にあります。あるシステムで使用可能な文字セットが、他のシステムでは使用できない場合があります。[ 8 ]
その他の場合、サーバーまたはデータウェアハウスのビジネスおよび技術的なニーズを満たすために、次の変換タイプの 1 つ以上が必要になる場合があります。[ 9 ]
sale_amount = qty * unit_price。ロードフェーズでは、データを最終ターゲットにロードします。最終ターゲットは、単純な区切り文字付きフラットファイルやデータウェアハウスなど、あらゆるデータストアです。組織の要件に応じて、このプロセスは大きく異なります。データウェアハウスによっては、既存の情報を累積情報で上書きする場合があります。抽出されたデータの更新は、日次、週次、または月次で行われることがよくあります。他のデータウェアハウス（または同じデータウェアハウスの他の部分）では、新しいデータを履歴形式で定期的に（たとえば1時間ごと）追加する場合があります。これを理解するには、前年の売上記録を保持する必要があるデータウェアハウスを考えてみましょう。このデータウェアハウスは、1年以上前のデータを新しいデータで上書きします。ただし、任意の1年間のデータ入力は履歴形式で行われます。置き換えまたは追加するタイミングと範囲は、利用可能な時間とビジネスニーズに応じて戦略的に決定されます。より複雑なシステムでは、データウェアハウスにロードされたデータへのすべての変更の履歴と監査証跡を保持できます。ロードフェーズがデータベースとやり取りする際、データベーススキーマで定義された制約、およびデータロード時にアクティブ化されるトリガーで定義された制約（例えば、一意性、参照整合性、必須フィールドなど）が適用され、これらはETLプロセスの全体的なデータ品質パフォーマンスにも貢献します。
実際のETLサイクルには、例えば以下のような追加の実行ステップが含まれる場合があります。
ETLプロセスは非常に複雑になる可能性があり、ETLシステムの設計が不適切だと、重大な運用上の問題が発生する可能性がある。
運用システムにおけるデータ値の範囲やデータ品質は、検証ルールや変換ルールを策定する時点での設計者の想定を超える場合があります。データ分析中にソースのデータプロファイリングを行うことで、変換ルール仕様で管理する必要のあるデータ条件を特定でき、ETLプロセスで明示的または暗黙的に実装されている検証ルールの修正につながります。
データウェアハウスは通常、さまざまな形式や目的を持つ多様なデータソースから構築されます。そのため、ETL（抽出、変換、ロード）は、すべてのデータを標準化された均質な環境に統合するための重要なプロセスとなります。
設計分析[ 10 ]では、サービスレベル契約内で処理する必要のあるデータ量を理解することを含め、ETLシステムのライフサイクル全体にわたる拡張性を確立する必要があります。ソースシステムからデータを抽出するために利用できる時間は変化する可能性があり、同じ量のデータをより短い時間で処理する必要があるかもしれません。一部のETLシステムは、数十テラバイトのデータでデータウェアハウスを更新するために、テラバイトのデータを処理するように拡張する必要があります。データ量の増加に伴い、日次バッチから複数日マイクロバッチ、メッセージキューとの統合、または継続的な変換と更新のためのリアルタイム変更データキャプチャまで拡張できる設計が必要になる場合があります。
一意キーは、すべてのリレーショナルデータベースにおいて重要な役割を果たします。一意キーは、すべての要素を結びつけるからです。一意キーは、特定のエンティティを識別する列であり、外部キーは、別のテーブルにある主キーを参照する列です。キーは複数の列で構成される場合があり、その場合は複合キーと呼ばれます。多くの場合、主キーは自動生成される整数であり、表現されるビジネスエンティティには意味を持ちませんが、リレーショナルデータベースのためだけに存在します。これは一般的にサロゲートキーと呼ばれます。
データウェアハウスには通常、複数のデータソースがロードされるため、キーは重要な検討事項となります。例えば、顧客は複数のデータソースに存在し、あるソースでは社会保障番号が主キー、別のソースでは電話番号、さらに別のソースでは代替キーとして扱われる場合があります。しかし、データウェアハウスでは、すべての顧客情報を1つの次元に統合する必要があるかもしれません。
この懸念に対処する推奨方法は、ファクトテーブルからの外部キーとして使用されるウェアハウスサロゲートキーを追加することです。[ 11 ]
通常、ディメンションのソースデータに更新が発生すると、その更新内容はデータウェアハウスに反映されなければなりません。
ソースデータの主キーがレポート作成に必要な場合、ディメンションには既に各行のその情報が含まれています。ソースデータがサロゲートキーを使用している場合、クエリやレポートでは決して使用されないにもかかわらず、ウェアハウスはそれを追跡する必要があります。これは、ウェアハウスのサロゲートキーと元のキーを含むルックアップテーブルを作成することによって行われます。 [ 12 ]この方法で、ディメンションはさまざまなソースシステムからのサロゲートで汚染されることなく、更新機能が維持されます。
ルックアップテーブルは、ソースデータの性質に応じてさまざまな方法で使用されます。考慮すべきタイプは 5 つあります。[ 12 ]ここでは 3 つを紹介します。
ETLベンダーは、複数のCPU、複数のハードドライブ、複数のギガビットネットワーク接続、そして大量のメモリを搭載した高性能サーバーを使用し、レコードシステムを毎時数テラバイト（約1GB/秒）の処理能力でベンチマークテストしている。
実際のETLプロセスでは、通常、データベースロードフェーズが最も時間がかかります。データベースは、同時実行性、整合性の維持、インデックスの処理などを行う必要があるため、パフォーマンスが低下する可能性があります。したがって、パフォーマンスを向上させるには、以下の方法を採用するのが有効です。
しかし、一括操作を使用しても、ETLプロセスでは通常、データベースアクセスがボトルネックとなります。パフォーマンスを向上させるために一般的に用いられる方法には、以下のようなものがあります。
nullパーティショニングを歪める可能性のある値に注意してください）。disable constraintdisable triggerdrop index... ; create index...）。特定の操作をデータベース内で行うか外部で行うかは、トレードオフを伴う場合があります。たとえば、重複レコードの削除はdistinctデータベース内では処理が遅くなる可能性があるため、外部で行う方が理にかなっています。一方、distinct重複レコードの削除によって抽出する行数が大幅に（100倍）減少する場合は、データのアンロード前にデータベース内でできるだけ早い段階で重複レコードを削除する方が理にかなっています。
ETLにおける一般的な問題の原因の一つは、ETLジョブ間の依存関係が多数存在することです。例えば、ジョブ「A」が完了するまでジョブ「B」を開始できないといったケースです。通常、すべてのプロセスをグラフ上に可視化し、並列処理を最大限に活用してグラフを縮小し、連続処理の「連鎖」をできるだけ短くすることで、パフォーマンスを向上させることができます。また、大きなテーブルとそのインデックスをパーティショニングすることも非常に有効です。
もう一つのよくある問題は、データが複数のデータベースに分散していて、それらのデータベースで処理が順次行われる場合に発生します。データベース間でデータをコピーする方法としてデータベースレプリケーションが使用される場合もありますが、これは処理全体を著しく遅くする可能性があります。一般的な解決策は、処理グラフをわずか3層に縮小することです。
このアプローチにより、処理は並列処理を最大限に活用できます。たとえば、2つのデータベースにデータをロードする必要がある場合、ロード処理を並列で実行できます（最初のデータベースにロードしてから2番目のデータベースに複製するのではなく）。
処理は、場合によっては順次実行する必要があります。たとえば、メインの「ファクト」テーブルの行を取得して検証する前に、ディメンション（参照）データが必要になります。
一部のETLソフトウェア実装には並列処理機能が含まれています。これにより、大量のデータを扱う際にETLの全体的なパフォーマンスを向上させるための様々な手法が可能になります。
ETLアプリケーションは、主に3種類の並列処理を実装しています。
これら3種類の並列処理は、通常、単一のジョブまたはタスク内で組み合わされて動作します。
もう一つの難点は、アップロードされるデータの一貫性を確保することです。複数のソースデータベースは更新サイクルが異なる場合があり（数分ごとに更新されるものもあれば、数日または数週間かかるものもある）、すべてのソースが同期されるまで特定のデータを保留するETLシステムが必要になる場合があります。同様に、データウェアハウスをソースシステムの内容や総勘定元帳と照合する必要がある場合、同期および照合ポイントを設定する必要が生じます。
データウェアハウスの手順では、通常、大規模なETLプロセスを、順次または並列で実行される小さな部分に分割します。データフローを追跡するために、各データ行に「row_id」を、プロセスの各部分に「run_id」をタグ付けするのが合理的です。障害が発生した場合、これらのIDがあれば、失敗した部分をロールバックして再実行するのに役立ちます。
ベストプラクティスでは、プロセスの特定の段階が完了した時点の状態であるチェックポイントを設定することも推奨されています。チェックポイントに到達したら、すべてのデータをディスクに書き込み、一時ファイルを削除し、状態をログに記録するなどするのが良いでしょう。
確立された ETL フレームワークは、接続性と拡張性を向上させる可能性があります。優れた ETL ツールは、組織全体で使用されているさまざまなリレーショナル データベースと通信し、さまざまなファイル フォーマットを読み取ることができなければなりません。ETL ツールは、エンタープライズ アプリケーション統合、さらにはエンタープライズ サービス バスシステムへと移行し始めており、これらのシステムは現在、データの抽出、変換、ロードだけにとどまらず、はるかに多くの機能をカバーしています。多くの ETL ベンダーは現在、データ プロファイリング、データ品質、メタデータ機能を備えています。ETL ツールの一般的なユース ケースには、CSVファイルをリレーショナル データベースで読み取り可能なフォーマットに変換することが含まれます。数百万件のレコードの典型的な変換は、ユーザーが CSV のようなデータ フィード/ファイルを入力し、できるだけ少ないコードでデータベースにインポートできるようにする ETL ツールによって容易になります。
ETLツールは、コンピュータサイエンスを専攻する学生が大規模なデータセットを迅速にインポートする場合から、企業のアカウント管理を担当するデータベースアーキテクトまで、幅広い専門家によって利用されています。ETLツールは、最大限のパフォーマンスを実現するために頼りになる便利なツールとなっています。多くの場合、ETLツールにはGUIが搭載されており、ユーザーがビジュアルデータマッパーを使用してデータを簡単に変換できます。これにより、ファイルを解析してデータ型を変更する大規模なプログラムを作成する必要がなくなります。
ETLツールは従来、開発者やITスタッフ向けのものでしたが、調査会社Gartnerは、ITスタッフに頼るのではなく、必要に応じてビジネスユーザーが自ら接続やデータ統合を作成できるように、これらの機能をビジネスユーザーに提供することが新たなトレンドになっていると述べています。[ 13 ] Gartnerは、こうした非技術系のユーザーを「市民インテグレーター」と呼んでいます。[ 14 ]
オンライン トランザクション処理(OLTP) アプリケーションでは、個々の OLTP インスタンスからの変更が検出され、更新のスナップショットまたはバッチに記録されます。ETL インスタンスを使用すると、これらのバッチを定期的に収集し、共通の形式に変換して、データ レイクまたはデータ ウェアハウスにロードできます。[ 1 ]
データ仮想化は、 ETL処理の高度化に活用できます。ETLにデータ仮想化を適用することで、複数の分散データソースにおけるデータ移行やアプリケーション統合といった、ETLで最も一般的なタスクを解決できます。仮想ETLは、多様なリレーショナルデータ、半構造化データ、非構造化データソースから収集されたオブジェクトやエンティティの抽象化された表現を用いて動作します。ETLツールはオブジェクト指向モデリングを活用し、中央に配置されたハブアンドスポークアーキテクチャに永続的に保存されたエンティティの表現を操作できます。ETL処理のためにデータソースから収集されたエンティティやオブジェクトの表現を含むこのようなコレクションはメタデータリポジトリと呼ばれ、メモリ上に存在させることも、永続化することも可能です。永続的なメタデータリポジトリを使用することで、ETLツールは単発プロジェクトから永続的なミドルウェアへと移行し、データ統合とデータプロファイリングをほぼリアルタイムで一貫して実行できます。
抽出、ロード、変換(ELT) は、抽出されたデータが最初にターゲットシステムにロードされる ETL の一種です。[ 15 ]分析パイプラインのアーキテクチャでは、データのクレンジングとエンリッチメントを行う場所[ 15 ]や、ディメンションをどのように整合させるかも考慮する必要があります。[ 1 ] ELT プロセスの利点には、スピードと、非構造化データと構造化データの両方をより簡単に処理できる能力などがあります。[ 16 ]
データウェアハウスにおけるETLプロセスを教えるコースの教科書として使用されているラルフ・キンボールとジョー・カセルタの著書『 The Data Warehouse ETL Toolkit 』（Wiley、2004年）はこの問題を取り上げています。 [ 17 ]
Amazon Redshift、Google BigQuery、Microsoft Azure Synapse Analytics、Snowflakeといったクラウドベースのデータウェアハウスは、高い拡張性を備えたコンピューティング能力を提供します。これにより、企業は事前変換処理を省略し、生データをデータウェアハウスに複製して、必要に応じてSQLを使用して変換処理を行うことができます。
ELTを使用した後、データはさらに処理され、データマートに保存される可能性があります。[ 18 ]
ほとんどのデータ統合ツールはETLに偏っていますが、ELTはデータベースやデータウェアハウスアプライアンスでよく使われています。同様に、TEL（変換、抽出、ロード）を実行することも可能で、データはまずブロックチェーン上で変換され（トークンの焼却など、データの変更を記録する方法として）、その後別のデータストアに抽出およびロードされます。[ 19 ]
{{cite web}}: CS1 maint: url-status (リンク){{cite web}}: CS1 maint: url-status (リンク)