Zenn
Open4

dbt導入事例

dbt
0w00w0

モノタロウ

マーケター自身がデータを管理するために、広告運用にdbtを導入した経緯と効果

Pain

データ供給体制の綻び

  • データ量・需要の増加とエンジニア工数不足
    • データソース取得ニーズへの対応遅れ
    • データパイプライン開発・保守の遅れ

データ理解の支援体制の綻び

  • データの種類が増加したが、既存の仕組みでフォローアップしきれない
    • データモデルとメタデータが非同期（スプレッドシートで情報管理）
    • データの仕様変更とメタデータが連携しない
  • 利用者の認知負荷が上昇
    • 情報量、検索性
  • メンバー間（シニア・ジュニア）の情報格差の助長

オーバーヘッドの大きい保守構成

  • データ加工処理を（ELT？）アプリ内に記述（SQL含む）
  • データ加工処理の変更＝ソース変更＝レビュー＆デプロイが必要
  • データ変換処理の変更に対する工数上のオーバーヘッドが大きい

課題

  • データ活用がスケールできない（現状維持で精いっぱい）

アプローチ

ELTの役割分担の明確化

  • Transformはアプリ内で行わず、アプリ外（SQL）でユーザー部門が担当
    • エンジニアの工数制約から離れて、ユーザー側で変換処理を実装・保守可能に

非エンジニアがT層を担える仕組みづくり

  • アナリティクスエンジニアの基礎能力はある前提
  • T層の開発・保守に必要なエンジニアリングレベルを下げる
    • GUIベースのバージョン管理、メタデータ管理、スケジュール実行
  • dbt cloudを選択
    • 不要な知識：Python、CLI
    • 必要な知識：SQL、git

効果

  • リリース工数の削減
    • シングルコマンドでリリース
  • データ品質、データ保守体制の向上
    • テスト機能
  • ドキュメント品質の向上
    • メタデータ管理とExposures（メタデータダッシュボード）
0w00w0

感想

dbtのモデルケースのようなペインとソリューションでした。
T層の実装はユーザー部門で行えそうだけど、ユーザーが思い思いの実装をすると徐々に保守性が下がってしまいそう。誰かしらルールやアーキテクチャ（Staging・Intermediateなど）を設計、浸透させる役割は必要そうだけど、それはエンジニアサイドで担当するのだろうか。

0w00w0

Superside

DBT Core & Airflow

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-osmosis python package
      • cloudにあった機能を提供：IDEからクエリやコンパイルを行うためのdbtサーバー、差分から下流のコンパイル・Run

  • DBT Catalog

    • スタティックなカタログをS3へアップロード
0w00w0

確かに一人・月で300ドルは高額ですね。

このポストでは実装面も多く触れられていたのですが、自社の環境とは結構異なるので割愛。