分析用のデータをどこに置くかが決まったら、次は、そこへデータをどう運び込み、どこで整えるかを決めることになります。
その運び方の代表的な型が ETL と ELT で、両者の違いは変換をどこで行うかにあります。
この違いが分かると、取り込みの Fivetran と変換の dbt が別々の製品として並んでいた理由や、AWS で Glue・zero-ETL・Redshift がそれぞれどこを受け持つのかにも説明がつきます。
私はデータ基盤を運用したことがなく、各社の公式ドキュメントを読みながら学んでいるところです。
データの置き場所の選び方は、データウェアハウス・データレイク・レイクハウスの違いとして別の記事にまとめました。
ETLとELTとは
ETL は Extract・Transform・Load の頭文字で、データを取り出し、変換してから、保存先へ読み込む処理を指します。
Microsoft の ETL の解説によると、変換の段階では専用のエンジンが業務のルールに沿ってデータを書き換えます。
途中のデータは、ステージングテーブルという一時的な表に置かれることがよくあります。
変換で行うのは、絞り込み、並べ替え、集計、結合、クレンジング、重複の除去、検証といった操作です。
ELT は順番を入れ替え、取り出したデータをまず保存先へそのまま入れて、変換は保存先の中で行います。
同じ解説は、ETL と ELT の違いは変換を行う場所だけだと説明しています。
ELT では別の変換エンジンを置かず、保存先のデータストアが持つ処理能力で変換します。
AWS の ETL と ELT の比較ページも、ETL は別の処理用サーバーで変換し、ELT はデータウェアハウスの中で変換する、と同じ線で分けていました。
2 つを並べると、次のとおりです。
| 観点 | ETL | ELT |
|---|---|---|
| 順番 | 取り出し → 変換 → 読み込み | 取り出し → 読み込み → 変換 |
| 変換する場所 | 保存先の外にある変換用のエンジンやサーバー | 保存先のデータウェアハウスやレイクハウスの中 |
| 保存先に残るデータ | 変換を終えたデータ | 生のデータと、変換したデータの両方 |
| 向く場面 | 保存先の計算資源が限られている・入れる前に検査が要る | 保存先が計算資源を伸び縮みさせられる・生のデータを残したい |
| 道具の例 | AWS Glue の ETL ジョブ | Fivetran で取り込み、dbt で変換 |
ETL と ELT の違いは、変換の計算をどこにやらせるかにある、と捉えておくと、この先の道具の話がつながります。
なぜELTが増えたのか
ETL では、データ元と保存先のあいだに、変換用のエンジンがもう 1 段挟まります。
AWS の比較ページは、ETL は変換の段階が詰まりどころになりやすく、ELT はデータウェアハウスの並列処理を使えるぶん速い、と比べています。
Microsoft の解説も、ELT なら保存先を大きくするだけで変換の処理性能も一緒に伸びる、と利点を挙げています。
ただし同じ解説には、ELT がうまく回るのは、保存先が変換を効率よくこなせるだけの力を持つ場合に限る、という条件も付いていました。
取り込みの側の Fivetran のドキュメントは、安いクラウドのストレージと強力な列指向のデータウェアハウスによって、壊れやすい ETL のパイプラインは過去のものになった、という立場です。
製品を売る側の言い分ではあるものの、保存先が変換の重さを引き受けられるようになったという見立ては、Microsoft と AWS の説明とも重なります。
もう 1 つの理由は、生のデータを手元に残せることです。
Microsoft の解説は、探索的な分析や将来のスキーマの変更に備えて生のデータを取っておきたいときを、ELT を選ぶ場面に挙げています。
変換の誤りに後から気づいても、保存先に生のデータが残っていれば、取り込み直さずに変換だけをやり直せます。
FDE のデータ統合を扱った記事で読んだ Palantir の Foundry も、データを前処理せずに生のまま取り込む方針でした。
加工の記録を、取り込んだ後のパイプラインの側に一か所で残すためです。
どこで使われるか
ELT の構成では、取り込みにあたる E と L と、変換にあたる T を、別々の道具が受け持つことがあります。
その組み合わせとしてよく並べられてきたのが、Fivetran と dbt です。
Fivetranは取り出して入れるところまで
Fivetran は、データ元ごとのコネクタがデータを受け取り、保存先へ書き込むサービスです。
ドキュメントは、データ元をできるだけ変換せずに忠実に写すことを原則に挙げています。
取り込みの途中で行うのは、保存先が扱えない型の変換と、わずかな整形程度です。
取り出しと読み込みは Fivetran が設計して運用し、利用者はその先で使う SQL を書く、という分担が示されています。
データ元で列の型が変わったときは、古い値も新しい値も失わずに入れられる型へ、列の型を自動で広げます。
変換を後回しにするので、保存先には変換前の生のデータが常に残ります。
dbtは保存先の中で変換するところだけ
dbt は、データの取り出しも読み込みもせず、保存先に入ったデータの変換だけを受け持つ道具です。
dbt の公式ドキュメントによると、業務のロジックは SQL の select 文で書き、dbt がそれをモデルと呼ぶ表やビューとして保存先に作ります。
変換の SQL は保存先の中で実行されるので、計算に使われるのは保存先のデータウェアハウスの資源です。
同じページには、データテスト、ドキュメントの自動生成、バージョン管理とプルリクエスト、CI/CD、系譜（リネージ）といった機能が並んでいます。
次は、ドキュメントにあるデータテストの例からの抜粋です。
models:
- name: orders
columns:
- name: order_id
data_tests:
- unique
- not_null
# 略（status 列の accepted_values）
- name: customer_id
data_tests:
- relationships:
arguments:
to: ref('customers')
field: idデータテストの説明によると、テストは条件に反する行を探す select 文として動き、返ってくる行が 0 件なら合格になります。
unique・not_null・accepted_values・relationships の 4 つは、最初から用意されています。
変換の結果をコードと一緒にテストできるので、ソフトウェア開発の習慣をそのままデータの変換に持ち込めます。
2026年6月に1つの会社になった
Fivetran と dbt Labs は、2025 年 10 月 13 日に合併を発表し、2026 年 6 月 1 日に手続きを終えました。
会社は当面 Fivetran + dbt Labs の名前で運営され、発表の中でも、Fivetran は取り込み、dbt は変換と管理を受け持つ製品として紹介されています。
同じ発表は、dbt Core v2.0 を Apache 2.0 ライセンスで公開したことにも触れていました。
発表を読む限り、取り込みと変換を分ける ELT の分担は、会社が 1 つになった後も製品の切り分けとして残っています。
AWSで組むなら
AWS のサービスに置き換えると、受け持ちは次のように分かれます。
| 受け持ち | Fivetran・dbt の場合 | AWS のサービスの場合 |
|---|---|---|
| SaaS からの取り込み（EL） | Fivetran のコネクタ | Amazon AppFlow・Glue の zero-ETL 統合 |
| 業務の DB からの複製（EL） | Fivetran のデータベースのコネクタ | Aurora・DynamoDB などの zero-ETL 統合 |
| 保存先の中での変換（T） | dbt | Redshift や Athena で実行する SQL |
| 保存先の外での変換（ETL） | 行わない（Fivetran の変換は最小限） | AWS Glue の ETL ジョブ |
AWS Glue は、70 を超えるデータ元につながり、ETL・ELT・ストリーミングを 1 つのサービスで扱えるサーバーレスのデータ統合サービスです。
ETL のジョブは Apache Spark を土台にしたサーバーレスのエンジンで動き、AWS Glue Studio の画面で変換の流れを組み立てることもできます。
Glue の zero-ETL 統合は、Salesforce・ServiceNow・Zendesk などの SaaS や DynamoDB から、Redshift や Amazon SageMaker のレイクハウスアーキテクチャへデータを写す仕組みです。
Aurora から Redshift への zero-ETL 統合は、OLTP と OLAP の違いを扱った記事で取り上げました。
Amazon AppFlow は、Salesforce のような SaaS と、S3・Redshift などの AWS のサービスとのあいだで、コードを書かずにデータをやり取りするサービスです。
変換の側では、dbt が Redshift・Athena・Glue 向けのアダプタを信頼済みのアダプタとして載せていて、AWS の保存先にも dbt を組み合わせられます。
先に知っておく用語
ETL と zero-ETL の短い定義は OLTP と OLAP の記事の用語集に置いたので、ここではそれ以外に出てくる言葉を確かめておきます。
- ステージングテーブル: 変換の途中のデータを一時的に置いておく表
- コネクタ: データ元ごとの取り出し方をまとめた部品。Fivetran や AppFlow は、この単位でつなげるデータ元を増やしている
- モデル: dbt で、SQL の select 文 1 つで定義する変換後の表やビュー
- マテリアライゼーション: dbt のモデルを、ビュー・テーブル・インクリメンタルなど、保存先にどの形で作るかの設定
- データテスト: 変換の結果について「この列に重複がない」のような条件を確かめる SQL
- コントロールフロー: 取り込みや変換の作業をどの順番で動かし、前の作業が成功や失敗で終わったときに次をどうするかを決める流れ
- リバース ETL: 変換を終えたデータを、分析の側から CRM などの業務のツールへ戻す処理
いつ使わないか
ELT が広く使われるようになった今でも、ETL を選ぶ場面や、取り込みの道具そのものが要らない場面があります。
| 状況 | 選ぶもの | 理由 |
|---|---|---|
| 個人情報などを、保存先へ入れる前に外したことを確かめる必要がある | ETL、または取り込み時の列の除外・ハッシュ化 | ELT では生のデータがそのまま保存先に入る |
| 保存先の計算資源が限られていて、重い変換に耐えられない | ETL | 変換の負荷を保存先の外へ逃がせる |
| 複雑な業務のルールに、専用の変換エンジンが要る | ETL | 保存先の SQL だけでは書きにくい |
| 機器の近くで、送る前にデータを絞り込んだり形式を変えたりしたい | ETL（エッジでの処理） | 保存先へ届く前に変換が要る |
| 届いたその場で処理したい | ストリーミング処理 | ETL も ELT も、決まった間隔のバッチで動くことが前提 |
| データ元が Aurora や DynamoDB のように AWS の中にある | zero-ETL 統合 | 取り込みの仕組みを AWS が用意して管理する |
| データが小さく、変換も数本の SQL で足りる | 保存先の SQL だけ | 道具を増やすと、その保守も増える |
Microsoft の解説は、規制やコンプライアンスの要件で、読み込む前に整えたデータの監査が求められる場合を、ETL を選ぶ理由に挙げています。
AWS の比較ページも、ETL では個人情報のマスキングのような保護の仕組みを開発者が作る必要がある、と書いていました。
裏を返すと、ELT で何も手を打たなければ、個人情報も生のまま保存先へ入ります。
データ元が Aurora や DynamoDB のように AWS の中にあるなら、外部の道具を足す前に、zero-ETL 統合で足りるかを確かめる手があります。
変換を保存先に任せられるなら ELT、保存先に入れる前に止めたいものがあるなら ETL、と考えると最初の判断がしやすくなります。
課金と落とし穴
ELT は道具が分かれるぶん、課金も取り込み・変換・保存先のそれぞれに分かれます。
課金の軸
金額は改定されやすいので、ここでは何に対して払うかだけを挙げます。
- Fivetran: 月ごとに同期した重複のない行の数（Monthly Active Rows）で数える。同じ月に何度同期しても 1 行は 1 回だけ数え、最初の同期で取り込む過去のデータには費用がかからない。変換の機能はモデルの実行回数で別に数え、MAR には含めない
- dbt で回す変換: SQL は保存先で実行されるので、Redshift や Athena の計算の課金がそのままかかる。それぞれの課金の軸は OLTP と OLAP の記事で触れた
- AWS Glue の ETL ジョブ: 使った DPU の時間で、秒単位に課金される。1 DPU は 4 vCPU と 16 GB のメモリにあたる
- Glue の zero-ETL 統合: 統合そのものに追加の料金はかからない。SaaS などのアプリから取り込む場合は受け取ったデータ量で課金され、写した先の Redshift などの料金も別にかかる
Fivetran の数え方の詳細は料金の仕組みのページに、Glue の課金の軸は AWS Glue の料金ページにまとめられています。
生のデータには個人情報もそのまま入る
Fivetran には、個人情報を含む表や列を同期の対象から外す、データブロッキングという機能があります。
列のハッシュ化を選ぶと、取り込んだ値をハッシュ値に置き換えてから保存先へ書き込みます。
ドキュメントによると、ハッシュ化した列は、データどうしを結合するキーとしては使い続けられます。
ただし、主キーの列は外すこともハッシュ化することもできません。
データブロッキングと列のハッシュ化の説明には、対応するコネクタの範囲も書かれています。
どの列を保存先に入れてよいかを決めるのは、責任共有モデルでいう利用者の側の仕事です。
削除した行が消えずに残る
Fivetran の多くのコネクタでは、ソフトデリートという同期の方式が既定になっています。
データ元で行が削除されると、保存先では行を消さずに、_fivetran_deleted という列を TRUE にして削除済みの印を付けます。
集計する側がこの列を見ずに数えると、削除済みの行まで件数や売上に入ってしまいます。
ソフトデリートの説明は、再同期の最中は削除の印が一時的に正しくないことがあるとして、再同期が終わるまで下流の読み手を止めるよう勧めていました。
全件を作り直す変換が毎回走る
dbt のモデルをテーブルとして作ると、実行のたびに表をまるごと作り直します。
dbt のマテリアライゼーションの説明は、テーブルは問い合わせが速い代わりに、作り直しに長い時間がかかることがあると書いています。
新しい行だけを変換するインクリメンタルモデルにすれば、作り直しの時間を大きく減らせます。
それでも同じページは、dbt run が遅くなってから使うもので、最初からインクリメンタルにはしないよう勧めていました。
インクリメンタルモデルでも、最初の 1 回だけは元のデータの全行を変換して表を作ります。
次は、インクリメンタルモデルの説明にある例からの抜粋で、コメントは日本語に置き換えました。
{{
config(
materialized='incremental'
)
}}
select
*,
my_slow_function(my_column)
from {{ ref('app_data_events') }}
{% if is_incremental() %}
-- 2 回目以降の実行でだけ、前回までに入れた最新の event_time 以降の行に絞る
where event_time >= (select coalesce(max(event_time),'1900-01-01') from {{ this }} )
{% endif %}ELT では変換の計算を保存先で払うので、全件を作り直す表が増えるほど、保存先の請求も増えていきます。
他クラウドでは
Google Cloud では、BigQuery Data Transfer Service が取り込みを、Dataform が変換を受け持ちます。
BigQuery Data Transfer Service は、Salesforce・ServiceNow などの SaaS や Amazon S3、Redshift から、決まった間隔で BigQuery へデータを運ぶサービスです。
Dataform の説明は、自らを ELT の変換の部分を受け持つサービスと位置づけています。
データ元から取り出して BigQuery へ読み込んだ後のデータを、テストとドキュメントのそろった表へ変換するのが Dataform の役目です。
保存先の外で変換する処理には、バッチとストリームのデータ処理をまとめて扱う Dataflow があります。
Azure では、Azure Data Factory が ETL と ELT の両方を扱うデータ統合サービスです。
公式の概要には、コピーアクティビティでデータを 1 か所に集め、その後でマッピングデータフローを使って変換する流れが書かれています。
マッピングデータフローは Spark の上で動き、クラスターを自分で管理しなくても変換を組めます。
Azure Data Factory の概要は、Microsoft Fabric の Data Factory を次の世代と位置づけ、新しく始めるならそちらからと勧めています。
dbt の信頼済みのアダプタには、BigQuery や Microsoft Fabric のウェアハウス向けのものも含まれていました。
ここまでのサービスを 3 社で並べると、次のとおりです。
| 受け持ち | AWS | Google Cloud | Azure |
|---|---|---|---|
| 取り込み（EL） | AppFlow・Glue の zero-ETL 統合 | BigQuery Data Transfer Service | Data Factory のコピーアクティビティ |
| 保存先の中での変換（T） | Redshift・Athena の SQL | Dataform | Fabric のウェアハウス・レイクハウス |
| 保存先の外での変換（ETL） | Glue の ETL ジョブ | Dataflow | Data Factory のマッピングデータフロー |
参考
本文のリンクで紹介した公式ドキュメントと発表は、いずれも 2026-10-04 に参照しました。
製品の名前や機能、料金は変わることがあり、Fivetran と dbt Labs のように会社の形ごと変わる例もあるので、構成を決める前にはリンク先の最新の記述を確かめてください。
最後に
ETL は保存先の外で変換してから入れ、ELT は生のまま入れてから保存先の中で変換します。
Fivetran と dbt は ELT の取り込みと変換を分けて受け持つ道具で、AWS では AppFlow や zero-ETL 統合と、Redshift・Athena の SQL や Glue がそれぞれの役にあたります。
ELT の保存先として名前がよく挙がる Snowflake は、ストレージとコンピュートの分離から別の記事で整理しました。
資格試験では、AWS の SAA-C03 のタスク 3.5 が、データの取り込みと変換のソリューションを扱う領域です。
AWS Certified Data Engineer – Associate（DEA-C01）は、第 1 分野がまるごと「データの取り込みと変換」で、Glue や AppFlow のほか、Amazon MWAA などを使ったパイプラインのオーケストレーションも並んでいます。
変換を書き始める前に、生のデータを保存先に置いてよいかと、変換の計算をどこで払うかを決めておくと、ETL か ELT かはおのずと絞られます。
以上です。
コメントを残す