ビッグデータのためのDWH基盤【第1回】
読めば分かる！ ビッグデータのためのデータウェアハウス（DWH）とは？
BI／DWH分野でバズワードとなっている「ビッグデータ」。ビッグデータとはどのようなデータを指す言葉なのか。そしてビッグデータを格納するDWH製品の代表的な3つのアプローチを紹介する。
変化するビッグデータの定義
「ビッグデータ」という言葉は、ここ1年ほどで急速に取り上げられるようになったが、定義は今もって曖昧なようである。筆者が理解しているもともとのビッグデータの定義は、Twitter、Facebookといったソーシャルネットワーキングサービス（SNS）に、1日当たり数Tバイトといった莫大な単位で蓄積されるデータのことである。これらは、文字や映像を中心としたいわゆるマルチメディアデータであるため、一般的なデータウェアハウス（DWH）とは直接の関連はなかった。
しかし、ここのところDWH分野でもビッグデータという言葉が頻繁に登場するようになった。これは、ビッグデータという言葉で表されるデータの種類が、マルチメディアデータだけでなく、大量に蓄積される（されている）定型的なデータも含むようになったためと考えられる。ここで言う定型的なデータとは、行（レコード）と列（カラム）で表現されるデータのことであり、別の言い方をすると、リレーショナルデータベース（RDB）で格納可能なデータということができる。
昔から存在するビッグデータ
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アプライアンス関連コンテンツ
平井明夫
株式会社アイエイエフコンサルティング
マーケティング部 マーケティングディレクター
日本DEC（現日本ヒューレット・パッカード）、コグノス（現日本アイ・ビー・エム）、日本オラクルを経て、現在はアイエイエフコンサルティングに在籍。一貫してソフトウェア製品の開発、マーケティング、導入コンサルティングを歴任。特に、DWH、BIを得意分野とする。現在はBI技術の啓蒙のため、講演・執筆に積極的に取り組んでいる。
Copyright © ITmedia, Inc. All Rights Reserved.
ビッグデータのためのDWH基盤
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？ PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？ 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣 -
製品資料
[サイボウズ株式会社] AIが「わざわざ使うツール」になっていない？ 業務で自然に使う導線にする秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか？ 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
ChatGPTは“検索しまくり”でGeminiは“淡泊”？ データが明かすAIの裏側
-
4
なぜ「Gemini 4 Argon」は出遅れたのか？ Googleが狙う“逆転のシナリオ”
-
5
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
6
損保ジャパンはなぜ「COBOL」を捨てなかったのか？ 脱メインフレームの真相
-
7
「Wi-Fi 7」経由でWindowsが乗っ取られる？ 最高権限奪取の恐怖
-
8
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
9
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
10
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険？ 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化？ 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない？ 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー