ELT プロセスフローは、最新のデータ ストレージと処理プラットフォームの能力とスケーラビリティを活用します。各コンポーネントを詳しく見ていきましょう。

• 抽出: この最初のステップでは、元データを元のソースから収集します。これらのソースは、データベース（SQL および NoSQL）、エンタープライズ アプリケーション（CRM や ERP など）、SaaS プラットフォーム、API、ログファイルなど、非常に多様です。抽出プロセスでは、これらのシステムからデータを効率的に取り出すことに重点を置きます。
• 読み込み: 2 番目のステップでは、抽出された元データが、多くの場合元の形式のまま、または最小限の処理で、大容量のストレージ システムに直接読み込まれます。この元データの一般的なターゲットは、大量の構造化データ、半構造化データ、非構造化データを処理できるクラウド データレイクまたは最新のクラウド データ ウェアハウスです。
• 変換: この最後のステップは、データがターゲット システムに安全に格納された後に行われます。データ ウェアハウスまたはデータレイクのコンピューティング能力を使用して、元データをクリーンアップ、構造化、拡充し、分析、レポート、機械学習に適した形式に変換します。変換には、フィルタリング、結合、集計、形式の標準化、新しいデータポイントの導出などがあります。

ELT プロセスでは、読み込み前に変換が固定されないため、柔軟性が得られます。たとえば、データ サイエンティストは元データにアクセスして予期せぬパターンを探索したり、アドホックな分析を行ったりできます。一方、ビジネス インテリジェンス チームは、レポート用にキュレートされた変換済みデータセットを構築できます。

ELT アプローチには、特に大量のデータや多様なデータ型を扱う環境において、いくつかの潜在的な利点があります。

• データ取り込みの高速化: ステージング領域で変換が完了するのを待つよりも、ターゲット システムに元データを読み込む方が一般的に高速です。つまり、初期探索や特定のユースケースでデータをより早く利用できるようになります。
• 柔軟性とアジリティ: 元データはターゲット システムに保持されるため、ビジネス要件の進化に合わせて変換を反復的に開発、変更、追加できます。変換ロジックが変更された場合でも、ソースシステムからデータを再取り込みする必要はありません。すでに読み込まれている元データに対して変換を再実行するだけです。
• スケーラビリティ: 最新のクラウド データ ウェアハウスとデータレイクは、大規模なスケーラビリティに対応できるように設計されています。ELT は、これらのターゲット システムの堅牢な処理エンジンを使用して変換を実行することで、この固有の機能を活用します。これにより、組織は増大するデータ量と複雑な変換を効率的に処理できます。
• 元データの保持: 元データを保存することで、より完全な履歴レコードを保持できます。これは、データの監査、以前の変換でエラーが見つかった場合の再処理、まだ予測されていない将来の分析ニーズに非常に役立ちます。データ サイエンティストは、最も粒度の細かい、変換されていないデータにアクセスできると、多くの場合メリットがあります。
• 特定のワークロードの費用対効果: 変換にクラウド データ ウェアハウスのコンピューティング能力を使用すると、特にデータ ウェアハウスが最適化された処理を提供する場合は、個別のインフラストラクチャを維持したり、変換用の専用 ETL ツールのライセンスを取得したりするよりも費用対効果が高くなることがあります。
• 多様なデータタイプのサポート: ELT は、構造化データ、半構造化データ（JSON や XML など）、非構造化データ（テキストや画像など）の処理に適しています。データはネイティブ形式で読み込み、必要に応じて変換できます。これは、ビッグデータ シナリオでは大きな利点となります。読み込み前ではなく処理中に構造を適用するこの「スキーマオンリード」アプローチが、ELT の特徴です。

ELT にはいくつかのメリットがありますが、組織が対処すべき特定の考慮事項もあります。

• データ ガバナンスとセキュリティ: 機密情報や個人を特定できる情報（PII）が含まれている可能性のある元データをデータレイクやデータ ウェアハウスに読み込むには、堅牢なデータ ガバナンス、セキュリティ、コンプライアンス対策が必要です。アクセス制御、暗号化、データ マスク手法は、移行先の環境内でこのデータを保護するために不可欠です。
• ターゲット システム内での変換の複雑さ: データ ウェアハウス（SQL を使用するなど）やデータレイク内で直接複雑な変換ロジックを管理することは、強力ではあるものの、困難になる可能性があります。これらのツールに精通した熟練した人材と、コードの管理と最適化に対する規律あるアプローチが必要です。
• ツールとオーケストレーション: 効果的な ELT の実装は、抽出と読み込みのステップをオーケストレートし、ターゲット システム内で変換を管理および実行するための適切なツールに依存します。多くのクラウド プラットフォームでツールが提供されていますが、それらを統合してワークフロー全体を管理するには、慎重な計画が必要です。
• 「データスワンプ」になる可能性: データレイクに読み込まれた元データが適切にカタログ化、管理、統制されていない場合、データレイクは「データスワンプ」になり、データを見つけにくく、信頼性が損なわれたり、効果的に使用するのが難しくなったりする可能性があります。強力なデータ マネジメント戦略が不可欠です。
• データ品質の責任: 変換はプロセスの後半で行われるため、データ品質を確保するには、読み込み後に専用のステップが必要になる場合があります。ターゲット システム内のデータのモニタリングと検証が重要になります。

こうした課題に事前に対処することで、組織は ELT パラダイムの利点を最大限に活用できます。

適切なデータ統合戦略を選択するには、ELT と、より従来型の ETL（抽出、変換、読み込み）プロセスの違いを理解することが重要です。主な違いは、変換ステップがどのタイミングで発生し、どこで実行されるかです。

ELT は、Google Cloud が推奨するデータ統合パターンです。ELT では、ソースシステムからデータを抽出し、BigQuery に読み込み、分析に使用する形式に変換します。データをデータ ウェアハウスに読み込む前に変換する ETL（抽出、変換、読み込み）とは異なり、ELT アプローチでは、BigQuery の機能をフル活用してデータ変換を実施し、SQL ユーザーがデータ統合パイプラインを効果的に開発することができます。

ELT と ETL のどちらを選ぶかは、多くの場合、具体的なユースケース、既存のインフラストラクチャ、データ量、組織の分析ニーズによって異なります。多くの最新のデータ アーキテクチャでは、パイプラインの異なる部分に ELT と ETL の両方を使用するハイブリッド アプローチも採用されています。