データウェアハウスの設計思想
田中VPoE「MDSの全体像は掴めたね。次はデータの格納先、データウェアハウスについて深掘りしよう。うちの会社でも、本番DBに直接BIツールを繋いでパフォーマンスが落ちたことがあっただろう?」
あなた「はい、先月もSlackで『本番DBが重い』と騒ぎになりました。」
田中VPoE「それがまさにDWHを導入すべき理由だ。分析用のデータは分析専用の基盤で扱うべきなんだ。」
データウェアハウスとは
データウェアハウス(DWH)は、分析目的に特化したデータ格納基盤です。業務システム(OLTP)から分離され、大量データの集計・分析クエリに最適化されています。
OLTPとOLAPの違い
| 項目 | OLTP(業務システム) | OLAP(分析基盤) |
|---|---|---|
| 目的 | トランザクション処理 | 分析・レポーティング |
| クエリパターン | 少数行のCRUD | 大量行の集計・結合 |
| データモデル | 正規化(3NF) | 非正規化(スター/スノーフレーク) |
| 応答時間 | ミリ秒 | 秒〜分 |
| 同時接続数 | 数千〜数万 | 数十〜数百 |
| 代表的DB | MySQL, PostgreSQL | BigQuery, 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 | ビジネスロジック適用 | 重い変換 | 全社(読み取り) |
レイヤー設計の原則
- イミュータビリティ:Rawデータは絶対に上書きしない
- 単一責任:各レイヤーは1つの役割のみ担う
- 依存方向:Raw → Staging → Martの一方向
- 命名規則:
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の比較
| 機能 | BigQuery | Snowflake | Redshift |
|---|---|---|---|
| アーキテクチャ | サーバーレス | 仮想ウェアハウス | クラスタ型 |
| ストレージ/計算分離 | 完全分離 | 完全分離 | RA3で分離 |
| スケーリング | 自動 | 手動/自動 | 手動 |
| 課金モデル | クエリ量/定額 | クレジット | ノード時間 |
| 半構造化データ | ネイティブJSON | VARIANT型 | SUPER型 |
| マテリアライズドビュー | 対応 | 対応 | 対応 |
まとめ
| 項目 | ポイント |
|---|---|
| DWHの目的 | 分析専用基盤、OLTPとの分離 |
| レイヤー設計 | Raw → Staging → Mart の3層 |
| スキーマ設計 | スタースキーマ(ファクト + ディメンション) |
| SCD | 時間変化する属性の管理パターン |
| クラウドDWH | ストレージと計算の分離が主流 |
チェックリスト
- OLTPとOLAPの違いを説明できる
- DWHの3層モデル(Raw/Staging/Mart)を理解している
- スタースキーマのファクトとディメンションを説明できる
- SCDの各タイプの違いを理解している
次のステップへ
DWHの設計思想を理解しました。次は、DWHをさらに発展させた「レイクハウス」アーキテクチャについて学びましょう。
推定読了時間:30分