データパイプラインはかつて、ソースシステムからデータを引き出し、クリーンで構造化された形式に変換し、完成品をデータベースに読み込むという厳密な順序に従っていました。この順序 (抽出、変換、読み込み、つまり ETL) は、ストレージが高価で、宛先システムが大量の計算を実行するのに十分な強力さを持っていなかった時代には理にかなっていました。

しかし、クラウドウェアハウスがそのすべてを変え、ELT (抽出、読み込み、変換) が現在多くのアナリティクスチームのデフォルトのパターンになりました。従来の ETL は約 40% の市場シェアを維持していますが、ELT などの他のデータパイプラインタイプに急速に遅れをとっています。

以下では、ELT とは何か、その仕組み、およびそれが適している場合とそうでない場合について説明します。

主なポイント

• ELT (抽出、読み込み、変換) プロセスでは、最初に生データをクラウドウェアハウスに読み込み、次に変換します。これにより、アナリストはデータにすばやくアクセスでき、モデルを改善するための柔軟性が高まります。

• クラウドウェアハウスは、ストレージとコンピューティングを分離し、弾力的に拡張し、アナリストが構造化照会言語 (SQL) で変換ロジックを記述できるようにするため、ELT に適しています。

• サードパーティのインフラストラクチャーを経由せずにウェアハウスに直接同期する決済代行業者と連携することで、パイプラインの複雑さとセキュリティリスクが軽減されます。

ELT とは何か、またその仕組み

ELT (抽出、読み込み、変換) は、ソースシステムからのデータの抽出、生のまま中央の宛先への読み込み、そしてアナリティクス、レポート、または機械学習のための宛先内での変換という 3 つのステップを中心に構築されたデータ連携パターンです。

一般的な ELT ワークフローが実際にどのように機能するかを次に示します。

• 抽出: コネクターまたはパイプラインジョブがソースシステムからレコードを引き出し (増分的に、スケジュールに従って、またはイベントをトリガーとして)、元の構造のまま宛先に書き込みます。

• 読み込み: 生のテーブルは多くの場合専用のスキーマでウェアハウスに格納され、フィールド名、データ型、関係性がソースに存在していたとおりに正確に保持されます。

• 変換: 変換ロジックはウェアハウス内で実行され、data build tool (dbt) などの SQL ベースのツールにより、チームはそれらのモデルのバージョンを管理し、テストを行い、生のレイヤーの上にデータセットを構築できます。

生データが先に格納されるため、アナリストはすぐにクエリを実行でき、再度抽出することなく単一のソースから複数のダウンストリームビューを構築できます。変換モデルが間違っている場合は、それを書き直して、ウェアハウスにすでにあるデータに対して再実行します。

実際の ELT と ETL の違い

ETL と ELT のアーキテクチャーの主な違いは、変換が行われる場所です。ETL では宛先の外で、ELT では宛先の中で変換が行われます。

ETL と ELT の最大の違いは次のとおりです。

• データの可用性: ETL パイプラインでは、データが変換されて読み込まれるまでクエリを実行できません。ELT では最初に生データが格納されるため、変換ジョブが個別に実行されている間にアナリストがそのデータを操作できます。

• 改善のスピード: ETL パイプラインでの変換の変更は、多くの場合、パイプライン自体の再構築を意味します。ELT では、SQL モデルを更新し、ウェアハウスにすでにあるデータに対して再実行します。

• コンピューティングの場所: ETL 変換はパイプラインインフラストラクチャー (その目的のためにプロビジョニングした個別のサーバーまたはサービス) で実行されます。ELT 変換はデータウェアハウスのコンピューティングで実行されます。これは弾力的に拡張可能であり、すでに費用が支払われています。

• 生データの保持: ETL は通常、変換された出力が生成されると中間状態を破棄します。ELT はデフォルトで生のレイヤーを保持するため、要件が変更されたときに履歴データを再処理できます。

ELT はなぜ最新のクラウドデータウェアハウスに適しているのか？

以下の特性により、ELT はクラウドウェアハウスに最適です:

• ストレージとコンピューティングの分離: Snowflake や BigQuery などのプラットフォームでは、データの保存とクエリに対して別々に課金されます。必要なだけ生データを蓄積でき、変換ジョブは実行時にのみコンピューティングリソースを消費します。

• 柔軟なスケーリング: 必要なコンピューティングリソースを作成してジョブを実行し、その後再びリソースを減らすことができます。並列化はウェアハウスによって処理されます。

• 列指向ストレージ: クラウドウェアハウスはデータを列指向形式で保存するため、行ベースのストレージに比べて分析クエリ (大規模なデータセットの集計、フィルター、結合) が劇的に高速化されます。

• SQL ネイティブ: ほとんどのアナリストやアナリティクスエンジニアは、すでに SQL を理解しています。ウェアハウス内で変換を実行することで、ビジネスロジックを理解している担当者が変換モデルを直接記述し、管理できるようになります。

ELT が適している場合

ELT はすべてのデータパイプラインにとって正解というわけではありませんが、認識できる一連の条件に適合します。

ELT がうまく機能する傾向があるのは次のような場合です。

• 大規模または急成長しているデータセット: 1 日に何百万ものイベントを同期している場合、読み込み前に変換を実行するには大規模なパイプラインインフラストラクチャーが必要になります。生データを読み込んでウェアハウス内で変換する方が、大規模な環境では実用的です。

• 頻繁に変更される変換ロジック: 変換が SQL モデルとしてウェアハウス内に存在する場合、アナリティクスの要件を更新する際にパイプラインインフラストラクチャーを再デプロイする必要はありません。

• 複数のダウンストリームのユースケース: ウェアハウス内の生データは、ビジネスインテリジェンスのダッシュボード、機械学習の機能ストア、オペレーションレポートに同時にデータを提供できます。パイプラインを 1 つ構築し、ユーザーごとに異なるデータモデルを作成します。

• アナリティクスエンジニアリングのケイパビリティを持つチーム: ELT により、変換の所有権がアナリティクスレイヤーに移ります。dbt などのツールを使用するチームはこれに適しています。

ELT は、次のような状況には適していません。

• 生データに対する規制上の制約: 一部の医療および金融データの環境では、マスキングやフィルタリングを行う前に機密データを格納することが禁止されています。その場合、変換はアップストリームで行う必要があります。

• 厳密な宛先スキーマ: 宛先が生データや半構造化データに対応できない場合、ELT の読み込み優先アプローチは解決する以上の問題を引き起こします。

• 小規模で安定したデータセット: シンプルな ETL パイプラインで十分な場合、ウェアハウスの変換インフラストラクチャーを追加することは、メリットの少ないオーバーヘッドになります。

ELT に伴う課題

生データをウェアハウスに格納することは強力ですが、ガバナンスとコストの課題を伴う場合があります。

ELT の潜在的な課題として以下が挙げられます。

アクセス制御

生のテーブルには、個人が特定される情報 (PII)、財務記録、内部識別子など、広くアクセス可能にすべきではないデータが含まれることがよくあります。ETL では、データが宛先に到達する前に機密フィールドをマスクまたは削除できます。しかし ELT では、データが先に格納されます。行レベルのセキュリティ、列のマスキング、または厳密にスコープされたウェアハウスのロールがない場合、アナリストが表示すべきではないフィールドをクエリできる可能性があります。

データ品質

アップストリームソースからの不良データは、チェックが実行される前にウェアハウスに格納されます。dbt のテストフレームワークやウェアハウスネイティブのデータ品質機能を使用して変換レイヤーに品質テストを構築しないと、null フィールド、重複レコード、スキーマの変更、型の不一致がダウンストリームのモデルに伝播する可能性があります。

コスト管理

変換ジョブはウェアハウスのコンピューティングで実行され、記述が不十分な SQL (無制限のスキャン、パーティションフィルターの欠落、冗長なテーブル全体の更新など) は多額のコストを発生させる可能性があります。クエリコストに制限を設定し、可能な場合は増分モデルを使用し、コンピューティングの使用量を監視することは、最初からワークフローに組み込む価値があります。

ELT ワークフローにおける決済データの処理方法

多くのチームは、決済代行業者のアプリケーションプログラミングインターフェイス (API) に対してカスタムの連携を構築するか、サードパーティのコネクターを使用します。しかし、カスタムの連携では API の変更に伴う継続的なメンテナンスが必要になり、サードパーティのコネクターを使用すると、機密の財務データが追加のベンダーのインフラストラクチャーを経由することになります。

Stripe Data Pipeline は、Stripe ダッシュボードに直接組み込まれたネイティブなオプションです。数回クリックするだけで、Stripe データとレポートが Snowflake、Databricks、Amazon Redshift などに同期されます。ノーコードで、コネクターの構成や管理する個別の認証情報も必要ありません。同期は Stripe 独自のインフラストラクチャーを使用して実行されるため、転送中の財務データがサードパーティのシステムで処理されることはありません。

知っておくべきいくつかの具体事項は次のとおりです。

• 履歴の対象範囲: Stripe Data Pipeline には、同期を有効にした時点からではなく、Stripe アカウントの開始時からの履歴データが含まれます。

• スキーマ: データは Stripe のデータモデル (支払い、顧客、サブスクリプションなど) を反映したテーブルに格納されるため、生データのレイヤーを大規模にクリーンアップすることなく、その上に変換モデルを直接構築できます。

• データの完全性: 生のオブジェクトデータに加えて、Stripe Data Pipeline には事前構築された財務レポートとキュレーションされたデータセットへのアクセスが含まれており、月間経常収益 (MRR) や不正利用の分析などの一般的なユースケースにおいて、レポート作成を迅速化し、変換作業を削減できます。