Open4
dbt導入事例
0w0モノタロウ
マーケター自身がデータを管理するために、広告運用にdbtを導入した経緯と効果
Pain
データ供給体制の綻び
- データ量・需要の増加とエンジニア工数不足
- データソース取得ニーズへの対応遅れ
- データパイプライン開発・保守の遅れ
データ理解の支援体制の綻び
- データの種類が増加したが、既存の仕組みでフォローアップしきれない
- データモデルとメタデータが非同期（スプレッドシートで情報管理）
- データの仕様変更とメタデータが連携しない
- 利用者の認知負荷が上昇
- 情報量、検索性
- メンバー間（シニア・ジュニア）の情報格差の助長
オーバーヘッドの大きい保守構成
- データ加工処理を（ELT？）アプリ内に記述（SQL含む）
- データ加工処理の変更＝ソース変更＝レビュー＆デプロイが必要
- データ変換処理の変更に対する工数上のオーバーヘッドが大きい
課題
- データ活用がスケールできない（現状維持で精いっぱい）
アプローチ
ELTの役割分担の明確化
- Transformはアプリ内で行わず、アプリ外（SQL）でユーザー部門が担当
- エンジニアの工数制約から離れて、ユーザー側で変換処理を実装・保守可能に
非エンジニアがT層を担える仕組みづくり
- アナリティクスエンジニアの基礎能力はある前提
- T層の開発・保守に必要なエンジニアリングレベルを下げる
- GUIベースのバージョン管理、メタデータ管理、スケジュール実行
- dbt cloudを選択
- 不要な知識：Python、CLI
- 必要な知識：SQL、git
効果
- リリース工数の削減
- シングルコマンドでリリース
- データ品質、データ保守体制の向上
- テスト機能
- ドキュメント品質の向上
- メタデータ管理とExposures（メタデータダッシュボード）
0w0感想
dbtのモデルケースのようなペインとソリューションでした。
T層の実装はユーザー部門で行えそうだけど、ユーザーが思い思いの実装をすると徐々に保守性が下がってしまいそう。誰かしらルールやアーキテクチャ（Staging・Intermediateなど）を設計、浸透させる役割は必要そうだけど、それはエンジニアサイドで担当するのだろうか。
0w0Superside
Pain
- dbt cloudを利用していた。開発者の人数増にともない、SSOの要求が発生した。Enterpriseが必要。
- 高額な料金提案
- Team:$50/seat -> Enterprise: $300/seat
アプローチ
dbt Coreへ移行
構成
開発環境を dbt Cloud IDE → ローカルのVS Code へ変更
-
開発環境の構成
- Visual Studio Code (IDE)
- dbt Power User (VS code) plugin
- cloudにあった機能を提供： オートコンプリート、Queryの結果参照、Modelテストの実行など
- Better Jinja (VS code) plugin
- シンタックスハイライト
- dbt Power User (VS code) plugin
- dbt-osmosis python package
- cloudにあった機能を提供：IDEからクエリやコンパイルを行うためのdbtサーバー、差分から下流のコンパイル・Run
- Visual Studio Code (IDE)
-
DBT Catalog
- スタティックなカタログをS3へアップロード
0w0確かに一人・月で300ドルは高額ですね。
このポストでは実装面も多く触れられていたのですが、自社の環境とは結構異なるので割愛。