LookerとDataPortalはどちらもBIというジャンルのプロダクトでGoogleが開発してる。
しかしこの2つの製品は設計思想が大幅に異なる。その違いを色々考えてみる。
LookerとDataPortal
基本事項の大雑把な比較
| 契約 | 実行環境 | 対応DWH | 出自 | チャートの作り方 | 外部接続 | |
|---|---|---|---|---|---|---|
| Looker | GCPとは別の契約が必要 | 契約単位での専用インスタンス | 色々 | Looker社をGogoleが買収 | モデルベース | API,コールバックAPI（コネクタ） |
| DataPortal | 無料 | フルマネージド | BigQueryのみ | Googleオリジナル | SQLベース | API |
チャートの作り方の比較
ここでは、最大の違いだと思われるチャートの作り方に着目する。
チャートというのは、ダッシュボードを構成する単一のデータ可視化表現（いわゆるグラフ）の事。
LookerもDataPortalもチャートを複数組み合わせてダッシュボードを構成するが、チャートの作り方に大きな違いがある。
DataPortalでは、1つのSQLから1つのチャートが作られる。チャートとSQLは1:1の関係にある。
Lookerでは、1つのモデルから複数のチャートが作られる。チャートとモデルはN:1の関係にある。
Lookerではチャートを作るのにSQLは書かない。
モデルとExplore
モデルとはLookerを特徴づける仕組みであり「とあるデータ探索ニーズの為に設計された、DWHの抽象レイヤ」の事。モデルはLookMLという定義言語によって記述される。LookMLはテーブル群の関係と属性がSQLの断片として記述されたymlベースのDSLだ。モデルはLookerのランタイムにデプロイされると様々な集計ニーズを実現する「動的ビュー・仮想データマート」のように動作する。
Exploreはデプロイされたモデルを操作するためのUIで、ユーザーはExploreを操作して集計とその結果を可視化しチャートを作る事ができる。
1つのモデルから複数のチャートを作る事が可能で、モデルとチャートの関係は1:Nとなる。
Lookerはモデルから複数のチャートを作る事ができる
モデルがあると何が嬉しいのか
DataPortalのようなChart from SQLなBIはシンプルで敷居が低いが、長期間運用しチャートの数が増えると色々と問題が起き治安が悪くなる。
- チャート間の仕様の不整合の増大
- ダッシュボード開発者のリソース逼迫とモチベーションの低下
- 似ているようで少しずつ違う大量のSQLの管理の難しさ
Lookerはモデルという中間レイヤによってパターンに沿ったSQLを抽象化し計算仕様を共通化できる。
この思想をSSOT(Single source of truth="信頼可能な唯一の情報源")と呼んだりする。
SSOTの思想に則って作られたデータ基盤は、スケーラビリティとガバナンスを大幅に向上させる事ができ、治安を高める事ができる。（データ基盤に秩序と安寧を！！）
ユースケースと役割の違い
DataPortalではビジネスユーザーがSQLを書ける人（アナリストとか）にチャートの作成を依頼する事が多い。
LookerではビジネスユーザーがExploreを操作（=セルフサービスBI）してチャートを作り、SQLを書ける人はLookMLでモデルを記述する。
| ロール | DataPortal | Looker |
|---|---|---|
| ビジネスユーザー | 依頼して待つ | 自分でExploreを操作してチャートを作る |
| SQLを書ける人 | SQLを書いてチャートを作る | LookMLを書いてモデルを作る |
様子の比較
