Looker で利用するデータモデルをワイドテーブルからスタースキーマに変更したら予想以上に大変だった

はじめに

データエンジニアの dach です。2025年2月に拠点横断アナリティクスという、複数の拠点のデータを横断的に分析し、経営判断や業務改善に活用するための機能をリリースしました。この機能では Looker を活用しており、マルチテナントに対してダッシュボードを提供しています。この記事では、拠点横断アナリティクスに利用している「データモデル」について一部紹介したいと思います。

Looker が BigQuery からデータを取得する仕組み

「なぜワイドテーブルからスタースキーマへの移行をしたのか」をお話する前に、「なぜ」がより伝わるために前提として「Looker が BigQuery からデータを取得する仕組み」を説明します。Looker がデータを取得するまでの仕組みはざっくりと以下のステップに分けられます。

1. Looker 上で分析したい項目を選択し、データ取得を実行する（Explore）
2. Looker がクエリを発行する（Looker API）
3. Looker が BigQuery（ソースデータベース） に対し、クエリを発行する（BigQuery API）

「Looker が BigQuery からデータを取ってくる」と書くと上記図のように単純な流れですが、実際にはもう少しだけ複雑です。Looker には Explore というセマンティックレイヤーがあり、基本的には定義済みのデータ項目を選択してデータを取得します。（STEP-1 に該当）

[Explore の画面イメージ]

Explore で選択されたデータ項目は、バックグランドで SQL に変換されます。Explore の裏側には Model という、View（DB の単一テーブル、もしくは複数テーブルを結合したもの）と View の結合方法に関する情報をまとめたものが存在します。Looker は Model に定義された情報を元に、選択された項目が取得できるように View を結合した SQL 生成します。（STEP-2 に該当）
そして、生成した SQL を Looker に紐づけた SA の権限に基づいて、 BigQuery 上で実行し、データを取得します。（STEP-3 に該当）

-- 生成された SQL イメージ(複数 View で Model を構築している場合)
select
	t1.dim_1,
	t2.dim_2,
	t3.fact_1
from view_1 as t1
left join view_2 as t2 on t1.dim_1 = t2.dim_1
left join view_3 as t3 on t1.dim_1 = t3.dim_1

[関係を表した図]

ワイドテーブルからスタースキーマへの移行

当初、PoC として開発を進めていた拠点横断アナリティクスは、開発スピードを重視して内部向けに構築され実績もあるワイドテーブル（非正規化テーブル）を利用して実装をしていました。PoC としては期待通りの働きを見せてくれたものの、以下の課題があることがわかりました。

• データリネージが複雑であるためデータ項目追加のコストが高い（拡張性）
• view_2 データは表示したくない、などユーザーに応じた柔軟なデータアクセス制限を行うことが難しい（機密性）
• ダッシュボード上のグラフの分だけクエリが発行されることもあり、パフォーマンスの最適化に限界がある（保守性）

上記の課題を解決するため、スタースキーマモデルへの移行を決定、以下の 2 STEP で移行を行いました。

1. ワイドテーブルとそのリネージを分解しリモデリングする
2. LookML の書き換えをする

[ワイドテーブル参照]

[スタースキーマへの移行]

移行をやってみて辛かったこと

実際にやってみた所感は唯一つ「作り込んでいた分だけしんどさがある」ということです（笑）。工程としては前述の通り 2 STEP しか無いですが、そこには色々な辛さが待っていました。例えばリモデリングでは、結合が最小化されるようにモデルの分離やロジックの最適化を行いますが、最適な分割粒度はどうするか、類似項目をどこまでまとめるか、複雑な算出項目をどのように取り扱えるようにするか、暗黙的に利用されていたロジックやスコープについての関係者間での合意、など、実装やアーキテクチャ以外の部分でも大変に頭を悩まされました。

また LookML の書き換えも、複数になる View の管理方法を適切にするためにディレクトリ構造を再設計したり、ダッシュボードを LookML 化していたので、ダッシュボード上で使われているすべての項目（フィルタや Look など）を適切な View に変換する必要があるなど、単純作業の物量が押し寄せて時間を取られました。

そのため、私が一番お伝えしたいのは（当たり前のことですが）「Looker 上のあれこれを構築する前に、モデリングは確定した方が良い」ということです。幸い、リリース前のことだったので開発スケジュール以外に影響はなかったので安心（？）でしたが、実際に運用が始まってからだと相当大変になると思います。

まとめ

スタースキーマへの移行は、短期的には大きな工数を要しましたが、長期的なデータ品質の向上とメンテナンス性の改善に大きく貢献したと言えます。特に、拠点横断アナリティクスのような複雑なデータモデリングでは、適切なデータモデリングの重要性が顕著となりました。

参考文献

• LookerML の用語と概念: https://cloud.google.com/looker/docs/lookml-terms-and-concepts?hl=ja
• データベースの接続方法: https://cloud.google.com/looker/docs/connecting-to-your-db?hl=ja