データウェアハウスとは
- 基幹系DBと意思決定システム（Decision Support System）に用いられる情報系DBとの分離を説き、提唱したシステム環境
- 基幹系DBから必要なデータを抽出して新たに構築する
特性
- サブジェクト指向
- 基幹系DBでは業務に基づいたデータモデリングを行う
- DWHでは業務から独立して、企業にとって重要な項目や課題に基づいた（サブジェクト指向）データモデリングを行う
- 業務…業務上の「商品」、「顧客」とはなにか？
- サブジェクト指向…企業の意思決定における「商品」、「顧客」とはなにか？
- 全社レベルでのデータの統合
- 業務DBレベルでの「商品」と全社レベルでの「商品」の意味は異なる
- 時系列
- ある時点の値をもつデータを時系列に沿った順序で集めたもの（スナップショット）
- 不変性
- DWHには一定の時間ごとに新しいデータが追加されるが、既存のデータの値が更新されることはない
- データは検索処理が中心
DWHの構成要素
- データソース
- 基幹系DB、外部DB
- データウェアハウス
- データウェアハウス
- 大規模
- 全社レベル
- 多数のサブジェクトから構成
- データマート
- 部門レベル
- 少数のサブジェクトから構成
- DWHが格納しているデータの中から、部門や知識、使用目的別にデータを抽出し構築
- エンドユーザの要件に従ってDWHからデータを切り出して保管したもの、である場合がある
- DWHとデータマートはデータモデリング時のDBとビューの関係にあたる。ただし、データマートはビューではなくマテリアライズドビュー
- あらかじめ用途別の集計データを格納しておくことでDWHの中から大量データを検索・集計する必要がなくなる
- データウェアハウス
- リポジトリ
- DWHのデータに関する定義情報であるメタデータを管理
- エンドユーザ環境
- 分析・レポーティングなど
構成
- DWH単独構成
- データマート単独構成
- DWH/データマート複合構成
┌─────────────────┐ ┌─────────────────┐
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ ┌──────────────┐
│ Data Source │ │ Data Warehouse │ │ │
│ │──────▶│ │◀─────│ End User │
│ │ │ │ │ │
│ │ │ │ └──────────────┘
│ │ │ │
│ │ │ │
│ │ │ │
└─────────────────┘ └─────────────────┘
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │ ┌──────────────┐
│ Data Source │ │ Data Warehouse │ │ Data Mart │ │ │
│ │──────▶│ │◀────│ │◀──────│ End User │
│ │ │ │ │ │ │ │
│ │ │ │ │ │ └──â───────────┘
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ ┌─▶│ Data Mart │◀─┐
│ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ ┌──────────────┐
│ Data Source │ │ Data Warehouse │ │ └─────────────────┘ │ │ │
│ │──────▶│ │◀─┴───────────────────────┴───│ End User │
│ │ │ │ │ │
│ │ │ │ └──────────────┘
│ │ │ │
│ │ │ │
│ │ │ │
└─────────────────┘ └─────────────────┘
多次元DB
- 次元（Dimension）という視点を切り替えることによって様々な検索や分析を行うことができるDB
多次元DBの設計
┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐
│ <Dimension> │ │ │ │ <Dimension> │
│ Customer │┼────┐ │ <Fact> │ ┌────┼│ Product │
│ │ │ │ │ │ │ │
└────────────────────┘ │ │ * customerId │ │ └────────────────────┘
│ ╱│ * purchaceId │╲ │
├─────│ * productId │─────┤
┌────────────────────┐ │ ╲│ * shopId │╱ │ ┌────────────────────┐
│ <Dimension> │ │ │ ... │ │ │ <Dimension> │
│ Purchase │┼────┘ │ │ └───┼│ Shop │
│ │ │ │ │ │
└────────────────────┘ └────────────────────┘ └────────────────────┘
- 関係DBの表を fact table と dimension table に分類する
- fact table（ファクト表）
- 分析の基本となるデータ要素
- 次元の交差する部分で求めることができる数値データを格納
- dimension table（次元表）
- ファクト表についての属性
- 次元について説明する情報
- fact table（ファクト表）
- fact table には dimension table のキーが入っている
Webアプリケーションのイベントデータ収集をどのように行うか
以下はデータウェアハウスの定義などとは関係なく、個人の考察です。
イベント発行
- Webアプリケーションの処理中の特定の操作時に「イベント」を発行する
- 永続化層へのCRUD操作
- その他、永続化層には表出しないがビジネスとして重要な指標が取得できる操作
- イベント発行は（HTTP リクエストのレイテンシを低下させないために）非同期でデータ連携システムへと通知される
イベントデータの連携
- データ連携システムは、データウェアハウスや、監視システムなどへイベントデータを送信する
イベントデータの集計・分析
- データマートを用意する
- 素のイベントデータを格納するテーブル
- 分析用途に合わせたファクト表と次元表
- エンドユーザ向けのビューから集計や分析を実施する
参考文献
- データウェアハウスの基礎: RDBから一歩進んでデータ利用技術を学ぶ
