👨‍🎓

dbt_project_evaluatorで学ぶdbtベストプラクティス

2024/02/17に公開

dbt

tech

はじめに

dbtドキュメントの中に「dbtベストプラクティスガイド」があります。
モデリング方法やモデル名称の付け方まで、膨大な数の知見がまとめられています。
https://docs.getdbt.com/best-practices

これらを全て読み込んでデータモデリングに役立てたいところですが、いかんせん量が多すぎて使いこなせないのが悩みです。。

そんな時に活用できるdbtパッケージが、今回紹介するdbt_project_evaluatorです！

dbt testコマンドによって、自分のdbt projectがベストプラクティスに違反しているかどうか確認することができます。

インストール

こちらの公式サイトからインストールを進めていきます。

packages.ymlに以下を記述します。

packages.yml

packages:
  - package: dbt-labs/dbt_project_evaluator
    version: 0.8.1

次にdbt depsを実行すると、パッケージをインストールできます。

さっそくprojectをevaluateしてみる

パッケージをインストールできたところで、さっそく使ってみたいと思います。
通常のdbtテストと同じく、dbt testを実行するだけです。

jaffle_shopデフォルトの状態でもいくつかwarningが出てきます。

公式ドキュメントに各ルールの解説があるので、一つ一つ確認しながらベストプラクティスに従っていきましょう。

Warning in test is_empty_fct_model_naming_conventions_

Model Naming Conventions
モデル名称に関する警告です。
モデルタイプ（stagingモデルなのか？martモデルなのか？）を推測しやすい名称にすると、ユーザがモデルを理解しやすくなります。
具体的には、モデル名称に以下のようなの接頭語を付けるとモデルタイプを判別しやすくなります。

モデルタイプ	接頭語
Staging	`stg_`
Intermediate	`int_`
Mart	`fct_` or `dim_`
Other	`rpt_`

さて、今回出た警告はどのように修正すれば良いでしょうか？
警告メッセージを手がかりに、テスト結果の詳細を見てみましょう。

Warning in test is_empty_fct_model_naming_conventions_ (models/marts/structure/structure.yml)
Got 2 results, configured to warn if != 0

compiled Code at target/compiled/dbt_project_evaluator/models/marts/structure/structure.yml/is_empty_fct_model_naming_conventions_.sql

is_empty_fct_model_naming_conventions_.sqlというコンパイル済みSQLの結果をもとに、警告を出力しているようです。

is_empty_fct_model_naming_conventions_.sql

select count(*) as n_records
from "postgres"."public"."fct_model_naming_conventions"

fct_model_naming_conventionsというテーブルの中にレコードがあったら警告を出すようです。
このテーブルの中身を見てみましょう。

これを見ると、どのモデルがベストプラクティスに違反しているのか、そしてどのように修正すれば良いのかまで提案してくれています！
今回のケースだと、customersとordersがモデルタイプとしてotherに該当しているので、接頭語としてrpt_を付けるべきと提案されています。
（modelディレクトリ直下にモデル配置しているので、このような判定をされているようです）

とりあえず言われた通りにモデル名称を変えてみましょう。

警告が消えました！

Warning in test is_empty_fct_undocumented_models_

Undocumented Models
「ドキュメントちゃんと書こうね」という警告です。

同じ要領でテスト詳細を見てみましょう。

確かにstagingモデルにドキュメントを書いていませんでした。
最低限モデルに関する説明くらいは書いておきましょう。

schema.yml

version: 2

models:
  - name: stg_customers
    description: 顧客に関する生データを読み込み、idをリネームする。
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null

  - name: stg_orders
    description: 注文に関する生データを読み込み、idをリネームする。
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ['placed', 'shipped', 'completed', 'return_pending', 'returned']

  - name: stg_payments
    description: 支払いに関する生データを読み込み、idをリネームした上で合計額を単位換算する。
    columns:
      - name: payment_id
        tests:
          - unique
          - not_null
      - name: payment_method
        tests:
          - accepted_values:
              values: ['credit_card', 'coupon', 'bank_transfer', 'gift_card']

これで再度dbt runした上でテスト実行すると、、、

全てのテストを突破しました！
valid_documentation_coverageという警告も出ていましたが、stagingモデルのドキュメントを追加したことで一緒に解消されたようです。

まとめ

今回はjaffle_shopを使ってdbt_project_evaluatorを試してみました。
（公式サンプルプロジェクトでもベストプラクティス違反が用意されているのが面白いですね笑）

データモデリングの品質を上げるのに役立つだけでなく、ベストプラクティスを勉強することにも役立ちそうだと思っています！