dbt Core導入における非中央集権データ組織のデータモデリング環境構築
ピクシブ株式会社 / azuki
メンバー / データサイエンティスト / 従業員規模: 301名〜500名 / エンジニア組織: 101名〜300名
ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|
11名〜50名 | 2023年7月 | B to C |
アーキテクチャ
![アーキテクチャ図](https://cdn.findy-tools.io/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBa29CIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--21b818e9579fa98f97307b7d21096a98b361a3cf/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-07-09%2017.34.33.png?disposition=inline)
アーキテクチャの意図・工夫
赤い線がdbtに関連するところです。
ポイントは3つあります。
1. 外部テーブルをdbtで管理
- external機能を使って、yamlファイルで外部テーブルを定義
- スプレッドシートなど入力が不安定な外部テーブルに対してテストを導入することでバリデーションも行なっている
2. dbt専用の開発環境データセット
- dbt用とembulk・python用の違いはテーブルの有効期限の有無
- データをアップロードすることが目的のembulk・pythonはその場限りで不要なテーブルになるので有効期限を設定している
- dbtはrefで参照する都合上、有効期限の設定を行なっていない
3. 既存のシステムからの移行とエコシステム
- dbt導入前のシステムではpythonから変数埋め込みができるSQLを使ってデータを加工していたが、dbtを導入したことによってpythonの利用範囲が狭まり、ソースコードを整理することができた
- dbt Power User ・SQLFluff ・ sqlfmtを導入することでソースコードの品質担保や開発の効率化にも繋がった
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
dbt導入以前はBigQueryのデータ加工SQLを自社で開発したツールで管理していました。
データ加工用のSQLをAirflowで定期的に実行し、テーブルの更新を行なっていました。
また弊社ではpixiv, BOOTH, FANBOXなど2024年7月時点で19個のプロダクトがあり、プロダクトが社員数に対して多いという事情から非中央集権データ組織を採用しています。プロダクトを管理している各ドメインチームがメインでELTを行い、データ基盤チームがそのサポートやインフラ整備を行なっています。
そうした背景も相まって、以下3点の問題がありました。
1. 整備されていないテーブルやビューの乱立
- ドキュメント化されていないSQLやUDFが増えていた
- SSOT(信頼できる唯一の情報源)を意識したデータモデリングを行いたい
2. データ品質を保証する仕組みが無い
- データに対するテストがあまりできておらず、データ品質の担保が課題になっていた
3. スケールしにくい設計の改善
- カラムの追加などにも対応可能なDRY原則を意識した設計にしたい
どのような状態を目指していたか
5W(Why・When・Who・Where・What)の要件でまとめました。
- Why
ツール導入前の課題
に該当する3点を解決したい
- When
- 課題の状況的にできるだけ早く導入したい
- Who
- データ専任ではないドメインチームのエンジニアが使うツール
- Where
- 既存で利用しているスケジューラー(Airflow)と相互運用性がある
- What
- Whyの課題を解決できるデータモデリングツール
- 非中央集権データ組織なので、開発環境でも細かく権限を設定できるようにしたい
比較検討したサービス
- Dataform
- dbt Cloud (有償 SaaS 版 dbt )
- dbt Core (OSS & CLI 版 dbt )
比較した軸
- 開発しやすいツールか?
- 既に導入済みのAirflowとの相性
- データ専任ではないエンジニアが扱いやすいツールか?
選定理由
開発しやすいツールか?
- dbt Power UserでVSCode上での開発を快適にできる
- SQLFluffはdbtテンプレートがあり、dbtに合ったLintツールを採用できる
既に導入済みのAirflowとの相性
- Airflow上でdbtを実行するパッケージ
astronomer-cosmos
もある - dbt Cloudと異なり、セキュリティも既存システムと近い場所で管理できる
データ専任ではないエンジニアが扱いやすいツールか?
- SQL, Python, Gitの知識があれば開発可能
- 国内・海外問わず記事やコミュニティフォームが活発
- Dataformは日本語の解説記事が少なく利用のハードルが高い
導入の成果
改善したかった課題はどれくらい解決されたか
課題1. 整備されていないテーブルやビューの乱立
- モデルのレイヤリング
- stagingモデル: 各チームが使うベースとなるモデル
- intermediateモデル: ビジネス要件に合わして調整されたモデル
- martモデル: アドホックな分析やレポートで参照するモデル
- モデルのtag管理
- 各部で管理する範囲とデータ基盤チームが管理する範囲を明確化
- dbtのドキュメント機能
dbt docs
でカタログ化やデータリネージを実現- Google Cloudの機能と被る部分はあるが、開発環境で容易に確認できる点が魅力
課題2. データ品質を保証する仕組みが無い
- uniqueやnot nullなど基本的なテストをgeneric data testで実施
- ビジネス要件に合っているかをsingular data testでチェック
課題3. スケールしにくい設計の改善
- 再利用可能なモデルの作成
- stagingモデルやハブになるモデルを作成することで、整備されたデータを再利用できる
- 共通部分をmacroで定義
- 特にGA4(Google Analytics 4)のデータは共通箇所が多いため、macro機能が大活躍している
導入時の苦労・悩み
ドメインチームへの推進 と プロダクトを意識した運用ルールの策定
- ドメインチームへの推進
- データモデリングという概念が浸透していないので、dbtを入れる理由などの説明を丁寧に行う必要があった
- dbtはデータ専任ではないバックエンドエンジニアやフロントエンドエンジニアが扱うには学習コストが高く、社内向けのドキュメントを充実させる必要があった
- プロダクトを意識した運用ルール
- レイヤリングやモデル名の命名規則などを意識しておかないと互いのモデルが干渉し合う可能性があり、運用ルールをしっかり決めておく必要があった
導入に向けた社内への説明
上長・チームへの説明
上長含めデータ基盤チーム間では課題間の共有ができており、モデリングツールを導入することに関しては簡単に了承が得られました。
OSSの為、ツールに対する費用が掛からず了承を得やすかったという側面もあります。
効果に関してはドメインチームが利用しないと出ないため、メリット等をドキュメントにまとめて口頭での説明を行いました。
活用方法
よく使う機能
1. モデル管理
- 3つの層 staging・intermediate・mart にレイヤリング
- tagでモデルを管理することで非中央集権データ組織でも管理しやすい体制
- モデルに対するテストの実施
2. dbt docs
- 自動でドキュメント生成
- ドキュメントの更新忘れを解消。最新情報の提供を実現
3. external機能
- 外部テーブルの管理
- 対象はGoogle スプレッドシートやGCS(Google Cloud Storage)のデータ
ツールの良い点
- スケーラビリティ
- モデル管理をすることで非中央集権データ組織でもスケールしやすいデータモデリングができる
- macro機能でSQLを部品化できる
- ref関数で依存関係を構築できる
- エコシステム
- 拡張ツールが充実している
- 特にdbt Power UserはVSCode上でクエリ結果のプレビューやコードジャンプが出来るため、非常に便利
- ドキュメント機能
- Webブラウザで表示可能なドキュメント生成機能が優秀
- マークダウンでドキュメントが書ける
- リネージグラフ機能で視覚的に依存関係が分かる
ツールの課題点
- 差分更新
- dbtのstateが複雑な部分があり、予期しない差分を取得してしまう時がある
- モニタリング機能
- dbtのtest結果が追いにくい状況を解決したい
- dbt内の複数プロジェクト運用
- モデル名の被りが許されないなど非中央集権データ組織で使いにくい点がある
ツールを検討されている方へ
SQLだけではMartテーブルやViewの管理が難しくなった方に是非導入を検討して欲しいツールです。
dbtを検討している方は dbt Cloud (有償 SaaS 版 dbt ) と dbt Core (OSS & CLI 版 dbt ) で機能が異なる部分もあるのでどちらが良いか検討して頂く必要があります。
dbtは拡張ツールも充実しています。dbtを正しく使えているかを評価するdbt project evaluator
・モニタリングを強化するElementary
などdbt専用のツールを取捨選択しつつdbtを拡張していくことをオススメします。
今後の展望
- Airflowとの親和性を高める為にastronomer-cosmosの導入を検討
- dbtのモニタリング用にElementaryの導入を検討
- dbt内のプロジェクトを分けて、モデル名の被りなどを意識せずに各チームで管理できるdbt環境の構築
ピクシブ株式会社 / azuki
メンバー / データサイエンティスト / 従業員規模: 301名〜500名 / エンジニア組織: 101名〜300名
2023年にピクシブ株式会社に中途入社、データ基盤やBIの整備を担当している。現在は財務データに関するアーキテクチャの開発も行なっている。
よく見られているレビュー
ピクシブ株式会社 / azuki
メンバー / データサイエンティスト / 従業員規模: 301名〜500名 / エンジニア組織: 101名〜300名
2023年にピクシブ株式会社に中途入社、...
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法