dbtの推奨ディレクトリ構成

dbt の推奨ディレクトリ構成

この記事では、dbt の推奨ディレクトリ構成について紹介します。

データ変換において意識すべき点

プロジェクトにあるデータは以下の 3 つの意識すべき点があります。

Sources
- サードパーティツールによってロードされるスキーマとテーブル
Staging models
- ソースデータテーブルと一対一の関係を持つモデル
  - カラムの名前が変更されたり、再構成されたり、有用な形で一貫性のあるフォーマットに修正
Marts models
- ビジネスプロセスエンティティを表現するモデル

推奨ディレクトリ構成

上記のデータ変換において意識すべき点を踏まえ、dbt Style Guideでは以下のような構成が推奨されています。

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

例

こちらの記事では、Stripe API による支払いレコードがデータウェアハウスにロードされているという例をとって、以下のようなディレクトリ構成を紹介しています。

├── dbt_project.yml
└── models
    ├── marts
    │   ├── core
    │   │   ├── core.yml
    │   │   ├── dim_customers.sql
    │   │   ├── fct_orders.sql
    │   ├── finance
    │   ├── marketing
    │   └── product
    └── staging
        └── stripe
            ├── src_stripe.yml
            ├── stg_stripe.yml
            ├── stg_stripe__customers.sql
            └── stg_stripe__invoices.sql

staging ディレクトリについて

staging ディレクトリは少なくとも以下を含む必要があります。

分析に有用な各オブジェクトに 1 つの staging model
- 命名はstg_<source>__<object>
- 一般的には view（パフォーマンスが求められる場合は table）
ウェアハウスにロードされているデータを定義するsrc_<source>.ymlファイル
スキーマを定義するstg_<source>.ymlファイル

marts ディレクトリについて

marts はビジネスの実体やプロセスを記述したモデルです。Marketing、Finance、Product などビジネスユニットごとにグループ化されることが多いです。ビジネス全体で共有されるモデルは、core ディレクトリにグループ化されます。

各ディレクトリには以下のファイルが存在します。

fct_<verb>sql
- ファクトモデル
dim_<noun>sql
- ディメンションモデル
スキーマファイル（.yml）

補足：ファクトとディメンションについて

データ設計手法の一つとして、スタースキーマというものがあります。スタースキーマでは、データを「ファクト」と「ディメンション」に分け、ファクトテーブル 1 つにつき複数のディメンションを関連づけます。星形のデータ構造を取ることからスタースキーマと呼ばれています。ファクトテーブルとは、対象のイベントの発生ごとに 1 レコードを表現するテーブルであり、大きなデータになる傾向にあります。ディメンションテーブルは分析の切り口となる属性値を表現したテーブルで、比較的小さなデータになる傾向にあります。

参考

備考

Hakky ではエンジニアを募集中です！まずは話してみたいなどでも構いませんので、ぜひお気軽に採用ページからお問い合わせくださいませ。