LESSON 30分

データウェアハウスの設計思想

田中VPoE「MDSの全体像は掴めたね。次はデータの格納先、データウェアハウスについて深掘りしよう。うちの会社でも、本番DBに直接BIツールを繋いでパフォーマンスが落ちたことがあっただろう?」

あなた「はい、先月もSlackで『本番DBが重い』と騒ぎになりました。」

田中VPoE「それがまさにDWHを導入すべき理由だ。分析用のデータは分析専用の基盤で扱うべきなんだ。」

データウェアハウスとは

データウェアハウス(DWH)は、分析目的に特化したデータ格納基盤です。業務システム(OLTP)から分離され、大量データの集計・分析クエリに最適化されています。

OLTPとOLAPの違い

項目OLTP(業務システム)OLAP(分析基盤)
目的トランザクション処理分析・レポーティング
クエリパターン少数行のCRUD大量行の集計・結合
データモデル正規化(3NF)非正規化(スター/スノーフレーク)
応答時間ミリ秒秒〜分
同時接続数数千〜数万数十〜数百
代表的DBMySQL, PostgreSQLBigQuery, Snowflake

DWHのレイヤー設計

DWH内のデータは、用途に応じてレイヤー(層)に分けて管理します。

3層モデル

┌──────────────────────────────────────┐
│         Mart Layer(マート層)         │
│   ビジネスユースケースごとの集計テーブル   │
│   例: daily_sales, customer_ltv       │
├──────────────────────────────────────┤
│       Staging Layer(ステージング層)    │
│   クレンジング・型変換・重複排除          │
│   例: stg_orders, stg_customers       │
├──────────────────────────────────────┤
│         Raw Layer(ロウ層)            │
│   ソースデータをそのまま格納             │
│   例: raw_mysql_orders, raw_api_users  │
└──────────────────────────────────────┘
レイヤー目的変換の度合いアクセス権限
Rawソースの忠実な複製なし(as-is)データエンジニアのみ
Staging標準化・クレンジング軽い変換データエンジニア + アナリスト
Martビジネスロジック適用重い変換全社(読み取り)

レイヤー設計の原則

  1. イミュータビリティ:Rawデータは絶対に上書きしない
  2. 単一責任:各レイヤーは1つの役割のみ担う
  3. 依存方向:Raw → Staging → Martの一方向
  4. 命名規則raw_, stg_, mart_ のプレフィックスで識別

スキーマ設計パターン

スタースキーマ

              ┌─────────────┐
              │  dim_date   │
              └──────┬──────┘

┌──────────────┐     │     ┌──────────────┐
│ dim_product  ├─────┼─────┤ dim_customer │
└──────────────┘     │     └──────────────┘

              ┌──────┴──────┐
              │ fact_sales  │
              └─────────────┘
  • ファクトテーブル:ビジネスイベント(売上、注文、クリック)
  • ディメンションテーブル:属性情報(商品、顧客、日付)

スタースキーマの利点

利点説明
クエリ性能JOINが少なく高速
理解しやすさビジネスユーザーにも直感的
BI連携多くのBIツールがスタースキーマ前提
拡張性新しいディメンションの追加が容易

ディメンションモデリングの例

-- ファクトテーブル
CREATE TABLE fact_orders (
    order_id STRING,
    customer_key INT64,
    product_key INT64,
    date_key INT64,
    quantity INT64,
    amount NUMERIC,
    discount_amount NUMERIC
);

-- ディメンションテーブル
CREATE TABLE dim_customer (
    customer_key INT64,
    customer_id STRING,
    name STRING,
    segment STRING,      -- 'Gold', 'Silver', 'Bronze'
    region STRING,
    registered_at TIMESTAMP,
    -- SCD Type 2 用カラム
    valid_from DATE,
    valid_to DATE,
    is_current BOOLEAN
);

Slowly Changing Dimensions(SCD)

ディメンションの属性が時間とともに変化する場合の対処パターン:

タイプ戦略履歴保持ユースケース
SCD Type 1上書きなしメールアドレスの修正
SCD Type 2新行追加あり顧客ランクの変遷を追跡
SCD Type 3カラム追加直前のみ前回の住所を保持

クラウドDWHの比較

機能BigQuerySnowflakeRedshift
アーキテクチャサーバーレス仮想ウェアハウスクラスタ型
ストレージ/計算分離完全分離完全分離RA3で分離
スケーリング自動手動/自動手動
課金モデルクエリ量/定額クレジットノード時間
半構造化データネイティブJSONVARIANT型SUPER型
マテリアライズドビュー対応対応対応

まとめ

項目ポイント
DWHの目的分析専用基盤、OLTPとの分離
レイヤー設計Raw → Staging → Mart の3層
スキーマ設計スタースキーマ(ファクト + ディメンション)
SCD時間変化する属性の管理パターン
クラウドDWHストレージと計算の分離が主流

チェックリスト

  • OLTPとOLAPの違いを説明できる
  • DWHの3層モデル(Raw/Staging/Mart)を理解している
  • スタースキーマのファクトとディメンションを説明できる
  • SCDの各タイプの違いを理解している

次のステップへ

DWHの設計思想を理解しました。次は、DWHをさらに発展させた「レイクハウス」アーキテクチャについて学びましょう。


推定読了時間:30分