📚 関連書籍
※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。
####『ゼロから触ってわかった！dbt実務入門 非公式ガイド SQLで作るモダンデータ変換・テスト・ドキュメント・セマンティックレイヤー』
本書は、dbtをこれから学びたい方、SQLを使ったデータ変換をより体系的に管理したい方、データ基盤やモダンデータスタックに関心がある方に向けて書いた入門書です。
https://amzn.to/3SmxlJz
ETLとELTの違い
dbtを理解するうえで欠かせない考え方が、ETLとELTの違いです。
どちらも、業務システムや外部サービスからデータを集め、分析に使える形へ整えるためのデータ処理の流れを表しています。
ただし、大きく違うのは、
データをいつ、どこで変換するか
です。
ETLは、Extract、Transform、Loadの略です。
ELTは、Extract、Load、Transformの略です。
どちらも最初にデータを取得する点は同じです。
しかし、ETLではデータをデータウェアハウスへ格納する前に変換します。
一方、ELTでは、まずデータをそのままデータウェアハウスやレイクハウスへ格納し、その後で変換します。
この順番の違いが、現代のデータ基盤において非常に重要な意味を持ちます。
データ基盤の処理は「どこで変換するか」が重要
データ基盤では、単にデータを集めるだけでは不十分です。
業務システムから取得したデータは、そのままでは分析に使いにくいことが多いからです。
たとえば、次のような状態です。
- カラム名がシステム都合のままになっている
- 日付形式が統一されていない
- コード値の意味が分かりにくい
- 不要なレコードが含まれている
- 複数テーブルを結合しないと意味のある指標にならない
- 欠損値や重複が含まれている
そのため、分析用に使う前には、何らかの変換処理が必要になります。
ここで重要になるのが、
その変換をどこで行うのか
という考え方です。
データウェアハウスへ格納する前に変換するのか。
それとも、いったんデータ基盤へ入れてから変換するのか。
この違いが、ETLとELTの違いです。
従来のETL
従来のETLでは、業務システムからデータを抽出し、専用のETLツールやバッチ処理の中でデータを加工してから、データウェアハウスへロードしていました。
たとえば、販売管理システムから売上データを取り出し、次のような処理を行います。
- 日付形式を変換する
- 不要なカラムを削除する
- 商品マスタと結合する
- 欠損値を補正する
- 分析用のカラム名へ変換する
- 集計しやすい形に整える
そのうえで、データウェアハウスへ保存します。
つまりETLでは、
入れる前にきれいにする
という考え方が中心です。
この方式は、オンプレミス環境や高価なデータウェアハウスを使っていた時代には合理的でした。
当時は、データウェアハウスの保存容量や処理能力が限られていたため、必要なデータだけを事前に整えて格納することが重要だったからです。
データウェアハウスに余計なデータを入れると、コストやパフォーマンスに影響しやすい。
そのため、事前に必要な形へ加工してからロードするETLが広く使われてきました。
ETLのメリット
ETLには、現在でも有効なメリットがあります。
代表的なものは次の通りです。
- データウェアハウスに入る前に品質を整えられる
- 不要なデータを事前に除外できる
- 保存するデータ量を抑えやすい
- 用途が明確な場合は処理を最適化しやすい
- 既存のETLツール資産を活用できる
特に、データ利用目的が明確で、必要なデータ項目も決まっている場合には、ETLは分かりやすい方式です。
たとえば、定型帳票や固定レポートを作るために、毎日同じ形式のデータを作成する場合には、ETLでも十分に対応できます。
ETLの課題
一方で、ETLにはいくつかの課題があります。
まず、変換処理がデータウェアハウスの外側に存在するため、処理内容が見えにくくなりがちです。
たとえば、次のような状態です。
- 専用ツールの画面上でロジックが作られている
- バッチプログラムの中に変換処理が埋め込まれている
- 一部の担当者しか処理内容を理解していない
- ドキュメントと実際の処理が一致していない
このような状態では、どのようにデータが作られているのかを後から追いにくくなります。
また、変換後のデータしか保存していない場合、あとから別の切り口で分析したくなったときに困ることがあります。
元データの一部を捨ててしまっていると、新しい要件に対応するために、再度データ取得処理から見直す必要が出てきます。
さらに、データ変換の責任が一部のエンジニアや専用ツールに集中しやすい点も課題です。
分析者がSQLで理解できる処理であっても、ETLツールの中に閉じていると、変更や確認に時間がかかることがあります。
クラウド時代のELT
クラウドデータウェアハウスやレイクハウスの普及により、データ基盤の考え方は大きく変わりました。
Snowflake、BigQuery、Databricks、Redshiftなどのクラウド基盤では、大量のデータを保存し、必要なタイミングで高い処理能力を使って変換することが現実的になりました。
その結果、先にデータをそのまま格納し、あとからデータ基盤上で変換するELTの考え方が広がりました。
ELTでは、まず業務システムや外部サービスから取得したデータを、できるだけ元の形に近い状態でデータ基盤へロードします。
その後、SQLを使って、分析用テーブルやデータマートを作成します。
つまりELTでは、
入れる前にきれいにする
のではなく、
入れてから必要な形に整える
という考え方になります。
ELTが実務で使いやすい理由
ELTの大きなメリットは、元データを保持したまま、用途に応じて柔軟に変換できることです。
たとえば、最初は売上分析だけを目的としてデータを使っていたとします。
しかし、あとから次のような分析要件が出てくることがあります。
- 顧客分析
- 商品分析
- 解約分析
- マーケティング分析
- 広告効果分析
- 在庫分析
- 需要予測
このとき、元データがデータ基盤上に残っていれば、新しい分析要件に合わせてSQL変換を追加できます。
データの取り込み処理そのものを大きく作り直す必要はありません。
また、変換処理をSQLで記述できるため、データエンジニアだけでなく、分析者やアナリティクスエンジニアも開発に参加しやすくなります。
SQLは、多くのデータ人材にとって共通言語です。
そのためELTでは、データ変換のロジックをチームで読み、レビューし、改善しやすくなります。
ELTでは元データを残せることが強い
ELTの実務上の強みは、元データを残せることです。
元データを残しておくと、あとから要件が変わったときに対応しやすくなります。
たとえば、最初は不要だと思っていたカラムが、あとから分析に必要になることがあります。
ETLで事前にそのカラムを捨ててしまっていると、再度取り込み処理を見直す必要があります。
一方ELTでは、元データを保持していれば、後からSQL変換を追加するだけで対応できる可能性があります。
つまりELTは、
将来の分析要件の変化に強い
方式だと言えます。
現代のデータ活用では、最初からすべての分析要件が決まっていることは多くありません。
そのため、あとから柔軟に変換できるELTは、実務と相性が良いのです。
dbtはELT時代のTransformを支える
ここでdbtが登場します。
ELTでは、データをロードした後のTransform、つまり変換処理が非常に重要になります。
生データをそのまま置くだけでは、分析や業務利用には使いにくいからです。
たとえば、次のような処理が必要になります。
- カラム名を整える
- データ型をそろえる
- 複数テーブルを結合する
- 不要なレコードを除外する
- 重複を排除する
- ビジネス上の指標を定義する
- BIツールで使いやすいデータマートを作る
こうした処理を、SQLで管理しやすくするのがdbtです。
dbtは、ELTのうち最後のTであるTransformを担当します。
そのため、dbtを理解するには、ETLからELTへの流れを理解しておくことが重要です。
dbtはETL全体を置き換えるツールではない
ここで誤解しやすいポイントがあります。
dbtは、ETL全体を置き換えるツールではありません。
dbtは主に、データ基盤へロードされた後のデータを変換するためのツールです。
つまり、dbtの主な役割は次の通りです。
- データ取り込みそのものではない
- 外部システムからデータを抽出する主担当ではない
- APIからデータを集める主担当ではない
- ロード後のデータをSQLで整える
- 分析しやすいテーブルやビューを作る
- テストやドキュメントとあわせて変換処理を管理する
データ取り込みには、別のETL / ELTツールやクラウドサービスが使われることが一般的です。
dbtは、その後段で、データを分析しやすい形へ整えるために使われます。
この役割を理解しておくと、dbtの位置づけが明確になります。
ETLとELTの違いを整理する
ETLとELTの違いを整理すると、次のようになります。
| 観点 | ETL | ELT |
|---|---|---|
| 処理順序 | Extract → Transform → Load | Extract → Load → Transform |
| 変換タイミング | データ基盤に入れる前 | データ基盤に入れた後 |
| 変換場所 | ETLツールや外部処理 | DWH / Lakehouse上 |
| 元データの保持 | 限定的になりやすい | 保持しやすい |
| 柔軟性 | 事前設計に依存しやすい | 後から変換を追加しやすい |
| 相性の良い環境 | オンプレミスDWH | クラウドDWH / Lakehouse |
| dbtとの関係 | 主担当ではない | Transformを担う |
ETLは、データウェアハウスに入れる前に変換します。
ELTは、データウェアハウスやレイクハウスに入れた後に変換します。
ETLは、事前に用途が明確で、必要なデータだけを整えて格納する考え方に向いています。
ELTは、元データを保持しながら、あとから柔軟に分析用途を広げる考え方に向いています。
どちらが絶対に優れているという話ではありません。
重要なのは、現在のクラウドデータ基盤では、ELTの考え方が非常に実務に合いやすくなっているという点です。
現代のデータ基盤ではELTが主流になりやすい
現代のデータ基盤でELTが使いやすくなっている理由は、クラウド基盤の進化にあります。
クラウドデータウェアハウスやレイクハウスでは、次のようなことが可能になりました。
- 大量データを比較的安価に保存できる
- 必要なときに高い計算リソースを使える
- SQLで大規模データを処理できる
- 処理量に応じてスケールできる
- 元データと加工後データを同じ基盤上で管理できる
これにより、先にデータをためて、後から用途に応じて変換するという考え方が現実的になりました。
そして、このELTのTransform部分を管理する代表的なツールがdbtです。
dbtは、SQL、テスト、ドキュメント、依存関係管理を組み合わせて、データ変換をチームで管理しやすくします。
まとめると
ETLとELTの違いは、
データをいつ、どこで変換するか
にあります。
要点を整理すると、次の通りです。
- ETLはExtract、Transform、Loadの順で処理する
- ELTはExtract、Load、Transformの順で処理する
- ETLはデータ基盤に入れる前に変換する
- ELTはデータ基盤に入れた後に変換する
- ETLは事前に用途が明確な処理に向いている
- ELTは元データを保持しながら柔軟に分析用途を広げやすい
- クラウドDWHやレイクハウスの普及によりELTが実務に合いやすくなった
- dbtはELTにおけるTransformを支える代表的なツールである
dbtは、ETL全体を置き換えるツールではありません。
データ取り込みを担当するのではなく、ロード後のデータをSQLで整え、分析しやすい形へ変換するためのツールです。
この違いを理解しておくと、dbtの役割がより明確になります。
📚 関連書籍
※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。
Databricks／Snowflake／n8n／Salesforce／AI基盤e／POC／要件定義の進め方 を体系的に学べる
「ゼロから触ってわかった！」シリーズをまとめました。
『ゼロから触ってわかった！Microsoft Fabric実務入門 データ統合・分析・BI・AI活用の全体像をやさしく学ぶ出版のお知らせ 』
『ゼロから触ってわかった！ Databricks 本番導入完全ガイド（非公式） ― Serverless・Lakeflow・AI時代のデータ基盤実践 ― 』
『Databricks──ゼロから触ってわかった！Databricks非公式ガイド（2026年更新版）』
クラウド時代の分析基盤を “体験的” に学べるベストセラー入門書。
Databricksの操作、SQL／DataFrame、Delta Lakeの基本、ノートブック操作、SDP（宣言型パイプライン）
Serverless、Genieなどを初心者でも迷わず進められる構成で解説しています。
https://amzn.to/4uIqEj4
『ゼロから触ってわかった！ Snowflake × Databricks次世代データ基盤PoC実践 非公式ガイド』
本書を読み終えたとき、「POCって何から始めればよいのか」が明確になり、「自分たちにもできる」という確信を持てることを目指しています。
https://amzn.to/43qI0oR
『ゼロから触ってわかった！ Snowflake × Databricksでつくる次世代データ基盤 - 比較・共存・連携 非公式ガイド』
SnowflakeとDatabricks――二つのクラウドデータ基盤は、これまで「どちらを選ぶか」で語られることが多くありました。本書は、両プラットフォームをゼロから触り、構築・運用してきた実体験をもとに、比較・共存・連携のリアルを丁寧に解説する“非公式ガイド”です。
https://amzn.to/4efDkIk
Snowflake
ゼロから触ってわかった！Snowflake非公式ガイド ― 基礎から理解するアーキテクチャとCortexによる次世代AI基盤
初めてSnowflakeに触れる方には「最初の一冊」として。
なんとなく使っているけれどモヤモヤしている方には「頭の中を整理する一冊」として。
AI時代のエンジニアを目指すための、確かな燃料となる一冊です。
https://amzn.to/4x1VvZm
「ゼロから触ってわかった！Codex - AIエージェント時代のソフトウェア設計」
本書は、AIエージェントと共に開発する時代において、エンジニアが思考停止せず、主体的に価値を発揮し続けるための指針を提示します。
ツールの使い方ではなく、これからの開発の本質を理解したいすべてのエンジニアへ。
https://amzn.to/4o0repH
「ゼロから触ってわかった！ Claude Code × ChatGPT × Gemini AI共生戦略 -“対立”ではなく“共生”する時代へ」
Claude Code × ChatGPT × Geminiという共生モデルを解説します。
https://amzn.to/4a2dJjC
『ゼロから触ってわかった！スペック駆動開発入門 ― SaaS is dead？AI時代のソフトウェア設計論』
前半では思想や背景を丁寧に整理し、後半ではスペック・実装・実行の三層モデルをサンプルコードとともに具体化します。
https://amzn.to/3RFEZya
####『ゼロから触ってわかった！dbt実務入門 非公式ガイド SQLで作るモダンデータ変換・テスト・ドキュメント・セマンティックレイヤー』
本書は、dbtをこれから学びたい方、SQLを使ったデータ変換をより体系的に管理したい方、データ基盤やモダンデータスタックに関心がある方に向けて書いた入門書です。
https://amzn.to/3SmxlJz
Databricks
『ゼロから触ってわかった！Azure × Databricksでつくる次世代データ基盤 非公式ガイド ―』
クラウドでデータ基盤を作ろうとすると、Azure・Storage・ネットワーク・権限・セキュリティ…
そこに Databricks が加わった瞬間、一気に難易度が跳ね上がります。 “最初のつまづき” を丁寧にほどいていくのが本書です。
https://amzn.to/3QaOzbW
『Databricks──ゼロから触ってわかった！AI・機械学習エンジニア基礎 非公式ガイド』
Databricksでの プロンプト設計・RAG構築・モデル管理・ガバナンス を扱うAIエンジニアの入門決定版。
生成AIとデータエンジニアリングの橋渡しに必要な“実務の型”を体系化しています。
資格本ではなく、実務基盤としてAIを運用する力 を育てる内容です。
https://amzn.to/3PYK4ku
『Databricks認定データエンジニアプロフェッショナル 試験レベル ― 1日3分！気になったところから読めるデータブリックス！魂の100本ノック！』
本書は、Databricks認定データエンジニア・プロフェッショナル相当の論点を、
100個のユースケースに分解し、**“2択の検討”→“解説コラム”→“結論”**でテンポよく叩き込む「魂の100本ノック」です。
暗記ではなく、現場で遭遇する判断ポイント（取り込み・変換・品質・共有・監視・性能/コスト・セキュリティ・ガバナンス・デプロイ・モデリング）を、短い読書時間で反復できるように整えました。
https://amzn.to/4vkLm8K
https://amzn.to/4fhNBF5
Databricks Advancedシリーズ（上／中／下）
Databricksを “設計・運用する” ための完全版実践書
「ゼロから触ってわかった！Databricks非公式ガイド」の続編として誕生した Advancedシリーズ は、
Databricksを触って慣れた“その先”――本格運用・チーム開発・資格対策・再現性ある設計 に踏み込む構成です。
📘 ［上］開発・デプロイ・品質保証編
https://amzn.to/4dGQoGv
📘 ［中］取込・変換・監視・コスト最適化編
https://amzn.to/49zbPHb
📘 ［下］セキュリティ・ガバナンス・トラブルシュート・最適化戦略編
https://amzn.to/4efDkIk
「ゼロから触ってわかった！Databricks × Airbyte」
クラウド時代のデータ基盤を“なぜ難しいのか”から丁寧にほどくガイドが完成しました。
Ingestion / LakeFlow / DLT / CDC をやさしく体系化し、
Airbyte × Databricks の真価を引き出す設計思想まで詰め込んだ一冊です。
https://amzn.to/3XOlV0t
『Databricks──ゼロから触ってわかった！DatabricksとConfluent(Kafka)連携！非公式ガイド』
Kafkaによるストリーム処理とDatabricksを統合し、リアルタイム分析基盤を構築するハンズオン形式の一冊。
イベント駆動アーキテクチャ、リアルタイムETL、Delta Live Tables連携など、
モダンなデータ基盤の必須スキルがまとめられています。
https://amzn.to/42HdmqZ
Salesforce
『ゼロから触ってわかった！Salesforce AgentForce + Data360（Data 非公式ガイド』
Salesforceの最新AI基盤 AgentForce と Data360（Data Cloud） を、実際の操作を通じて理解できる解説書。
https://amzn.to/4u4PyZ2
要件定義（上流工程/モダンデータスタック）
『モダンデータスタック時代の シン・要件定義 クラウド構築大全 ― DWHからCDP、そしてMA / AI連携へ』
クラウド時代の「要件定義」って、どうやって考えればいい？
Databricks・Snowflake・Salesforce・n8nなど、主要サービスを横断しながら“構築の全体像”をやさしく解説！
DWHからCDP、そしてMA／AI連携まで──現場で使える知識をこの一冊で。
https://amzn.to/4nZm0ux
データメッシュ
####『ゼロから触ってわかった データメッシュ入門 ― 思想・型・組織構造から考えるデータメッシュ』
「Data Mesh を導入すべきかどうか」を断言する本ではありません。
自分たちにとって、どこまで分散し、何を共有し、どこに責任を置くのか。
その判断をするための思考の土台を整理する一冊です。
https://amzn.to/3REkyBS
データクリーンルーム
ゼロから触ってわかった データクリーンルーム実践入門 ～ Lakehouse時代のクリーンルームを、思想・設計・マネタイズで読み解く ～
データはあるのに、渡せない。それでも一緒に分析したい——そんな現場の悩みから、本書は始まります。
データクリーンルームを「難しい技術」ではなく、現実の業務でどう使い、どう続けるかという視点で整理しました。
非ITのビジネスパーソンにも読める、実践的な一冊です。
https://amzn.to/4fiG6O2
MCP
『ゼロから触ってわかった！MCPビギナーズガイド』 ― AIエージェント時代の次世代プロトコル入門 アーキテクチャ・ガバナンス・実装―
MCPというプロトコルは、単なる技術トレンドではなく
「AIとシステムの関係性」そのものを変える可能性を秘めています。
SaaS、AIエージェント、ガバナンス、アーキテクチャ、その交差点を一度、立ち止まって整理した一冊です。
https://amzn.to/4nZm0ux
n8n
『n8n──ゼロから触ってわかった！AIワークフロー自動化！非公式ガイド』
オープンソースの自動化ツール n8n を “ゼロから手を動かして” 学べる実践ガイド。
プログラミングが苦手な方でも取り組めるよう、画面操作中心のステップ構成で、
業務自動化・AI連携・API統合の基礎がしっかり身につきます。
👉 https://amzn.to/48Blxca
💡 まとめ：このラインナップで“構築者の視点”が身につく
これらの書籍を通じて、
クラウド基盤の理解 → 要件定義 → 分析基盤構築 → 自動化 → AI統合 → 運用最適化
までのモダンデータスタック時代のソリューションアーキテクトとしての全体像を
「体系的」かつ「実践的」に身につけることができます。
- PoC要件整理
- データ基盤の要件定義
- チーム開発／ガバナンス
- AIワークフロー構築
- トラブルシュート
など、現場で直面しがちな課題を解決する知識としても活用できます。