🌊

"How we structure our dbt projects"を読む

2022/03/04に公開

dbt

tech

概要

dbt style guideを読んでいたら、このポストを参照していて、とても内容が濃かったので別でまとめました
同僚に読んでもらうために、僕なりに翻訳、噛み砕いたものなのとなっています
原文と若干ニュアンスが違うかもしれません、Single Source of Truthの精神でぜひ原文も読んでみてください

tenajimaの感想

dbtのプロジェクトをどのように構築していくべきか学ぶ中で、データをどのように捉えるべきか(dimensionとfactなど)も同時に学べてすごく良かった
僕も型として「このパターンはこのようにプロジェクトを作っていく」というのを何個か持てるようになりたい

How we structure our dbt projects

前提としてここで示す方法は、dbtとしてはベストだと思うが、自分自身のプロジェクトにとって最適かどうかは自分で判断してね(より深くディスカッションして使ってね)って言ってる

Data transformation 101

プロジェクトのデータは3つのチェックポイントで分けている
1. ソース
- データソースに準拠した構造(例えばテーブルやカラム)をサードバーティーツールで読み込んだもの
1. ステージングモデル
- データモデリングの最小単位
- 各モデルはソースデータテーブルと一対一の関係を持つ
- ソースデータテーブルと粒度は同じだが、カラムはリネーム、リキャストなど有用なものに整えられている状態にする
1. マートモデル
- ビジネスプロセスやエンティティを表現するモデルで、ベースとなるデータソースから抽象化されている
ここで注目すべきなのはソースとステージングモデルはデータソースが基点なのに対して、マートモデルはビジネスが基点であること
dbtおすすめのプロジェクトではまずmodelsディレクトリをを以下のように構成することから始めるべき

├── dbt_project.yml
└── models
    ├── marts
    └── staging

Staging raw data

ステージング層の目的は生データを受け取り、データクレンジングを行うことだ
stg_というプレフィックスを持つことは次のことを示す
- データ基盤のルールに従ってフィールドをリネーム、リキャストしている
- タイムゾーンなどのデータ型が揃っている
- 空文字をnullに置き換えるなどの簡単なクレンジングが行われている
- 有用であればリストの展開(flattening)が行われている
- ユニークかつ非null値であるプライマリキーがある
ステージングモデルにはコンテキストの追加のために、追加カラムを結合が可能で、ユニオンによる行の追加やフィルタによる削除、ナチュラルキーの重複排除やサロゲートキーのハッシュ結合もできる
複数のデータソースを扱うことが多いので、ステージングディレクトリでは、ソースごとに1つのディレクトリを作成する

├── dbt_project.yml
└── models
    ├── marts
    └── staging
        ├── braintree
        └── stripe

それぞれのstagingディレクトリは最低限次のものを含む
- 分析に有用な各オブジェクトに1つのステージングモデル
  - stg_<source>__<object>というファイル名にする
- 1つのsrc_<source>.ymlファイル
  - sourceの定義、テスト、ドキュメントを記述する
- 1つのstg_<source>.ymlファイル
  - 同じディレクトリのモデルのテストとドキュメントを書く

├── dbt_project.yml
└── models
    ├── marts
    └── staging
        └── braintree
            ├── src_braintree.yml
            ├── stg_braintree.yml
            ├── stg_braintree__customers.sql
            └── stg_braintree__payments.sql

ymlファイルを1つにまとめたいという声も合理的だが、ymlが肥大化してきたらこの方法をお勧めする
ephemeral materializationをよく使うようになってきたらbaseディレクトリを使って作る

Describing a business through marts

martsはビジネスエンティティやビジネスロジックを含んだモデルを置くところ
ビジネスの単位でディレクトリを切るのが良い
- マーケ、経理、プロダクト

├── dbt_project.yml
└── models
    ├── marts
    |   ├── core
    |   ├── finance
    |   ├── marketing
    |   └── product
    └── staging

ここではファクトモデルとディメンジョンモデルを構築し、そのモデルが依存するソースデータから抽象化することが目標である
- fct_<verb>
  - 行数が多くて列数が少ないデータ
  - 実世界で発生した、あるいは発生しているプロセス
  - セッション、トランザクション、オーダー、などイミュータブルなイベントストリーム
- dim_<noun>
  - 行数が少なくて列数が多いデータ
  - 各レコードは人、場所、ものなどを表す
  - (人の属性情報など)劇的に変化するなどはないが、ミュータブルである
ステージングモデルの作業がクリーニングなどの前処理に限られているのに対し、ファクトテーブルはディメンジョンの選択(および削除)、日付の特定、ビジネスロジックの実行といっデータ変換を行う部分である
このレイヤーのモデリングはステージングモデルの作成よりもかなり複雑で、組織の分析ニーズに適合した形になる
ここでは便利なパターンをいくつか紹介する
- パフォーマンスを上げるためにfct_とdim_モデルをテーブルとして作る。基本的にはテーブルとして作るが、パフォーマンス懸念があるときのみインクリメンタルで作る
- ファクトモデル、またはディメンジョンモデルを作る前に必要な途中での変換はmarts/<mart>/intermadiateディレクトリに配置する。<useful_name>__<transformation_in_past_tense>.sqlという名前で格納する。二重アンダースコアが使われていることからこれらは中間モデルであることを示すようにする。
- モデルは同一ディレクトリの<dir_name>.ymlファイルにてテストを行うようにする
```
├── dbt_project.yml
└── models
    ├── marts
    │   ├── core
    │   │   ├── core.md
    │   │   ├── core.yml
    │   │   ├── dim_customers.sql
    │   │   ├── fct_orders.sql
    │   │   └── intermediate
    │   │       ├── customer_orders__grouped.sql
    │   │       ├── customer_payments__grouped.sql
    │   │       ├── intermediate.yml
    │   │       └── order_payments__joined.sql
    │   ├── finance
    │   ├── marketing
    │   └── product
    └── staging
```
- DAGで表すとこのように表される

Accessories to data

ロバストなdbtプロジェクトで見かけるSQLファイルには、ステージングやマートに加えて次のようなモデルディレクトリがしばしば見られる

utils
- all_daysテーブル、あらゆるところで役に立つ
lookups
- zipcodeと国を紐づけるなどのマッピングテーブル
- これらはcsvとdbt seedを使って用意するのが良い
- これはいろんなところで参照するだけでなく、BIツールで使うこともある
admin
- 監査ログ、DWHの運用、メンテナンス情報、プロジェクトを進めるために実行した雑多なDDLのインクリメント記録など
metrics
- ファクトテーブルから取得した測定値から正確に定義されたもの

Final thoughts

この記事ではdbtによってDAGを構築することを説明した
それはソースモデルからマートモデルまで左から右に処理をすることを説明した
しかし、現実ではしばしば右から左へモデルを考えることが多い
ダッシュボードのアイデアや、作りたいレポートから考え始めて、ダッシュボードをワークさせるために必要なマートモデルの構造をホワイトボードに書き出す
実際にSQLを書き始める前に、同じホワイトボードにデータソースまで遡るように処理を書き出す
何度かモデリングを繰り返すうちに、DAGを左から右へどう構築していけば良いのか直感的にわかるようになってくる
目的地を考えてからモデリングの旅に出るようになってくるのだ

概要

tenajimaの感想

How we structure our dbt projects

Data transformation 101

Staging raw data

Describing a business through marts

Accessories to data

Final thoughts

Discussion