こんにちは、 Ubie でソフトウェアエンジニアをしている syu_cream です。 最近は社内のデータ分析基盤のリードなどをやっております。
本記事では、まさにそのデータ分析基盤について概要と技術的構成、今後について、最近の事情を踏まえながら紹介します。社内データ基盤に関わる開発・運用に関わるソフトウェアエンジニアの方や、分析ユースケースで利用するデータアナリストなど、社内のデータ分析環境に関わる人々にとって何か参考になる記事となれば幸いです。
Ubie のデータ分析基盤とは
Ubie はデータの会社です。それは勝手に僕がそう名乗っている訳ではなく、社内でもそうした認識があり、事業を支えるコアにデータの蓄積と利活用があります。データ利活用のシーンとしては、データに基づく事業やプロダクトの方向性付けもありますし、もっと Ubie 特有事情で言うと「患者のジャーニーをデータで捉え、製薬企業と連携する」といった価値創出があります。（これらの具体的なエピソードに関しては、ぜひ既存のブログ記事もご覧いただければ！）
Ubie においてデータ分析は一定の民主化に成功しており、中央集権的なチームの稼働や許可を待たずに各チーム・メンバーが自発的にデータを連携して分析、可視化を行っています。分析を行うのはデータアナリストに限定されず、多くのソフトウェアエンジニア、果てはアナリストでもエンジニアでもないメンバーが分析に加わる場合もあります！
そうしたデータ利活用ニーズがある Ubie ですが、分析するデータをゼロから収集・加工して分析するパイプラインを都度敷設するのはコストと技術的困難、信頼性低下などの諸問題を発生させかねません。医療データを取り扱う Ubie において、センシティブなデータは適切な管理下に置かれる必要もあります。これを「様々なデータを効率的・安全に蓄積してデータ分析可能にすることを、データエンジニアリングのスペシャリティを発揮して一挙に行う」のがデータ分析基盤の責務です。 2024/11 現在、データ分析基盤は「データ分析にまつわる生産性」と「データ信頼性」にコミットすると位置付けています。
データ分析基盤の構成
全体像
データ分析基盤を実現するデータパイプラインの全体像は下図の通りです。
技術スタックとしては以下を活用しています。
- Dataflow
- ブラウザやモバイルのフロントエンドから送信されるログをPub/Subを介してリアルタイムにBigQueryに同期するために利用
- Cloud Composer
- アプリケーションDBからのデータ転送と、dbt による変換処理を定期実行するためのスケジューラーとして利用
- BigQuery
- データ蓄積と分析の環境としてフル活用
- dbt (dbt core)
- 分析向けの変換やデータプライバシーを加味したデータ分析提供環境の仕分け、仮名加工などを担う。 BigQuery 上の分析環境を支えるエコシステムの中心的存在
- Lightdash
- コード管理されたデータ可視化環境の提供
- （現在 Looker Studio との併用あり）
- （データソースとしてアプリケーション側で Cloud Spanner, AlloyDB を使用）
dbt を中心とした変換パイプライン
特徴的なのは dbt & Lightdash によって広くコード管理された変換・可視化パイプラインでしょう。データを取り込みデータレイクに配置するまではあまり重厚な変換処理を行わず、 dbt SQL モデルでクエリで加工を繰り返します。 dbt のモデルは多段のレイヤー構造を持ち、それぞれのレイヤーに特化した責務を実現することで各モデルをシンプルに保ちつつ、再利用性を高めています。
このレイヤー構造については過去に発信をしており、基本的にこれに従っています。
dbt モデルの開発には一定の民主化に成功しており、社内で数多くの開発者が携わっています。下図は規模感を示す一例ではありますが、 3000 件以上の dbt モデルが稼働している状態です。全てのモデルが最重要という訳ではないし、敢えて冗長的にモデルを構築してもいる訳ですが、 dbt を中心としたデータ分析基盤の規模感は伝わるかと思います。
Lightdash を用いた分析エコシステム
dbt で加工したデータを Ubie では主にLlightdash (一部は Looker Studio と併用) を用いて可視化しています。 Lightdash は dbt のモデル定義上でメトリクスやディメンジョンの定義、ラベリング等が行えます。 dbt でデータ分析のエコシステムを構築しているチームにおいて、障壁を低く導入できるとともにコード管理の恩恵をさらに埋めることができる可視化ツールと言えます。
...
- name: view_event_name
description: "View event name for the XXX content"
meta:
dimension:
type: string
label: view_event_name
- name: click_links_event_name
description: "Click-links event name for the XXX content"
meta:
dimension:
type: string
label: click_links_event_name
- name: show_event_XXX_id
description: "XXX has the show event for the XXX content"
meta:
metrics:
show_event_count:
type: count_distinct
label: "XXX 掲載数"
...
Lightdash で作成したダッシュボードはそのままだと dbt のコード管理の世界から分離されてしまうのですが、 Ubie ではダッシュボードから dbt の exposures を自動で書き起こすワークフローを作成してもいます。これにより dbt のモデルからダッシュボードへのリネージが繋がり、モデル変更の影響範囲が観測しやすくなっています。
この dbt & Lightdash を中心としたデータ変換・分析パイプラインは開発者の参入障壁障壁がやや高まるものの、その投資効果は複利で効いてきます。そして現在、社内のエコシステムとスキルの習熟度、データ分析を広く行っていく文化の醸成に成功してきており、リターンが投資を大きく上回るフェーズになってきています！具体的には以下の記事で紹介しているように、データアナリストではないメンバー（例えば BizDev や QA エンジニアなど）が、一定データ分析に明るいメンバーが構築した dbt & Lightdash のパーツを組み合わせてデータ分析を行い、結果プロダクト開発の方向性を決めうるインサイトを得るに至っています。
データプライバシーを考慮した分析環境の分離
Ubieが取り扱うサービスでは複数の法令やガイドラインにまたがったデータを取得・保存することがあります。法令やガイドラインの異なる複数のデータが1つのデータベースや分析環境内に混入すると、分離を正しく行うことが難しくなりガイドライン違反になりかねません。これを避けるべく、 Ubie ではアプリケーションのデータベースやログの保存場所、そこから ETL して分析可能にする BigQuery の Google Cloud プロジェクトを分割しています。
下図はデータベースやログ、分析環境を分離している構成イメージです。この中で BigQuery 上に展開される領域群はどのようなデータを配置して良いか、どんな人がアクセス可能かが規定されており、それに従って Google Cloud プロジェクトの IAM 権限や BigQuery にアクセスするツール等の権限管理を行っています。
今後の方向性
ここまで紹介してきた Ubie のデータ分析基盤ですが、「様々なデータを効率的・安全に蓄積してデータ分析可能にすること」ができる基盤の骨子は一定出来上がってきました。会社のデータ収集・分析要件に対してシンプルでスケーラブルな手段を提供し続けられていると自負しています。
今後立ち向かう必要があるのは、この基盤をより事業・組織の状況に沿ったアップデートを行うことです。ここまで紹介してきたとおり、 Ubie はデータの会社であり極端な話データが売り上げに転化されます。データ分析基盤というのは Garbage In, Garbage Out であり、いかに良質なデータを大量に収集できるかが肝です。
しかしながらこれは言葉で表現するほど容易な話ではありません。下図に示すデータの収集から分析に至るまでの活動、社内では最近これをデータ・バリューチェーンと呼称しておりますが、このバリューチェーンでは様々な思惑とステークホルダー、得意領域の異なるスペシャリストが登場します。データ・バリューチェーン上で発生する課題は、データを使う最前線でありそれを価値に転じさせている「③データをつかう」人々が最も感じやすいでしょう。一方その課題を解く能力は、上流の「①データをつくる」人々が持っている事が多いです。この非対称性をいつどうやって解くとデータ分析の活動が最大化されるでしょうか？中間に位置するデータ分析基盤はこの悩ましい問題に立ち向かう必要があると考えます。
ちなみにUbieのデータ・バリューチェーンの概念に関してはこちらの記事でも詳しく語られています。
これに関連して、データ収集・分析をどういった体制で解くべきかを考える必要もあります。世の中で囁かれている DataOps や Data Mesh の考え方を取り入れるのもあると思いますし、課題を特定してメタデータ管理のツールなどソリューションを当てていくのもありえるでしょう。データの収集・分析が民主化されアジリティ高くデータが価値に転じている今の Ubie の文化とメンバーのマインドを考慮して、基盤のあるべき姿を微修正することが求められます。
おわりに
以上、現在の Ubie のデータ分析基盤の紹介でした。同様のデータ基盤はテック企業各社に多々あると思われますが、日々関わっている人々や関心のある方々の刺激になる記事となっていれば幸いです。
ちなみに Ubie ではこれまで紹介してきたデータ・バリューチェーンに関わる様々な職種の人材を募集中です！ Ubie では非常に明瞭な目的意識と利活用の出口を意識したデータ収集・分析が成されており、率直に申し上げて複雑で難易度が高いデータプロダクトを作っていると認識しておりますが、この難題を解く結果、人々、それこそ我々にとって身近な人の健康をも守れる可能性を秘めていると思います。もしこのチャレンジに少しでもご興味があれば、以下採用サイトや、僕 syu_cream にご連絡いただければ幸いです！
Ubie のデータ関連職種とそれぞれのメンバーが立ち向かっていることについて理解を深めたい場合、こちらの資料もございますので、ぜひ！
Discussion