Looker導入を機にデータガバナンスと分析基盤を整える話

Last updated at 2021-12-19Posted at 2021-12-19

初めに

株式会社じげんの齋藤です。
データ分析基盤チームで、データガバナンスやデータ可視化を担当しています。

この度、じげんでは【Looker】を導入することになりました。
PoC（導入前トライアル）の結果と、データガバナンスの展望についてお伝えします。
おまけでデータ戦略で妄想している未来についても語ります。

今回はLookerのデータガバナンス、コーディングのコツは導入前のためスコープ外です。
主にBQ(BigQuery)のデータの流れの話になります。
Lookerのガバナンスの仕組みについては株式会社ZOZOさんのこちらのブログが詳しいです。

PoCでは、とある事業部の朝会シート(スプシ)をLookerに置き換えました。
データ分析基盤はBQの管理に、分析担当者やマーケはLookerの管理に集中できるようになります。

朝会シート課題
- データソースの種類が多く(BQ,手書き,スプシadd-onなど)管理が煩雑
- KPIの定義が不明確(SQLや関数など)で、統一されていない
- 分析担当が都度BQに必要なテーブルを作成するなど、全体像が見えない
PoCのスコープ
- 各種KPIのLookMLでの定義
- データソースのBQ(BigQuery)一元化
- 必要なDM(Data Mart)をBQに作成

※ LookML: Lookerで導入しているデータモデリング言語

テーブルの可視化やグラフ化、分析用のモデルの作成は問題なく完了したものの、
POCの短期間で、LookMLとDMの構造でデータカオス化が進み、見通しが悪くなったので以下を決めました。

LookMLでUnion,Joinを繰り返すと依存関係やフィルターの設定が複雑になる
LookMLでのUNNESTはviewが多数できて見通しが悪くなる
よって、BQで処理済のDWH(Data Warehouse)を作成する

マーケや分析担当が調整&確認しやすいようにLookMLで行う

Looker導入に合わせてデータ分析基盤も再設計し、以下流れでデータガバナンスを整えることにしました。

分析基盤の構造
- DL 事業部単位。BQに作成。
- DWH サービス単位。BQに作成。
- DM サービス単位。DWHプロジェクトにデータセットを作成。
- BI サービス単位。分析担当がルールに則って作成。

DL,DWHはデータ分析基盤チームが全事業部を管理。権限は限定。
DM,BIは分析担当者がLooker経由で管理。変更はGitで管理。

DL、DWH,BIを明確に分けることで、それぞれの工程が明確化して、権限の設定も簡単になった。

データの流れ
・内部データソース
①CloudSQL/GCS → ②DL(BQ) → ③DWH(BQ) → ④BI(Looker)
・外部データソース
①GCS(BQ) → ②DL(BQ) → ③DWH(BQ) → ④BI(Looker)

①→②では、欠損データの検出やプライバシー情報のハッシュ化など、最低限の処理を実行
②→③では、BIの需要に合わせ正規化の解除や結合、UNIONなどを実行
③→④では、必要カラムの限定やJOINなどのほか、ビジネス上の調整やKPIの定義を行う

Looker導入に合わせては、以下のことを明文化した。

じげんではLookerに加えてELTの各工程にツールを導入し、より強力なガバナンスの構築を目指しています。

以下3種類のツールを導入してデータガバナンスを網羅することを構想している。
・ETLツールのCloud Data Fusion導入して外部ソースなども一括管理
・データ変換ツールのDataFormを導入してDL,DWHを管理
・BI、可視化はLookerで管理

権限の明確化とGit管理によって、DLからBIまでの全工程でガバナンスを網羅できる
※これらを導入するのはこれからなので、結果はまだわかりません。今後に期待ください。

-GCP Official Icons and Solution Architectures
インフラ構造を図示する際などに活用しています。

-Cloud Data Fusion
Googleのデータ統合サービス。GUIでパイプラインの制御をすることが可能。