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

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

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 の両方を使用するハイブリッド アプローチも採用されています。