なむなむ

@namb_nam による恥晒し

dbtのベストプラクティスを知る②

前回の記事
dbtのベストプラクティスを知る① - なむなむ

今回は、最後の2章からPro-tipsを学ぶぞ。

Pro-tips for workflows

Use the model selection syntax when running locally

  • 開発中、作業中のモデルと下流のモデルのみ実行するのが良いことがある
  • モデル選択構文を使用する

Run only modified models to test changes ("slim CI")

  • 自信をもってコード変更をマージするには、それによりプロジェクトの他の場所が壊れないか知っておく必要がある
  • そのために、本番データとは別のサンドボックス環境で、gitワークフローの自動チェックとしてテストするのがおすすめ
  • 同時に、プロジェクト内の全モデルをRun・テストするには時間も金もかかる
  • dbtは、以前の本番Runの成果物と比較して、
    • ①変更されたモデルを判断し、変更されていないモデルの上に構築できる
    • ②モデルやテスト結果のステータスを判断できる
      • result:fail, result:error, result:passなど
  • ③賢く再実行するために、スコープ内のモデルでdbtコマンドを手動で上書きするのではなく、result:<status>ステータスを使う
    • ④誤ったモデルをすべて再実行し、同時に行った、誤ったモデルに関連する可能性のある変更も実行し、下流で使用
    • ⑤誤ったモデルをすべて再実行し、再テスト
      また、誤ったモデルに関連する可能性のある変更を同時に実行し、下流で使用
    • 誤ったモデルや失敗したテストをすべて再実行
    • 誤ったモデルをすべて再実行し、同時に行った、誤ったモデルに関連する可能性のある変更を実行し、下流で使用
    • ⑥変更されたノードやエラーノードとは無関係のテストが失敗している（合格するためにデータロードをリフレッシュする必要があるソーステストと考える）
    • 失敗したテストをすべて再実行し、それでも失敗するとわかっているテストは除外
    • "EL"処理中にソースデータが更新され、リフレッシュ後に再実行が必要な場合にも適用できる
# ①
dbt run -s state:modified+ --defer --state path/to/prod/artifacts
dbt test -s state:modified+

# ③
dbt run --select state:modified+ result:error+ --defer --state path/to/prod/artifacts

# ④
dbt build --select state:modified+ result:error+ --defer --state path/to/prod/artifacts

# ⑤
dbt build --select state:modified+ result:error+ result:fail+ --defer --state path/to/prod/artifacts

# ⑥
dbt test --select result:fail --exclude <example test> --defer --state path/to/prod/artifacts

※--state target/フラグを使用する場合、result:errorとresult:failフラグはdbt buildコマンドを使用する場合のみ同時に（同じコマンドで）選択できます。dbt testは以前のコマンド呼び出しでdbt runからrun_results.jsonを上書きする
stateに関するドキュメント

急に実践的すぎるな？？？

Pro-tips for dbt Projects

Limit the data processed when in development

  • 開発環境において、実行時間を短縮することで、より迅速にコードを反復可能
  • ターゲット名でデータを制限することで、実行速度を上げる
select
*
from event_tracking.events
{% if target.name == 'dev' %}
where created_at >= dateadd('day', -3, current_date)
{% endif %}

Use hooks to manage privileges on objects that dbt creates

Separate source-centric and business-centric transformations

  • モデリングの2段階
    • ①異なるソースを一貫した構造に変換するソース中心変換
      • 変換の例：カラムの再エイリアスと再キャスト、モデルが正しい粒度を持つための結合・ユニーク化
    • ②ビジネスに関連するエンティティやプロセスを表すモデルへの データ変換や、SQLでビジネス定義を実装するビジネス中心な変換
  • この区別を明確にするために、２種の変換を別のモデルに分けることが最も有効

Managing whitespace generated by Jinja

これも突然だな！  
しかし、意味的なモデル分類は重要そう  
汎用性の高い中間テーブルを作るなどの意味で