LoginSignup
1

More than 1 year has passed since last update.

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

Last updated at Posted at 2021-12-19

初めに

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

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

ビジネスインテリジェンス&ビッグデータ分析ソフトウェア - Looker

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

「データ集計基盤の改善でLooker導入に至ったワケ」 -株式会社ZOZO TECH BLOG

PoCについて

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

スプシ管理からLookerへ

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. 1の需要に必要十分なカラムをもつ、正規化しないDWHの作成
3. DWHの作成に必要なDLの作成

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

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

分析基盤の構造、DL/DWH周りの設計はこちらを参考にしました。
『ビッグデータを支える技術 ——ラップトップ1台で学ぶデータ基盤のしくみ』

まとめ

データ分析基盤構造

データ分析基盤インフラ設計
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
じげんではLookerに加えてELTの各工程にツールを導入し、より強力なガバナンスの構築を目指しています。

以下3種類のツールを導入してデータガバナンスを網羅することを構想している。
・ETLツールのCloud Data Fusion導入して外部ソースなども一括管理
・データ変換ツールのDataFormを導入して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までの全工程でガバナンスを網羅できる
※これらを導入するのはこれからなので、結果はまだわかりません。今後に期待ください。

参考資料

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

  • DataForm ELTのTに特化したツール。GCPに組み込まれて無料になり、BQとの連携が強化された。

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1