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

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

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

[ビジネスインテリジェンス＆ビッグデータ分析ソフトウェア - Looker](https://ja.looker.com/)

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

[「データ集計基盤の改善でLooker導入に至ったワケ」 -株式会社ZOZO TECH BLOG](https://techblog.zozo.com/entry/looker-data-processing-improvement)

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

![スプシ管理からLookerへ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/507849/b09f2766-b74a-216f-bf35-42530172c150.png)

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

* PoCのスコープ
    * 各種KPIのLookMLでの定義
    * データソースのBQ(BigQuery)一元化
    * 必要なDM(Data Mart)をBQに作成
  
 ※ LookML: Lookerで導入しているデータモデリング言語

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

* LookMLで（なるべく）しないこと 
    * UNION
    * JOIN
    * UNNEST

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


- LookMLで（なるべく）すること
    * KPIの定義
    * マーケ/ビジネス上の調整(月末利用率など)

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

# Looker導入後のデータ分析基盤
Looker導入に合わせてデータ分析基盤も再設計し、以下流れでデータガバナンスを整えることにしました。
1. Lookerで可視化が必要なデータ,テーブルの洗い出し
2. １の需要に必要十分なカラムをもつ、正規化しないDWHの作成
3. DWHの作成に必要なDLの作成

- 分析基盤の構造
    - DL 事業部単位。BQに作成。
    - DWH サービス単位。BQに作成。
    - DM サービス単位。DWHプロジェクトにデータセットを作成。
    - BI サービス単位。分析担当がルールに則って作成。
  
DL,DWHはデータ分析基盤チームが全事業部を管理。権限は限定。
DM,BIは分析担当者がLooker経由で管理。変更はGitで管理。


分析基盤の構造、DL/DWH周りの設計はこちらを参考にしました。
[『ビッグデータを支える技術 ——ラップトップ1台で学ぶデータ基盤のしくみ』](https://gihyo.jp/book/2021/978-4-297-11952-2)

# まとめ
## データ分析基盤構造
![データ分析基盤インフラ設計](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/507849/c129817e-0a2c-f7ea-92c2-436f9409796d.png)
DL、DWH,BIを明確に分けることで、それぞれの工程が明確化して、権限の設定も簡単になった。

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

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

## データガバナンスのための決定事項
Looker導入に合わせては、以下のことを明文化した。
1. データ基盤とBIの権限範囲の明確化
2. DL,DWH,DMの構造決定、命名規則の明文化
3. LookMLですること、しないことの決定 



# おまけ
## データ分析基盤未来予想図
![スクリーンショット 2021-12-13 16.10.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/507849/e5678ef8-f32d-d183-37ce-6c05e5957d45.png)
じげんではLookerに加えてELTの各工程にツールを導入し、より強力なガバナンスの構築を目指しています。

以下3種類のツールを導入してデータガバナンスを網羅することを構想している。
・ETLツールの[Cloud Data Fusion](https://cloud.google.com/data-fusion/docs/?hl=JA)導入して外部ソースなども一括管理
・データ変換ツールの[DataForm](https://dataform.co/)を導入してDL,DWHを管理
・BI、可視化はLookerで管理


## Looker,DataForm,Data Fusionにより達成できる未来
- コードのGit管理
    - Data Fusion (データソース~DL)
    - DataForm (DL~DW)
    - Looker (DM~BI)
- 権限範囲
    - DL~DWHまでをデータ分析基盤チーム
    - DM~BIを分析担当者

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

# 参考資料
- [『ビッグデータを支える技術 ——ラップトップ1台で学ぶデータ基盤のしくみ』](https://gihyo.jp/book/2021/978-4-297-11952-2)
データウェアハウスや列指向DBについてはこちらを参考にしました。

- [DAMA-DMBOK](https://www.dama.org/cpages/body-of-knowledge)
データマネジメントのバイブル。日本語は[こちら](https://www.dama-japan.org/)

- [「データ集計基盤の改善でLooker導入に至ったワケ」](https://techblog.zozo.com/entry/looker-data-processing-improvement)
 [株式会社ZOZO](https://corp.zozo.com/)さんのテックブログ記事です。looker導入にあたり参考にしました。


-[GCP Official Icons and Solution Architectures](https://docs.google.com/presentation/d/1vjm5YdmOH5LrubFhHf1vlqW2O9Z2UqdWA8biN3e8K5U/edit#slide=id.g19b41f69d7_2_265)
 インフラ構造を図示する際などに活用しています。

- [DataForm](https://dataform.co/)
ELTのTに特化したツール。GCPに組み込まれて無料になり、BQとの連携が強化された。

-[Cloud Data Fusion](https://cloud.google.com/data-fusion/docs/?hl=JA)
 Googleのデータ統合サービス。GUIでパイプラインの制御をすることが可能。