データ基盤をdbtとLookerで刷新した話

こんにちは。柴田です。 OLTAでデータ基盤の刷新を行ったので背景など共有したいと思います。

背景

これまでOLTAのデータ基盤は比較的シンプルな構成で運用しており、サービス初期においては特に問題なく機能していました。しかし、サービスの成長に伴い、データ量や求められるデータの質が高度化するにつれて、以下のような課題が顕在化してきました。

複雑化するSQL

重要な経営指標を算出するために、高度なSQLの知識が必要となり、担当者しか理解できないような職人芸的なクエリが増えていました。

集計の属人化

簡単な指標の集計でさえ、都度担当者が定義を確認する必要があり、非効率でした。

依頼の遅延と不整合

データ集計の依頼に時間がかかり、手作業によるミスも発生しやすく、定義の不統一も散見されるようになっていました。

これらの課題が積み重なり、アナリストは本来の分析業務に集中できず疲弊し、ビジネスサイドのメンバーがデータを利用しようとする際にも、時間的な制約やデータの信頼性の低さから、十分な活用ができていない状況でした。

やったこと

dbt

まず着手したのは、分析のための中間テーブル（マート）を構築する仕組みの改善です。そこで導入したのがdbtというツールです。これにより、マートを定義するSQLをコードとして管理し、GitHubのPull Requestベースでレビューを行うワークフローを確立できました。dbtがテーブル間の依存関係を自動で管理してくれるため、意図しない循環参照が発生した場合にエラーとして検知できる点も大きなメリットです。

以前の仕組みでは、BigQueryのviewを作成すると、そのviewが定期的にテーブルとして実体化されるというシンプルなものでしたが、複雑化するにつれて依存関係の把握が困難になり、循環参照も発生していました。（循環参照により、特定のレポートだけ1日遅れの数値が出る、などの事象が発生していました） dbtの導入により、この課題を解消し、より安全かつ効率的なデータマートの構築が可能になりました。

BIツールで集計を行うことを見越して、このレイヤーでは事前集計を行わず、BIツールが発行するクエリで日次、週次などを切り替えられるようにしました。

Looker

BIツールの選定も行いました。metabaseというツールを導入していたのですが、GUIから行える操作が十分ではなく、ビジネス職のメンバーはmetabaseでの分析は行わず、何をするにもデータチームからのデータ抽出を待つ、という状態になっていました。データガバナンスの向上、セルフサービスBIの実現を目的として Lookerを導入しました。 LookMLの話を始めると長くなってしまうので、このエントリでは割愛しますが、Lookerは価格に見合うだけの価値があると感じています。運用コストもほとんどかからず、気が付くと便利な新機能が追加されているのも魅力です。ただし、LookMLを効果的に使いこなすには、それなりの学習コストとスキルが必要となることは認識しておく必要があります。

組織改善

日々増加するデータをビジネスの意思決定に活用していくアナリストと、そのための基盤となるデータを正しく蓄積し、活用しやすい状態に保つデータエンジニアという、2つの専門職に分けたチーム体制を構築しました。

現状の課題をヒアリングする中で、これら2つの役割を同じチームが担当していたことが、データ基盤の整備を遅らせる一因になっていたことが分かりました。役割を明確に分けることで、それぞれの専門性を活かし、より効率的に業務に取り組めるようにしました。

現在のステータス

日々の新しい分析、データ活用はdbt, Lookerを利用した新しい仕組みの上で動いています。今後も活用が定着するようにLookMLのメンテなどを日々を行っています。

また（良い方向の）想定外の事象として、ビジネス側メンバーによるレポート、ダッシュボードの作成が想定よりも進んでいます。LookMLによりメトリクスの算出方法を提供することで、自分たちで必要なレポートを必要なタイミングで作ることが出来ています。事前に要件を決めずに試行錯誤できるのがよいようです。ビジネス側メンバーにSQLを覚えてもらうというアプローチもありますが、こちらはデータガバナンスを保つのが難しいです。LookMLであれば発行するSQLはLookML開発者側でコントロールできます。

余談ですが、Looker導入後に以下のmetrics-firstという概念を紹介している記事を見つけました。

Dashboards are dead - 3 reasons to go metrics-first

ざっくりいうとデータチームからダッシュボードを提供するアプローチは様々な要因でうまくいかず、セルフサービスはガバナンスに問題がある。ダッシュボードではなくメトリクスを提供するとうまくいく、という内容です。直面していた問題の捉え方と解決のアプローチが似ていて、方針は間違ってなさそうだなと安心しました。

さらに余談なのですが、LookMLが提供するセマンティックレイヤーとLLMは相性がよさそうで、自然言語による実用レベルのデータ分析が近い将来実現出来そうで楽しみです。LookerへのGemini実装が少しずつ始まっているので今後活用できるユースケースが出てきたら紹介したいと思います。

データエンジニア募集について

今回のデータ基盤刷新を通じて、OLTAに不足していたのは「データエンジニアリング」という考え方だったと強く感じました。現在、このデータエンジニアリングを実践してくれるデータエンジニアを積極的に募集しています。データエンジニアリングを軽視することでどのような課題に直面するのかを身をもって経験したからこそ、その重要性を深く理解しており、データエンジニアが存分に力を発揮できる環境が整っていると思います。

記事の執筆環境について

なおこの記事はほぼ完成に近い状態で下書き保存してから、仕上げまでおよそ半年ほどかかりました。半年放置したのはひとえに僕の怠惰によるもの（半年推敲したわけではありません）ですが、テックブログの執筆を急がされたり、強制されない環境であることをアピールしたいと思います。自社のプレゼンスとか採用とか色々あると思うのですがそれを目的にしたテックブログは続かないと思うので、各自の裁量で書きたいときに書くという環境を維持して長く続けていきたいです。