dbtプロジェクト構築に関するベストプラクティス #5 「モデル以外のプロジェクト構成要素に関する検討事項」 #dbt

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

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

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

そこで当エントリでは、幾つか展開されている「dbtベストプラクティスガイド」で紹介されているコンテンツの中から『dbtプロジェクト構築』に関するものの中で、既存エントリで公開してきたもの『以外の要素』についてどのようにdbtで構築していくかについて読み解いていきたいと思います。

過去の『dbtプロジェクト構築』に関するベストプラクティス一覧：

• #1「概要」 #dbt | DevelopersIO
• #2「ステージングデータ層(Staging Layer)に関する検討事項」 #dbt | DevelopersIO
• #3「中間データ層(Intermediate Layer)に関する検討事項」 #dbt | DevelopersIO
• #4「マート層(Marts Layer)に関する検討事項」 #dbt | DevelopersIO
• #5 「モデル以外のプロジェクト構成要素に関する検討事項」(当エントリ)

目次

• プロジェクト構成レビュー
• YAMLの詳細
• その他フォルダの使用方
• プロジェクトの分割
• まとめ

プロジェクト構成レビュー

過去4本のエントリでは、dbtプロジェクトの主要なディレクトリであるmodelsフォルダに焦点を当ててきました。当エントリではYAML設定ファイルへのアプローチ方法から始めて、プロジェクトの残りのファイルやフォルダがこの構造にどのように適合しているかを拡大して見ていきます。

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

YAMLの詳細

dbtプロジェクトに於いてYAML設定ファイルの構造化を検討する際、任意の設定ファイルをできるだけ素早く見つけられるようにするために、ファイルサイズと一元化の良いバランスを取りたいところです。トップレベルのYAMLファイルであるdbt_project.yml, packages.ymlはファイルパス(最上位に配置)とファイル名(この名前)を遵守する必要がありますが、ソースとモデルに関する設定ファイルは好きなファイル名、ファイルパス、ファイル構成にすることが出来ます。重要なのはファイルの中身です。

以下に推奨するルール、避けておくべきルールを列挙します。

-- dbt_project.yml

models:
  jaffle_shop:
    staging:
      +materialized: view
    intermediate:
      +materialized: ephemeral
    marts:
      +materialized: table
      finance:
        +schema: finance
      marketing:
        +schema: marketing

その他フォルダの使用方法

上記で言及してきたものはdbtプロジェクトで開発を進めていく上で中心・肝となる部分にフォーカスした内容でしたが、dbtプロジェクトにはその他のフォルダやファイル構成もあります。

jaffle_shop
├── analyses
├── seeds
│   └── employees.csv
├── macros
│   ├── _macros.yml
│   └── cents_to_dollars.sql
├── snapshots
└── tests
└── assert_positive_value_for_total_amount.sql

シード(seeds)

アナライシズ(analyses)

テスト(tests)

スナップショット(snapshots)

マクロ(macros)

プロジェクトの分割

アナリティクス・エンジニアリングのエコシステムにおいて、重要な検討事項のひとつに、『コードベースを複数のdbtプロジェクトに分割する方法とタイミング』があります。

dbt Labs社の見解としては、ほとんどのプロジェクト、特にスタートアップのチームに対して、「他に選択肢がないか、より複雑な回避策を省くことができない限り、分割は避けるべきだ」というものです。

プロジェクトを分割する必要がある場合は、プライベートパッケージを使うことで完全に可能ですが、複雑さと分離が追加されることは、ほとんどの組織にとって、現在のところ、助けになるどころか邪魔になります。とはいえ、これは変更される可能性が高いです。dbt Labs社では、たくさんのdbtプロジェクトを簡単にひとつの系統にまとめられる世界を作りたい...と考えているようです。今後のdbt Labs社及びdbt関連プロダクトがどのように進化発展していくかが気になるところではありますが、将来を見守っていきましょう。

ということでプロジェクト分割における『すべき/べからず』集です。

まとめ

という訳で、『dbtプロジェクト構築』に関するベストプラクティス最終回(あ、Semantic Layer向けのマート層のやつがあったけどまぁ良いか)、モデルにおける各種レイヤー層以外の要素に関する構成や配置等に関するベストプラクティスを見ていきました。

今回の内容に限らず、『ベストプラクティス』はあくまで参考情報です。dbt Labs社が推奨するガイドラインを学び、自分達が関わるプロジェクトや組織のこれまでのルールや慣習を踏まえて『良き落とし所』となるルールやガイドライン等を作成し、文書化してプロジェクトに適用していくのが何より重要です。そしてdbtやdbt Labsが進化していくのと合わせてプロジェクトの内容も変化、成長していけるように適宜ルールを見直し、改善していきたいですね。

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