dbt とは何か、そして分析エンジニアリングがデータスタックに革命を起こす理由
dbt は SQL にソフトウェア エンジニアリングをもたらします: Git によるバージョン管理、自動テスト、ドキュメント化 自動生成およびデプロイメントパイプライン。分析エンジニアリングとは何か、その役割を理解する 分析エンジニアの話と、dbt がデータ変換の標準になった理由 Snowflake、BigQuery、Redshift で。
dbt が解決する問題
3 年間にわたってさまざまなアナリストによって作成された SQL クエリでいっぱいのデータ ウェアハウスを想像してください。
何百もの呼び出されたビュー final_v3_DEFINITIVO_bis、計算ロジックが複製されています
10 か所の異なる場所にあり、データ品質を保証するためのテストはなく、文書化もありません
その列が実際に何を意味するのかについて net_revenue_adjusted.
これは、2026 年に与えられたほとんどのチームの出発点です。そして、それはまさにその通りです。 という問題 dbt (データ構築ツール) 解決するために設計されました。
dbt は新しい ETL ツールではなく、パイプライン オーケストレーターでもデータでもありません 倉庫。それはツールです 変換: すでにロードされているデータを取得します。 ウェアハウスに保存し、SQL とプラクティスを使用してすぐに使用できる分析モデルに変換します。 ソフトウェアエンジニアリングの。
ELT と ETL: 世界が変わった理由
何十年もの間、支配的なパラダイムは ETL でした。 抽出する, 変身, 負荷。データはソースから抽出され、中間層に変換されました （多くの場合、専用サーバー上にあります）その後、すでに最終的な形式でデータ ウェアハウスにロードされます。
などのクラウド データ ウェアハウスの出現 雪の結晶, BigQuery e アマゾン赤方偏移 彼はこの論理をひっくり返した。これらのシステムにはコンピューティング能力があります 事実上無制限で、ストレージコストは非常に低いです。データを変換することはもはや意味がありません 前に それらをロードするには、生のままロードして変換することをお勧めします。 dopo、に直接 倉庫。こうしてELTが誕生しました。
ELT と ETL: 根本的な違い
- ETL: ウェアハウスの外での変換 (専用サーバー、Spark、Talend) — 高価で、厳格で、デバッグが困難
- エルト: ウェアハウス内の変換 (ネイティブ SQL) — スケーラブルでコスト効率が高く、テストと文書化が容易
- dbt は非常に優れた ELT ツールです。ソフトウェア エンジニアリングで ELT の T を処理します。
コンクリートのdbtとは何ですか
dbt は、次のことを可能にするコマンド ライン (およびクラウド) ツールです。
- SQL 変換を次のように記述します Git でバージョン管理されたモデル
- 定義する 自動依存関係 マクロを使用したモデル間
ref() - 追加 品質テスト コード内で直接データにアクセスする
- 自動的に生成 ドキュメントと系統グラフ
- これらすべてを 1 つで行う CI/CD パイプライン
dbt テンプレートは、単なる SELECT を含む SQL ファイルです。 dbtはそれを倉庫で実体化します 構成に応じて、ビュー、テーブル、または増分テーブルとして使用できます。
-- models/marts/finance/orders_daily.sql
-- dbt materializza questo come una tabella nel warehouse
SELECT
DATE_TRUNC('day', created_at) AS order_date,
SUM(total_amount) AS revenue,
COUNT(*) AS order_count,
AVG(total_amount) AS avg_order_value
FROM {{ ref('stg_orders') }} -- ref() crea la dipendenza
WHERE status = 'completed'
GROUP BY 1
注意してください {{ ref('stg_orders') }}: dbt は、このモデルが依存していることを知っています
から stg_orders、依存関係グラフ (DAG) を自動的に構築し、
パターンが正しい順序で実行されていることを確認します。
分析エンジニアの役割
DBT の台頭により、新しい専門家が誕生しました。分析エンジニア。 これは、データ アナリストとデータ エンジニアの中間のプロファイルです。
- 彼は SQL をアナリストと同じくらい深く知っています
- エンジニアのようにソフトウェア エンジニアリングの実践 (Git、テスト、CI/CD) を適用する
- データウェアハウス変換レイヤーを構築および維持します
- データ アナリスト (モデルを使用する) およびデータ エンジニア (取り込みパイプラインを管理する) と協力します。
によると、 2025 年のデータ エンジニアリングの現状、分析エンジニアの役割が拡大 LinkedIn では過去 3 年間で 340% 増加しており、データの世界で最も検索されているプロフィールの 1 つとなっています。
2026 年の dbt エコシステム
dbt は単なるツールではありません。dbt は 2 つの主要なディストリビューションを備えた完全なエコシステムになっています。
DBTコア
バージョン オープンソースで無料 DBTの。 pip経由でインストールされ、ラインから動作します コマンドを使用し、あらゆる CI/CD システムと統合します。すべての主要なデータ ウェアハウスをサポート: Snowflake、 BigQuery、Redshift、Databricks、DuckDB、PostgreSQL などをアダプター経由で利用できます。
dbtクラウド
のマネージドサービス dbt研究所、dbtの背後にある会社。 Web IDE、スケジューラを追加します 統合されたモニタリング、dbt Explorer (高度なリネージ)、一貫したメトリクスのための dbt セマンティック レイヤー。 開発者向けの無料プランと、チーム向けの月額 100 ドルのエンタープライズ プランで利用できます。
dbt プロジェクトの柱
dbt プロジェクトには、以前は混乱があった場所に秩序をもたらす標準的な構造があります。
jaffle_shop/ # nome del progetto
├── dbt_project.yml # configurazione del progetto
├── profiles.yml # credenziali di connessione (locale)
├── models/
│ ├── staging/ # modelli vicini alla sorgente
│ │ ├── stg_orders.sql
│ │ ├── stg_customers.sql
│ ├── marts/ # modelli business-oriented
│ ├── finance/
│ │ └── orders_daily.sql
│ └── marketing/
│ └── customer_ltv.sql
├── tests/ # test SQL personalizzati
├── seeds/ # CSV statici come reference data
├── macros/ # funzioni SQL riutilizzabili
└── analyses/ # query ad hoc (non materializzate)この階層構造 (ステージング → 中間 → マート) がベスト プラクティスです。 DBTコール 階層化されたアーキテクチャ:
- ステージング: ソースと 1 対 1、名前を変更して型をキャストするだけ
- 中級: ステージング モデル間の複雑な結合と集計
- 火星: BI と分析で使用できる最終モデル
テストとドキュメント: dbt のキラー機能
データ開発サイクルを完全に変える 2 つの dbt 機能:
自動テスト
各テンプレートに付属する YAML ファイルでテストを直接定義します。
# models/staging/schema.yml
models:
- name: stg_orders
columns:
- name: order_id
tests:
- unique
- not_null
- name: status
tests:
- accepted_values:
values: ['completed', 'pending', 'cancelled']
- name: customer_id
tests:
- not_null
- relationships:
to: ref('stg_customers')
field: customer_id
Con dbt test、dbt はこれらのテストをウェアハウス内で SQL クエリとして実行し、パイプラインに失敗します。
何かが間違っている場合。 Python コードも外部フレームワークも必要ありません。
自己作成のドキュメント
同じ YAML ファイルに説明を追加します。
# models/marts/schema.yml
models:
- name: orders_daily
description: "Aggregazione giornaliera degli ordini completati"
columns:
- name: order_date
description: "Data dell'ordine, troncata al giorno"
- name: revenue
description: "Totale ricavi per il giorno, al netto dei resi"
dbt docs generate && dbt docs serve ドキュメントを含む静的サイトを生成します
完成し、すべてのモデル間の依存関係を示す対話型 DAG が表示されます。それぞれの列は、
文書化され、ソースまで追跡可能です。
最新のデータスタックの dbt
dbt は通常、スタックの T 層です 現代のELT:
- 摂取: Airbyte、Fivetran、Stitch、または Python スクリプトが生データをウェアハウスにロードします
- ストレージ: Snowflake、BigQuery、Redshift、Databricks Delta Lake
- 変換: dbt は生データを分析モデルに変換します
- BI と分析: Looker、Metabase、Tableau、またはノートブックは dbt モデルを使用します
2026 年には、dbt はスタートアップ企業から 30,000 社を超える企業 (dbt Labs データ) のデータスタックに存在します。 GitLab、JetBlue、Conde Nast、Shopify などの大手企業まで。
2026 年に DBT を学ぶ理由
DBT の学習に時間を投資する具体的な理由:
- 市場の需要: データ エンジニアの求人情報の 45% に「dbt」が含まれています ヨーロッパの LinkedIn の分析エンジニア
- 生産性: dbt チームは、費やした時間が 60 ～ 70% 削減されたと報告しています 自動テストによるデータ パイプラインのデバッグ
- 生態系: dbt Hub 上の 200 を超える dbt パッケージ (dbt-utils (ライブラリ) を含む) 標準) と高度なテストの dbt-expectations
- 可観測性: Elementary、re_data、ツールとのネイティブ統合 本番環境での品質監視のためのデータ可観測性
dbt は万人向けではありません
すでにクラウド データ ウェアハウスを持っていて、主言語として SQL を使用している場合、dbt は意味があります。 これは、非構造化データの大規模な変換に Spark の代替となるものではなく、適切でもありません。 リアルタイム ストリーミング パイプライン (Flink、Kafka Streams、または Spark Structured Streaming を使用する場合)。 dbt の優れた点は、SQL ウェアハウスでのバッチ分析です。
結論と次のステップ
dbt は、データ チームが分析パイプラインを構築および維持する方法を再定義し、 ソフトウェア エンジニアリングの成熟した実践 (テスト、バージョン管理、ドキュメント、CI/CD) を 何十年も彼らなしで生きてきた世界。
重要なポイント: dbt は大企業にとってニッチなツールではありません。 アクセス可能でオープンソースであり、バックエンドとして DuckDB を使用して 1 台のラップトップでも実行できます。の SQL を知っている人にとっては学習曲線は低く、報酬は高くなります。
シリーズの次の記事では、dbt コア プロジェクトを最初からセットアップします。dbt をインストールし、次のことを書きます。
の profiles.yml、最初のモデルを作成して、 ref() マクロが動作中
実際のデータセット上で。