STORES株式会社のdbt導入事例

参考になった

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

STORES株式会社 / K

メンバー / データエンジニア

最終更新日2024/08/21投稿日2024/08/22

ツールの利用規模	ツールの利用開始時期	事業形態
10名以下	2022年10月	B to B

ツールの利用規模	10名以下
ツールの利用開始時期	2022年10月
事業形態	B to B

アーキテクチャ

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

以下の役割で階層を分けてデータモデリングを行っています。

source

各データソースから転送してきた結果を格納する。
加工処理は一切行わない。

staging

preparation以降でデータモデリングをしやすくするために、テーブル名/カラム名の正規化やデータ型の変換などの必要最低限の加工処理を行う。

preparation

warehouseでワイドテーブルをSELECT *のみで作るために、単一のデータソースからなる計算済み/集計済みカラムを生成する。
ログやイベントに対する特定条件の絞り込みや最新断面の絞り込みを行う。

warehouse

データ活用者がよしなに欲しいデータを欲しい形式で抽出できるようにするために、ローデータのワイドテーブルを生成する。
複数のデータソースからなる計算済み/集計済みカラムを生成する。
原則、絞り込みは行わず、データソースとデータの粒度を揃える。

mart

施策の効果検証やビジネスオペレーション改善などで利用するために、ワイドテーブルを特定条件で絞り込むテーブル/ビューを生成する。
日次/月次、店舗ごと/顧客ごとなど、必要に応じて集計粒度を変える。

工夫点

敢えて細かく役割を分けることで、どこで何をすべきかを明確にし、常にセオリーに沿ってデータモデリングを行えるようにしている。
warehouse,martにて、dbt のephemeralモデルで共通処理を定義することで、本来物理化する必要のないテーブルやビューを作らず、かつロジックのサイロ化を防止している。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

dbt 導入以前は、テーブルごとにCREATE OR REPLACE TABLE文、及びINSERT INTO文を記載した.sqlファイルを用意し、独自のスクリプトで依存関係を考慮しながらバッチ処理で日々更新を行っていました。

運用自体は回っていたものの、以下の課題を抱えていました。

データ品質を担保するためのテスト処理の仕組みがない。
メタデータが外部ドキュメントで管理されており、テーブルの新規作成・変更時に更新漏れが起きる。
依存関係が可視化されていないため、変更を加えたことによる影響範囲が不明瞭。
依存関係を考慮した上で、部分的に複数テーブルを更新する仕組みがない。
.sqlファイルの作成、及び修正にかかるメンテナンスコストが地味に高く、エラーを起こしやすい。

どのような状態を目指していたか

先ほど挙げた課題を解消しつつ、以下の状態を目指すために dbt の導入を決めました。

データ品質を担保しつつ、スピーディにデータモデリングを行うことができる状態。
データに責任を持つ組織として、一定の品質を担保した上でエンドユーザーにデータを提供できる状態。
今後発生しうる要件・要望にも柔軟に対応できる状態。

比較検討したサービス

dbt Core ← 採用
dbt Cloud
Dataform
LookML(Looker)

比較した軸

BigQuery に対して利用できるか？
ツール自体の利用コストはいくらか？
ドキュメントや導入事例は豊富か？
既存処理からの置き換えるコストは高くないか？
学習ハードルは高くないか？

選定理由

上記比較軸をすべてクリアしていること、当時SNS等で dbt が話題になっておりこれからもアップデートされることが期待できたこと、社内に dbt の利用経験者がいたことの3点から、dbt を採用することにしました。また、導入及び運用に伴う費用の安さと、導入検討時に dbt Cloud でのみ提供されている機能で必要なものがなかったため、dbt Core を採用することにしました。

導入の成果

改善したかった課題はどれくらい解決されたか

データ品質を担保するためのテスト処理の仕組みがない

デフォルトで利用できるGeneric Testを活用することで、最低限のデータ品質を担保しつつ、外部パッケージを導入することで、要件にあわせて柔軟にテスト処理を実装できる状態になりました。

メタデータが外部ドキュメントで管理されており、テーブルの新規作成・変更時に更新漏れが起きる

各モデルの.ymlファイルでメタデータを管理していくようにしたことで、モデルの開発と同時にメタデータの更新もできるようになり、Pull Request時にメタデータのレビューも通せるようになったため、更新漏れの防止とメタデータ自体の品質を向上させることができました。また、dbt が.ymlファイルの内容をもとにデータカタログ(dbt Docs)を自動生成してくれるため、外部ドキュメントで管理するということも不要になりました。

依存関係が可視化されていないため、変更を加えたことによる影響範囲が不明瞭

dbt 独自の記法でデータモデリングを行うことで、dbt Docs 上でデータリネージを確認することができるようになり、モデルの変更を加えた際の影響も一定把握できる状態になりました。

依存関係を考慮した上で、部分的に複数テーブルを更新する仕組みがない

dbt のコマンドで更新対象を細かく制御できるため、容易に部分的な複数テーブルの更新を行える状態になりました。

モデルファイルを作るコストが地味に高く、エラーを起こしやすい。

基本的に SELECT文のみでデータモデリングを行っていくため、導入前よりもモデルファイルを作るコストは下がりました。

導入に向けた社内への説明

上長・チームへの説明

まずはチームの定例ミーティングにて、現状の課題を共有しつつ、dbt を導入することでそれらの課題を一定解消できることを説明しました。課題に関しては既に共通認識を持てていたのと、今後も社内のデータ活用需要が高まっていくことが予想されたため、このタイミングで dbt を導入するメリットは大きいと判断し導入することが決まりました。

活用方法

よく使う機能

標準機能
- dbt runコマンドによるモデルのデプロイ
- dbt testコマンドによるテスト処理の実行
- dbt Docs を通したデータカタログの提供
- Jinjaのmacroを活用した共通処理の実装
dbt-osmosis
- 外部パッケージ
- 下流のモデルにメタデータを伝播させ、コスパよくメタデータの拡充を図ることができる
elementary
- 外部パッケージ
- モデルの更新にかかる時間やエラー率といったメタデータを保存・活用することができる

ツールの良い点

基本的にSELECT文のみで、データモデリングを行うことができる。(用途に合わせてCREATE文やMERGE文を書く必要がない)
デフォルトで用意されているテスト機能が豊富、かつ外部パッケージを活用することで細かく要件にも対応できる。
Pythonで開発されたテンプレートエンジンのJinjaを扱うことができるため、SQLのみでは実現できない処理を実装することができる。
dbt 独自の記法でモデリングすることで、dbt Docs 上でデータリネージを確認することができる。

ツールの課題点

dbt Cloud でしか提供されていない機能が存在する。
スナップショットや増分更新なども気軽に実装できる反面、弊社は BigQuery を採用しているため、意図せずストレージ費用が膨らんだり、full refreshによるテーブルの再構築時にスロットを長時間上限いっぱいまで消費してしまいクエリ費用が高くなってしまう可能性も持ち合わせている。