ブログ著者:Clive Bearman  本ブログはShould I Use ETL or ELT In My Data Pipelines? の翻訳になります。

世の中には何世紀にもわたって情熱的に議論されてきた多くの哲学的な問題があります。いわく、ニワトリと卵、どちらが先か?コーラはペプシより美味しいのか?カクテルドレスは青か金か?そして、ハン・ソロが先に撃ったのか否か?しかし、テクノラティを分断する長きにわかる問題は次のようなものでしょう。”データ・パイプラインにETLとELTのどちらを使うべきか?”

この記事ではその論争に終止符を打とうと思います。

基本に戻る

任意のデータパイプラインのフローの目的は、ある場所から別の場所へ、所定の形式と構造で格納されたデータを単純に移動させることです。データのオリジンはソースと呼ばれ、デスティネーションはターゲットと呼ばれ、シンクと呼ばれることもあります。このプロセスを記述するパターンは2つありますが、どちらも期間、頻度、搬送技術、プログラミング言語、ツールなどを規定していません。パターンは以下の通りです。

  • ETL – Extract (抽出)、Transform (変換)、Load (ロード) の略で、パイプラインの各段階で何が起こるかを正確に説明しています。データは最初にソースから抽出され、次に何らかの方法で変換されます。最後に、データ サブセットがターゲット システムにロードされます。

  • ELT – Extract、Load、Transform のパターンは類似しています。パイプラインは、ソースからデータのサブセットを抽出から開始し、すぐにターゲットにロードします。最後のステップでは、データ変換が実行されます。

下の図は、データのサブセットが変換と最終的なロードが発生する前に転送されることを示しています。

同じ意味で、伝送や最終的なロードの前にデータサブセットを抽出して変換することも同様に有効です。

実際には、ベンダの実装がデータ転送操作の順序や優先順位を決定することが多いのです。実際には、先に述べた実装の詳細(頻度など)の多くも、ベンダーに大きく依存しています。

ETLとバッチ

一般的に、ETLプロセスは、ユースケースに応じて、毎分、毎時、毎日、毎週など、あらかじめ決められたスケジュールで動作します。また、ETLパイプラインは外部のトリガーやイベントに応答して実行することができますが、これはあまり一般的ではありません。

スケジュールされたETLプロセスは、バッチモードで動作すると言われており、頻度は以下の制約によって決定されることが多いです。

  • 必要なデータの適時性
  • データを抽出する時間
  • 変換にかかる時間
  • データを送信する時間
  • ロードを実行する時間
  • バッチ間のトランザクション量

全体的に、このプロセスはうまく機能しますが、データ量とETL処理時間が必要な適時性を超えると苦戦します。例えば、銀行は10分ごとに100万件のトランザクションでデータウェアハウスを更新する必要があるかもしれませんが、バッチの抽出、変換、ロードには15分かかります。頻度を20分に延長しても、データ量もそれぞれ200万行に増えているため、答えにはなりません。

では銀行は何をしているのでしょうか?

ELT、CDC、リアルタイム

この銀行の代替戦略は、プロセスを再考し、異なるステップが発生したときに再び優先順位をつけることです。データの抽出、転送、ロードにかかる時間が以前と同じであると仮定すると、ELTを使用することで、より多くのリソースが利用可能なときに、バックエンドが変換を実行できるようになります。

このパターンは、変更データキャプチャ(Change Data Capture、CDC) を追加することでさらに強化することができます。CDCはETLのようなバッチスケジュールでは動作せず、データソースに変更が発生するたびにトリガーされます。したがって、先ほどの銀行の例では、ELTプロセスはトランザクションごとに実行され、最小限のデータ量で送信されます。100万行の処理を待つ必要はありません。事実上、抽出とロードのプロセスはリアルタイムで行われます。

銀行は、一括変換プロセスをスケジュールするか、データが消費されるまで変換を延期するかを選択することができます。実際、多くの顧客が両方のオプションを採用しています。

さらに、近年ではデータの量、速度、種類が非常に増えており、特にクラウドデータ移行データウェアハウスレイクのインジェスト、ML Ops(機械学習を使用したデータパイプラインの継続的な配信と自動化)などのシナリオでは、ELTがデータ移動のデファクトパターンとして多くのインスタンスでETLに取って代わってきています。

結論

この記事では、ETLとELTのどちらがデータパイプラインに適したパターンなのかという議論を始め、”それは場合による “という満足のいかない答えに落ち着きました。ETLは伝統的にデータ統合の定番となってきましたが、実際、タイムリーさが重要な場合、ETLは停滞してしまいます。したがって、アナリティクスや機械学習のプロジェクトでリアルタイムのデータが必要な場合は、ELTが選択のパターンとなります。

受賞歴のあるELTソリューションを使ってリアルタイムにデータを動かすことを試してみたい場合は、Qlik Data Integrationテストドライブを試してみてください。