抽出、ロード、変換（ELT）とは

ELTはETLと似ていますが、ELTはデータ前処理に対してETLとは根本的に異なるアプローチで、クラウド環境への移行に伴い、ごく最近になって採用されるようになったものです。

ELTは、主要な3つの段階（抽出、ロード、および変換）で構成されています。これらの各段階について、以下で詳しく説明します。

データ抽出中に、データは送信元ロケーションからステージング・エリアにコピーまたはエクスポートされます。データ・セットは多数のデータ・タイプで構成され、事実上すべての構造化ソースまたは非構造化ソースから取得されます。この一部には以下が含まれますが、これに限定されません。

• SQLまたはNoSQLサーバー
• CRMおよびERPシステム
• テキスト・ファイルと文書ファイル
• Eメール
• Webページ

ただし、非構造化データで使用される方が一般的です。

このステップでは、変換されたデータをステージング・エリアからデータウェアハウスやデータレイクなどのデータ・ストレージ・エリアに移動させます。

多くの組織では、データの読み込みプロセスは自動化され、明確に定義され、継続的でバッチ駆動型です。通常、ELTは、ソース・システムとデータウェアハウスのトラフィックがピークに達し、消費者が分析などにデータを使用するのを待っている営業時間中に行われます。

この段階では、SQLを使用してデータにスキーマを適用するか、分析の前にデータを変換する、スキーマ・オンライトのアプローチが採用されます。この段階には、以下が含まれます。

• データのフィルタリング、クレンジング、重複排除、検証、認証。
• 未加工データに基づいた計算、翻訳、データ分析、または集計の実行。これには、一貫性を保つために行と列のヘッダーの変更から、通貨や測定単位の変換、テキスト文字列の編集、値を追加または平均化まで、組織固有のBIや分析目的に合致するために必要なすべてのことが含まれる場合があります。
• 官公庁・自治体または業界の規制により管理されるデータの削除、暗号化、非表示、またはその他の保護。
• ウェアハウスにデプロイされたスキーマに基づいた、データの表または結合表へのフォーマット。

ELTは、ほぼ同じ頭字語で知られる姉妹プロセスのETLと混同されることがあります。しかし、ELTと、抽出、変換、ロードの略語であるETLの間には、いくつかの明確な違いがあります。ETLは、複数のデータ・ソースからのデータを単一の一貫性のあるデータ・ストアに結合し、データウェアハウスまたは他のターゲット・システムにロードするデータ統合プロセスです。従来のETLツールは、ビジネス・インテリジェンス（BI）および人工知能（AI）アプリケーションをサポートするデータウェアハウジングを作成するために設計されていました。

明らかな違いは、ELTプロセスが変換関数の前にロード関数を実行することで、ETLプロセスの2番目と3番目のステップが逆になっていることです。ELTは、送信元ロケーションからデータをコピーまたはエクスポートしますが、変換のためにステージング・エリアに移動する代わりに、未加工データをターゲット・データ・ストアに直接ロードし、必要に応じて変換できます。ELTは、転送中のデータを変換しません。

しかし、ステップの順序だけが違うわけではありません。ELTでは、ターゲット・データ・ストアはデータウェアハウスであることもありますが、多くの場合、構造化データと非構造化データの両方を大規模に保持するように設計された大規模な中央ストアであるデータレイクになります。

データレイクは、ビッグデータ・プラットフォーム（Apache Hadoopなど）または分散型のNoSQLデータ管理システムを使用して管理されます。これらはビジネス・インテリジェンスをサポートできますが、多くの場合、人工知能、機械学習、予測分析、リアルタイムのデータ・ストリームやイベント・ストリームを利用したアプリケーションをサポートするために作成されます。

ETLとELTの違いは他にもあります。例えば、ETLは中央リポジトリーに移動する前にデータを変換するため、ELTよりもデータ・プライバシー・コンプライアンスを単純化あるいは体系化することができます（例えば、アナリストが機密データを使用する前に変換しない場合、データレイクでマスクされないまま放置される可能性があります）。ただし、データサイエンティストは、未加工データの「サンドボックス」で動作し、特定のアプリケーションに合わせた固有のデータ変換を実行できるELTを好む場合があります。しかし、多くの場合、ETLとELTのどちらを選択するかは、利用可能なビジネス・リソースとニーズのどちらを選択するかによります。

ELTは、プロセスをワークフローに統合するユーザーにいくつかのメリットを提供します。注目すべきメリットのいくつかを見てみましょう。

大量のストリーミングデータが生成されると、ELTはそのデータをすぐにロードし、出力先に到達した後にデータを変換します。これにより、ETLのようにロード関数の前に変換が発生した場合に頻繁に発生しがちな速度の低下を防止できます。多くの場合、このデータに関連して決定を下す必要があり、遅延は許容されません。例として、リアルタイムで消費される大容量のデータを生成する株式市場が挙げられます。このようなシナリオでは、データが出力先に到達した後に変換が行われるため、ELTが最適なソリューションになります。

データは出力先に到着した時点で変換されるため、ELTでは、データの受信者が制御データを操作できます。ELTでは、変換ステージとロード・ステージを分離することで、変換ステージのコーディング・エラーやその他のエラーが別のステージに影響を与えないようにしています。

ELTは、データウェアハウスの能力とサイズを利用して、大容量の変換またはスケーラブルなコンピュートを実現します。特にクラウドのシナリオでは、各クラスター内に複数のノードが存在し、複数のクラスターを利用できるため、出力先データウェアハウスは、必要に応じてノードを増減させることができます。これにより、オンデマンドの柔軟性と拡張性が実現します。

ELTはデータ変換のためにそれほど強力なサーバーを必要とせず、ウェアハウス内にすでにあるリソースを活用することができます。これにより、コストが削減され、リソース効率が向上します。

ELTを使用することで、コストとリソースの柔軟性を考慮して、任意の出力先リポジトリーを使用できます。データウェアハウスは、大量のデータを保管できるカラムナ・メモリーベース・ストレージなどのMPPアーキテクチャー（超並列処理）を使用しています。データが受信されるとすぐにスキーマまたは変換モデルを適用するデータレイク・プロセス（造語で「スキーマ・オン・リード」とも呼ばれます）もサポートされています。これらの効率的な処理により、大容量のデータにも柔軟に対応できます。

連続稼働は、データへの高速アクセスを必要とするあらゆる環境に理想的です。ELTは、オンデマンドで継続的にアクセスされるアプリケーションを含むことが多いクラウド環境でのデータ活用に適しています。同様に、クラウドネイティブのELTの変換は、前述の拡張性と柔軟性を提供します。

組織は、ETLからELTアーキテクチャーへの移行を選択できます。移行の理由としては、リアルタイムでの対応や対話が必要とされるなど製品やサービスの用途が変更する場合、またはデータ量が急激に増加し、インフラストラクチャーへの大量の処理要求により、変換がロード・ステージを遅らせている場合があります。組織は、クラウドに移行し、処理をオフロードしたい場合や、出力先の場所のデータをより早く使用したい場合は、ETLからELTへの移行を選択できます。

移行シナリオでは、現実的には、問題に遭遇することが予想されます。まず第一に、ELTとETLでは完全に異なるロジックとコードが使用されます。これには、完全な再構成と、場合によっては新しいインフラストラクチャーまたはクラウド内にインフラストラクチャーを持つ新しいプロバイダーが必要になる可能性があります。さらに、ELTの場合、未加工データが出力先ウェアハウスに送信されます。したがって、セキュリティーを考慮し、データを安全に保持するために実装する必要があります。

ELT は新しいテクノロジーではありません。ステージング・テーブルはこれまで、データをウェアハウスに移動して処理と変換を行うために使用されており、多くの場合、SQLスクリプトが使用されていました。SQLスクリプトはハードコーディングされているため、コーディング・エラーが発生する可能性があります。SQLを使用する場合、顧客はSQLスクリプトを使ったネイティブ・ウェアハウスの実行と宣言型プログラミング（別称、宣言型オーサリング）のどちらかを選ぶ必要がありました。宣言型オーサリングは、プログラムがどのように達成するかではなく、プログラムが何を達成しなければならないかを記述したコードを作成することで、より最新のクラウドを活用したデータウェアハウス環境のメリットを提供します。このプロセスにより、特にロード関数より先に変換を行う場合に、他のプロセスで発生する固有のコーディング・エラーを防ぐことができます。

ELTは通常、大容量データやリアルタイム・データを使う環境で使用されます。具体例としては以下が挙げられます。

• 即時にアクセスが必要な組織例えば、証券取引や、流通在庫、製造業用部品、その他の材料を扱う大規模な卸売業者は、ビジネス・インテリジェンスにすぐにアクセスするために最新のデータにリアルタイムでアクセスする必要があります。
• 膨大な量のデータを扱う組織。例えば、気象予報機関などの気象システムは、定期的に大容量のデータを収集、照合、使用します。大容量のトランザクションを行う企業も、このカテゴリーに該当する可能性があります。超大型望遠鏡を備えた天文学研究所などの組織では、照合して分析する必要のある大容量のデータが生成されます。大容量のデータを生成および利用し、そのデータへのリアルタイム・アクセスを必要とする業界が数多く存在するため、2つのカテゴリー間に重複が生じる可能性があります。