読めば分かる！　ビッグデータのためのデータウェアハウス（DWH）とは？

BI／DWH分野でバズワードとなっている「ビッグデータ」。ビッグデータとはどのようなデータを指す言葉なのか。そしてビッグデータを格納するDWH製品の代表的な3つのアプローチを紹介する。

公開 2011年09月29日 09時01分

更新 2012年09月04日 14時35分

著者

平井明夫

[アイエイエフコンサルティング]

印刷する連載新着通知を受け取る

変化するビッグデータの定義

　「ビッグデータ」という言葉は、ここ1年ほどで急速に取り上げられるようになったが、定義は今もって曖昧なようである。筆者が理解しているもともとのビッグデータの定義は、Twitter、Facebookといったソーシャルネットワーキングサービス（SNS）に、1日当たり数Tバイトといった莫大な単位で蓄積されるデータのことである。これらは、文字や映像を中心としたいわゆるマルチメディアデータであるため、一般的なデータウェアハウス（DWH）とは直接の関連はなかった。

　しかし、ここのところDWH分野でもビッグデータという言葉が頻繁に登場するようになった。これは、ビッグデータという言葉で表されるデータの種類が、マルチメディアデータだけでなく、大量に蓄積される（されている）定型的なデータも含むようになったためと考えられる。ここで言う定型的なデータとは、行（レコード）と列（カラム）で表現されるデータのことであり、別の言い方をすると、リレーショナルデータベース（RDB）で格納可能なデータということができる。

DWH関連記事

昔から存在するビッグデータ

　DWH分野におけるビッグデータの定義が、大量に発生する定型的なデータを含むとするならば、ビッグデータは昔から存在する。それは、例えばPOSデータであり、eコマースサイトのデータである。もともとDWHは比較的大量なデータを蓄積するためのIT基盤ではあるが、その中でもこれらは「日々刻々と膨大な量の明細データが発生する」という意味で立派にビッグデータの資格を満たしている。

　POSデータは、店舗小売業のレジで発生する販売データである。販売管理アプリケーションでは、1つのレシートが1件のトランザクションとなるが、DWHに格納される際は、購入商品アイテムごとに明細レコードとして格納するため、データ量はさらに莫大なものになる（関連記事：あるスーパーマーケットに見るPOSデータ分析の実践）。

　eコマースサイトのデータは、基本的な属性はPOSデータと同じであるが、一般的に会員制を取るため、購買者の個人属性（年齢、性別など）がデータに追加され、結果としてデータ量をさらに増大させる。

DWHのデータベース構造

　DWHで用いられる標準的なデータベース構造は、「スタースキーマ」と呼ばれる。スタースキーマは、中心のファクトテーブルと呼ばれるインデックスと数値カラムで構成されるテーブルの周りを、ディメンションテーブルと呼ばれる属性データで構成される複数のテーブルが星型に取り囲んだ形で表現される。

スタースキーマ

　ファクトテーブルとディメンションテーブルは、サロゲートキーと呼ばれるDWH内固有のキーで結合されている（上図では、顧客キー、部署キーがこれに相当する）。サロゲートキーにより、業務システムにおけるマスターデータの変更に対応し、マスターの一貫性を保証することができる。また、スタースキーマでは、業務システムで発生する明細データを各ディメンションの最も細かいレベル（日ごと、顧客ごとなど）で集約してファクトテーブルに格納する。これにより、ファクトテーブルのレコード数を予測可能な範囲に収め、DWH全体のデータ量をある程度コントロールすることができる。

マスターデータ関連コンテンツ

ビッグデータのためのデータベース構造とは？

　スタースキーマはDWHの分野では標準的なスキーマではあるが、高度に正規化されているため、ディメンションの数が多くなればジョインの数も増え、その分検索の際にシステム的な負荷が増大するという特性がある。また、マスターレコード（ディメンションレコード）の追加の際に、サロゲートキーの付加をはじめとするマスターの一貫性を保証するためのマスターメンテナンス処理が極めて複雑であり、頻繁にマスターレコードの変更が発生するような場合は、メンテナンス処理が追い付かなくなるというリスクを持つ。同様に、業務システムで発生する明細データはいったん集約した後、ファクトテーブルに保存する必要があるため、リアルタイム性を保証するのが難しい。

　本稿で取り上げているようなビッグデータの場合は、これらの特性（弱点）が顕著に現れる。そのため、以前からDWHの世界ではビッグデータのような莫大なデータを処理するために、スタースキーマとは別のデータ構造が存在する。それが、「大福帳スキーマ」である。大福帳スキーマとは、もともとERP分野で発生した考え方で、明細レコードを全てそのまま格納してしまうものである。この大福帳スキーマで構成されたDWHは、オペレーショナルDWHと呼ばれることもある。大福帳スキーマでは、正規化も集約も行われないため、マスターの一貫性は保証されず、全体のデータ量もコントロールできない。その代わり、短時間で膨大に発生する明細レコードをリアルタイムに格納することができるし、マスターのメンテナンスで処理が停滞することもない。

ビッグデータのためのDWH基盤3つのアプローチ

　ビッグデータに対応したDWHにおいて、大福帳スキーマが許されるとするならば、ビッグデータのためのDWH基盤の選択には、以下3つのアプローチが存在する。

アプローチ	特徴
NoSQLデータベース	・パブリッククラウドの分散処理技術から派生したデータベース技術・非リレーショナル型でKVS（キーバリューストア）が基本・並列処理によるスケールアップに優れる・大福帳スキーマを採用する場合の有力な選択肢
カラム型データベース	・列方向にデータをまとめて扱うため、大福帳スキーマの場合の有力な選択肢となる・以下のような場合は、より有力な選択肢となる・属性の数が多く、カーディナリティが低い場合・ファクトレスファクトになる場合
DWHアプライアンス	・RDBソフトウェアとハードウェアを一体化することで高速化・正規化、集約も可能なアプローチ

　1つ目は、NoSQLデータベースである。NoSQLはHadoop（Hbase）に代表される従来のRDBとは異なるタイプのデータベースである。全てのNoSQLデータベースがDWHに適用できるわけではないが、大福帳スキーマを前提として考えるのであれば、有力な選択肢の1つとなる。NoSQLデータベースについては本連載の第2回で詳細な解説を行う。

　2つ目は、カラム型データベースである。カラム型データベースは従来のRDBの技術の延長線上にあるといえるが、列方向の処理を優先し、インデックスによる検索性能に優れる。属性の数が多いデータを対象とする場合は有力な選択肢となる。カラム型データベースについては本連載の第3回で詳細に解説する。

カラム型データベース関連コンテンツ

　最後は、DWHアプライアンスである。従来のRDBの技術の延長線上で考えるのであれば、最も一般的なアプローチといえる。DWHアプライアンスについては本連載の第4回で詳細な解説を行う。

DWHアプライアンス関連コンテンツ

ERPユーザー注目、SAPがデータベースベンダーになる意味
オラクルとSAPのモバイルBIが実現する「真のリアルタイム」、それぞれの意味
DWHアプライアンスの真実 Oracle ExadataとNetezza TwinFinの比較（ホワイトペーパー）
「Oracle Exadata」が塗り替える企業データ分析の常識（ホワイトペーパー）

平井明夫

株式会社アイエイエフコンサルティング

マーケティング部　マーケティングディレクター

日本DEC（現日本ヒューレット・パッカード）、コグノス（現日本アイ・ビー・エム）、日本オラクルを経て、現在はアイエイエフコンサルティングに在籍。一貫してソフトウェア製品の開発、マーケティング、導入コンサルティングを歴任。特に、DWH、BIを得意分野とする。現在はBI技術の啓蒙のため、講演・執筆に積極的に取り組んでいる。

印刷する