データウェアハウス — 川から直接汲むか、ダムに貯めてから配るか

会社のデータは、たいていあちこちに散らばっています。注文は注文システムのDB、会員情報は会員システムのDB、広告の表示記録はまた別のログ。どれもお客さんへのサービスを動かしている本番のDBです。

そこへ経営やマーケティングの人が「地域別の売上が知りたい」と言い出したとき、本番DBに直接つないで集計すると何が起きるか。そしてデータウェアハウス(DWH)はそれをどう解決するのか。DWHは、各地の川(本番DB)から水を集めて貯めておくダムのようなものです。各家庭(各部署)は、ダムから必要な分だけ蛇口で引く。下の図1の配管で、2つのつなぎ方を試してみてください。

川から直接汲むと、何が困るのか

本番DBは、お客さんの1件1件の注文をさばくために作られています。「この会員の注文を1件取ってくる」のような小さな仕事を、大量に素早くこなすのが得意です。一方、分析は「去年1年分の注文を全部読んで、地域ごとに合計する」のような大きな仕事。図1でいくつかの部署が同時に分析すると、本番DBの負荷が跳ね上がり、お客さんの注文画面まで遅くなります。

もう1つの問題は、データが別々のDBに分かれていることです。「地域別の売上」には注文DBと会員DBの両方が要りますが、DBをまたいだ JOIN はふつうできません。しかも片方は「東京都」、もう片方は「Tokyo」と書いてあったりする。結局、それぞれから抜き出して表計算ソフトで手作業の突き合わせになりがちです。

DWH — 集めて、そろえて、貯めておく

DWHは、分析のための専用の貯水池です。お客さんの少ない深夜などに、各本番DBからデータを集め(Extract)、表記ゆれや単位をそろえ(Transform)、DWHに流し込み(Load)ます。この3工程の頭文字が ETL です。

いったんダムに貯めてしまえば、どの部署が何回分析しても本番DBには1滴の負荷もかかりません。注文も会員も広告も、形がそろった状態で1か所にあるので、部署をまたぐ集計も1本のSQLで済みます。DWHは大量の行をまとめて読むことに特化した作り(列ごとに保存するカラム型など)になっていて、集計そのものも速い。部署ごとに必要な分だけを切り出した小さな蛇口をデータマートと呼びます。

代わりに払うのは鮮度です。図1のDWHの答えには「昨夜3:00時点」と付きます。夜間バッチなら、最大でほぼ1日前のデータです。「いまこの瞬間の在庫」のように最新でないと困るものは本番DB側で、「先月の傾向」のように少し古くてもよいものはDWHで――答えに求める鮮度で使い分けます。

まとめ

データウェアハウスは、散らばった本番DBの水を集めて、きれいにそろえて、貯めておくダムです。各部署はダムから必要な分だけを引くので、本番DBは分析に邪魔されず、部署をまたぐ集計も1か所で済みます。その代わり、ダムの水は前回汲み上げた時点のもの。本番は「いま」をさばき、DWHは「これまで」を分析する――役割を分けることが、この仕組みの核心です。