ビジネスインテリジェンスツールにデータを提供したり、機械学習モデルをトレーニングしたりするためのデータパイプラインを構築する場合、最初に行うべき決定の 1 つは、データがウェアハウスに到達する前か後かという、変換が行われる場所です。つまり、抽出、変換、ロード (ETL) パイプラインと抽出、ロード、変換 (ELT) パイプラインのいずれかを選択する必要があります。

この選択により、アナリストが未加工データにどれだけ早くアクセスできるか、どこにどれだけのコンピューティングを費やしているか、データモデルが変更されたときにどれだけ簡単に適応できるかが決定されます。世界のデータパイプラインツールの市場は 2030 年までに 483.3 億ドル になると予測されており、ETL は ELT やその他の種類のパイプラインにシェアを奪われています。

以下では、各モデルの仕組み、ETL または ELT が意味を持つ場合、および特定のデータソースに対する両方のアプローチに専用のコネクターがどのように適合するかについて説明します。

主なポイント

• ETL はデータがターゲットに到達する前にデータを変換します。ELT は未加工データをロードし、ウェアハウス自身のコンピューティングを使用してウェアハウス内で変換します。

• ELT は、ほとんどの最新のデータチームにとってデフォルトのパターンです。ETL は、制約のあるターゲット、厳格なガバナンス要件、従来のパイプラインで引き続き一般的です。

• 特定のデータソース向けの専用コネクターにより、一般的なコネクターで発生することがあるデータ品質の問題のリスクを軽減できます。

ETL と ELT パイプライン: その違いは何か？

ETL は「抽出、変換、ロード」を表します。ETL モデルでは、ソースシステムからデータを引き出し、データをクリーンアップ、再形成、およびフィルタリングする変換レイヤーを通して実行し、処理された結果をデータウェアハウスやデータマートなどのターゲットにロードします。

ETL では、データがターゲットに到達する前に、別個の処理エンジンが困難な作業を実行します。ウェアハウスは、未加工のソースレコードではなく、クエリの準備が整った構造化データを受け取ります。ソースからの再処理は、再抽出するか、別の場所に別個の未加工コピーを保持することを意味します。

ELT は「抽出、ロード、変換」を表し、最後の 2 つのステップを逆にします。未加工データが最初にターゲットに到達し、その後、ウェアハウス自身のコンピューティングを使用してウェアハウス内で変換が実行されます。

この移行は、クラウドデータウェアハウスにより、大規模なデータセット全体で Structured Query Language (SQL) 変換を安価かつ高速に実行できるようになったことで実用的になりました。ソースとターゲットの間に別個の変換エンジンを配置するのではなく、ウェアハウスが変換環境になります。

ETL の仕組み

ETL パイプラインは 3 つの段階で実行され、それぞれに異なる責任があります。

ETL の仕組みは次のとおりです。

• 抽出: コネクターまたは取り込みジョブは、データベース、支払いアプリケーションプログラミングインターフェイス (API)、サービスとしてのソフトウェア (SaaS) プラットフォーム、またはフラットファイルなどのソースからデータを引き出します。このステップでは、認証、ページネーション、増分と完全な更新のロジック、およびレート制限が処理されます。

• 変換: 抽出されたデータは処理レイヤーに移動し、そこでクリーンアップ (null の処理、タイプのキャストなど)、再形成 (結合、集計、列の名前変更など)、フィルタリングが行われ、場合によっては他のソースからの参照データで強化されます。

• ロード: 処理されたデータセットは、パイプラインの設定方法に応じて、完全な上書き、アップサート、または追加としてターゲットにロードされます。

ETL は、次の特定の状況で引き続き使用する意味があります。

• 制約のあるターゲット: コンピューティングが制限されている古いデータウェアハウスやオンプレミスシステムは、大規模な変換を所定の場所で効率的に実行できないため、事前変換されたデータをロードすることが唯一の現実的なオプションです。

• 厳格なガバナンス要件: 組織によっては、個人が特定される情報または機密性の高い財務データが未加工の形でウェアハウスに到達しないようにする必要があります。アップストリームでの変換とマスキングにより、アーキテクチャ上でその要件を満たします。

• エッジ環境: データを中央インフラストラクチャーに追加するモノのインターネット (IoT) や組み込みシステムは、未加工の大規模なペイロードを送信できないことが多く、送信前のローカル変換が実質的に必要になります。

• 従来のパイプラインの負債: 多くの成熟した組織には、何年にもわたって確実に実行されてきた ETL パイプラインがあります。それらを ELT として再構築することにはリスクが伴い、その価値がない場合があります。

ELT の仕組み

ELT パイプラインは、未加工または軽くフォーマットされたソースデータを抽出して、直接ターゲットにロードします。変換はその後、スケジュールまたはオンデマンドで、ウェアハウス自身のコンピューティングを使用して実行されます。

たとえば、コネクターはソースからデータを抽出し、ウェアハウスの未加工のスキーマに書き込むことができます。アナリティクスエンジニアは、その未加工のスキーマから読み取り、ビジネスロジックを適用して、ビジネスインテリジェンス (BI) ツールがクエリできるクリーンなテーブルを作成する data build tools (dbt) モデルを記述します。ロジックを変更する必要がある場合は、モデルを更新して、すでに存在するデータに対して再度実行するだけです。

ELT は以下の理由から賢明な選択です。

• 未加工データへのより迅速なアクセス: データはウェアハウスにすぐに到達するため、変換レイヤーが完了する前に、チームはデータの調査と検証を開始できます。

• より安価な改善: ETL で変換を変更することは、多くの場合、パイプラインの変更、再処理、再ロードを意味します。ELT では、SQL モデルを更新し、すでにあるデータに対して再度実行するだけです。

• ウェアハウス規模のコンピューティング: クラウドウェアハウスは大規模なデータセットを高速で処理するように構築されています。つまり、別個のミドルウェアレイヤーを独立して拡張するのではなく、本格的なコンピューティングを変換に適用していることになります。

• 完全な未加工の履歴: 未加工データは常にウェアハウスにあるため、ダウンストリームのテーブルを最初から再度派生させることができます。これは、ビジネス定義が変更された場合や、データ品質の問題をデバッグする必要がある場合に重要です。

ETL と ELT をどのように選択するか

大規模な組織では通常、異なるソースに対して両方のデータ処理モデルを並行して実行します。組織のニーズにより、どちらの方法が適しているかが決まります。

考慮すべき事項は以下のとおりです。

データの量と速度

大量で高頻度のデータは、一般に ELT データパイプラインに適しています。クラウドウェアハウスはこれらを適切に処理でき、上流で重い変換エンジンを実行するコストは急速に増加します。トレードオフとして、変換が重い場合はウェアハウスのコンピューティング費用が増加し、生データの保存にはコストがかかります。

変換ロジックが安定して明確に定義されている少量のパイプラインであれば、問題なく ETL を維持できます。

変換のオーナーシップ

変換が SQL ベースであり、迅速な適応が求められるアナリティクスエンジニアによって管理されている場合、dbt や類似のツールを使用した ELT が適していると考えられます。

変換が Python や Java でコード化され、データエンジニアリングチームによって管理されている場合、ETL は既存のツールチェーンに自然に適合する可能性があります。

生データへのアクセス

アナリストが生のソースデータにアクセスする必要がある場合 (アドホックな調査、監査、または変換ロジックがまだ開発中であるなどの理由から)、ELT をデフォルトの選択肢とすることをお勧めします。生データを保持しない ETL パイプラインでは、そのようなアクセスを後から組み込むことは困難です。

ガバナンスとコンプライアンス

共有の宛先に到達する前に特定のデータをマスキングまたは匿名化する必要がある場合、ETL により、その要件をアーキテクチャー上で強制できます。

ELT でも列レベルのセキュリティとウェアハウスレベルのアクセス制御により、同じ要件の多くを満たすことができます。ただし、実装方法は異なるため、コンプライアンス義務に照らして検討する価値があります。

チームのワークフロー

dbt を中心とした高度な SQL スキルとバージョン管理の習慣を持つチームであれば、構築に関与していないカスタム ETL パイプラインを維持するよりも、ELT のセットアップから多くの価値を引き出すことができます。チームの働き方との互換性は、重要な要素です。

データコネクターは ETL および ELT パイプラインにどのように適合するか？

一般的な ETL および ELT ツールは、設定可能なコネクターを通じて幅広いソースを処理します。この広範さは有用ですが、トレードオフが伴います。

支払いデータが良い例です。Stripe のデータモデルは、イベント、支払い、返金、不審請求の申請、残高取引、顧客、サブスクリプション、インボイスをカバーしています。Stripe の API のバージョン管理に対応していない、または増分同期ロジックを不正確に処理する一般的なコネクターは、ダッシュボードや財務の消込に影響を与えるまで捕捉が困難なエラーを生成する可能性があります。

Stripe Data Pipeline はこれに直接対処します。

• Stripe による構築と保守: Stripe がコネクターを所有し、社内の Stripe インフラストラクチャーを直接ミラーリングするため、データの量や API のレート制限に関係なく、完全性と正確性を確保しながら継続的かつ確実にデータを同期できます。

• ウェアハウスへの直接同期: データはサードパーティのコネクターを経由せずに Amazon Redshift、Snowflake、Databricks などに移動するため、機密性の高い財務データが追加のベンダーのインフラストラクチャーから除外されます。

• 完全な Stripe データセット: 同期は Stripe オブジェクト、構築済みの財務レポート、および厳選されたデータセットをカバーし、分析とレポートを加速させます。

• 軽量なセットアップ: 接続は Stripe ダッシュボードで設定され、ノーコードで完了します。他のソースに対してすでに ELT パイプラインを実行している場合、Stripe データは同じパターンに分類されます。