ビッグデータのための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
-
事例
[日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は? 先行企業の導入事例3選 -
技術文書・技術解説
[日本オラクル株式会社] 無自覚なリスク 秘伝Excelファイルが監査の壁、不正・ミスの温床となる理由 -
製品資料
[日本オラクル株式会社] 戦略的経理の第一歩 失敗のない「脱Excel」を実現する秘訣とは? -
技術文書・技術解説
[日本オラクル株式会社] いまさら聞けないオンプレERPとクラウドERPの違い 最適な製品をどう見極める? -
事例
[株式会社ビザスク] 連結売上高が約2倍に成長、富士フイルムが実践した新規事業創出の戦略とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
3
年収700万超エンジニアに共通するスキルと「もっと勉強すべきだった分野」
-
4
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
5
クラウド資格コレクターは評価されない? 年収1000万を分ける“OSの理解度”
-
6
脱VMwareか、継続か? 仮想化ソフト主要6製品の機能とスペックを徹底比較
-
7
JSONをやめてPythonで送る トークン消費を約7割抑えるAIの設計
-
8
「0.3秒のスピード顔認証」の入退室管理が社員に好評 事例に学ぶオフィス改革
-
9
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
10
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー