Looker

解決する課題

• 部署ごとに「売上」「アクティブユーザー」の定義がバラバラで、レポートごとに数値が食い違う問題を、指標の一元定義で解消したい
• データウェアハウスのデータをコピーして抽出（エクストラクト）せず、最新の状態をそのまま分析したい
• 分析結果を社内ダッシュボードだけでなく、自社アプリケーションへ埋め込んで外部ユーザーにも提供したい
• SQL を書けない利用者でも、ガバナンスの効いた範囲でセルフサービスに探索できる環境を用意したい

主要概念と用語

• LookML: Looker 独自のモデリング言語。テーブル・結合・指標（メジャー）・ディメンションを宣言的に定義し、これがすべての分析の「単一の真実の源」になる。SQL を直接書くのではなく、LookML が利用者の操作を SQL に変換する
• モデル / ビュー / エクスプロア: ビューは個々のテーブルの定義、モデルは利用するデータベース接続と公開範囲、エクスプロアは利用者が探索を始める入口。利用者はエクスプロアからドラッグ操作で分析する
• ディメンション / メジャー: ディメンションは「いつ・どこで・誰が」のような切り口、メジャーは「合計・件数・平均」のような集計値。LookML で一度定義すれば全レポートで再利用される
• Look / ダッシュボード: 保存された単一のクエリ結果が Look、複数のタイル（グラフや表）をまとめた画面がダッシュボード
• PDT（永続的派生テーブル）: クエリ結果をデータベース側に物理化して再利用する仕組み。重い集計を事前計算し、応答を速くする
• 埋め込み分析（Embedded Analytics）: ダッシュボードや探索画面を外部アプリへ組み込む機能。プライベート埋め込みと、外部ユーザー向けの署名付き埋め込みがある
• Looker（Google Cloud core）と Looker Studio: 前者は LookML を基盤とするエンタープライズ BI、後者は無償で手軽な可視化ツール。役割が異なる別製品である点に注意

仕様・制限・クォータ

• Looker は自前でデータを保持しないのが基本思想。クエリは接続先のデータウェアハウス（BigQuery、Snowflake、各種 SQL データベースなど）側で実行され、Looker は結果を受け取って描画する
• そのため性能とコストの多くは接続先データベース側に依存する。重いダッシュボードはデータベースの処理量を増やすため、PDT やキャッシュで負荷を抑える設計が重要
• 同時クエリ数やスケジュール配信数、エクスポート行数などには上限が存在する。具体的な数値はエディション・プランや接続先によって異なるため、断定せず公式ドキュメントで都度確認する
• 提供形態として、Google がホストするクラウド版に加え、ユーザー自身のインフラで運用する形態も歴史的に存在する。新規採用では Google Cloud 上のマネージド版が中心になる

内部の仕組み

Looker の中核は、利用者の GUI 操作をその場で SQL に変換し、接続先のデータウェアハウスへ発行する点にあります。データを Looker 側へ抽出・複製しないため、利用者が見るのは常にデータベースの最新状態です。この「クエリ・オン・デマンド」方式が、抽出ファイルを定期更新する従来型 BI との大きな違いです。

変換の元になるのが LookML です。アナリストがテーブル定義・結合・指標を LookML で記述すると、Looker はその定義に基づいて利用者の選択（どのディメンションとメジャーを組み合わせるか）から正しい SQL を組み立てます。指標の計算ロジックが一箇所に集約されるため、どのダッシュボードから見ても同じ数値になります。これが**セマンティックレイヤー（意味の層）**と呼ばれる役割です。

繰り返し実行される重いクエリには、結果を一定時間使い回すクエリキャッシュと、集計結果をデータベース側のテーブルとして物理化する PDT が効きます。PDT はスケジュールやトリガーで再生成でき、ダッシュボード表示のたびに巨大な集計を再計算する事態を避けられます。

設計パターン / ベストプラクティス

• 指標は LookML に集約し、ダッシュボード側で独自計算を増やさない。定義の重複が数値のブレを生むため、メジャーは可能な限りモデル層で定義する
• LookML はバージョン管理（Git）と連携して開発する。開発モードと本番モードを分け、変更をレビューしてからデプロイする運用が標準
• 重い集計や頻出クエリは PDT で事前計算し、ダッシュボードの応答を安定させる。生成タイミングはデータ更新サイクルに合わせる
• ダッシュボードのタイル数とフィルタ範囲を欲張らない。1 画面に大量のタイルを置くと、その分だけ接続先データベースへのクエリが増える
• 外部公開には署名付き埋め込みを使い、ユーザー属性（テナント ID など）で行レベルのデータ分離を行う

運用・監視

• Looker 自身の利用状況は System Activity（システムアクティビティ）で把握できる。誰がどのクエリを実行し、どれだけ時間がかかったか、エラー率はどうか、を継続的に観察する
• 遅いダッシュボードは、Looker ではなく接続先データベースのクエリ性能を疑うのが基本。実行された SQL とその所要時間を確認し、PDT 化やインデックス、ウェアハウスのスケールで対処する
• スケジュール配信（メール / Slack / クラウドストレージ）の失敗を監視し、配信が止まっていないかを確認する
• LookML の変更は本番反映前に検証し、ブロークンなコンテンツ（壊れた参照）を Content Validator で洗い出してからデプロイする

コスト

セキュリティ

• 認証は Google Cloud の IAM や SSO（SAML / OpenID Connect）と連携し、組織のアカウント基盤に統合する。AWS で言えば IAM や IAM Identity Center による認証統合に相当する
• Looker 内部の認可はロールとモデルセットで制御する。誰がどのモデル（=どのデータ範囲）にアクセスでき、開発できるかを最小権限で割り当てる
• 行レベルのアクセス制御は、ユーザー属性を LookML のフィルタに渡すことで実現する。マルチテナントの埋め込みでは、各テナントが自分のデータだけを見られるようにこの仕組みが必須
• データ本体の暗号化やネットワーク分離は接続先データウェアハウスと Google Cloud 側の機能に委ねる。資格情報は接続設定として安全に保管し、ハードコードしない

Well-Architected の観点

• 運用上の優秀性（オペレーショナルエクセレンス）: LookML を Git でバージョン管理し、開発・本番を分離してレビューを経てデプロイする。指標定義をコード化することで、変更の追跡とロールバックが可能になり、属人化を避けられる
• 指標を一元管理する結果、レポート間の数値の不一致という運用上の混乱を構造的に減らせる。System Activity による利用監視と Content Validator による事前検証を運用サイクルに組み込むことで、壊れたコンテンツを本番に出さない体制を作れる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# Looker のプロビジョニングや LookML 開発は管理コンソールと Git が中心で、
# 日常操作に gcloud は使いません。ここでは前提となる
# 接続先（BigQuery）側の準備を gcloud / bq の例で示します。

# 1) 分析対象のデータセットを BigQuery に用意する（Looker の接続先になる）
bq --location=asia-northeast1 mk --dataset MY_PROJECT:analytics

# 2) Looker のクエリ実行に使うサービスアカウントを作成する
gcloud iam service-accounts create looker-bq \
  --display-name="Looker BigQuery connection"

# 3) そのサービスアカウントに BigQuery 実行権限を最小権限で付与する
gcloud projects add-iam-policy-binding MY_PROJECT \
  --member="serviceAccount:looker-bq@MY_PROJECT.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataViewer"

gcloud projects add-iam-policy-binding MY_PROJECT \
  --member="serviceAccount:looker-bq@MY_PROJECT.iam.gserviceaccount.com" \
  --role="roles/bigquery.jobUser"

# 4) このサービスアカウントの認証情報を Looker の接続設定に登録し、
#    LookML から analytics データセットを参照する。