dbtプロジェクト構築に関する ベストプラクティス #4「マート層(Marts Layer)に関する検討事項」 #dbt

アライアンス事業部 エンジニアグループ モダンデータスタック(MDS)チームのしんやです。

dbtはクラウド型データウェアハウス（DWH）におけるデータ変換に特化したツールです。非常に使い勝手が良く便利なツールである一方、様々な機能が提供されているのでいざ使ってみよう！となると『何をどうやって作り上げていけば良いんだろう？』『この場合のルールや制限はどういうものがあるの？どういう取り決めをもって扱えば良いんだろう？』という風に思うこともあるかと思います。(実際私自身そう感じました)

そんなユーザーの疑問や悩みを解決する、いわゆるdbtユーザー向けのガードレール的な存在となりうるコンテンツがdbt社から展開されています。それが『dbtベストプラクティスガイド(Best practice guides)』です。構造、スタイル、セットアップなど、dbt Labsの現在の視点を通した「ベストプラクティス」がまとめられています。

そこで当エントリでは、幾つか展開されている「dbtベストプラクティスガイド」で紹介されているコンテンツの中から『dbtプロジェクト構築』に関するもの、データウェアハウスにおける『マート層(Mart Layer)』をどうdbtで構築していくかについて読み解いていきたいと思います。

目次

• マート層におけるファイルとフォルダの検討事項
• マート層におけるモデルの検討事項
• マート層におけるその他検討事項
• まとめ

マート層におけるファイルとフォルダの検討事項

まず初めに断りとして、dbtのドキュメントではこの「マート層」のベストプラクティスについて「dbt Semantic Layerを使う場合」と「dbt Semantic Layerを使わない場合」の2つの情報が存在しています。当エントリでは「dbt Semantic Layerを使わない場合」の内容に関して紹介していきます。 ※機会をみて「dbt Semantic Layerを使う場合」の情報も紹介出来ればと思います。

ちなみに大方針としては、以下のように整備の仕方が異なります。

• dbt Semantic Layerを使用しないプロジェクトでは、以下のベストプラクティスに従って、大幅に非正規化することをお勧め
• dbt Semantic Layerを使用する場合は、MetricFlowが最も柔軟に対応できるように、できるだけ正規化することをお勧め

当エントリでの内容を説明、解説するために、jaffle_shopプロジェクトのmodels/marts配下の構造を使います。

jaffle_shop
├── README.md
├── analyses
├── seeds
│   └── employees.csv
├── dbt_project.yml
├── macros
│   └── cents_to_dollars.sql
├── models
│   ├── intermediate
│   │   └── finance
│   │       ├── _int_finance__models.yml
│   │       └── int_payments_pivoted_to_orders.sql
│   ├── marts
│   │   ├── finance
│   │   │   ├── _finance__models.yml
│   │   │   ├── orders.sql
│   │   │   └── payments.sql
│   │   └── marketing
│   │       ├── _marketing__models.yml
│   │       └── customers.sql
│   ├── staging
│   │   ├── jaffle_shop
│   │   │   ├── _jaffle_shop__docs.md
│   │   │   ├── _jaffle_shop__models.yml
│   │   │   ├── _jaffle_shop__sources.yml
│   │   │   ├── base
│   │   │   │   ├── base_jaffle_shop__customers.sql
│   │   │   │   └── base_jaffle_shop__deleted_customers.sql
│   │   │   ├── stg_jaffle_shop__customers.sql
│   │   │   └── stg_jaffle_shop__orders.sql
│   │   └── stripe
│   │       ├── _stripe__models.yml
│   │       ├── _stripe__sources.yml
│   │       └── stg_stripe__payments.sql
│   └── utilities
│       └── all_dates.sql
├── packages.yml
├── snapshots
└── tests
    └── assert_positive_value_for_total_amount.sql

中間データ層におけるモデルの検討事項

ここでは2つのmartsモデルを挙げて、marts ディレクトリ内のモデルのベストプラクティスを見ていきます。これらは、ビジネスに適合した、つまり私たちのビジョンとニーズに合わせて作成されたエンティティであり、これらの変換されたコンポーネントを組み合わせて作成しています。

orders.sql

-- orders.sql

with

orders as  (

<pre><code>select * from {{ ref('stg_jaffle_shop__orders' )}}
</code></pre>

),

order_payments as (

<pre><code>select * from {{ ref('int_payments_pivoted_to_orders') }}
</code></pre>

),

orders_and_order_payments_joined as (

<pre><code>select
    orders.order_id,
    orders.customer_id,
    orders.order_date,
    coalesce(order_payments.total_amount, 0) as amount,
    coalesce(order_payments.gift_card_amount, 0) as gift_card_amount

from orders

left join order_payments on orders.order_id = order_payments.order_id
</code></pre>

)

select * from orders_and_payments_joined

customers.sql

-- customers.sql

with

customers as (

<pre><code>select * from {{ ref('stg_jaffle_shop__customers')}}
</code></pre>

),

orders as (

<pre><code>select * from {{ ref('orders')}}
</code></pre>

),

customer_orders as (

<pre><code>select
    customer_id,
    min(order_date) as first_order_date,
    max(order_date) as most_recent_order_date,
    count(order_id) as number_of_orders,
    sum(amount) as lifetime_value

from orders

group by 1
</code></pre>

),

customers_and_customer_orders_joined as (

<pre><code>select
    customers.customer_id,
    customers.first_name,
    customers.last_name,
    customer_orders.first_order_date,
    customer_orders.most_recent_order_date,
    coalesce(customer_orders.number_of_orders, 0) as number_of_orders,
    customer_orders.lifetime_value

from customers

left join customer_orders on customers.customer_id = customer_orders.customer_id
</code></pre>

)

select * from customers_and_customer_orders_joined

マート層におけるその他検討事項

• テーブルを使用してトラブルシューティングを行う：
  • マートまでビューと一時的なモデルを積み重ねる(エンドユーザーに本当に使用してもらいたいモデルがある場合に、チェーンの最後にあるウェアハウスにデータを構築するだけ)ことは、運用環境では理想的ですが、開発ではいくつかの困難が生じる可能性があります。
  • 特に、特定のエラーが後のモデルで表面化しているように見える場合がありますが、実際にはモデルチェーンのかなり初期の依存関係(モデルがエラーをスローする前に構築されたDAG内の祖先モデル)に起因しています。
  • データベースエラーがどこで何を示しているのかを特定するのが難しい場合は、ウェアハウスが実際に発生しているエラーをスローするように、モデルの特定のチェーンをテーブルとして一時的に構築すると役立つことがあります。

まとめ

という訳で、dbtプロジェクト構築に関するベストプラクティス第4弾としてデータウェアハウスにおける「マート層」に関する取り組み方の紹介でした。

分析ユーザーやBIツールに見せることになるレイヤー(層)のデータとなることもあり、データや情報の在り方についてもこれまで紹介したものとは異なる内容が多かったですね。幾つかの指摘事項では「急ぎ過ぎるな、時が来たらその時に動け」的なものもあり、そのあたりの整理整頓の見極めも状況によってしていかなければならないということも分かり勉強になりました。

• dbt の記事一覧 | DevelopersIO
• dbtベストプラクティスまとめ の記事一覧 | DevelopersIO