dbt meetup #19 『dbtを『なんとなく動かす』を卒業します』

2026/2/25に開催されたdbt meetup #19で紹介した発表資料になります。

【アジェンダ】
今回の発表内容に対するモチベーション
dbt実行の裏側と「なんとなく」で動かすリスク
dbt projectとDWH側（Snowflake）における工夫
まとめ

Transcript

1. © Finatext Holdings Ltd. dbt meetup #19 dbtを『なんとなく動かす』を卒業します 株式会社ナウキャスト 高橋　裕人 2026年2月25日 1
2. © 2026 Finatext Holdings Ltd. • 名前：高橋 裕人 ◦ Zenn：@tilt_max3 • 株式会社ナウキャスト ◦ データエンジニア ◦ 顧客向けデータ基盤構築支援 ◦ 前職：診療放射線技師 => データエンジニア • 趣味 ◦ 釣り（海釣り） ◦ 居酒屋巡り 2 自己紹介
3. © 2026 Finatext Holdings Ltd. 3 Data Service Business ビッグデータを用いたプロダクトを提供する事業。 Data & AI Solution Business データとAIで顧客のDXを支援する事業。 Data Service Platform Unit 事業横断でデータ基盤の高度化、R&Dなどを行うチーム。 Investment Research Unit 機関投資家向けに ビッグデータ分析 SaaSを提供。 Real Estate Unit 商圏分析や売上予測 モデルによる店舗物 件の診断サービスを 不動産会社に提供。 Data Holder Unit 提供元からデータを受領し、データパイプラインの構築を行うチーム。 Engineering Team データエンジニアリングと生成AI活用 に精通したエンジニアリングチーム。 Consultant Team データとAIを用いたDXに 特化したコンサルティングチーム。 Economic Research Unit ビッグデータから計 算したマクロ指数を 金融機関・官公庁等 に提供。 データプロダクトの提供と顧客支援の二つのビジネスを推進 会社紹介
4. © 2026 Finatext Holdings Ltd. データウェアハウス ライセンスデータ データホルダー 解析 POSデータ 日本経済新聞 1,500店舗の スーパーマーケッ ト True Data 4,000店舗の スーパー、 ドラックストア 2,600店舗の 家電小売 クレジットカードデータ JCB JCBカードの 所有者・加盟店 クレディセゾン セゾンカードの 所有者 求人データ 人流データ TV広告データ KDDI 携帯搭載の 地理データ フロッグ 130超の日本の web求人広告 サイト エムデータ 日本の全無料 チャンネンルの TV広告データ 官公庁・シンクタンク・投資家 エンドユーザー 投資家 不動産事業者 オルタナティブデータの商社としての機能を持つ 4 会社紹介（データサービス事業）
5. © 2026 Finatext Holdings Ltd. AWS ECS で dbt コマンドを実行 ELTパイプラインのクエリエンジン、そして Snowsight 等でのデータ分析にSnowflake を利用 Snowflake のリソースは 基本的にTerraformで管理 Airflow で ECS task を スケジュール実行 データ基盤のアーキテクチャ簡易図 5 ナウキャストのデータ基盤
6. © 2026 Finatext Holdings Ltd. • 今回の発表内容に対するモチベーション • dbt実行の裏側と「なんとなく」で動かすリスク • dbt projectとDWH側（Snowflake）における工夫 • まとめ 6 アジェンダ
7. © 2026 Finatext Holdings Ltd. • 実行戦略の統制（dbtをプロジェクトをどう動かすか） ◦ 「最適なマテリアライゼーション（Incremental等）」の実行戦略の意思決定 • データ基盤のガバナンスと統制（dbtプロジェクトおよびデータ基盤を守る） ◦ 基盤のガードレール設計 ◦ DWHの意図しない変更・更新を防ぐ堅牢な権限設計 ◦ AIによるモデル量産に耐えうる、ディレクトリ構造と命名規則の定義。 • セマンティック・コンテキストの提供（dbtプロジェクトをどう進化させるか） ◦ AIエージェントが正しくデータを探索したりビジネスロジックを理解できるように、 Semantic LayerやMetadata（schema.ymlなど）を「AIが読める仕様書」としての整備 7 AIがモデルの開発・コーディングを担う中で、人間がどう安全に品質に責任を持つか Coding Agentがモデルを作る時代に、データエンジニアは何をすべき？
8. © 2026 Finatext Holdings Ltd. そこで 改めて基本に立ち返り そもそも、dbt runの裏側で何が起きているのかを理解した上で dbt projectやDWHの品質をどう担保していったらいいか dbt実行の流れを見ながら考えてみました 8 今回の発表内容に対するモチベーション
9. © 2026 Finatext Holdings Ltd. dbtは、共通機能を持つ dbt-core が、各DWH固有のAdapter（プラグイン）を呼 び出す形式で動作しています。 • dbt-core ◦ https://github.com/dbt-labs/dbt-core ◦ プロジェクトの解析、依存関係(DAG)の構築、Jinjaのレンダリング • dbt-snowflake ◦ https://github.com/dbt-labs/dbt-adapters ◦ Snowflake特有の方言や仕様などを吸収し、dbt実行をオーケストレーションする 今回は、dbt-snowflakeについて整理しました。BigQueryやRedshiftなどadapterに よって、内容が異なる部分があるため注意してください。 9 前提：dbt-coreとdbt-adapters
10. © 2026 Finatext Holdings Ltd. dbt runが実行されると、大きく分けて5ステップで実行される 1. Parse： a. モデルを読み込みmanifest.jsonを作成 2. Compile： a. JinjaをSQLへコンパイル 3. Connection： a. DWHへの接続情報を元にコネクションを作成する 4. Execute： a. 各種materializationごとの処理フローに基づき、DWHにSQLを送信 5. Persist： a. オブジェクトに対する権限付与の実行やschema.ymlのdescription反映 10 本題：dbt runの5ステップ
11. © 2026 Finatext Holdings Ltd. dbt run実行前に、モデル実行に必要なリソースの取得・チェックが実行される 4.1. 必要なRelationの特定 （不足してる場合 CREATE OBJECT 実行） 4.2. on-run-start hooksの実行 4.3. Relation情報の取得 （Database, Schema, Indentifierの決定） 4.4. Pre-hook 実行 ➔ カスタムRelationの取得： ◆ generate_database_name() ◆ generate_schema_name() ◆ generate_alias_name() ➔ カスタムスキーマの設定不備でも、　　　　 新規スキーマが作成されてしまうため注意 11 4. Execute部分の深掘り（実行前処理）
12. © 2026 Finatext Holdings Ltd. Relation（データベースオブジェクトの識別子）の状態によって、実行クエリが異なる 4.5. Relationの状態確認 CREATE OBJECT AS <Compiled Query> CREATE OR REPLACE TABLE AS <Compiled Query> Incremental 更新処理へ Viewの場合 Tableの場合 DROP & CREATE VIEW AS <Compiled Query> 既存なし 既存あり is_full_refresh not_full_refresh 同名Relation かつ 別オブジェクトある場合 DROP OBJECT 実行 12 4. Execute部分の深掘り（Relation状態による分岐）
13. © 2026 Finatext Holdings Ltd. 増分データをTEMPORARY TABLEとして作成し、増分更新を実行する 4.6. 一時Relation作成 （CREATE TMP VIEW/TABLEの作成） 4.7. カラム変更の更新 （ALTER TABLE / ALTER COLUMN） 4.8. Incremental Strategy ごとの更新処理実行 merge append delete+insert microbatch insert_overwrite 13 4. Execute部分の深掘り（Incremental更新処理）
14. © 2026 Finatext Holdings Ltd. モデル実行後の、後処理を実行 4.9. 一時Relationの削除 4.10. post-hooks実行 4.11. apply grants 4.12. persist-docs 4.13. Query Tagのリセット 4.14. 実行結果の集計 ➔ 4.6で作成した一時テーブルやビューを削除 ➔ apply_grantsで、自動的にデータベースの権限を grant/revokeを実行 ◆ Account RoleへのGRANT/REVOKEのみ対 応 ➔ persist_docsで、schema.ymlの内容をテーブル やカラムのディスクリプションに反映 ◆ テーブルに対するALTER TABLE/COLUMN が実行されるOWNERSHIP権限が必要 14 4. Execute部分の深掘り（後処理）
15. © 2026 Finatext Holdings Ltd. 1. dbt実行ROLEにOWNERSHIP権限がついてる必要があるが、OWNERSHIP権限は 単一のROLEにしかつけられない => 複数ROLEを使ってdbt runの実行ができない（SnowflakeではREPLACE実 行にOWNERSHIP権限が必要） 15 浮き彫りになってきた注意点（1/3）
16. © 2026 Finatext Holdings Ltd. 2. transient=falseで実行してもREPLACEされ、Time-Travelで履歴が追跡できな い => 本番データや履歴保持したい要件のあるテーブルに対して --full-refresh実行 materialized=table設定は避ける => materialized=incrementalの利用を検討する 16 浮き彫りになってきた注意点（2/3）
17. © 2026 Finatext Holdings Ltd. 3. CREATE SCHEMA権限はdbt実行ROLEには付与したくない => 開発者によって意図しないスキーマが作成されるリスク 4. Snowflakeアダプターではcopy_grantsがデフォルトfalseのため、trueにしてお かないと権限が引き継がれない => 基本的にはcopy_grants=trueに設定しとく => future grantsで対応（将来作成されるオブジェクトへの権限付与） 17 浮き彫りになってきた注意点（3/3）
18. © 2026 Finatext Holdings Ltd. 1. DWH（Snowflake）側で適切なリソース・権限管理を行う 2. dbt projectの構成・コード品質のチェック・監視を行う 18 ガードレールとしてのアプローチ
19. © 2026 Finatext Holdings Ltd. Service Role 層 Warehouse Account Role project eval Database Warehouse Account Role dbt Exec Access Role 層 dbt CI User dbt Dev User1 dbt Dev User2 dbt Exec User Database Role table-create Database Role table-select tables views Database Role view-create Database Role view-select Functional Role 層 Warehouse Account Role dbt Exec Warehouse Account Role For AI Database Role Ownership Database Role Read ナウキャストでは、ロールを３つの層に分けることで柔軟かつ完結な権限管理を Terrafromで行ってる 19 DWH（Snowflake）側における権限管理
20. © 2026 Finatext Holdings Ltd. • Account Roleではなく、 Database RoleにOWNERSHIP権限を持たせる ◦ Database RoleがTableやViewのOWNRESHIPを持つことで、複数のAccount Roleから 実行可能 （OWNERSHIPの衝突回避） ◦ 一つのdbt実行Roleに過度な権限集中を防止する • Managed Access Schemaを有効にする（スキーマ所有者のみが権限操作可能に） ◦ Terraform定義とのドリフトを予防する • スキーマ内オブジェクト（ TableやView）のみdbtで管理 ◦ CREATE SCHEMA権限はdbt実行ROLEに付与しない ◦ apply_grantsは利用せずに、TerraformでRoleやDatabaseの管理（権限のドリフト防止） • Coding Agentからのデータ品質チェックやデータ探索のクエリ実行用の ReadOnlyなRoleの 利用 ◦ 意図しないテーブル更新や削除を防止する 20 権限管理構成のポイント
21. © 2026 Finatext Holdings Ltd. 項目 dbt-checkpoint dbt-osmosis dbt-project-evaluator 開発フロー CI / Pre-Commit CI / 定期実行 CI / 定期実行 役割・スコープ ミクロな品質担保 コード規則・命名規則の 強制 yml定義の自動同期 DWHとYAMLの整合性維 持 マクロな構造診断 DAGの健全性・アーキテク チャ評価 制御する項目 例 ・命名規則の無視 ・SELECT * の使用 ・schema.yml への追記漏 れ ・削除済みカラムの定義残 留 ・レイヤー構造の無視（中抜 き） ・過度な依存関係（複雑な DAG） ツールによる解 決 ・ 規則違反を即座にブ ロック ・カラム明示を強制 新規カラムをYAMLに自動 追加 不要な定義を自動削除 レイヤー違反のPRをブロック 依存数（fan-out）の警告 21 dbtプロジェクト側における品質チェック
22. © 2026 Finatext Holdings Ltd. 「なんとなく動かす」と ... 1. 意図しないデータ消失 2. 権限エラーでの突然の実行失敗 3. 意図しないオブジェクト作成 実行フローを理解することで ... 1. トラブル時の迅速な原因特定 2. 適切なDWH側での権限設計 3. 最適なdbt project設定（copy_grants、transient等） 4. 最適な実行戦略の決定 予期せぬ品質低下や障害を防ぐために ... • DWH（Snowflake）側で適切なリソース・権限管理を行う • dbt projectの構成・コード品質のチェック・監視を行う 22 まとめ