Extract、Transform、Load（ETL）は、1つ以上のソースからデータを統合し、データウェアハウス、データレイク、運用データストアなどのターゲットデータコンテナに取り込むために使用される3段階のコンピューティングプロセスです。このプロセスには、ソースシステムからの生データの抽出、クリーニングと再構築による変換、宛先へのロードが含まれます。ETLは通常、ソフトウェアアプリケーションによって自動化されますが、システムオペレーターが手動で実行することも可能です。これはデータウェアハウジングにおける基礎的な技術であり、クラウドベースおよびリアルタイムストリーミングのシナリオをサポートするように進化してきました。
ETLシステムは、データ品質と一貫性を強制するように設計されています。異種ソースからデータを抽出し、検証および変換ルールを適用し、出力がターゲットスキーマに準拠していることを保証します。適切に設計されたETLパイプラインは、プレゼンテーション用に準備されたデータを提供でき、アプリケーション開発者やエンドユーザーが追加処理なしで意思決定を行えるようにします。このプロセスは、異なるベンダーによって開発されたり、別々のハードウェアでホストされたり、異なるステークホルダーによって管理されることが多い複数のアプリケーションからのデータを組み合わせるためによく使用されます。例えば、原価計算システムは、給与、販売、購買システムからのデータを統合する場合があります。
フェーズ
ETLは、抽出、変換、ロードの3つの明確なフェーズで構成されます。各フェーズには特定の目的と課題があり、これらが連携してソースから宛先へデータを移動するパイプラインを形成します。
抽出
抽出フェーズでは、ソースシステムからデータを取得します。これは多くの場合、最も重要なステップであり、データを正しく抽出することで下流のプロセスの基盤が整います。ソースには、リレーショナルデータベース、フラットファイル、XML、JSON、IBM Information Management Systemなどの非リレーショナル構造、またはVirtual Storage Access Method（VSAM）やIndexed Sequential Access Method（ISAM）などの形式が含まれます。データは、ウェブクローラーやデータスクレイピングを介して外部ソースから取得されることもあります。場合によっては、ETLは中間ストレージなしでソースから宛先へ直接データをストリーミングできます。
抽出の本質的な部分はデータ検証であり、データがパターン、デフォルト、リストなどの所定のドメイン内で期待される値を持っているかどうかをチェックします。データが検証ルールに失敗した場合、完全に拒否されるか、部分的に拒否されることがあります。拒否されたデータは、理想的には分析と修正のためにソースシステムに報告されます。このプロセスは、データラングリングと呼ばれることもあります。
変換
変換フェーズでは、抽出されたデータに一連のルールまたは関数を適用して、ロード用に準備します。データクレンジングは主要な機能であり、適切なデータのみがターゲットに渡ることを保証します。異なるシステムが互換性のない文字セットや形式を使用する場合に課題が生じます。一般的な変換タイプには以下が含まれます：
- ロードする特定の列のみを選択する、または欠損値のあるレコードを無視する。
- コード値を変換する（例：性別コードを「1」/「2」から「M」/「F」に変換）。
- 自由形式の値をエンコードする（例：「Male」を「M」にマッピング）。
- 新しい計算値を導出する（例：sale_amount = qty * unit_price）。
- 検索パフォーマンスを向上させるためにデータをソートする。
- 複数のソースからのデータを結合し、レコードを重複排除する。
- データを集約する（例：店舗または地域ごとの総売上を要約）。
- サロゲートキー値を生成する。
- データを転置またはピボットし、列を分割する、または繰り返し列を分解する。
- 参照テーブルからデータをルックアップして検証する。
検証の失敗は、ルール設計と例外処理に応じて、完全拒否、部分拒否、または拒否なしにつながる可能性があります。多くの変換では、コード変換が不明なコードに遭遇した場合など、例外が発生する可能性があります。
ロード
ロードフェーズでは、変換されたデータをターゲットに挿入します。ターゲットは、単純な区切りフラットファイルまたは複雑なデータウェアハウスである場合があります。プロセスは組織の要件によって異なります。一部のウェアハウスは、累積データで既存の情報を上書きします。これは多くの場合、毎日、毎週、または毎月のスケジュールで行われます。他のウェアハウスは、毎時など、定期的な間隔で履歴形式の新しいデータを追加します。例えば、過去1年間の販売記録を維持するウェアハウスは、1年以上前のデータを上書きし、現在の年のデータを履歴形式で保持する場合があります。置換または追加のタイミングと範囲は、時間とビジネスニーズに応じた戦略的な選択です。より複雑なシステムは、すべての変更の履歴と監査証跡を維持できます。
ロード中は、スキーマで定義されたデータベース制約（一意性、参照整合性、必須フィールドなど）が適用されます。データロード時にアクティブ化されるトリガーもこれらのルールを強制し、無効なレコードの拒否につながる可能性があります。
バリアントと最新の使用法
ETLには、ELT（抽出、ロード、変換）と呼ばれるバリアントがあり、データは変換前にターゲットにロードされます。このアプローチは、ターゲットシステムが強力な処理能力を持つクラウドベースのデータウェアハウジングでますます使用されています。ETLとELTの両方が、バッチ処理だけでなく、リアルタイムストリーミングシナリオにも適用され、ほぼ即時のデータ統合を可能にします。
最新のETLツールは、Amazon Web Services、Azure、Google Cloudなどのクラウドプラットフォームをサポートすることが多く、多様なソースからの大量のデータを処理できます。人工知能と機械学習の台頭もETLに影響を与えており、データパイプラインがますます分析およびモデルトレーニングシステムにフィードされるようになっています。
課題とベストプラクティス
効果的なETLシステムの設計には、慎重な計画が必要です。主な課題には、データ品質の問題の処理、スキーマ変更の管理、大規模なパフォーマンスの確保が含まれます。ベストプラクティスには以下が含まれます：
- 明確なデータ検証ルールと例外処理を定義する。
- 保守性のために変換ロジックを文書化する。
- 増分ロードを使用して処理時間を短縮する。
- ETLジョブを障害とパフォーマンスのボトルネックについて監視する。
- 抽出およびロード中のデータセキュリティとコンプライアンスを確保する。
ETLは、データ統合戦略の重要なコンポーネントであり、運用システムと分析環境の間のギャップを埋めます。データ量が増加し、ソースが多様化するにつれて、ETLプロセスは進化を続け、最新の需要を満たすためにストリーミングおよびクラウドネイティブ技術を組み込んでいます。