データウェアハウス
Data Warehouse ・ でーたうぇあはうす
分析のために大量データを蓄積する専用データベース。業務DBとは設計思想が根本から異なる。
✦ 30秒で試す — 航海同じデータベースなのに、得意なことが正反対このクエリが読み込むデータ量は、おおよそ？予想してみる概要
データウェアハウス（DWH）は、分析のために大量のデータを蓄積・集計することに特化したデータベースです。日々の業務を処理するデータベースが「1件を速く正確に読み書きする」ために設計されているのに対し、DWHは「何億行もの履歴を横断して集計する」ために設計されており、同じ「データベース」という言葉でくくられていても、内部構造から設計思想まで根本から異なります。
売上ダッシュボード、ユーザー行動分析、経営レポート — 組織の意思決定を支える数字の多くは、各所からETLで集められたデータが積まれたDWHの上で計算されています。BigQuery・Snowflake・Amazon Redshiftといったクラウドサービスの名前を聞いたことがあれば、それらがまさに現代のDWHです。
なぜ生まれたか
業務システムのRDBMSは、注文の登録や在庫の更新といった OLTP（Online Transaction Processing、オンライントランザクション処理）のためにチューニングされています。ここに「過去3年分の全注文を商品カテゴリ別・月別に集計する」ような分析クエリを直接投げるとどうなるか。何千万行もの全件走査が業務処理と CPU・ディスクの読み取り・ロックを奪い合い、最悪の場合、本番の注文処理が止まります。しかも業務システムは販売・会計・在庫と部門ごとに別々に作られているため、「顧客」の ID も「売上」の定義もシステムごとに違い、横断的な数字を出すたびに手作業の突き合わせが必要でした。
そこで1980年代末から90年代にかけて、「業務のためのデータベースと、分析のためのデータベースを分ける」という考え方が確立しました。1988年に IBM の Barry Devlin と Paul Murphy が「ビジネスデータウェアハウス」という構成を論文で示し、1992年に Bill Inmon が『Building the Data Warehouse』で「主題別に統合され、時系列を持ち、消されない、意思決定のためのデータの集まり」と定義します。業務DBからデータを定期的に写し取り（この工程が ETL）、定義をそろえて分析専用の置き場に積み、分析クエリはすべてそちらで受ける。1993年には E.F. Codd がこの分析側の処理を OLAP（Online Analytical Processing）と名付け、1996年には Ralph Kimball が『The Data Warehouse Toolkit』で後述のスタースキーマを中心とする設計手法（ディメンショナルモデリング）を体系化しました。OLTP と OLAP の分離は、以後のデータ基盤設計の大前提になっています。
詳細
列指向 — 集計を速くする物理構造
OLTP と OLAP の違いは、データをディスクに並べる順序という物理レベルにまで及びます。業務用のRDBMSは1行の全列を連続して置く「行指向」で、1件をまるごと読み書きする処理に向いています。一方 DWH の典型的なクエリは「全行の金額列だけを合計する」ように、少数の列を大量の行にわたって読む操作です。そこで現代の DWH は、同じ列の値を連続して置く「列指向（カラムナ）」ストレージを採ります。集計に必要な列だけを読めばよく、同じ型の値が並ぶので圧縮もよく効く。読むデータ量が桁違いに減ることが、何十億行の集計を秒単位で返せる根本的な理由です。行指向と列指向で読むページがどう変わるかは、OLTPとOLAPの図と体験部品で確かめられます。代わりに1行ずつの挿入・更新は苦手になるため、DWH へは ETL や ELT でまとめて追記するのが基本です。
スタースキーマ — 正規化をあえて崩す
論理設計の流儀も業務DBとは逆向きです。業務DBでは更新時の矛盾を防ぐために正規化を徹底します。すると「商品 → カテゴリ → 部門」のように情報が何段ものテーブルに分かれ、分析のたびに多数の結合が必要になって、SQLは複雑に、クエリは重くなります。DWH では更新がほぼ追記だけなので正規化の恩恵が薄く、代わりに Kimball が広めた「スタースキーマ」が定番になりました。
中心に置くのは、売上の明細1件を1行とする大きなファクトテーブルです。持つのは数量・金額のような「足し合わせる計測値」と、周囲のディメンションを指すキーだけ。周囲には日付・商品・店舗・顧客といった「集計の切り口」を持つディメンションテーブルを置き、ファクトから1本ずつ線を張ります。商品ディメンションはカテゴリ名や部門名を正規化せずに1行へ持つので、どんな切り口の集計も「ファクトを見たいディメンションと1段だけ結合して GROUP BY」という同じ形で書けます。あえて冗長さを許し、分かりやすさと集計性能を取る — 正規化の教科書とは逆の判断が正解になる世界です（ディメンションをさらに正規化して枝分かれさせた形はスノーフレークスキーマと呼ばれます）。
設計で最初に決めるべきは「粒度」、つまりファクトの1行が何を表すかです。「注文1件」か「注文明細1行」か「店舗×日の集計」かで、後から答えられる問いが決まります。粗い粒度で積んでしまうと細かい分析は二度とできないため、原則は取れるかぎり細かい粒度で持つことです。もうひとつの定番の悩みが、ディメンションの属性が時間とともに変わること（顧客の会員ランクが上がる、店舗が別の地域に移る）で、履歴を上書きするか、版を分けて新しい行を足すかを属性ごとに選びます（緩やかに変化するディメンション、SCD と呼ばれる技法）。上書きすれば過去の売上まで新しいランクで集計され、版を分ければ「当時のランク」で集計できます。
データレイクとレイクハウス、そしてクラウドDWH
DWH は構造化された「整ったデータ」の置き場ですが、2010年代にはログ・画像・JSONのような非構造データも「とりあえず全部、生のまま安く貯めておく」データレイクという考え方が広がりました。安価なオブジェクトストレージに何でも置ける柔軟さの半面、管理を怠ると使い物にならないデータの沼（データスワンプ）と化す弱点があります。近年は、レイクの安さと柔軟さの上に DWH 並みの管理機能（トランザクションやスキーマ管理）を載せた「レイクハウス」という折衷アーキテクチャも登場し、境界は溶けつつあります。
実装面では、クラウドコンピューティングが DWH の姿を一変させました。かつて数千万円規模の専用アプライアンスだった DWH は、BigQuery・Snowflake・Redshift のようなフルマネージドサービスになり、ストレージと計算を分離して必要なときだけ計算資源をスケールさせ、スキャンしたデータ量や計算時間で課金される形が主流です。導入の敷居が劇的に下がった一方、「雑なクエリが巨大テーブルを全スキャンして高額請求になる」というクラウド特有の落とし穴も生まれました。SELECT * を避けて必要な列だけを書く（列指向では読む列の数がそのまま費用になる）、日付などでテーブルを物理的に区切るパーティション分割で読む範囲を絞る、といったスキャン量を意識した書き方と設計が実務の必須知識です。
試問
同じ「データベース」でも、日々の業務を処理する業務DB（OLTP: 1件を速く正確に読み書きする）と、分析のためのデータウェアハウス（OLAP: 何億行もの履歴を横断して集計する）では、得意なことも作り方も正反対です。
8つの特徴を、業務DB（OLTP）とデータウェアハウス（OLAP）のどちらのものかで仕分けよ
項目を選んでから、入れる箱を選びます