ETLよりもELTプロセスを使用することに賛成する論点は何ですか?


19

私の会社では、ETL(extract-transform-load)プロセスを使用する代わりに、ELT(extract-load-transform)プロセスを使用していることに気付きました。
2つのアプローチの違いは何ですか?また、どの状況で一方が他方よりも「良い」でしょうか?いくつかの例を提供できれば素晴らしいと思います。

回答:


13

ETL対ELTに関する多くの議論があります。

ETLとELTの主な違いは、処理が行われる場所 です。データのETL処理はETLツールで行われます(通常、一度に記録およびメモリで行われます)データのELT処理はデータベースエンジンで行われます

データは同じであり、データの最終結果は両方の方法で達成できます。

それはあなたとあなたの環境に大きく依存します。強力なデータベースエンジンと優れたハードウェアがあり、重い処理を行える場合は、ELTが適しています。忙しいデータウェアハウスエンジンがあり、処理から解放する必要がある場合ETL用。

ETLツールを使用すると、ETL(T)などの両方のオプションが提供されることに注意してください。ETLツールで変換を実行でき、データベースエンジンでも変換を実行できます。

しかし、ELTにはデータベースエンジンでの変換オプションしかありませんが、データベースはセットベースの操作がレコード単位のETLツールよりも優れていることを知っておく必要があります。

同様の質問がSOで尋ねられましたが、ETLをサポートしており、ETLとELTを比較する素晴らしい記事ですが、ELTを支持しています


10

それはほとんどセマンティクスの問題です。これについての議論で多くの熱気が放出されますが、私はこの2つの区別に本当の哲学的な深さがあることを本当に確信していません。

あるレベルでは、最終的にロードする前にETLをクライアント側のツールでデータを変換するように表示できます。ELTは、形式を比較的変更せずにデータが何らかのステージング領域に転送されることを意味します。その後、「変換」が行われます。

これらは非常にふわふわした定義であり、さまざまな技術アーキテクチャに適用できます。また、いずれかの用語を使用して説明できる多くの設計があります。

私は、すべての変換およびビジネスロジックを多かれ少なかれ同種のコードベースに組み込むことができるアーキテクチャを非常に強く支持しており、変換ロジックが非常に複雑な多くのシステムを実行しました。これは、ETLツールを使用してデータを取得するだけで、すべての変換はストアドプロシージャで行われていました。間違いなく、これはETLまたはELTとして記述でき、違いは単にセマンティクスの1つにすぎません。

ただし、一部のツールは非常にデータベース中心です(たとえば、Oracle Data Integratorは、多くの場合ELTツールと呼ばれます)。このビューをサブスクライブする場合、データが変換される前に「Extract」と「Load」が発生し、ステージング領域に着陸してから、SQLまたはPL / SQLコード(ツールまたは手書き)。私が話したいくつかの人々は、ODIの主なメリットをOWBではないと考えているようです。

Informatica PowercentreやMS SQL Server Integration Servicesなどのクライアント側ツールを使用する場合、ツールはデータのクライアント側に広範な変換を行うことができます。Ascential DatastageやAb Initioなどの一部のETLツールは、高速化のためにフラットファイルやインメモリデータ構造で多くの作業を行うように設計されています。この種のアーキテクチャでは、変換はロードされる前にすでに行われています。おそらく、このタイプのアーキテクチャは間違いなく「ETL」に分類できますが、実際の作業はすべてストアドプロシージャコードの束によって行われるツール中心のプロジェクトを数多く見ています。

さまざまなツールとアーキテクチャアプローチには利点がありますが、「ETL」アプローチと「ELT」アプローチのメリットについて包括的な説明をすることはできません。用語が広すぎるため、その違いはほとんど意味がないからです。一部のツールとアーキテクチャには特定の利点がある場合があります。たとえば、Ab Initioのフラットファイルの大量使用は、大量のデータボリュームでパフォーマンスを大幅に向上させます。

実際には、「ETL」と「ELT」を区別することは、システム要件、プラットフォーム、および技術アーキテクチャのより深い議論に入ることなく、かなり無意味です。


1

それはお金の問題でもあります。あなたが指摘するようにデータ量が多い場合、Ab InitioやDataStage Parallel Extenderのようなフラットファイルベースのソリューションは確かに高速ですが、中から高の6桁の命題になります。IRI CoSortは(ELT比較により)非常にETL中心であり、複雑なHadoop実装を除き、ファイルシステムの速度で変換ボリュームに対処する唯一の手頃な方法です。また、一般的に問題にハードウェアを投げること(ELTアプライアンスやメモリ内DBも同様)は、コスト的にも拡張性がないと思います。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.