「抽出、ロード、変換」を表すELTは、データ統合プロセスのタイプの1つで、ETL「抽出、変換、ロード」と似ています。 ELTのプロセスは、生データをソース・システムからデータウェアハウスなどの出力先リソースに移動します。 ELTは、ETLと似ていますが、ELTは、データ前処理に対してETLとは根本的に異なるアプローチで、クラウド環境への移行に伴い、ごく最近に採用されるようになったものです。
ELTは、主要な3つの段階(抽出、ロード、および変換)で構成されています。 これらの各段階について、以下で詳しく説明します。
データ抽出中に、データは送信元ロケーションからステージング・エリアにコピーまたはエクスポートされます。 データ・セットは多数のデータ・タイプで構成され、事実上すべての構造化ソースまたは非構造化ソースから取得されます。この一部には以下が含まれますが、これに限定されません。
ただし、非構造化データで使用される方が一般的です。
このステップでは、変換されたデータをステージング・エリアからデータウェアハウスやデータレイクなどのデータ・ストレージ・エリアに移動させます。
多くの組織では、データの読み込みプロセスは自動化され、明確に定義され、継続的でバッチ駆動型です。 通常、ELTは、ソース・システムとデータウェア・ハウスのトラフィックがピークに達し、消費者が分析などにデータを使用するのを待っている営業時間中に行われます。
この段階では、SQLを使用してデータにスキーマを適用するか、分析の前にデータを変換する、スキーマ・オンライトのアプローチが採用されます。 この段階には、以下が含まれます。
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は通常、大容量データやリアルタイム・データを使う環境で使用されます。 具体例としては以下が挙げられます。
IBM Cloud Pak for Dataは、オープンで拡張可能なデータ・プラットフォームで、データ・ファブリックを提供し、任意のクラウド上ですべてのデータを、AIおよび分析用に使用できるようにします。
AIは、新しい方法でデータの価値を提供しています。 DataOpsソリューションを使用して、データを編成し、AIとマルチクラウドの世界に対応できるようにします。
データ統合により、構造化データと非構造化データを変換し、スケーラブルなビッグデータ・プラットフォーム上のシステムに配信できます。