【DataPlatform】ETL/ELTツールに関する比較

『データプラットフォーム技術バイブル』を読んで、ETL / ELT について整理してみました。

データプラットフォーム技術バイブル　〜要素技術の解説から実践的な構築法、利活用まで〜

本記事は下記記事の続編です。
www.hanatare-papa.jp

記事のポイント

• ETLとは
• ELTとは
• ETLに採用されるミドルウェアとその比較
• ELTに採用されるミドルウェアとその比較

ETL とは

ETL (Extract, Transform, Load) とは、データソース（DB / ファイル / APIなど）からデータを抽出 (Extract)し、変換 (Transform)して、DWHやデータマートなどの格納先にロード (Load)する一連の処理を指します。

ここでは以下の ETL 製品について比較します。

• Apache Spark
• AWS Glue
• Embulk
• DataSpider Servista
• Talend
• Informatica IDMC

今回読んだ本では、ApacheSpark・AWS Glue・Embulkだけでしたが、追加でDataSpider Servista・Talend・Informatica IDMCのことも調べたので、そこも合わせて比較したいと思います。

変換機能

文字コード変換・改行コード変換・データフォーマット変換・圧縮/解凍処理・項目マッピング・フィルタリング・データの結合・データクレンジングといった機能性に対して機能性があるかないかを比較しています。

製品名	機能性
Apache Spark	全対応可（コーディング次第）／データクレンジングは SparkSQL や MLlib で高度化可能。文字コード変換／改行コード変換／ファイルフォーマット変換／圧縮・解凍／項目マッピング／フィルタリング／データクレンジングをプログラムで実装可能。
AWS Glue	フル対応。データクレンジングは PySpark の関数＋ Data Catalog の統合活用。文字コード変換／改行コード変換／ファイルフォーマット変換／圧縮・解凍／項目マッピング／フィルタリング／データクレンジングが可能。
Embulk	基本機能は可（YAML＋Ruby 拡張）。クレンジングは自前実装が多い。文字コード変換／改行コード変換／ファイルフォーマット変換／圧縮・解凍／項目マッピング／フィルタリングは可能。データクレンジングは Ruby プラグインや外部ジョブとの連携が必要。
DataSpider Servista	GUIでフル対応。特に GUI でのデータクレンジング（正規化／欠損補完／パターン修正）が簡単。文字コード変換／改行コード変換／ファイルフォーマット変換／圧縮・解凍／項目マッピング／フィルタリング／データクレンジングが GUI ベースで設定可能。
Talend	フル対応。GUI＋Java コード併用でデータクレンジング機能も豊富（Data Quality 機能あり）。文字コード変換／改行コード変換／ファイルフォーマット変換／圧縮・解凍／項目マッピング／フィルタリング／データクレンジングが GUI または Java コードで実現可能。
Informatica IDMC	フル対応。CLAIRE AI のサジェスト＋データ品質／クレンジング GUI 機能が充実。文字コード変換／改行コード変換／ファイルフォーマット変換／圧縮・解凍／項目マッピング／フィルタリング／データクレンジングが高度に GUI で実現可能。

製品	強み	弱み	評価
Apache Spark	非常に柔軟・高度な ETL 処理が可能。大規模データ向き。	GUIなし。すべてコードで構築が必要。業務ユーザーには扱いづらい。
AWS Glue	GUI（Glue Studio）と PySpark が両立。AWS連携がスムーズ。	AWS に閉じたエコシステムであるためマルチクラウド／他社ツール連携は弱め。
Embulk	軽量 ETL に特化。シンプルな構成／実行が可能。	高度なデータクレンジング・複雑な変換処理は不得意。GUI なし。
DataSpider Servista	GUI 完結。多様な業務データ変換／クレンジングが容易。	高度な大規模バッチ処理（TB超えの分散処理など）は苦手。
Talend	ETL＋Data Quality 機能が一体化。中～大規模まで幅広く対応可能。	Javaベースのため環境整備に手間がかかる場合がある。
Informatica IDMC	高度な Data Quality／クレンジング／AI支援機能が強力。	コスト高め。小規模用途にはオーバースペックになることも。

対応文字コード

製品によって対応している文字コードに制約がないかを比較しています。各製品ごとに強み、弱みに差があまりなく、Embulkがプラグインが必要となるケースがあるため、その差がある程度になります。

製品名	対応文字コード
Apache Spark	ほぼ全対応（コード側で任意に対応可）。UTF-8／UTF-16／Shift-JIS／ISO系など。
AWS Glue	UTF-8／UTF-16／ISO-8859／Shift-JIS 他、主要文字コードに対応。
Embulk	UTF-8中心。プラグインで Shift-JIS／ISO 系など他の文字コードも利用可能。
DataSpider Servista	GUIで主要文字コード（UTF-8／Shift-JIS／EUC-JP／ISO系）をサポート。
Talend	多数対応。UTF-8／Shift-JIS／EUC-JP／ISO系など幅広く対応。
Informatica IDMC	多数対応。UTF-8／Shift-JIS／ISO系 など、ガバナンス機能と併用可能。

対応フォーマット

製品によって対応しているファイルや、データのフォーマットに差がないかを比較しています

製品名	フォーマット
Apache Spark	CSV／JSON／Parquet／Avro／ORC／Delta Lake／SequenceFile など。
AWS Glue	CSV／JSON／Parquet／Avro／ORC／XML／JDBC／その他 AWS 各種フォーマット。
Embulk	CSV／JSON／Parquet／Avro／JDBC／一部Excel／YAML／プラグイン拡張可。
DataSpider Servista	Excel／CSV／JSON／XML／JDBC／SOAP／REST／EDI など業務向け対応が豊富。
Talend	CSV／JSON／Parquet／XML／Avro／JDBC／ERP／SaaS／REST API など幅広く対応。
Informatica IDMC	数千種以上（圧縮・暗号化含む）。CSV／JSON／Parquet／Avro／ORC／Excel／SAP／REST API など。

製品	強み	弱み
Apache Spark	Hadoop系ファイルフォーマット（Parquet／Delta Lake）との相性が良い。	非業務系フォーマット（EDI／ERP）などは標準非対応。
AWS Glue	AWSエコシステム（Parquet／ORC／JSON）との親和性が非常に高い。	非AWS系の特殊フォーマットは追加作業が必要。
Embulk	ファイル／DB に強い。シンプルなデータロード用途に最適。	EDI／ERP／業務向けフォーマットは弱い。
DataSpider Servista	EDI／ERP／REST／SOAP／業務系フォーマットまでGUIで広範対応。	ビッグデータ系フォーマット（Parquet／Delta Lake）はやや弱め。
Talend	非常に広範囲なフォーマット対応。ビッグデータ／業務系両方対応可。	特になし（バランスが非常に良い）。
Informatica IDMC	対応フォーマットの種類は最大級（暗号化／圧縮含む）。	特になし。業務向け／ビッグデータ／クラウドデータいずれにも強い。

接続先の柔軟性

製品によって接続可能なシステムの主なものを比較しています

製品名	コネクタ／接続対象
Apache Spark	Hadoop／S3／GCS／Kafka／JDBC／HDFS／NoSQL（Cassandra／MongoDBなど）他。
AWS Glue	AWS 各種（S3／RDS／Redshift／Athena／DynamoDB）＋ JDBC／API 他。
Embulk	DB（PostgreSQL／MySQL／Oracle 他）／ファイル／クラウドストレージ中心。
DataSpider Servista	ERP／CRM／DB／メインフレーム／SaaS／オンプレAPI／REST／SOAP／EDI 等幅広い。
Talend	DB／ERP／SaaS／REST API／Kafka／JMS／クラウドAPI／ファイルシステム 他多数。
Informatica IDMC	50,000 以上のコネクタを保有。DB／ERP／SaaS／REST API／Kafka／メインフレーム／データレイク／クラウド全般。

製品	強み	弱み
Apache Spark	オープンソース系接続先には強い。Hadoop／Kafka／NoSQL。	ERP／CRM／SaaSなど業務アプリ系は追加開発が必要。
AWS Glue	AWS内の各サービス接続が非常に強力。	他クラウドや一部業務SaaSはコネクタ不足が出やすい。
Embulk	DB／ファイル接続は優秀。	SaaS／ERP／業務APIは弱い。
DataSpider Servista	ERP／CRM／メインフレーム／EDI／SaaSなど幅広くGUIで設定可能。	Hadoop／ビッグデータレイク系はやや弱い。
Talend	非常に広い範囲に対応（DB／SaaS／クラウド／ビッグデータ）。	特になし（コネクタ量産可能）。
Informatica IDMC	50,000以上のコネクタを持つ最大級対応力。	特になし（業務向けでもビッグデータでも柔軟対応）。

開発生産性

使うにあたって開発生産性がどれだけあるかを比較しています

製品名	開発生産性
Apache Spark	コーディング主体。習熟が必要で難易度は高めだが柔軟性は極めて高い。
AWS Glue	GUI（Glue Studio）＋ PySpark／Scala で高速開発可能。AWS環境との統合が強み。
Embulk	YAML＋プラグイン簡易構成。軽量／高速構築可能だが複雑な処理はコードが必要。
DataSpider Servista	完全GUI。ノーコード開発が可能で業務部門でも比較的利用しやすい。
Talend	GUI中心＋Java併用で柔軟な開発が可能。学習コストはややあるが強力。
Informatica IDMC	CLAIRE AI によるマッピング支援。ほぼGUI開発可能で生産性は極めて高い。

製品	強み	弱み
Apache Spark	高度な処理は柔軟。	開発難易度高め（データエンジニア向け）。
AWS Glue	AWS Glue Studio によりノーコード～ローコード開発も可能。	Sparkライクな理解が求められるため学習コストはある。
Embulk	YAMLベースで簡易なETLは高速開発可能。	GUIがない。複雑な処理はかなり手作りになる。
DataSpider Servista	業務部門でも扱える完全GUI。	スクリプトによる高度な拡張は難しめ。
Talend	GUI＋コード併用。開発効率が高い。	Javaベースで慣れが必要。初期セットアップや学習が重め。
Informatica IDMC	CLAIRE AI によるサジェスト＋GUI完結が非常に高い生産性。	特になし（エンタープライズ用途では最上位レベルの生産性）。

コーディング言語

発生産性に関係している内容ですが、コーディングが可能な場合対応している言語が何かを比較をしています。コーディングには、用途による向き不向きとなるため、強み、弱みの比較はしていない。

製品名	コーディング言語
Apache Spark	Scala／Java／Python／R／SparkSQL。
AWS Glue	PySpark（Python）／Scala／SparkSQL。
Embulk	YAML／Ruby（filter/output）／Java（一部プラグイン）。
DataSpider Servista	基本不要（GUI中心）。一部カスタム時に JavaScript／Java。
Talend	Java／Groovy／Talend Expression Language（DSL）。
Informatica IDMC	Java／Python／SparkSQL（ただしGUI中心で完結可能）。

運用・ガバナンス対応

使うにあたって運用のしやすさを比較しています。

製品名	ガバナンス／リトライ
Apache Spark	自前構築が基本。Airflow／Oozie／自作監視が必要。
AWS Glue	Data Catalog＋ジョブ再実行／通知対応。AWS EventBridge 等と組み合わせ可。
Embulk	外部依存（ジョブ管理／監視は別途 Airflow／Jenkins／cron 等利用）。
DataSpider Servista	GUIで監視／ジョブ状況管理／リトライ機能も標準搭載。
Talend	MDM＋ガバナンス機能完備。ジョブ監視／リトライ管理もGUIで実施可能。
Informatica IDMC	MDM／データ品質／プロファイリング／自動リトライ／ガバナンス機能が豊富。

製品	強み	弱み
Apache Spark	Airflow 等と組み合わせれば柔軟性は高い。	標準機能としてはガバナンスやリトライ機能は用意されていない。
AWS Glue	Data Catalog 連携。EventBridge などAWS基盤により整備可能。	クロスプラットフォームなデータガバナンスは弱め。
Embulk	外部依存。シンプルなジョブには向くがガバナンスは弱い。	大規模なジョブ管理／リトライは難しい。
DataSpider Servista	GUIで可視化管理／リトライ／監視が整備。	特になし（中規模用途では優秀）。
Talend	ガバナンス機能がしっかり整備（MDM などと組み合わせ可能）。	特になし（大規模用途でも活用される）。
Informatica IDMC	ガバナンス／リトライ／データ品質が最強クラス。	特になし（エンタープライズ標準対応）。

インフラ運用

使うにあたってインフラ管理の運用のしやすさを比較しています。

製品名	インフラ運用
Apache Spark	クラスタ構築／保守が必要。マネージド Spark（Databricks 等）利用で簡素化可。
AWS Glue	フルマネージド。サーバーレスで管理負荷が低い。
Embulk	軽量ジョブ実行環境が必要。cron／Airflow 等と組み合わせが一般的。
DataSpider Servista	GUIサーバ／エージェントで運用。オンプレ／クラウドどちらにも対応。
Talend	Talend Cloud ならマネージド運用可。オンプレ Studio は自前管理。
Informatica IDMC	クラウドネイティブで完全マネージド。セキュリティ／運用負荷は最小。

製品	強み	弱み
Apache Spark	マネージド版（Databricks 等）なら柔軟。	クラスタ構築／運用保守は高コスト。
AWS Glue	完全マネージド。運用負荷が非常に低い。	AWS クラウド依存。マルチクラウドでの一元管理は不得意。
Embulk	軽量／cron等で簡単実行。	運用自動化や大規模な環境には向かない。
DataSpider Servista	GUIサーバ中心の運用が容易。	マネージド SaaS 版ではなく、自前管理要素が残る。
Talend	Talend Cloud ならマネージド。	オンプレ版はインフラ運用負荷が残る。
Informatica IDMC	クラウドネイティブで完全マネージド。	特になし（運用面では最上位クラス）。

ELT とは

ELT (Extract, Load, Transform) は、まずデータをDWHにロードし、その後にDWH内でTransformを実行するアーキテクチャです。
データ量が増加している現代では、DWHのスケーラビリティと性能を活用して変換処理を行う ELT パターンが広く利用されています。

ELT製品としては以下を対象に比較します。

• dbt（Transform専用）
• Airbyte（Extract / Load専用）

変換機能

文字コード変換・改行コード変換・データフォーマット変換・圧縮/解凍処理・項目マッピング・フィルタリング・データの結合・データクレンジングといった機能性に対して機能性があるかないかを比較しています。

製品名	ETL主な機能性
dbt	T（Transform）に特化。SQLベースで変換／フィルタリング／マッピング／データクレンジングは得意。E/Lは別途必要。文字コード／改行コード変換はSQLで対応可能。ファイル操作は非対応。
Airbyte	E/L特化。ファイルフォーマット変換（CSV→DBなど）は得意。項目マッピングは簡易対応（UIあり）。Transform は「Basic Normalization」＋ dbt連携で実現。データクレンジングは基本外部ツール依存。

対応文字コード

製品によって対応している文字コードに制約がないかを比較しています。

製品名	対応文字コード
dbt	対象データウェアハウスの対応に準ずる（基本UTF-8）。変換はSQLで可。
Airbyte	ソース側／ターゲット側に準拠。Airbyteが自動でUTF-8へ変換対応。

対応フォーマット

製品によって対応しているファイルや、データのフォーマットに差がないかを比較しています

製品名	フォーマット
dbt	データウェアハウス内部のフォーマット（テーブル／ビュー）。ファイル操作は対象外。
Airbyte	CSV／JSON／Avro／Parquet／JDBC／SaaSAPI など幅広くEL対象に対応。ファイル／API／DB からデータをロード可能。

接続先の柔軟性

製品によって接続可能なシステムの主なものを比較しています

製品名	コネクタ／接続対象
dbt	データウェアハウス（Snowflake／BigQuery／Redshift／Databricks／Postgres／その他SQL）
Airbyte	600以上のコネクタ。SaaS／DB／API／ファイルなど幅広いE/L用ソース／シンクに対応。

開発生産性

使うにあたって開発生産性がどれだけあるかを比較しています

製品名	開発生産性
dbt	SQL＋YAMLで開発。dbt Cloud の GUI 補助あり。コード品質／テスト文化が強い。
Airbyte	GUI操作中心。E/L設定は簡単。Transform 部分は dbt連携前提で若干手間が残る。

コーディング言語

開発生産性に関係している内容ですが、コーディングが可能な場合対応している言語が何かを比較をしています。コーディングには、用途による向き不向きとなるため、強み、弱みの比較はしていない。

製品名	コーディング言語
dbt	SQL＋YAML（Jinjaテンプレートあり）。
Airbyte	JSON UI中心。必要に応じてコネクタは Python／Java／TypeScript で拡張可能。

運用・ガバナンス対応

使うにあたって運用のしやすさを比較しています。

製品名	ガバナンス／リトライ
dbt	バージョン管理／テスト／ドキュメント自動生成（dbt core／dbt Cloud）。リトライはワークフロー側（Airflow／Dagster／dbt Cloud）。
Airbyte	UIでリトライ設定／失敗時自動再試行あり。ガバナンスは軽め（エンタープライズ版は強化されている）。

インフラ運用

使うにあたってインフラ管理の運用のしやすさを比較しています。

製品名	インフラ運用
dbt	dbt Cloudならマネージド。dbt Coreは自前で実行環境（CI/CDなど）が必要。
Airbyte	Airbyte Cloudはマネージド。OSS版はDockerベースの自前運用が必要。

強み・弱み比較表

製品名	強み	弱み
dbt	SQL Transform に特化。データ品質担保が強力。 データモデリングやドキュメント自動生成ができる。	E/L機能は持たない。他ツールとの併用前提。ファイル系変換には向かない。
Airbyte	簡単に大量のソースからデータをEL可能。 GUIベースでノーコード。コネクタが豊富。	Transform はBasicレベル。複雑な変換はdbt連携や別途実装が必要。ガバナンスはやや軽め。

まとめ

ETL／ELTはそれぞれ得意領域が異なります。 ETL製品はGUIや企業向け連携に強みがあり、ELTはDWH＋SQL活用による柔軟性が強みです。

近年は「ETL＋ELT」のハイブリッド活用が主流 例：Airbyteで投入 → dbtで整形 → Looker／Tableau等で活用

選定ポイントは以下の通り：

観点 ETL製品群の傾向 ELT製品群（dbt＋Airbyte）の傾向 処理方式 ETL一体型で整形済データを投入 DWH内で変換を行う 開発生産性 GUI中心 or コーディング併用 SQL/YAML中心、GUI一部補助 ガバナンス 製品により差が大きい dbtはテスト文化が強い インフラ運用 マネージド製品増加中 dbt Cloud／Airbyte Cloudが主流化

以上、ETL／ELTの比較と選定の観点まとめでした。 今後は 「ETLとELTの使い分け方針」や「運用上の考慮事項」も別記事で深掘りしてみたいと思います。