DWHと普通のデータベースは何が違いますか?

業務データベースは取引を記録することに、DWHは大量のデータを読み取って分析することに、それぞれ特化して設計されています。分析処理を業務システムから切り離すことで、重い集計をかけても業務側の動作に影響しないのが本質的な違いです。

DWHのデメリットは何ですか?

商用DWHはデータの保存と分析の両方に費用がかかること、オンプレミス型は初期費用が高いこと、画像やテキストのような非構造化データに弱いこと、特定ベンダーへの依存(ロックイン)が起きやすいことなどが指摘されています。

小さな会社でもDWHは必要ですか?

データの発生源が1つで量も少ないうちは、業務データベースや表計算で足りる場面が多いはずです。複数のシステムにデータが散らばり、履歴をまたいだ分析が必要になり、集計が業務に影響し始めたときが検討の目安になります。

データウェアハウス(DWH)とは:データを倉庫に集める理由

「その集計、DWHでやりましょう」。データ分析の話題になると、DWH(データウェアハウス)という言葉がよく出てきます。直訳すればデータの倉庫。しかし考えてみると不思議です。会社にはすでに業務用のデータベースがあって、売上も顧客情報もそこに入っている。なぜわざわざ、別の倉庫にデータを引っ越しさせるのでしょうか。例によって、資料にあたって確かめました。

DWHは「業務を止めずに分析するための専用倉庫」で、利点も弱点もこの「分離」から生まれています。

業務データベースがあるのに、なぜもう1つ要るのか

百科事典の定義から。DWHは、業務で発生した情報を蓄積し、分析に使えるよう時系列で整形した構造化データの保管庫で、散らばったデータを一元管理して経営判断や戦略立案に役立てるためのシステムとされています※1。

鍵は「分析専用」という点です。AWSの解説は、通常のデータベースが取引の詳細を記録することに使われるのに対し、DWHは大量データの読み取りと傾向分析のために設計されている、と両者を区別しています。そして分析処理をトランザクション(業務処理)から分離することで、パフォーマンスを保てることを利点に挙げています※2。

たとえるなら、営業中のレジで棚卸しを始めるかどうか、という話です。レジ(業務データベース)は1件1件の会計を素早くさばく設計になっています。そこへ「過去3年の売れ筋を全部集計して」という重い仕事を持ち込むと、行列が止まる。だから閉店後の倉庫(DWH)にデータを移し、そちらで心置きなく数えるわけです。

倉庫には設計者がいた:1992年のインモン

この倉庫、自然発生したものではなく設計者がいます。米国のコンピューター科学者ビル・インモンは1992年に著書『Building the Data Warehouse』を出版し、データウェアハウスを「主題別に整理され、統合され、時系列を持ち、不揮発(消さない・上書きしない)であるデータの集合」と定義しました※3。インモンは「データウェアハウスの父」と呼ばれ※4、1990年代にはラルフ・キンボールが分析しやすいデータの並べ方(スタースキーマ)を広めるなど※4、倉庫の設計思想が競い合いながら発展していきます。

マーケティングのフレームワークと同じで、当たり前に使われる道具には作者と製造年月日がありました。DWHは1992年生まれ、今年で34歳です。

倉庫のありがたみと、倉庫の維持費

利点は、先ほどの「分離」から芋づる式に出てきます。複数のシステムに散らばったデータを1か所に統合できる。過去のデータを消さずに積むので、履歴をまたいだ傾向分析ができる。業務に影響を与えずに重い集計を回せる。形式が標準化されるのでデータの品質と一貫性を保ちやすい※2※4。

一方で、倉庫は建てて終わりではありません。弱点もはっきり指摘されています。オンプレミス型(自社設置)は初期費用が高く※3、商用DWHはデータの保存と分析の両方に課金される料金体系が一般的です※4。画像や文書のような非構造化データの扱いは苦手で、特定ベンダーの独自形式に依存するロックインも起きやすい※4。なお、この弱点リストの出どころであるDatabricksは、DWHの次の形(レイクハウス)を推す立場の企業なので、批判側の意見として少し割り引いて読むのが公平です。それでも、コストと硬さが弱点だという指摘自体は、利点の裏返しとして筋が通っています。

観点	利点	弱点
業務への影響	分析を業務から分離できる※2	倉庫を別に建てる費用がかかる※3※4
データ	複数ソースを統合・履歴を保存※2※4	非構造化データに弱い※4
運用	品質・一貫性を保ちやすい※2	ベンダーロックインの懸念※4

使うべきかの分かれ目

ここからは筆者の整理です。倉庫の本質が「分離」だとすると、分離が要らないうちはDWHも要らない、と言えそうです。データの発生源が1つで、量も知れていて、集計しても業務が困らないなら、業務データベースと表計算で十分回ります。

逆に、データが複数のシステムに散らばって突き合わせに手作業が要るようになったとき。過去との比較が仕事の中心になってきたとき。月末の集計で業務システムが重くなり始めたとき。それが倉庫の出番のサインです。メリット・デメリットの一覧を暗記するより、「いま分離が必要か」という一つの問いで考えるほうが、判断はぶれない気がします。

調べても分からなかったこと

日本企業のDWH導入率のような、信頼できる公的統計は見つけられませんでした。
「DWHにすると集計が何倍速くなる」といった一般化できる数字も見つかりませんでした。処理の内容や構成に依存するため、そもそも一般化できない性質のものだと思われます。

まとめ:倉庫は「分離」を買う道具

DWHを使うメリットは、業務を止めずに、散らばったデータを横断し、履歴をさかのぼって分析できること※1※2。デメリットは、その倉庫を建てて維持する費用と複雑さ、そして万能ではないこと(非構造化データの弱さなど)※3※4。どちらも「業務と分析を分離する」という一つの設計判断の表と裏でした。

1992年にインモンが定義した倉庫は、クラウドやレイクハウスへと形を変えながら、いまも会社のデータの置き場所であり続けています。倉庫を借りるかどうか迷ったら、棚卸しでレジの行列が止まっていないか、まず現場を見てみるのがよさそうです。

参考文献・出典

※1 : ｢DWH(ディーダブリューエッチ)とは？意味や使い方｣｜コトバンク https://kotobank.jp/word/DWH-573680

※2 : ｢データウェアハウスとは? - データウェアハウスの説明｣｜AWS https://aws.amazon.com/jp/what-is/data-warehouse/

※3 : ｢What is a Data Warehouse? | Definition from TechTarget｣｜TechTarget https://www.techtarget.com/searchdatamanagement/definition/data-warehouse

※4 : ｢Data Warehouse｣｜Databricks https://www.databricks.com/glossary/data-warehouse