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

ELTとは

「抽出、ロード、変換」を表すELTは、データ統合プロセスのタイプの1つで、ETL「抽出、変換、ロード」と似ています。 ELTのプロセスは、生データをソース・システムからデータウェアハウスなどの出力先リソースに移動します。 ELTは、ETLと似ていますが、ELTは、データ前処理に対してETLとは根本的に異なるアプローチで、クラウド環境への移行に伴い、ごく最近に採用されるようになったものです。

ELTの仕組み

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

抽出

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

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

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

ロード

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

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

変換

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

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

ETLとELTの比較

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

ETLとELTの違いとは

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

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

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

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

ELTのメリット

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

データをより速く出力先に移動させ、より迅速な可用性を実現

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

懸念事項の分離

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

サーバーのスケーリングの問題を回避

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

経費削減

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

柔軟性

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

連続稼働

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

ETLからELTアーキテクチャーへの移行に伴う課題

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

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

ELTの過去と未来

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

お客様事例

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

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