株式会社MIXIにおけるdbt導入事例

ツール導入前の課題

1. プロダクトごとに採用しているワークフローエンジンが異なるため学習コストが高く、結果的に運用が属人化してしまう課題があった
2. すでに採用しているワークフローエンジンではDWH（BigQueryなど）との通信部分を自前で実装していたためメンテナンスコストが高く、新機能を利用したいときも追加で実装する必要があった
3. 各プロダクトのアップデート対応（新規施策に伴うデータ取り込み、ログ解析など）も工数が高かった。特に内製ワークフローエンジンやLuigiではSQLの他にPythonやRubyなどの言語の知識も求められたためエンジニア以外のメンバーが自力のみでデータマートを構築しずらい状態になっていた

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

1. データ分析基盤のアーキテクチャや利用しているツール・サービスが統一されている状態。分析基盤をサービスごとに作っていたら大変なので今後は共通化したい。
2. ドメイン（SQL）のみに集中できる状態
3. データアナリストなど非エンジニアでも気軽にデータマートを作成できる状態

1. dbt Cloud（SaaS）
2. dbt Core（OSS） <- 採用
3. Airflow（Google Cloud Composer）
4. Prefect
5. Luigi

今現在抱えている課題を解決できるか、チームメンバーのスキルセットとの親和性を重要視していました。

※前提としてdbtはETL/ELTにおけるTの部分のみを担うツールです。データマートの構築パイプラインをどのツールが担うのかを観点に比較しました。複雑なワークフローにおいてはAirflow上でdbtを動かすなど組み合わせて利用するケースが多いです。

1. BigQueryへjob（SQL）を投げるだけなら最適なツールである点
2. 複雑な環境構築不要でローカル環境でさっと開発できる点
3. SQLを書くことに集中できる点
4. 学習コストが比較的低い点

dbt Cloudではなくdbt Core（OSS版）を選んだ理由としては、すでに他のワークフローエンジンを動かすための基盤をチームで運用していたためSaaSでなくても導入のコストが低かった点、導入当時はdbt Coreが持つ機能で十分に要件を満たせた点が決め手でdbt Coreを採用しました。

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

プロダクトごとに採用しているワークフローエンジンが異なるため学習コストが高く、結果的に運用が属人化してしまう課題があった

dbtを中心とした共通基盤を構築。新規プロダクトはこの基盤に乗っかることで7タイトルを超えるプロダクトの分析環境を支えることができた。

すでに採用しているワークフローエンジンではDWH（BigQueryなど）との通信部分を自前で実装していたためメンテナンスコストが高く、新機能を利用したいときも追加で実装する必要があった

通信部分はすべてdbt側が担ってくれるため、メンテナンスコストは大幅に下がった。

各プロダクトのアップデート対応（新規施策に伴うデータ取り込み、ログ解析など）も工数が高かった。特に内製ワークフローエンジンやLuigiではSQLの他にPythonやRubyなどの言語の知識も求められたためエンジニア以外のメンバーが自力のみでデータマートを構築しずらい状態になっていた

dbtの場合ドメイン(SQL)のみに集中できるため、dbtをあまり知らない人でも新しいデータマートの構築などができた。

どのような成果が得られたか

先述の通り7タイトルを超えるプロダクトにおいて安定して分析用データを提供する基盤を構築することができた。 またdbtの採用により今までデータエンジニアしかさわれなかったワークフローエンジンがデータエンジニア以外でも触れるようになった。（実際にサーバー側のエンジニアからもdbtモデルを追加するPull Requestが来るなど属人化・サイロ化を防ぐことができた）

dbt Core自体をどこで動かすかは議論の余地がありました。また、dbt自体はBigQueryなどのDWHへSQLを投げる以外の機能を持たないためそれ以外のワークフローをどこで実行するかは依然として設計する必要がありました。