Open6
【dbt】dbt アドホック

dbt導入環境で、分析タスクを実施するときの対応を検討する

jupyter notebookでdbt使えるパッケージ
良さそうでけどメンテされてなさそう

adhoc クエリの共存
想定するユースケース
- 分析した結果が内部でのみ利用される
- 新規事業やF/Sで始めたABテストの初速結果を振り返るなど、正確さよりもスピードが求められる状況
- 分析結果だけを完全に信じるわけではなく、あくまでも参考値として扱い、他の定性分析等を組み合わせて事業判断がなされる
![]()
- adhoc view を再利用するようになったら、強制的にadhocから退場させるようなリファクタリングの仕組み、ルールを作る必要がありそうです。
- アドホッククエリのリファクタリングはあまり進まなかった。

[dbt] Analysesでアドホックなクエリを開発する
analysesディレクトリ
- dbt runの対象外
- 実体化されない(テーブルやビューにならない)
- Jinjaやマクロ等は使える(Modelを開発するときと全く同じ環境でSQLが書ける)
分析データ量が増えてくると中間テーブルが作成したくなるので、いまいち

背景: アドホックなモデルをいつまでも残したくない
アドホックなモデルがいつから運用されているか機械的に把握する
アドホックなモデルにdeprecation_dateを付与する
レイヤリングを設計するということは設計したレイヤリングに沿わないデータリネージは基本的には許さない、ということを意味します
- 例: マートからデータレイクを直接参照しない
で対処可能

複数人がレビューすることで、より信頼性の高いデータを算出できる