Tokyo dbt meetup #7『新規事業でdbtを導入した話』by 渡辺大貴

こちらは、2023年12月18日(月)に開催された Tokyo dbt meetup #7でモンストゲーム運営部 解析グループの渡辺が発表した「新規事業でdbtを導入した話」 の登壇資料です。
https://www.meetup.com/tokyo-dbt-meetup/events/297671225/

Transcript

1. ©MIXI ©MIXI 新規事業でdbtを導⼊した話 株式会社MIXI デジタルエンターテインメント事業本部 モンストゲーム運営部 解析グループ 渡辺⼤貴 Tokyo dbt Meetup #7 2023.12.18
2. 2 ©MIXI ⾃⼰紹介 • 2020年株式会社ミクシィ（現MIXI）へ新卒⼊社 • データエンジニア4年⽬ • ~2020 : フルスタックエンジニア 渡辺 ⼤貴 ( Taiki Watanabe) 株式会社MIXI デジタルエンターテインメント事業本部 モンストゲーム運営部 解析グループ
3. 3 ©MIXI 1. dbt導⼊の背景 a. 組織の背景と課題感 b. Airflow導⼊ 2. dbt導⼊まで a. 技術選定 b. インフラアーキテクチャ 3. 導⼊してみて a. 実績‧良かった点‧改善点 4. 今後の展望 5. その他dbt周り a. モデル設計 Agenda
4. 4 ©MIXI 1. dbt導⼊の背景 「モンスターストライク」におけるデータ基盤の構築‧運⽤ ⼀部の新規事業におけるデータ基盤構築⽀援‧運⽤等も 現在運⽤中のプロダクト: 9サービス データ分析基盤はBigQuery + Lookerが基本 ETL系はAWS EMRやAWS Glueなど。最近はBigQueryでELTが多い。 モンストゲーム運営部 解析グループ
5. 5 ©MIXI 1. dbt導⼊の背景 1. プロダクトごとに採⽤しているワークフローエンジンが異なるため、学習コストが⾼め - 内製ワークフローエンジン、Luigiなど。dbt採⽤前はAirflow - 結果的に運⽤が属⼈化しがち 2. 各プロダクトのアップデート対応も⼤変 - 新規テーブル追加だけでもデータ信頼性を担保するためのテストは必要 3. DWHとの通信部分や依存パッケージのメンテナンスコストも 背景と課題感
6. 6 ©MIXI 1. dbt導⼊の背景 - 既存Operatorをフル活⽤して開発コストは削減 - 安定稼働している点はGood。再実⾏も楽で良い - クラスタを含めて全リソースをTerraform化。1コマンドで環境のフルセットが⽴ち上がるように Airflow導⼊の良かった点と反省点 新規事業(2020~)ではデータ基盤としてAirflow(on Cloud Composer)を利⽤ なるべく運⽤を⾃動化させる⽅針で設計 Keep Problem/Try - adhocタスクは向いていない。テーブル管理とかもワークフローとは切り離すべき。 - DAGが⼤きいと実⾏に時間がかかる。⽇時バッチなら良いが障害発⽣時の再実⾏時にはボトルネックに - テーブル毎のTransform処理がつらい設計にしてしまった 総合的に... 学習コスト: C, 開発体験: B, 運⽤性: S, 保守性: B
7. 7 ©MIXI 2. dbt導⼊まで - 分析基盤をサービスごとに作っていたら⼤変なので今後は共通化したい - 共通基盤で利⽤していくワークフローエンジンの技術選定 - Airflow: オーバースペック。⼿元で気軽に動かすのが⼤変。 - Luigi: 既存のやつはだいぶ古いバージョン。新規で作るにも接続部分は再開発の必要性。 - Prefect: だいぶ良さそうではあるが、Luigi同様開発コストは⾼そう。 - dbt: BigQueryへjob投げるだけなら最適。複雑な環境構築不要でさっと開発 :+1: 新規事業(2022~)のワークフローエンジン選定
8. 8 ©MIXI 3. dbt導⼊してみて 新規事業(2022~)のアーキテクチャ Logging Google Kubernetes Engine Cloud Spanner データ基盤 本番サーバー Cloud Storage BigQuery dbt Cloud Build Federation via Ext tbl Federation via Spanner Connection Looker Infrastructure - Source DB: Google Cloud Spanner - Source storage: Google Cloud Storage - Spanner to BQ: federated queries - 本番負荷を考慮してバックアップをリス トアしたクラスタへアクセス※ - Logging to BQ: via GCS - hourlyで⼗分だったためGCS Sink - GCS to BQ: via External table ※Cloud Next ’23で発表されたCloud Spanner Data Boostなら 直接Storageへクエリできるので負荷を気にせず連携できそう
9. 9 ©MIXI プロダクトB 3. dbt導⼊してみて 共通基盤(2022~)のアーキテクチャ データ基盤 プロダクトA Cloud Storage BigQuery dbt Cloud Build Looker 戦略 - 全タイトルで共通のKPIログを定義 - ログイン‧課⾦‧プレイなど - ゲーム共通で必須となるKPI - ログフォーマットも共通化 - ログ設計書（スプレッドシート） からdbtモデル(SQL)を⾃動⽣成 Storage Service Storage Service Data Transfer
10. 10 ©MIXI 3. dbt導⼊してみて - 保守作業における開発コスト‧レビューコストはだいぶ下がった。 - dbtの場合ドメイン(SQL)のみに集中できる - エコシステムが充実しているためデータ信頼性テストなどは実装レスでできる - (BQ) MERGE⽂など癖がある構⽂でもdbtを使えばよしなに⽣成してくれるのでgood - 学習コストも低め :+1: - dbtあんまり知らない⼈でも右ならえでできる - 実際にサーバー側を⾒ているエンジニアもdbtを動かしてPR出してくれた - シンプルなのでメンテナンスもしやすい - バージョンアップが気軽にできる 実績‧改善したこと‧良かった点 luigiや内製では抽象度が低かった。 SQL以外にもRubyやPythonをケアする必要があるため敷居が⾼い。 ( データアナリストが気軽にデータマートを実装するのが難しい )
11. 11 ©MIXI 3. dbt導⼊してみて - (dbt関係ないけど) BigQueryテーブルにおけるSTRUCT(RECORD)型の使い所 - Viewで使う分には使いやすくて良い - テーブルで使う場合STRUCTの中にカラム増やすときは型変更という扱いになるためログ系テーブ ルのロードには向かない - もしアプリケーションログを payload カラムの下に全部⼊れてSTRUCTにしてしまうと... - ログ系テーブルのロードにはJSON型がおすすめ - 全ログをJSON型でロードしてViewでログごとに必要なカラムを抽出するフローが私達の運 ⽤にはフィットした - スキーマの進化に強く、過去データの再集計も不要 - トレードオフとして読み取りパフォーマンスとデータサイズは犠牲になる 改善点‧失敗した点
12. 12 ©MIXI 3. dbt導⼊してみて - 複雑なことをやろうとすると沼る - 沼その1: aliasとthis.identifierの相性問題 - aliasを設定したモデル内で{{this.identifer}}を呼び出すとaliasで設定した値を参照 - ref関数にthis.identiferを渡す場合, aliasに設定する前の値が返ってくる 改善点‧失敗した点
13. 13 ©MIXI 4. 今後の展望 - 今後の新規プロダクトでも要件が合えば導⼊していきたい - ⼤規模なプロダクトはワークフローエンジンに求める要件が複雑なので部分的にdbtを活⽤できると良い - Transform部分、特にデータマートの作成ロジックのみをdbtで持つなど - dbtの内部的な挙動や利⽤可能な機能への理解を深めて、より⾼度な使い⽅ができると良い
14. 14 ©MIXI 5. その他dbt周り - How we structure our dbt projects - Modeling - dbt Community Discourse を参考にカスタマイズ - staging モデルとしてスナップショット‧ログデータのロード‧加⼯を扱う 1. ext: 外部データソース 2. src: ロード済みデータ 3. stg: 分析向けに整形したデータ（View） - martモデルでstagingされたデータを⽤いて分析やBIツールで参照する粒度へ加⼯ - ext→src→stg⽤のモデルファイルはファイル名以外コピペできるように モデル設計 Cloud Spanner Logging BigQuery Cloud Storage External Table BigQuery ext_some_log Managed Table BigQuery src_some_log View BigQuery stg_some_log
15. 15 ©MIXI 5. その他dbt周り models |- mart | |- dim_users.sql | |- fct_plays.sql | |- staging |- application_log |- snapshot |- ext_users.sql |- src_users.sql |- stg_users.sql モデル設計 データマート側はDimensional Modelingを採⽤。ビジネスロジックの粒度で分割 データ取り込み側はext, src, stgの3段で分割 select * from external_query( "{{...}}", "select * from {{ base_name() }} " ) {{ config( incremental_strategy=... ) }} select *, date("{{...}}") date from {{ ref("ext_"+base_name()) }} ext_users.sql src_users.sql Directory layout
16. ©MIXI