dbt徹底解説：SQLパイプラインを変革するdata build tool

問題：もう誰も把握できない自前のSQLパイプライン

私たちが引き継ぐデータ基盤の多くで、同じ光景が繰り返されます。データ変換は、cronで起動されるSQLスクリプトの積み重ね、3年前に書かれたストアドプロシージャ、そして誰もテーブルの更新順序を正確には知らないまま全体を起動するオーケストレーターの上に成り立っています。ダッシュボードの数値が間違っていても、原因のクエリを突き止めるのに半日かかります。アナリストが辞めれば、その業務ロジックも一緒に去っていきます。

問題の核心はSQLではありません。SQLは十分に役割を果たします。問題は、SQLの周りにエンジニアリングが欠けていることです。きちんとしたバージョン管理がない、テストがない、依存関係の明示的な管理がない、最新のドキュメントがない。dbtが埋めるのは、まさにこの空白です。

dbtが実際に行うこと

dbt（data build tool）は、ソフトウェアエンジニアリングの実践をデータ変換レイヤーに持ち込むオープンソースのフレームワークです。ここではモデルを書きます。Gitでバージョン管理されたSQLファイルで、それぞれがデータウェアハウス内のテーブルまたはビューを生成します。残りはdbtが引き受けます。

• 依存関係の管理：ref()関数を使うと、dbtがモデルのグラフ（DAG）を自動的に構築し、正しい順序で実行します。手作業でcronを並べる必要はもうありません。
• 品質テスト：一意性、非NULL、参照整合性、許容値などをYAMLで宣言し、実行のたびにチェックします。テストが失敗すれば、誤ったデータがダッシュボードに届く前にパイプラインを止めます。
• 自動生成されるドキュメント：説明、列単位のリネージ、DAGの図がコードとYAMLから生成されるため、常に最新の状態に保たれます。
• Jinjaテンプレート：再利用可能なマクロ、ループ、環境変数により、繰り返しのSQLをコピー&ペーストする代わりに共通化できます。
• マテリアライゼーション：同じモデルを、設定を1行変えるだけで、ビュー、再構築されるテーブル、増分テーブルのいずれにもできます。

重要な点：dbtはデータを移動せず、計算エンジンも持ちません。モデルをSQLにコンパイルし、実行をウェアハウス（BigQuery、Snowflake、Databricks、Redshift、Postgresなど）に委ねます。これはELTアーキテクチャの「T」です。まず生データをロードし、その後データがある場所で変換します。

なぜdbtは従来のETLを置き換えたのか

従来のETLツール（Informatica、Talend）は、データベース内の計算が高価で、ロード前にデータを変換していた時代に作られました。クラウドのウェアハウスはこの方程式を逆転させました。計算は伸縮自在で安価になり、まずすべてをロードしてから変換する方がシンプルになったのです。dbtはこのELTへの転換から生まれました。

その爆発的な普及は、3つの理由に集約されます。SQLで書けるため、独自のGUIツールを学ばなくてもどんなアナリストでも貢献できること。GitとCI/CDにネイティブに統合されるため、データがアプリケーションコードと同じガードレールを継承すること。そしてオープンソースであり、事実上の標準を生み出したこと。アナリティクスエンジニアという職種は、dbtを中心に形作られました。

私たちがクライアントの本番環境でどう導入したか

ある銀行グループでは、データベース費用が膨らみ続けていたRAG基盤の変換レイヤーを再構築しました。場当たり的なクエリの寄せ集めから、増分マテリアライゼーションと体系的なテストを備えたdbtモデルへ移行することで、データ部分のコストを一桁削減し、同時にパイプラインを監査可能にしました。これは銀行環境では譲れない要件です。

あるモビリティ系のデータ基盤（モントリオール/パリのハブ）では、dbtはレイクハウスアーキテクチャの中核に置かれました。継続的な取り込み、オブジェクトストレージ、そしてレイクハウスエンジンの上でdbtが変換レイヤー（ステージング、中間、マート）をオーケストレーションします。dbtが生成するリネージは基盤の生きたドキュメントとなり、テストにより下流のデータ品質インシデントが大きく減りました。

最もうまくいく構成は、ほぼ常に同じです。生データから業務利用可能な状態まで、レイヤーに分けたアーキテクチャです。

1. ステージング層：ソースごとに1モデル、最小限のクレンジング（リネーム、型付け、重複排除）。ここには業務ロジックを置きません。
2. 中間層：複数の出力で共有されるロジックを共通化する、再利用可能な結合や変換。
3. マート層：業務（財務、プロダクト、マーケティング）に公開されるテーブル。BIから直接利用されることを前提に設計します。

FinOps：dbt自体は無料、コストはモデル次第

dbt自体はCore版なら無料です。本当のコスト要因は、ウェアハウス内で発生する計算です。ここでdbtは強力なGreenOpsのレバーにも、使い方次第では浪費の温床にもなります。

• 増分マテリアライゼーション：実行のたびにテーブル全体を再構築するのではなく、新しい行だけを処理します。これがコスト削減の最大のレバーです。
• ビュー vs テーブル：ビューは構築コストはゼロですが、クエリのたびにデータを読み直します。テーブルは構築時にコストがかかりますが、読み取りは高速です。適切な選択は読み取り頻度によります。
• 実行の粒度：ソースが1日1回しか変わらないのに毎時すべてを再構築するのは、無駄に10倍払っているのと同じです。
• 対象を絞った実行：dbtのセレクタを使えば、DAG全体ではなく、変更の影響を受けるモデルだけを再実行できます。

私たちの現場ルール：dbtへの移行は、コードの美しさではなく、移行前後のウェアハウス費用で評価します。最も持続可能なコードは、無駄に実行しないコードです。

dbt Coreか、dbt Cloudか

dbt Coreは無償・オープンソースのコマンドラインツールで、自社のCI/CD（GitHub Actions、GitLab CI）やオーケストレーター（Airflow、Dagster）に組み込みます。dbt Cloudは有償のSaaSで、WebのIDE、マネージドなスケジューラ、ドキュメントのホスティング、きめ細かなアクセス制御を追加します。私たちの基本的な推奨は、まず既存のCI/CDとCoreで始め、チーム規模やガバナンス要件によってマネージドなツールのコストが明確に正当化される場合にのみCloudへ移行することです。

dbtを使うべきでないとき

dbtは万能の答えではありません。次のようなケースでは導入を推奨しません。

• データウェアハウス／レイクハウスがない：dbtはデータがある場所で変換します。基盤となるクラウドウェアハウスがなければ、頼るべきエンジンがありません。
• リアルタイム／ストリーミング変換が必要：dbtはバッチで動作します。ミリ秒単位のストリーム変換には適していません。
• SQLで表現できないロジック：重いPython処理（ML、複雑なパース）はdbtの自然な守備範囲を超えます。一部のウェアハウスではdbtがPythonモデルをオーケストレーションできるようになったとはいえ、です。
• 些細なスクリプト1本だけ：変わることのない安定した3本のクエリのために、dbtを導入する手間は見合いません。

どこから始めるか

dbtへの移行は、一気にすべてを切り替える必要はありません。まず既存の変換を棚卸しし、価値が見えやすい業務領域（財務マート、重要なダッシュボード）を1つ移行し、直近のインシデントを防げたはずのテストを追加し、ウェアハウス費用への影響を測定します。dbtレイヤーはその後、ソースごとに育てていきます。短い定義は用語集のdbtのページをご覧ください。変換レイヤーをコスト・品質・負債の観点から外部の視点で見てほしい場合、それはまさにAbbealが手がけるデータ監査です。