dbt State で、runs を最適化

*本スライドは、dbt World Tour Tokyo 2026 (https://www.getdbt.com/events/roadshow/dbt-world-tour-tokyo-agenda) で発表したものです。

ほとんどの dbt プロジェクトは、変更の有無にかかわらず、runごとに同じモデルを再構築しています。dbt State はそれを変えます。

Run のたびに、dbt State はウェアハウスのメタデータとモデルの SQL をチェックし、結果が変わるかどうかを意味的に判断した上で、build、skip、clone、または本番環境への auto-defer のいずれかを決定します。その結果、平均30%のコンピュート削減、無駄な再構築のないより新鮮なデータ、そして scheduler の速度ではなく、あなたの思考の速度で進む dev cycles を実現します。

このセッションでは、dbt State の仕組み、upstream の変更をどう解決するか、freshness SLA によってスケジュールではなくビジネスの都合に合わせた再構築がどう可能になるか、そして本番環境からの auto-cloning がコストをかけずにローカルでの iteration をどう加速するかをご紹介します。

Transcript

1. dbt State で、runs を最適化: コンピュートの削減、データの鮮度向上、 そしてより速い iteration を実現 三角 勇貴 Partner Solutions Architect dbt Labs
2. Agenda 01 dbt State とは 02 デモ 03 dbt State の仕組み 04 今後の展望と始め方
3. Agenda 01 dbt State とは 02 デモ 03 dbt State の仕組み 04 今後の展望と始め方
4. 859k 毎日スケジュール実行される dbt ジョブ数 多くの場合、データはほとんど変わっていない。 何千ものモデルが、同じ結果のために再ビルドされている。 ムダなビルドが、 時間とコンピュートを浪費する
5. これまでのトレードオフ コストを取るか、シンプルさを取るか コンピュートコスト ジョブの複雑性
6. dbt State 変更があったものだけをビルドし、変更がないものはスキップ オーケストレーションの簡素化 複雑なスケジュールではなくコードでデータ鮮度を定義し、ビ ジネスに必要な頻度で実行 ガバナンスを効かせた、素早い開発 高コストなミスや変更を恐れず、素早くイテレーションを回す パフォーマンスの最適化 上流で変更があったものだけをビルドし、コンピュートとビル ド時間を削減* *design partner の実績に基づく平均15〜30% のコンピュート削減。削減幅はプロジェクト構成やワークロードにより異なります。
7. オーケストレーションの簡素化 モデル設定にデータ鮮度の定義を集約し、ビジネス要件に対応 シナリオ：データ鮮度 SLA として、 毎時・毎日・毎週 のモデルが混在している これまで dbt State ジョブ 1 毎時 （000 を除く） ジョブ 毎時 dbt build -s tag:hourly dbt build ジョブ 2 毎日 000 （月曜を除く） dbt build -s tag:hourly tag:daily ジョブ 3 月曜 000 dbt build -s tag:hourly tag:daily tag:weekly # models/marts/_models.yml models: - name: fct_finance_daily config: lag_tolerance: 24h
8. ガバナンスを効かせた、素早い開発 高コストなミスや変更を恐れず、素早くイテレーションを回す 開発環境 本番環境から再利用 変更部分のみビルド
9. AI Agent のガードレールとして コンピュートの浪費を未然に防止 dbt State なし model build dbt State あり model build 変更分のみ dbt State
10. 「モデルに SLA を宣言し、実行が必要なものをモデル側で判断させることで、パイロットプロジェクトではすでに 25〜30% のモデル再利用と約 15% の Snowflake コスト削減を実現しています。」 — Alvin Chai, Senior Analytics Engineer, Fanatics 「コスト削減もうれしいですが、開発体験が素晴らしいです。巨大なリネージの中の 1 つのモデルを、上流をビ ルドしたり prod を dev に手動でコピーしたりせずに編集できるようになり、チームの働き方が大きく変わりま した。」 — Mykkel Rydal, Lead AI & Data Platform Engineer
11. dbt が動く場所なら、どこでも使えます 従量課金制の dbt アカウントを作成してください。 dbt platform の利用は 必須ではありません。 platform のアップグレードは不要。dbt State はどこでも動きます！
12. Agenda 01 dbt State とは 02 デモ 03 dbt State の仕組み 04 今後の展望と始め方
13. dbt StateデモのXポスト
14. dbt platformで見るdbt State – Cost Insights
15. dbt platformで見るdbt State – Deploy Jobの実行結果 1/2
16. dbt platformで見るdbt State – Deploy Jobの実行結果 2/2
17. Agenda 01 dbt State とは 02 デモ 03 dbt State の仕組み 04 今後の展望と始め方
18. 仕組み 1/2 dbt State のアーキテクチャ概要 Control Plane Data Plane (hosted: US GCP) (hosted: wherever you run dbt) 1. dbt run dbt State クライアント dbt State 3. target table, model query, timestamps 5. {build, skip, clone, defer} dbt State サービス 4. 合致レコードを見つける 2. 関連テーブルの最終変更日時を取得 6. 実行または再利用 データウェアハウス dbt State キャッシュ
19. 仕組み 2/2 – dbt State のコンピュート最適化戦略 skip・clone・defer で、build を必要最小限に抑える コード・データの変更を検知 再ビルドで結果は変わらない？ Yes skip Yes clone No 他の環境に同じテーブルがある？ No defer / build
20. 主要な設定 lag_tolerance 利用例 前回ビルドから、指定の時間は再ビル ドしない 環境ごとに異なるデータ鮮度を指定したい → jinja expressionで条件評価 require_fresh_data_from 利用例 親の「いずれか (any) 」か「すべて (all) 」に新データが来たら再ビルド 複数ソースを join するモデルで、当該ソー スが全て最新であるべき場合→ all allow_clones 利用例 他の環境から対象ターゲットへclone して良いか 社内ポリシー等の理由で、他環境から本番 環境への clone を許可しない場合 → prod profile で false models: +state: lag_tolerance: >{{ '4h' if target.name == 'prod' else '7d' }} models: +state: require_fresh_data_from: all # profiles.yml outputs: prod: allow_clones: false
21. Agenda 01 dbt State とは 02 デモ 03 dbt State の仕組み 04 今後の展望と始め方
22. 今後の展望 Lag tolerance recommendations: sub-project や model 単位で SLA を設定してプロ ジェクトを最適化し、コスト削減効果をさらに拡大 Column-aware reuse: コードの変更が下流で使われているカラムに実際に影響する場合に のみ model をビルド … and more!
23. Lag tolerance recommendations 過去30日の実行実績から、よりビルド時間削減が見込める設定値を、モデルごとに推奨する
24. 無料トライアルから、ぜひお試しください！ V1.7 to V1.12 V2.0.0 Platform