データ組織・基盤をスケール可能にするために dbt Core を導入した話

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

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

株式会社ヤプリ / yamamoto-yuta

メンバー / データサイエンティスト

最終更新日2024/10/04投稿日2024/06/25

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

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

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

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

（※ 詳細は「 dbt 基盤の開発フローを改善した話 - Yappli Tech Blog 」にて公開しています。ここではこの記事から要点を絞って紹介します。）

アーキテクチャ選定で意識したこと

本番環境に影響を出さずに本番相当の開発環境を提供すること
チームでの基盤開発を可能にすること
GitHub におけるブランチフローや自動化といった開発作法・作り込みなどはDSグループのスキルセットで対応可能な範囲に収めること

3点目について。弊社のデータ組織は、スキルセットがエンジニアリングではなくアナリティクスに寄っていました。そのため、 アナリストがキャッチアップして対応可能な範囲に作り込みを抑えることで、開発のアジリティが損なわれないように しました。

工夫点

本番用と開発用で GC プロジェクトを分離し、開発時の柔軟性を高くした
データセットを開発者毎に分離し、複数のメンバーが並行して開発を行えるようにした
本番テーブルを開発用 GC プロジェクトへ複製するようにし、本番相当の環境で開発を行えるようにした

特に3点目については、 BigQuery のテーブルクローン機能と TROCCO のカスタム変数ループ実行を組み合わせることで、複製にかかる手間と費用を最小限に 抑えることができました。

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

導入背景

ツール導入前の課題

弊社の分析用データ基盤はデータウェアハウス（DWH）に BigQuery 、データマート作成に TROCCO を採用し、2020年に誕生しました。そこから3年が経ち、現行体制では継続的な基盤強化が難しくなってきました。

課題を感じていたのは次の点です。

TROCCO のワークフローが属人化しており、作った本人以外によるメンテナンスが難しかった

データマート作成は TROCCO でワークフローを構築することで行っていました。しかし、分析用データ基盤が成長してくるにつれてワークフローが複雑になっていきました（ワークフローの中にワークフローが組み込まれる、など）。その結果、後からアサインされたメンバーがワークフローの全容を把握するのに苦労してしまっていました。

新規テーブル追加や既存テーブル改修を安全に行うのが難しかった

新規テーブルの追加や既存テーブルの改修を行う際は、BigQuery のコンソール等でクエリのチェックを行ってから TROCCO 上のジョブへ反映する、という方法を採っていました。しかし、この方法ではクエリのレビューが行いにくかったり、本番反映の際に人為ミスが起きやすかったりなど、安全性に課題がありました。弊社の分析用データ基盤は社内利用だけでなく顧客への提供サービスにも利用しているため、安全に追加・改修を行えることは重要でした。

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

データ組織をスケールするために、チームで分析用データ基盤を開発できる状態
継続的に分析用データ基盤を強化できる状態

比較検討したサービス

Dataflow
dbt Cloud (有償 SaaS 版 dbt ）
dbt Core （OSS & CLI 版 dbt ）　←採用

比較した軸

導入しやすさ

ツール導入にあたって費用も人的リソースもかけられなかったため、ここをクリアできるツールを選びました。

選定理由

TROCCO が dbt (Core) 連携機能を追加料金なしでサポートしていたため
→ 費用面はクリア
社内ですでに TROCCO が浸透していた
→ 既存の仕組みをベースにできるため、導入負担を減らせる（＝人的リソース面もクリアできる）

導入の成果

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

目指していた状態に対して、現状は次のようになりました。

＞データ組織をスケールするために、チームで分析用データ基盤を開発できる状態

現時点でデータ組織のメンバー（4人）全員が本番リリースを経験しています。うち2人はクォータ（3ヶ月）ほどかかる中規模開発に継続的に取り組んでいます。

＞継続的に分析用データ基盤を強化できる状態

dbt 導入後、以下分析用データ基盤の強化を実施済みです。

弊社のデータソリューション（ Yappli の CMS ダッシュボード、 Yappli Analytics ）のデータ参照元切り替え
Yappli Analytics への新規図表の追加

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

改善したかった課題が解決された以外に次の成果が得られました。

dbt docs によるデータカタログ拡充

dbt 導入前の弊社のデータカタログには次の課題がありました。

データ関係の仕様書が分散してしまっている
クエリを直接読まないと分からない
作った本人に直接聞かないと仕様が分からない

dbt にはデータカタログを自動生成してくれる機能（ dbt docs ）があります。これにより、一から頑張らなくてもある程度のデータカタログが自動で出来上がる上、「これからはここに情報を集約すれば良い」ということが明確になり、データの仕様把握などが容易になりました。

（※ 詳細は「データカタログの最初の一歩〜データ組織向けに dbt docs を整備している話〜 / Maintaining dbt docs for data organizations - Speaker Deck 」にて公開していますので、こちらをご覧ください。）

導入時の苦労・悩み

dbt 以外にキャッチアップしておくべき事柄が多く、それらをキャッチアップする必要があった点です。 具体的には次のようなものが挙げられます。

データモデリング
- データ構造のプラクティス（ディメンショナル・モデリング、スタースキーマ、etc.）
- モデルのレイヤー分けのプラクティス（ Staging 、 Marts 、 etc. ）
ソフトウェアエンジニアリングのノウハウ
- Git/GitHub活用、ブランチフロー
- CI/CD
- 本番、ステージング、開発の環境分け

そのため、導入時には下記の点を意識しました。

dbt のベストプラクティスページを読み込む
まずは小さくシンプルな方法で取り組み、最初から作り込まない

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

上長・チームへの説明

上長への説明

dbt Core が OSS であり、費用面の懸念事項がなかったこともあり、上長からはスムーズに承認を得られました。

一方で、 dbt 導入がデータ組織以外にとってどのようなメリットがあるのか、についての説明は意識的に取り組みました。 これは、データエンジニアリングについて社内から理解を得ることで、導入後にdbtをより活用しやすくするためです。まずはdbt で分析用データ基盤を整備することで大幅にクエリ費用を削減できる箇所や、バックエンドのエンジニアと適切に責務分担できる箇所があった（※1）ので、そちらをフックに dbt やデータエンジニアリングについて興味を持ってもらえるようにしました。

（※1 ... こちらの詳細は次の資料で公開しています: 次の10年を戦える分析用データ基盤構築の第一歩 - dbtによる基盤刷新とクエリ費用90%削減への取り組み - - Speaker Deck ）

チームへの説明

dbt 導入と同タイミングでデータ組織が1人→3人に増えたため、そもそも説明するチームメンバーがいませんでした。 メンバーが増えるにあたって事前に課題感の共有や dbt 導入の狙いなどについて擦り合わせることができた ため、データ組織としてスムーズに dbt 導入に取り組むことができました。

活用方法

共通データマートの作成
Yappli の CMS ダッシュボード用データマートの作成
Yappli Anlytics 用データマートの作成

よく使う機能

dbt の標準機能
- dbt run
- dbt test
- dbt docs

ツールの良い点

データモデリングツールとしての表現力が高い

dbt ではテーブルの参照関係（データリネージ）を追うことができたり、テーブルの実体化方法（ビュー、洗替テーブル、追記テーブル、など）を指定したりすることができます。これにより、各々の事情に合わせてデータ構造を設計・表現することができます。

公式ドキュメントが充実している

筆者が dbt を 1 年ほど使ってみた感覚として、 dbt でつまづいたり困ったりした時の解決策はだいたい公式ドキュメントに載っていました。また、公式ドキュメントには実装例やプラクティスなども書かれていてわかりやすく、とても参考になりました。

ツールの課題点

dbt を導入すれば解決、というわけではない

「ツールの良い点」にも書いた通り、 dbt の良い点はデータモデリングを実現しやすいところです。一方で、データモデリング自体は自分たちで行う必要があります。データモデリングに失敗すると、使いづらいデータ基盤になってしまいます。そのため、 dbt を導入する前に「自社のデータがどういった構造になっていると扱いやすいか？」を十分検討しておくことが重要になるかと思います。

dbt docs のテキスト表現力に限界がある

dbt docs は YAML ファイルの中に Markdown を書くことでテーブルやカラムの説明を細くすることができます。しかし、 dbt docs で利用できる Markdown 表現には制限があります。そのため、 dbt docs が充実してきてリッチなテキスト表現が欲しくなってきた際に限界を感じるようになるかなと思います。

今後の展望

dbt を導入して約1年半が経ちます。 dbt を導入していなければ、今のスピードと正確さでデータ組織でチーム開発するのは難しかったと感じており、導入したのは正解だったと思っています。

一方でまだまだ dbt の活用の余地がありますので、今後はそのあたりに取り組んでいきたいと思います。具体的には次の点に取り組んでいければと思っています。