データ統合手法 ETL、ELT、リバース ETL の詳細な説明

翻訳者 |チェン・ジュン

校正：孫淑娟

データ パイプライン プロジェクトに適したデータ統合アプローチを選択できるように、ETL と ELT の長所と短所、および両方の手法の使用方法について簡単に説明します。また、高速なデータ読み込み、最小限のメンテナンス、高度な自動化を必要とするワークフローにリバース ETL が適している理由についても説明します。

ETL と ELT の一般的な概念

今日の企業が直面している共通の課題は、複数のソースから複数の形式でデータを取得し、それを 1 つ以上のデータ ターゲットに転送する必要があることです。ほとんどのデータ移行プロジェクトでは複数のデータ ソースの収集が必要になるため、明確に定義されたデータ パイプライン (つまり、ソースから宛先までの情報のパスまたはワークフロー) が必要です。ターゲットとデータ ソースが異なる形式で保存されている場合は、最終ターゲットにロードする前にデータを調整またはクリーンアップする必要があります。現在、業界には、データ パイプラインにおけるアプリケーション データの変換と調整において一定の役割を果たすことができるツール、サービス、プロセスが数多く存在します。

ETLプロセス

ETL はデータ統合プロセスです。これにより、データ パイプライン プロジェクトは、さまざまなソースからデータをスムーズに抽出し、データを変換し、データ結果をターゲット データベースにロードできるようになります。 ETL であっても ELT であっても、データ変換および統合プロセスには次の 3 つの段階が含まれます (図 1 を参照)。

1. 抽出 – データベース クエリまたは変更データ キャプチャ (CDC) プロセスを使用して、ソース システム (SAS、オンライン、オンプレミスなど) からデータを抽出します。抽出後、データはさらなる処理のためにステージング領域に転送されます。
2. 変換 – データがクレンジング、処理、変換、強化されると、ターゲット データ パイプライン、データ ウェアハウス、データベース、またはデータ レイクで使用できる形式に変換されます。
3. ロード – 生データと変換されたデータをターゲット システムにロードします。このプロセスには、区切りファイルへの書き込み、データベース内のスキーマの作成、蓄積または集約されたデータによる既存のデータの上書きが含まれます。

図 1: ETL プロセス (Kai Waehner の「リバース ETL を使用する場合とアンチパターンを使用する場合」より)

ETL プロセスと ELT プロセスは、上記の手順を異なる順序で実行します。データ パイプライン チームは、データをターゲット データ リポジトリにロードする前か後にデータ変換を実行するかどうかを決定する必要があります。

ELTプロセス

ELT は、データ サイロの発生を防ぐために組織全体のデータを統合するために使用される方法です。データはデータ ソースから抽出され、データ ウェアハウスにロードされ、必要に応じて変換されます。アプリケーションに応じて変換が必要ですが、ELT プロセスでは、保存する前にデータを変換する必要があります (図 2 を参照)。

1. 抽出 – ETL と同じです。
2. ロード – ETL とは異なり、データは直接 (つまり、クレンジング、エンリッチメント、変換なしで) ロードされ、ターゲット システムに配信されます (通常、ターゲット スキーマとデータ型のさまざまな移行の考慮が必要になります)。
3. 変換 – データをロードした後、ターゲット プラットフォームはビジネス レポートの目的でデータを変換します。一部の企業では、dbt などのツールを使用してターゲット データを変換しています。したがって、ELT パイプラインでは、オンデマンドでターゲット データの変換を実行する必要があります。

図 2: ELT プロセス (Kai Waehner の「リバース ETL を使用する場合とアンチパターンを使用する場合」より)

ELT は、統合プロセスに含まれるステップの順序を変更し、変換が途中ではなく最後に行われるようにします。 ELT プロセスは、ステージの順序を切り替えることで、構造や形式を考慮せずに生データを受け入れるデータ レイクにデータをロードし、即時のデータ抽出とロードを可能にします。

ELT の採用に貢献するもう 1 つの要因は、クラウドベースのデータ ウェアハウスの広範な採用と実装です。クラウド データ ウェアハウス ソリューションは、コンピューティングとストレージを完全に分離し、無制限のデータを保存する機能を提供します。現在、ほとんどのデータ ウェアハウスはホストされています。つまり、企業はハードウェアやストレージを購入したり管理したりする必要がなく、ソフトウェアをインストールしたり拡張を検討したりする必要もありません。これらはすべてクラウド サービス プロバイダーによって管理および制御されます。これに基づいて、企業はクラウドホスト型データ ウェアハウスをより短い期間で構成できます。

ETL と ELT: 属性、機能、ユースケース

ETL と ELT の使用例に関しては、一方的なことはありません。次の表に、さまざまな属性の観点から見た 2 つの違いをまとめます。

リバース ETL の一般的な概念

リバース ETL は、クレンジングおよび処理されたデータを抽出するためのフレームワークです。データ ウェアハウス (またはデータ レイク/マート) から 1 つ以上の運用システムにデータをコピーします。その後、データは Salesforce などの他のアプリケーションに再導入され、業務運営や予測に使用できるようになります。抽出されたデータ ソースを操作することで、さまざまなユーザーが共通のツールを使用してデータにアクセスし、関連する洞察を得ることができます。最新のデータ テクノロジー スタックのコンポーネントとして、リバース ETL を使用すると、企業はビジネス インテリジェンス (BI) ツールのみを使用する場合よりも複雑な分析を実行できます。

戦略的な新しい統合プロセスとして、リバース ETL は急成長中の企業がデータ分析に費やす時間を短縮できます。このプロセスは、データ ウェアハウス内のデータをアクティブ化するために、ビジネス ユーザーの運用ツールとデータを同期することに重点を置いています。ユーザーは事前にデータを定義し、最終宛先の適切な列/フィールドにマッピングする必要があります。

同時に、企業のデータストレージ（データ参照やリレーショナルデータベースなど）は誰もが完全にアクセスできるわけではないリポジトリになっているため、リバース ETL を使用してさまざまなビジネスロールに基本データを提供する必要があります（図 3 を参照）。

図 3: リバース ETL プロセス (Kai Waehner の「リバース ETL を使用する場合とそれがアンチパターンである場合」より)

リバースETLのユースケース

データ ウェアハウスをデータ パイプラインの単なる最終コンポーネントとして見るのではなく、データ ウェアハウス内のクリーンアップされ準備された情報を活用するために、リバース ETL ユーザーはコネクタを使用してデータ ウェアハウス (SAP や SASS など) を読み取ることができます。たとえば、最新のデータ チームは、すぐに使用できるリバース ETL ソリューションを使用してデータ ウェアハウスからデータを抽出し、電子メール マーケティング、顧客サポート、販売、財務モデルをサポートできます。同時に、ビジネス チームに、より深く、より効率的で、より価値のあるセルフサービスを提供することもできます。

一般的に、リバース ETL は企業が次のことを達成するのに役立ちます。

• ビジネスの応答性 - ビジネス アプリケーションとデータの変更を迅速に追跡して対応します。
• ビジネス分析 - ビジネス チームの分析ワークフローに関する洞察を提供し、よりデータに基づいた意思決定を行えるようにします。
• データ インフラストラクチャ – ソース システムの数が増えるにつれて、リバース ETL は、データ ウェアハウスやデータ レイク内のデータを迅速かつ効率的に操作するための重要なツールになりました。
• クラウド アプリケーションのデータを複製 - レポート機能を強化し、タイムリーに情報を検索します。

リバース ETL の購入と構築

データ チームがサードパーティのリバース ETL ツールを導入すると、運用分析を迅速に実装できますが、それらを購入する必要があるのでしょうか、それとも独自のリバース ETL を構築する必要があるのでしょうか。以下では、リバース ETL プロセスとプラットフォームの設計と構築を例に挙げ、企業が意思決定を行う前に慎重に検討する必要がある 3 つの要素を示します。

1. データ コネクタの構築 – ウェアハウスから下流の運用システムにデータを転送するには、多くの場合、API コネクタを統合する必要があります。これは複雑な作業です。リバース ETL と関連プロセスを設計および構築することを選択した場合は、ETL パイプラインを構築するプロセスを開発チームに割り当てる必要があります。
2. 長期メンテナンスの準備 – 開発チームがデータ コネクタをリリースしたら、API 仕様が頻繁に変更されるため、コネクタを最新の状態に保つ必要があります。
3. スケーラビリティと信頼性を考慮した設計 - データ エンジニアは、ビジネスの成長に対応し、データの急増を効果的に管理するために、リバース ETL パイプラインを迅速に開発できるようにする必要があります。さらに、リバース ETL パイプラインは、パフォーマンスやデータ転送の問題がなく、信頼性が高くなければなりません。

まとめ

データ パイプラインを作成する際に最も重く時間のかかる手順は、さまざまなソースからデータを抽出し、プロセス全体をテストすることです。その中で、各データ ソースを同期する収集プロセスには、あらゆるレベルで多くの専門知識が必要になることがよくあります。あなたとあなたのチームがこれに興味がある場合は、次のリンクを参照してください。

• ガートナー リサーチ (2021)、データ統合ツールに関するガートナー マジック クアドラント
• Gartner Research (2020)、「データ統合ツールの重要な機能」
• Kai Waehner、リバース ETL を使用するタイミングとそれがアンチパターンとなるタイミング
• Stephen Roddewig、「ETL と ELT: 違いは何ですか?」どちらが良いでしょうか？ 》​​

翻訳者について

51CTO コミュニティの編集者である Julian Chen 氏は、IT プロジェクトの実装において 10 年以上の経験を持っています。社内外のリソースとリスクの管理に長けており、ネットワークと情報セキュリティの知識と経験の普及に注力しています。彼は、ブログ投稿、特別トピック、翻訳の形で最先端のテクノロジーと新しい知識を共有し続けています。彼はオンラインとオフラインで情報セキュリティのトレーニングや講義を頻繁に行っています。

原題: ETL、ELT、および逆ETL 、著者: Wayne Yaddow