レイク・DWH・マート：データの置き場所を決める

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

この章で学ぶこと

OLTP と OLAP を分けたあと、分析データは どこに、どんな形で 置くかが問題になります。 さくら商事の S3 には、広告 CSV・ログ・退職者のエクスポートが 名前も形式もバラバラ で残っていました。

一方、BigQuery には mart_finance など 会議で使う表 があります。 この レイク（Lake）・DWH・データマート（Data Mart） の違いを押さえましょう。

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

• レイク、DWH、マートの 目的と利用者 の違いを説明できる
• 「生 CSV 置き場」と「分析用表」の役割分担を設計できる
• analytics トラックの CTE マート作成と 本トラックの論点 の差を説明できる
• さくら商事の置き場所混乱を整理できる

1. S3 に何でも放り込む問題

鈴木さんが S3 バケット sakura-data-lake を監査したところ、次のようなオブジェクトが混在していました。

鈴木

「lake という名前なのに、貯水池兼ゴミ箱兼個人 PC になってる…」

置き場所が 1 つでも、中身のルールがなければ SSOT にはなりません。

2. 三つの置き場所

ざっくり 貯水池 → 浄水場 → 蛇口 の比喩で整理します。

次の図は、さくら商事のデータが どの段階で形を変えるか の全体像です。

lake に Excel や個人 CSV がある状態は、貯水池に 未処理の排水 が混ざっているイメージです。 会議数字は必ずマート（蛇口）から出します。

3. レイク：柔軟だが、ルールが必要

データレイク は、構造化・非構造化を問わず 安く大量に保管 する場所です。

3.1 さくら商事のレイクルール（導入案）

レイクは ゴミ箱ではなく、加工前の保管庫 です。

4. DWH：分析向けに整える

DWH（Data Warehouse） は、分析クエリ向けに スキーマ・履歴・品質 を整えたデータベースです。 さくら商事では BigQuery が DWH 相当です。

DWH は 「分析の作業場」 です。 ここで JOIN・クレンジング・粒度統一を行い、マートへ渡します。

5. データマート：利用者に近い表

データマート（Data Mart） は、特定の 部門・用途 に最適化した分析用表です。

マートは 蛇口 —— 利用者が最初に触る「使いやすい形」です。 Stage 2 のセマンティックレイヤーは、このマートの上に載ります。

5.1 野良マートとの境界

6. analytics トラックとの差

データアナリティクス入門 では、CTE でマートを SQL として書く ことを学びます。

SQL でマートを書ける ことと、組織の公式マートとして提供できる ことは別スキルです。

-- analytics で学ぶ「マートの形」（例）
          WITH daily_revenue AS (
            SELECT
              DATE(shipped_at) AS sales_date,
              SUM(total_amount) AS revenue
            FROM fct_orders
            WHERE status NOT IN ('cancelled')
            GROUP BY 1
          )
          SELECT * FROM daily_revenue;
          

同じロジックでも、本トラックの問いは 「この SQL の結果を mart_finance として誰が承認し、Looker からだけ触らせるか」 です。

7. さくら商事のターゲット構成（簡略）

Shopify / Ads / ERP
                  ↓
             S3 Lake (raw, 規約付き)
                  ↓ ETL
             BigQuery staging / DWH core
                  ↓ transform
             mart_finance / mart_marketing / mart_ops
                  ↓
             Looker Semantic Layer → ダッシュボード
          

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

体系コラム：用語のつながり

Stage 2 の「意味」と Stage 3 の「置き場」は、次の対応でつながります。

lake に何でも放り込むと、田中さんの個人 CSV と鈴木さんの ETL が同じ「置き場」に混ざり、正本が見えなくなります。柔軟さとルール はセットです。

まとめ

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

lake・DWH・マートは 階層の名前 であり、全部 BigQuery に入っていれば同じ、ではありません。 誰が何を触り、どこが公式か を層で分けると、Stage 1 の症状が再発しにくくなります。

次に読む

• 前章: OLTP と OLAP
• 次章: Bronze / Silver / Gold
• 関連: データマート（analytics）
• 関連: スタースキーマ（analytics）

確認問題

問題 1

S3 に tanaka_backup/orders.csv が置かれていた。 最も適切な分類と対応 はどれですか。

A. 公式データマート。Looker にそのまま接続
B. レイクのルール違反（個人コピー）。削除し、正規 ETL 経路を使う
C. OLTP 本番 DB の代替
D. メタデータカタログの正本

正解: B

解説: 個人バックアップは SSOT 崩壊とセキュリティリスク です。lake でも許容すべきではありません。

問題 2

「BigQuery に全部入っているから、レイクも DWH もマートも同じ」という発言について。

A. 正しい。物理的に同じ DB なら区別不要
B. 誤り。物理配置と 論理層（生/raw vs 整形 vs 用途別提供） は別概念
C. 誤り。マートは Excel のみ
D. 正しい。区別はベンダー marketing のみ

正解: B

解説: 同一 BigQuery プロジェクト内でも、raw_ads と mart_finance は 役割が違います。層の名前はガバナンスと利用者体験のためのものです。

問題 3

経営会議用の公式売上を出すとき、最初に参照すべき 置き場所はどれですか。

A. S3 の生 CSV
B. OLTP 本番 orders
C. mart_finance（DWH 上の公式マート） D. 個人 Google Sheets

正解: C

解説: 会議数字は マート + セマンティックレイヤー 経由が SSOT 設計です。A/B はソース層、D は野良マートです。

用語メモ（この章）