データウェアハウス｜データエンジニアリング

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：正規化と非正規化のトレードオフ・列指向ストレージと分析クエリ　|　関連：データレイクとオブジェクトストレージ・メダリオンアーキテクチャ

要点（BLUF）

データウェアハウス（DWH）は、分析専用に構造化データを集約した中央リポジトリ。業務DB（OLTP）から切り離し、重い集計クエリを引き受ける。
物理は列指向＋MPP（超並列処理）で、大量行の集計に最適化。設計はスキーマオンライト（書き込む前に構造を決める）。
クラウドDWH（Snowflake/BigQuery/Redshift）の革新は計算とストレージの分離。データ量と計算需要を独立にスケールでき、使った分だけ課金。

概念 ── なぜ分析を分けるのか

業務DB（注文・在庫）で重い分析クエリを回すと、本番の更新が詰まります。そこで分析用の別系を用意し、業務DBからデータを取り込んで集約するのがDWHです。OLTP（更新・1行操作）とOLAP（分析・大量集計）は要件が正反対なので、物理的に分けるのが定石です（→ 正規化と非正規化のトレードオフ）。

flowchart LR
    OLTP["業務DB（OLTP・正規化・行指向）"] --> ETL["取り込み・変換"]
    ETL --> DWH["DWH（OLAP・次元モデル・列指向）"]
    DWH --> BI["BI・分析・レポート"]

仕組み ── 列指向 + MPP + スキーマオンライト

列指向：集計で必要な列だけ読む（→ 列指向ストレージと分析クエリ）。
MPP（Massively Parallel Processing）：データを多数ノードに分割し、各ノードが部分集計してから統合する。1兆行のSUMも分割並列で捌く（分割統治は MapReduceの考え方と同根）。
スキーマオンライト：DWHに入れる前にテーブル構造・型を確定させる。入った時点で「整っている」ので、読む側は安心して使える。反面、入れる前の整形（ETL/ELT）が必要。

設計の勘所 ── クラウドDWHの計算・ストレージ分離

かつてのDWHは計算とストレージが一体（増やすなら両方同時）でした。クラウドDWHは両者を分離します。

観点	従来型（一体）	クラウド型（分離）
スケール	計算と容量が連動	各々独立に増減
課金	常時確保	使った計算・保存分だけ
同時実行	取り合い	仮想ウェアハウスを分けて隔離

データは安価なオブジェクトストレージに置き、必要なときだけ計算クラスタを起動して読む。これにより「普段は安く貯め、重い分析のときだけ計算を借りる」が可能になり、ELT（→ ETLとELT）の前提を作りました。

なぜそうするか ── 整った中央に集約する価値

なぜ各部署のDBを直接見ず、DWHに集約するのか。(1) 単一の真実（single source of truth）：売上の定義が部署ごとに食い違う事態を防ぐ。(2) 性能：分析専用に最適化された物理で速い。(3) 本番保護：業務DBに分析負荷をかけない。集約・整形のコストを払ってでも、「全社が同じ整ったデータを安全に・速く見られる」状態は組織にとって価値が大きい。次章の層構造（→ メダリオンアーキテクチャ）はこの「整える」を段階化したものです。

⚠️ よくある落とし穴

業務DBをそのままDWH代わりにする → 本番を圧迫し、分析も遅い。分離する。
スキーマオンライトを過信して生を捨てる → 後から別の切り口が欲しくなると詰む。レイク（→ データレイクとオブジェクトストレージ）に生も残す。
仮想ウェアハウスを起動しっぱなし → クラウドDWHは計算課金。アイドル自動停止を設定。
「DWHに入れれば正しい」と検証を省く → 入口の品質テスト（→ データ品質とテスト）は依然必要。

対応ラボ

なし（概念回）。DWHでの層別変換はメダリオンアーキテクチャのラボ（bronze/silver/gold）で確認。