はじめに
百川(ももかわ)と申します。私は2024年6月にリーナーに入社し、エンジニアのluluさんと2名体制でデータ分析基盤チームを発足し、データの収集から活用までを支える基盤づくりに取り組んでいます。
チーム発足から1年が経ったタイミングでもありますので、リーナーのデータ分析基盤チームにおける取り組みを紹介します。
データ分析基盤チームにおける1年間の取り組み
Google Cloudを中心にデータ分析基盤を構築しています。2024年以前より、リーナーのプロダクトのデータはBigQueryに集約しており、Looker Studioを利用したデータの可視化を行っていました。
データ同期処理についてはEmbulkとDataStreamが並行で運用されています。
データの収集から活用までの導線を整備することを目指して、チーム発足から1年間においてdbt、Lookerの導入に取り組みました。これらはまだ一部プロダクトでの利用に留まりますが、他プロダクトへの展開に向けて整備していきたいと考えています。
dbtの導入
dbt(data build tool)とはデータ処理プロセスのELTにおいて「T」にあたる、データ変換処理を担うツールです。BigQueryに集約したデータの変換処理を行うために、リーナーでは有償版のdbt Cloudを導入しました。必要な機能が一通り揃っているので、小規模なチームでも迅速に開発を進めることができました。
データ変換処理を抽象的に扱えるよう、dbtのプラクティスやディメンショナルモデリングの事例などを参考にして命名規則を設け、レイヤ設計を行ないました。
- Staging層: ソーステーブルと1対1の構成をとり、基本的な型変換処理などを定義しています。
- Intermediate層: ビジネスロジックに基づき、データ結合や絞り込み処理を定義しています。
- Fact/Dimension層: 分析の対象となる数値指標と、属性情報をそれぞれ定義しています。
これまではLooker Studioのカスタムクエリがデータ結合、変換、集計までの役割をすべて担っており、多重のWITH句を書かざるをえずコード行数が数百行になるなど、クエリ全体の見通しが悪くなりやすい傾向にありました。また、Looker Studioのカスタムクエリはブラウザ上でしか閲覧ができず、クエリのレビューや検索が難しいという問題もありました。
そこで頻繁に参照する指標から優先度を設定して、カスタムクエリの処理を分解し、dbtのデータモデルへ反映する作業を地道に行っています。クエリの責務を分離して、型変換などの共通処理は一箇所に集約することで、全体のロジックが見通しやすくなり、可読性とメンテナンス性が向上しました。クエリに対してLintやレビューを通せるようになったのも嬉しいポイントです。
データテストについては、dbtで提供されているテストの仕組みを利用していて、テーブルに予期せぬ値が紛れ込んだときに早期に検出できるようになりました。Not Null制約の検査など、頻繁に書くテストを簡潔に記述できるのが便利でした。
ドキュメンテーションについては、dbtのモデルやカラムに対するDescriptionを設定していきました。一からすべてを手作業で埋めていくのは大変だったため、dbt-osmosisを利用して一部の作業を自動化しています。
Descriptionの設定にあたっては、社内で策定されているユビキタス言語が大いに役立ちました。
私がリーナー入社初期からドキュメンテーションの活動に精力的に取り組むことができたのは、これまでユビキタス言語を整備・運用を続けてくれているリーナーメンバーのおかげです。
Lookerの導入
社内において、BIツールは主にLooker Studioが広く利用されていて、特にカスタマーサクセス支援のために多くのレポートが作成されていました。メンテナンスが難しく、似たようなレポートやカスタムクエリが複製されており、同じ集計定義を変更するときに一部で変更漏れが発生してしまうこともありました。
ダッシュボードをコード管理するツールはいくつかありますが、リーナーではLookerを導入しました。Lookerでは、LookML(Looker Modeling Language)という言語を用いて、モデル、ビュー、ダッシュボードといったリソースを定義します。こうした設計は、「多様な分析軸で指標を見たい」という利用者の要望へ柔軟に応えつつ、同じことを表す指標は一箇所に定義できるという利点がありました。
社内のビジネスメンバーでBigQueryやSQLに慣れている人があまり居なかったため、LookerのExploreという機能を利用して、SQLの知識が無くても直感的な操作でデータ抽出が行える環境を提供できることも魅力でした。
データモデルとダッシュボードをリポジトリで管理してコードベースで一貫して追跡できるようになったことで、例えばプロダクトのコードを変更したときにも、ダッシュボード側への影響範囲の特定がしやすくなりました。ダッシュボードのユースケースによってはフィルタを強制したいシーンがあり、コードベースで明示的にフィルタを指定できる点も良かったです。
LookMLにもユビキタス言語を用いてラベルやDescriptionを設定し、ダッシュボードの利用者、開発者がコラボレーションしやすい状態を目指しています。LookMLで設定したメタデータと生成AIを組み合わせた分析機能の進化に期待しています。
おわりに
こうして振り返ると、データの蓄積から活用までの導線を設計することに注力した一年間でした。まだまだ道半ばであり、忍耐強くアップデートを続ける必要があります。今回は取り組みの概要を紹介するに留まりましたが、つまづいたこと、大変だったことなどはまた別の機会に触れられればと思います。
データの信頼性を高めながら、データに基づいた意思決定を支援し、これからもお客様への価値提供に向き合っていきます。
宣伝
リーナーでは、データの利活用を通じて調達購買領域の課題を解決したいエンジニアを募集しています！
Discussion