テーブル・ビュー・MV：BI が重いときの設計判断

Stage 3 — 第4章 | データマネジメント入門 推定学習時間：40〜50分 | 難易度：★★★☆☆

この章で学ぶこと

Gold 層の mart_finance まで整えても、Looker を開くと 30 秒待たされる ことがあります。 原因はしばしば テーブル・ビュー・マテリアライズドビュー（Materialized View、MV） の選び方です。

さくら商事では、人気ダッシュボードが 毎回 2 億行をフルスキャン するビューに直結していました。 BigQuery のスロット課金も跳ね上がり、田中さんから苦情が来ます。

この章を終えると、こんなことができるようになります：

• テーブル、ビュー、MV の 動きとコスト の違いを説明できる
• 参照頻度・クエリの重さ・鮮度要求から 使い分け を判断できる
• BI 直結ビューのリスクを具体例で説明できる
• 「MV を張れば全部解決」という誤解を修正できる

1. 月次経営会議の前日

経営会議前日、木村さんが Looker の「全社 KPI」ダッシュボードを開きました。 ローディングが 45 秒。刷新しても 40 秒。

調査すると、Looker は次の ビュー を参照していました。

-- mart_finance_monthly_v（ビュー：中身は毎回計算）
          CREATE VIEW mart_finance_monthly_v AS
          SELECT
            DATE_TRUNC(shipped_at, MONTH) AS month,
            product_category,
            SUM(total_amount) AS revenue,
            COUNT(DISTINCT customer_id) AS buyers
          FROM silver_orders o
          JOIN silver_order_lines ol ON ...
          JOIN silver_products p ON ...
          WHERE ...
          GROUP BY 1, 2;
          

ビューは保存された SELECT 句 です。 参照のたびに フル計算 が走ります。

鈴木

「会議で 20 人が同時に開いたら、同じ重いクエリが 20 本。MV か 事前集計テーブル を検討しよう。」

2. 三つのオブジェクト

2.1 さくら商事での例

3. ビューが向く・向かない

さくら商事の教訓:

会議用 KPI に重いビューを直結しない。 Gold は テーブル or MV で提供し、Looker はそこから読む。

4. 使い分けフロー

判断軸は 頻度 × 重さ × 鮮度 の 3 つです。

参照頻度が高い？
            No → ビューで十分なことが多い
            Yes → クエリは重い？
                    Yes → 鮮度 1 時間で足りる？
                            Yes → MV
                            No  → 事前集計テーブル（ETL）
                    No  → ビュー or 軽量テーブル
          

次の図は、さくら商事の Looker 遅延を 設計で防ぐ ための分岐です。

MV は銀の弾丸ではありません。 refresh コストと 定義変更時の再構築 も管理対象です。

5. 判断表（さくら商事版）

5.1 鮮度（Timeliness）とのトレードオフ

公式売上は「最新 1 秒」より「説明可能で安定」 —— Stage 2 の合意と一致します。

6. MV の落とし穴

対策:

1. MV も Git 管理、リネージ 登録
2. refresh 失敗アラート
3. Gold テーブルを正、MV は読取加速の副本

7. Stage 3 の振り返り

Stage 4 からは 品質と信頼 —— 層が上がっても、値が間違っていれば意味がありません。

体系コラム：カリキュラム上の位置づけ

コラム：analytics との線引き

analytics トラックでは CTE でマート相当の中間表を作り、必要なら CREATE TABLE AS で物化します。本トラックでは、その判断を 組織ルール として固定します。

経営会議前日、鈴木さんは MV の更新遅延で古い数字が出た事故を経験しました。analytics でも DM でも、「速い」と「公式」は別問題 です。公式なら更新時刻と停止ルールまでセットで設計します。

まとめ

この章のキーメッセージ：

Looker が遅いのは BI ツールのせいだけではありません。 重いビューへの直結 は設計判断のミスです。 頻度・重さ・鮮度で Table / View / MV を選んでください。

次に読む

• 前章: Bronze / Silver / Gold
• Stage 4 第1章: データ品質の 6 軸
• 関連: BI ダッシュボード（analytics）

確認問題

問題 1

全社 KPI ダッシュボードが 2 億行 JOIN の ビュー に直結し、同時アクセスで遅い。 最も効果的な改善 はどれですか。

A. ダッシュボードの色を変える
B. 事前集計 テーブル または適切な MV に切り替え、Looker はそこから読む
C. ビューを増やして部門別に分ける
D. OLTP 本番から直接読む

正解: B

解説: 高頻度 × 重クエリは 物理化 が定石です。C は悪化、D は Stage 3-1 のインシデント再生です。

問題 2

「常に最新が必要」な要求について、さくら商事の 公式月次売上 に当てはめると最も適切なのはどれですか。

A. 秒単位の MV refresh が必須
B. 月次会議用途なら 日次〜月次バッチのテーブル で足りる。鮮度要求を業務と合わせて定義する
C. 鮮度は不要。10 年前のデータでよい
D. ビューなら自動的に最新になるので定義不要

正解: B

解説: 鮮度は 用途依存 です。公式月次はリアルタイム不要なことが多く、過剰な MV はコストだけ増えます。

問題 3

MV を 30 個作成し、どれが SSOT か分からなくなった。 データマネジメント上の問題 として最も適切なのはどれですか。

A. MV は SSOT にできないので問題ない
B. 加速用 MV と Gold 正本テーブル の役割が混同され、ガバナンス・リネージが崩れている
C. 30 個あれば品質が 30 倍
D. BigQuery が悪い

正解: B

解説: MV は 読取加速 の副本。正本は mart_* テーブル + カタログ + セマンティックレイヤー。乱立は野良マートと同型の問題です。

用語メモ（この章）