dbt Core導入における非中央集権データ組織のデータモデリング環境構築

参考になった

レビュー投稿日の情報になります

ピクシブ株式会社 / azuki

メンバー / データサイエンティスト / 従業員規模: 301名〜500名 / エンジニア組織: 101名〜300名

最終更新日2024/07/10投稿日2024/07/10

ツールの利用規模	ツールの利用開始時期	事業形態
11名〜50名	2023年7月	B to C

アーキテクチャ

アーキテクチャの意図・工夫

赤い線が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ブラウザで表示可能なドキュメント生成機能が優秀
- マークダウンでドキュメントが書ける
- リネージグラフ機能で視覚的に依存関係が分かる