データウェアハウス

概要

データウェアハウス（DWH）は、分析のために大量のデータを蓄積・集計することに特化したデータベースです。日々の業務を処理するデータベースが「1件を速く正確に読み書きする」ために設計されているのに対し、DWHは「何億行もの履歴を横断して集計する」ために設計されており、同じ「データベース」という言葉でくくられていても、内部構造から設計思想まで根本から異なります。

売上ダッシュボード、ユーザー行動分析、経営レポート — 組織の意思決定を支える数字の多くは、各所からETLで集められたデータが積まれたDWHの上で計算されています。BigQuery・Snowflake・Amazon Redshiftといったクラウドサービスの名前を聞いたことがあれば、それらがまさに現代のDWHです。

なぜ生まれたか

業務システムのRDBMSは、注文の登録や在庫の更新といったOLTP（Online Transaction Processing、オンライントランザクション処理）のためにチューニングされています。ここに「過去3年分の全注文を商品カテゴリ別・月別に集計する」ような分析クエリを直接投げるとどうなるか。何千万行もの全件走査が業務処理と資源を奪い合い、最悪の場合、本番の注文処理が止まります。分析のためのクエリが商売そのものを止める — これは実際に繰り返し起きた事故です。

そこで1980年代末から90年代にかけて、「業務のためのデータベースと、分析のためのデータベースを分ける」という考え方が確立しました。業務DBからデータを定期的に写し取り、分析専用に設計された置き場に積んで、分析クエリはすべてそちらで受ける。この分析側の置き場がデータウェアハウス（データの倉庫）であり、その働き方はOLAP（Online Analytical Processing、オンライン分析処理）と呼ばれます。OLTPとOLAPの分離は、以後のデータ基盤設計の大前提になりました。

詳細

行指向と列指向 — 集計を速くする物理構造

OLTPとOLAPの違いは、データをディスクに並べる順序という物理レベルにまで及びます。業務用RDBMSは「行指向」で、1行（1件の注文なら注文ID・日付・商品・金額のひとまとまり）を連続した領域に格納します。1件をまるごと読み書きする業務処理には最適な配置です。一方、分析クエリの典型は「全行の金額列だけを合計する」ように、少数の列を大量の行にわたって読む操作です。行指向のままでは、金額を読むためだけに全列を読み込むことになり、無駄が膨大になります。

そこでDWHは「列指向（カラムナ）」を採用します。同じ列の値を連続領域にまとめて格納するため、集計に必要な列だけをディスクから読めばよく、しかも同じ型の値が並ぶことで圧縮が非常によく効きます。読むデータ量が桁違いに減ることが、何十億行の集計を秒単位で返せる根本的な理由です。代わりに1行の挿入・更新は苦手になるため、DWHへはETLや後述のELTでまとめて追記するのが基本です。

スタースキーマ — 正規化をあえて崩す

論理設計の流儀も業務DBとは逆向きです。業務DBでは更新時の矛盾を防ぐために正規化を徹底しますが、正規化されたデータの分析には多数のテーブル結合が必要になり、SQLが複雑化してクエリも重くなります。DWHでは更新がほぼ追記だけなので正規化の恩恵が薄く、代わりに「スタースキーマ」という分析特化の形が定番になりました。中心に売上などの計測値を持つ大きなファクトテーブルを置き、その周囲に商品・店舗・日付といった属性を持つディメンションテーブルを星形に配置する構造で、分析者は「ファクトを、見たい切り口のディメンションで集計する」という一定のパターンでクエリを書けます。あえて冗長さを許して分かりやすさと集計性能を取る — 正規化の教科書とは逆の判断が正解になる世界です。

データレイクとレイクハウス、そしてクラウドDWH

DWHは構造化された「整ったデータ」の置き場ですが、2010年代にはログ・画像・JSONのような非構造データも「とりあえず全部、生のまま安く貯めておく」データレイクという考え方が広がりました。安価なオブジェクトストレージに何でも置ける柔軟さの半面、管理を怠ると使い物にならないデータの沼（データスワンプ）と化す弱点があります。近年は、レイクの安さと柔軟さの上にDWH並みの管理機能（トランザクションやスキーマ管理）を載せた「レイクハウス」という折衷アーキテクチャも登場しています。

実装面では、クラウドコンピューティングがDWHの姿を一変させました。かつて数千万円規模の専用アプライアンスだったDWHは、BigQuery・Snowflake・Redshiftのようなフルマネージドサービスになり、ストレージと計算を分離して必要なときだけ計算資源をスケールさせ、スキャンしたデータ量や計算時間で課金される形が主流です。導入の敷居が劇的に下がった一方、「雑なクエリが巨大テーブルを全スキャンして高額請求になる」というクラウド特有の落とし穴も生まれており、パーティション分割（日付などでテーブルを物理的に区切り、読む範囲を絞る仕組み）などスキャン量を意識した設計が実務の必須知識になっています。