Coalesce 2023 から、少し時間が経ち、皆様いかがおすごしでしょうか？
その中で話題になった dbt Mesh が気になったのでちょいちょい調べてみました
dbt Mesh とは
dbt Mesh は管理するデータが増えたときに発生する問題に対処するために生まれました
データが増えてくると中央集権的なデータチームがボトルネックになってしまいます
このようなとき、ソフトウェアエンジニアリングでは、ドメインごとに対象を分け、ドメインチームにその開発を移譲する分割統治するアプローチが一般的です
しかしデータが中心のプロジェクトでは普通のソフトウェア開発と異なり、ドメイン単位に分割するだけではガバナンスが効かなくなったり、サイロ化が進むなど、新たな問題が生み出してしまします
そのため、dbt Meshでは、横断的なガバナンスと、ドメイン単位の分割が可能なよう、マルチプロジェクト対応を行いました
※注意：全部の機能を使うには dbt Cloud projects on Enterprise plans です
dbt Mesh を構成する機能
dbt Mesh は下記の機能によって構成されています
それぞれ軽く見ていきましょう
プロジェクトをまたいだ参照
dependencies.yml に projects を指定することで、他プロジェクトに依存したrefが使えるようになります。
元々 ref関数 にはモデル名として一つの引数を与えることしかできませんでした。
しかしプロジェクトの依存関係を指定することで、ref関数のプロジェクト名とモデル名の2つを指定できるようになります。
下記の例では、他プロジェクトとして、 other_project を指定して、other_model_example をref関数 に指定しています。
projects:
- name: other_project
with monthly_revenue as (
select * from {{ ref('other_project', 'other_model_example') }}
),
この機能によって、複数のプロジェクトに分割されたモデルを利用することができるようになります。
これまでは自分たちのデータベースにシェアリングを作成するなど、データベースのアーキテクチャに応じて、手間が必要でしたが、プロジェクトをまたいだ参照が可能になったことで、実装選択肢が増えたことになります。
dbt Explorer
dbt Docs で生成されるドキュメントは大きなプロジェクトになってくるとUIパフォーマンスが悪化するなど問題が起きがちです。
それに対して最近生まれた dbt Explorer は割りとチューニングされており、大きなプロジェクトでも問題なく操作が可能です。
また、当然、 dbt Docs は一つのプロジェクトしかサポートしないという制約があり、マルチプロジェクトにはそもそも対応していません。
dbt Mesh はコンセプト的にマルチプロジェクトでかつ大きなプロジェクトが前提なので、 dbt Explorer は dbt Docs の上位互換として、 dbt Cloud のユーザの標準ツールとして、使われていきそうです。
操作はだいたい dbt Docs 変わらないので、既存ユーザの違和感も大きくないでしょう。
ガバナンス
ガバナンスでは グループ と アクセス修飾子 が使えるようになりました。
この2つの機能を組み合わせると「このモデルを特定のグループ内でしか参照できなくする」とか、「このモデルをそのプロジェクト内でしか参照できなくする」が実現できます。
グループは下記のように、 dbt_project.yml で group を指定することで利用できます。
models:
my_project_name:
marts:
customers:
+group: cx_team
finance:
+group: finance_team
もちろん、各モデルで上書き設定することもできます。
そして、次のようにモデルの設定で group と access を指定して、アクセス制御します。
models:
- name: dim_customers
group: cx_team
access: private
上記の例では access を private にすることで、 cx_team グループに所属するモデルからのみ参照できるように設定します。
アクセス修飾子は private 以外にも、 protected 、 public が使えます。
| アクセス修飾子 | 意味 |
|---|---|
| private | 同じグループだけから参照できる |
| protected | 同じプロジェクトかインストールされたパッケージからならば参照できる |
| public | どこからでも参照できる |
この機能を組み合わせることで、モデルの開発者自身がプロジェクトをまたいだ参照に対して制限を設けることができます。
モデルバージョン
データの提供者と消費者は対立する構造を持っています。
- 提供者：データの生成ロジックや構造を変更して、より良くしていきたい
- 消費者：変化しないでほしい
要するに上流システムの変更に下流システムが巻き込まれてデータ変換ジョブが停止するような事故を消費者は望んでいないけれど、上流システムはアジャイルに開発を進めてより良いプロダクトを作っていきたいという背景があるってことです。
ここで登場したのがこのモデルバージョニングです。
モデルバージョニングを使うと
- プレリリースのモデルを本番環境でテストしたり
- 古いバージョンのモデルを残して移行期間を設けたり
できるようになります。
具体的にはモデルのファイル名に moderl_name_v2.sql のように _v<v> を付け足します。
そうして、参照するときには ref関数 の引数にバージョンを指定して呼び分けます。
このようにバージョンを設けることで、消費者がいるモデルはそのまま維持しつつ、提供者は新しいバージョンのモデルを開発が継続できます。
また、 latest_version も指定でき、新しい消費者がどのバージョンを利用すればいいのかわかりやすくもできます。
そして古いモデルには deprecation_date を指定して、既存の消費者に新しいバージョンへの移行を促せます。
この機能はかなり柔軟ですが複雑でもあり、利用に当たっては様々な利用シナリオが想定されるので、開発標準などを含めて、この機能をプロジェクトに取り入れるか十分に検討が必要そうです。
モデル制約
これはデータベースの持つ制約機能を使うための機能です。
dbtでは5つの制約をサポートしています。
- not_null
- primary_key
- foreign_key
- unique
- check
これらをモデルのymlに指定します。
models:
- name: dim_customers
config:
contract:
enforced: true
columns:
- name: customer_id
data_type: int
constraints:
- type: not_null
このような指定をすれば、データベースの機能としての制約を利用することができるようになりました。
助かりますね。
ちなみに、データベースごとにサポートされてる構文と、その制約が強制されるかは異なるため、対応状況はそれぞれ確認しましょう。
最後に
これらの機能を組み合わせて dbt Mesh を実現していくというのが dbt を使ったデータメッシュです。
プロジェクトをまたげるようになったり、モデルをAPIのようにバージョニングできるようになったり、それぞれ単独でも強力な機能ではありますが、組み合わせて使いこなせば、あなたのデータライフが一段深まること間違いなし。
ぜひチャレンジしてみてください。
Discussion