ETLとELT：私たちは、あなたが判断する立場にあります

完全な開示：この記事は、データベースの外部でビッグデータを操作することに強いスーツを持っているETL中心の会社によって作成されているため、以下の内容は多くの人にとって客観的ではないように思われます。それでもなお、それは思考のための食べ物を提示することを意図しており、議論の場を開きます。

データウェアハウスアーキテクト（DWA）は当初から、データウェアハウスを作成し、さまざまなソースとフォーマットのデータをデータウェアハウスに投入するという任務を負っていました。データ量が劇的に増加しているため、これらの同じDWAは、データ統合とステージング操作をより効率的に実装することが課題となっています。データ変換がターゲットデータベースの内部で行われるのか外部で行われるのかという問題は、パフォーマンス、利便性、および経済的な影響のために重要な問題になっています。

ETL（抽出、変換、読み込み）操作では、データはさまざまなソースから抽出され、個別に変換され、DWデータベースおよび場合によっては他のターゲットに読み込まれます。 ELTでは、抽出は、変換も処理する単一のステージングデータベースに送られます。

ETLは、Informatica、IBM、Oracleなどの実績のあるプレーヤー、およびFACT（Fast Extract）、CoSortまたはHadoop変換、および同じEclipse GUIでの一括読み込みを組み合わせてデータを抽出および変換するVoracityを備えたIRIで繁栄しているため、引き続き普及しています。このアプローチにより、大規模なデータ変換のオーバーヘッドによるストレージと取得（クエリの最適化）用に設計されたデータベースへの負担を防ぐことができます。

ただし、「ボックス内」で変換を処理できるOracle Exadataなどの新しいデータベーステクノロジーとハードウェアアプライアンスの開発により、ELTは特定の状況下で実用的なソリューションになる可能性があります。また、ステージング（ロード）レイヤーとセマンティック（変換）レイヤーを分離することには、特定の利点があります。

ELTの引用された利点は、これらのステージ間の固有の依存関係を取り除くため、変換プロセスからロードプロセスを分離できることです。

Voracityはファイルシステム（またはHDFS）でデータをステージングするため、IRIのETLアプローチはとにかくそれらを分離することに注意してください。データベースにバインドされたデータチャンクは、（事前にソートされた）ロードの前に、外部から取得、クレンジング、および変換できます。これにより、データベース（およびBI /分析ツールなど）から大規模な変換の負担がなくなります。

多くの場合、データ量と予算は、DWAがETLまたはELTソリューションを開発する必要があるかどうかを決定するものです。 ITToolboxのブログ記事「SoWhatIsBetter、ETL or ELT？」で、Vincent McBurneyは、どちらのアプローチにも長所と短所を示しています。これを以下で繰り返します。その後、それぞれにIRIETLの典型的な応答を示します。指向のユーザーはポイントを作ります （私の最初の主観的な警告による）：

長所ETL

• ETLは、ワークロードのバランスを取り、RDBMSとワークロードを共有できます。実際、Voracityでコーディングせずに、SortCLプログラムまたはHadoopを介してデータを変換することで、そのワークロードを削除できます。
• ETLは、データマップを介して単一のデータフロー図でより複雑な操作を実行できます。 Voracityマッピングやワークフロー図のように、短く開いたものも抽象化します 4GLスクリプトとSQL
• ETLは個別のハードウェアで拡張できます– コモディティボックスでは、単一ベンダーのアプライアンスよりもはるかに低いコストで調達および保守できます
• ETLは、データモデル、データベースレイアウト、ソースデータモデルアーキテクチャに関係なく、パーティショニングと並列処理を処理できます。ただし、VoracityのCoSortSortCLジョブ パーティション化する必要はまったくありません…
• ETLは、ソースからターゲットに転送されるため、データをインストリームで処理できます。それが理にかなっている場合はバッチで処理することもできます
• ETLは、その作業を行うためにデータセットのコロケーションを必要としません。データ同期の心配なしに既存のデータソースプラットフォームを維持できます
• ETLは、今日、大量のメタデータリネージをキャプチャします- 1つのステージングDBで、どれだけうまくまたは直感的にそれを実行できますか？
• ETLはSMPまたはMPPハードウェアで実行できます– これも、DBとのパフォーマンスの競合を心配することなく、より費用対効果の高い方法で管理および活用できます。
• ETLは情報を行ごとに処理します。これは、サードパーティ製品へのデータ統合でうまく機能するようです。それでもなお良いです Voracityがボリュームで実行する、一度に1つのブロック、テーブル、またはファイル全体。

短所ETL

• ETLエンジンには追加のハードウェア投資が必要です–データベースサーバーで実行しない限り
• ETLシステムの構築またはETLツールのライセンス供与の追加コスト– ELTアプライアンスに比べてまだ安価ですが、Fast Extract（FACT）とCoSortを組み合わせてETLを高速化するVoracityなどのIRIツールはさらに安価です
  
• 行ベースのアプローチのパフォーマンスが低下する可能性があります– 正しいです。Voracityがデータをより大きなチャンクでプロファイリング、取得、変換、出力する機能が高速である理由
• ETLツールの実装に必要な専門的なスキルと学習曲線–同じEclipseIDEで複数のジョブ設計オプションを提供するVoracityのような人間工学に基づいたGUIを使用している場合を除く
• ETLツールベンダーへの依存による柔軟性の低下– 代わりに単一のELT/アプライアンスベンダーに依存することで、それがどのように改善されるかはわかりません。ベンダーに依存しないことが柔軟性とコスト削減の鍵ではありませんか？
• データは、データマートに到達する前にもう1つのレイヤーを移動する必要があります。ただし、マートがマルチターゲットVoracity操作で一般的なETLプロセスの別の出力である場合を除きます。

プロELT

• ELTはスケーラビリティのためにRDBMSエンジンハードウェアを活用しますが、クエリの最適化を目的としたDBリソースにも負担をかけます。 VoracityのCoSortおよびHadoop変換は、DBのメモリやI / Oリソースではなく、線形スケーリングアルゴリズムとタスク統合を活用します。
• ELTは、すべてのデータを常にRDBMSに保持します。ソースデータとターゲットデータが同じDBにある限り、これで問題ありません。
• ELTはデータセットに従って並列化され、ディスクI / Oは通常、スループットを高速化するためにエンジンレベルで最適化されます。はい。ただし、DBサーバーリソースと競合しない外部変換の場合はさらに当てはまります。
• ELTは、ハードウェアとRDBMSエンジンが拡張を継続できる限り拡張します。上記の代替案と比較して、どれくらいの費用がかかりますか？
• ELTは、適切に調整されたMPP RDBMSプラットフォームで3倍から4倍のスループット率を達成できます。これにより、アプライアンスもETLツールと比較してVoracityのパフォーマンスレベルになりますが、コストは20倍になります。
• ELT変換は、データベースがターゲットプラットフォーム上にあると、RDBMSサーバーで実行され、ネットワークにストレスがかからなくなります。そのため、代わりにデータベース（ユーザー）にストレスがかかりますか？
• ELTには、SQLを介した単純な変換仕様があります。これは、VoracityのEclipseGUIのCoSortSortCL構文やドラッグアンドドロップフィールドマッピングほど単純ではなく、柔軟性がなく、機能が豊富ではありません。

短所ELT

• ELTを完全にサポートする限られたツール– そして、大量のパフォーマンスを宣伝するDBアプライアンスの場合は非常に高額です
• 詳細な実行時監視統計とデータ系統の喪失– 特に、メタデータは、異種のファイル、テーブル、または非構造化ソースへの変更に対する分析に影響を与えます
• パフォーマンスのためのセットベースの設計によるモジュール性の喪失–およびそこから流れる機能性/柔軟性の喪失
• 変換はデータベースリソースを利用し、BIレポートのパフォーマンスに影響を与える可能性があります–クエリやその他のDB操作のパフォーマンスは言うまでもありません

その後、ETLT、TELT、さらにはTETLTのようなハイブリッドアーキテクチャが出現し、どちらのアプローチでも弱点を補おうとしています。しかし、これらは、すでにこのように複雑になっているプロセスにさらに複雑さを加えるようです。実際には特効薬はなく、多くのデータ統合プロジェクトは、SLA、コストの超過、複雑さの重みで失敗します。

これらの理由により、IRIはVoracityを構築して、CoSortSortCLプログラムを介して既存のファイルシステムまたはHadoopファブリックに再コーディングせずにデータを統合しました。 Voracityは、外部データ変換の両方のオプションを提供する唯一のETL指向（ただしELTをサポートする）プラットフォームです。データの移動と操作における優れた価格パフォーマンスに加えて、Voracityには次のものが含まれます。

• 高度なデータ変換、データ品質、MDM、およびレポート
• ディメンションの変更、データキャプチャの変更、データフェデレーション
• データプロファイリング、データマスキング、テストデータ生成、メタデータ管理
• ユーザーまたはEclipseウィザード、図、ダイアログが作成および管理する単純な4GLスクリプト
• Hadoop MR2、Spark、Spart Stream Storm、Tezでのシームレスな実行
• erwinスマートコネクタのサポート（他のETLツールからの変換）
• ネイティブのMongoDBドライバーと、他のNoSQL、Hadoop、クラウド、レガシーソースへの接続
• 組み込みのレポート、統計、予測機能、KNIMEとSplunkのタイアップ、分析ツールのデータフィード。

参照：

• http://www.iri.com/blog/data-transformation2/etl-elt-iri-in-between
• http://www.iri.com/solutions/data-integration/etl
• http://www.iri.com/solutions/data-integration/elt
• http://www.iri.com/solutions/data-integration/implement