背景・目的
データウェアハウスの設計には、さまざまなアプローチがありますが、自分自身で明確に理解ができていません。
そのため、本ページではデータウェアハウスの設計で用いられる主要なスキーマについて整理します。
まとめ
下記に特徴をまとめます。
| 特徴 | 説明 | メリット |
|---|---|---|
| スタースキーマ | ・DWHに利用される最も単純なスキーマ ・唯一または少数のファクトテーブルと、複数のディメンションテーブルが含まれる ・スノーフレークスキーマの一種 ・多次元データベースの実装の一種 ・1つのファクト表と階層構造のないディメンション表を用いる限りにおいては、クエリを単純化できる。 |
・理解と実装がシンプル ・結合への依存度が低いため、単純なクエリに最適 ・パフォーマンスが良い |
| スノーフレームスキーマ | ・スノーフレームスキーマは、スタースキーマを拡張している ・多次元データモデル ・ディメンションテーブルがサブディメンションテーブルに細分化されたもの ・BIやレポートによく使用される |
・高速なデータ検索 ・データ品質の確保 ・データウェアハウスのためのシンプルで一般的なデータモデル |
| Data Vault | データボルトには、ハブ、リンク、サテライトの 3 種類のエンティティがある | ・アジャイル ・構造化され、リファクタリングに柔軟に対応 ・ペタバイト規模にも対応する優れたスケーラビリティ ・ETL コード生成をサポートするパターンを使用 ・データレイヤー、ETL、スタースキーマなど、現行のアーキテクチャを使用可能 |
比較
- スタースキーマーは、簡単で習得し易いが、柔軟性に欠ける
- スノーフレークスキーマは、スタースキーマーより複雑で拡張性がある
- Data Vaultは柔軟で、スケーラビリティがある反面、複雑で技術的な知識が必要とのこと
| 特性 | スタースキーマ | スノーフレークスキーマ | Data Vault |
|---|---|---|---|
| データの履歴追跡 | 不向き | 不向き | 適している |
| 複雑なデータ統合 | 不向き | 不向き | 適している |
| 実装の複雑さ | 低い | 中程度 | 高い |
| クエリ性能 | 高速 | スタースキーマに比べて遅い場合がある | クエリの最適化が必要 |
| スキーマの柔軟性 | 低い | 中程度 | 高い |
| データの理解しやすさ | 理解しやすい | スタースキーマよりも複雑 | 技術的な知識が必要 |
| リアルタイムデータ分析 | 不向き | 不向き | 適している |
| スケーラビリティ | 中程度 | 中程度 | 非常に高い |
概要
スタースキーマからスノーフレーク、ギャラクシー、そしてデータボールトやアンカーモデリングまで、各スキーマの特徴、利点、そして適用シナリオを掘り下げます。
スタースキーマ
スタースキーマを元に整理します。
スタースキーマ または 星型スキーマ はデータウェアハウスに利用される最も単純なスキーマである。スタースキーマには唯1つもしくは少数のファクト表と複数のディメンション表が含まれる。スタースキーマはスノーフレークスキーマの一種であるが、多くの用途で利用されている。
- DWHに利用される最も単純なスキーマ
- 唯一または少数のファクトテーブルと、複数のディメンションテーブルが含まれる
- スノーフレークスキーマの一種
モデル
ファクト表はデータウェアハウスでの解析で利用され、複数の異なるディメンションに区分される。ファクト表は主要なデータを持つ一方、ディメンション表は相対的にサイズが小さくディメンションのそれぞれの値を表現する。必要に応じて、ディメンション表はファクト表と結合される。
ディメンション表は単純な主キーを持つ一方、ファクト表の主キーは関連するディメンション・キーを組み合わせた複合キーである場合もある。
ディメンション表に冗長なデータを含ませ、第2正規形に留めておくことは一般的である。一方ファクト表は、全てのデータはディメンションの組み合わせではなく、いずれかの唯1つのディメンションのみに含まれるため、第3正規形を用いることが多い。
スタースキーマは関係データベースを利用した多次元データベースの実装の一種である。典型的な関係データベースを利用できるため、専用の多次元データベースを用いるよりも、価格や利便性の面で利点がある。また、スタースキーマはスノーフレークスキーマの一種ではあるが、1つのファクト表と階層構造のないディメンション表を用いる限りにおいては、クエリを単純化できる。
- ファクト表
- 主要なデータを持つ
- すべてのデータはディメンションの組み合わせではない
- 第三正規形を用いることが多い
- 関連するディメンション・キーを組み合わせた複合キーである
- ディメンション表
- 相対的にサイズが小さい
- ディメンションのそれぞれの値を表現する
- 必要に応じてディメンション表はファクト表と結合される
- 冗長なデータを含ませる
- 第二正規形にとどめておく
- 主キーを持つ
イメージ
Delta Lake を使用して Databricks にスター スキーマを実装するための 5 つの簡単な手順
Delta Lake を使用して Databricks にスター スキーマを実装するための 5 つの簡単な手順を元に整理します。
ほとんどのデータ ウェアハウス開発者は、常に存在するスター スキーマに精通しています。1990 年代に Ralph Kimball によって導入されたスター スキーマは、ビジネス データをディメンション (時間や製品など) と事実 (金額や数量のトランザクションなど) に非正規化するために使用されます。スター スキーマは、反復的なビジネス定義の重複を減らすことでデータを効率的に保存し、履歴を維持し、データを更新し、集約とフィルタリングを高速化します。
- 反復的なビジネス定義の重複を減らすことで、データを効率的に保存し、履歴を維持し、データを更新し集約とフィルタリングを高速化する
従来のデータ ウェアハウスと同様に、Delta Lake では、デルタ スター スキーマ結合を大幅に改善するための簡単な経験則がいくつかあります。
成功への基本的な手順は次のとおりです。
- デルタ テーブルを使用してファクト テーブルとディメンション テーブルを作成する
- ファイル サイズを最適化してファイルを高速にプルーニングします。
- ファクト テーブルに Z オーダーを作成する
- ディメンションのキー フィールドとおそらく述語に Z オーダーを作成します。
- Adaptive Query Execution Optimizer の統計を収集するためのテーブルの分析
スノーフレークスキーマ
スノーフレークスキーマを元に整理します。
スノーフレークスキーマは、スタースキーマを拡張した多次元データモデルで、ディメンションテーブルがサブディメンションテーブルに細分化されたものです。スノーフレークスキーマは、データウェアハウスやデータマート、リレーショナルデータベースの多次元分析を使用した BI（ビジネスインテリジェンス）やレポーティングによく使用されています。
- スノーフレームスキーマは、スタースキーマを拡張している
- 多次元データモデル
- ディメンションテーブルがサブディメンションテーブルに細分化されたもの
- BIやレポートによく使用される
スノーフレークスキーマでは、エンジニアがそれぞれのディメンションテーブルを論理的なサブディメンションに細分化します。このため、データモデルは複雑になりますが、特定のデータ形式においてはアナリストが操作しやすくなります。
- データモデルは複雑になるが、特定のデータ形式においてはアナリストが操作しやすい
また、下図のとおり、実体関連図（ERD：Entity-Relationship Diagram）が雪の結晶のように見えることから、このデータウェアハウススキーマは、スノーフレークスキーマと呼ばれています。
スノーフレークスキーマとスタースキーマの比較
スタースキーマと同様に、スノーフレークスキーマの中央にもファクトテーブルがあり、外部キーを介して複数のディメンションテーブルに接続されています。しかし、スタースキーマと異なり、スノーフレークスキーマはより正規化が進んでいます。
- 中央にもファクトテーブル
- 外部キーを介して、複数のディメンションテーブルに接続される
スノーフレークスキーマは、高い正規化基準に厳密に準拠しており、ストレージ効率性は高いのですが、非正規化データモデルと比べるとクエリ時のパフォーマンスは劣ります。一方で、スタースキーマのような非正規化データモデルでは、データの冗長性（データの重複）が高く、データの重複を許容する代わりにクエリのパフォーマンスを高速化することができます。
- ストレージ効率性は高い
- パフォーマンスは、劣る
スノーフレークスキーマのメリット
- 高速なデータ検索
- データ品質の確保
- データウェアハウスのためのシンプルで一般的なデータモデル
スノーフレークスキーマのデメリット
- 初期設定時に要する膨大な工数
- 柔軟性に欠けるデータモデル
- 高いメンテナンスコスト
Data Vault
Data Vault とはを元に整理します。
Data Vault（データボルト）とは、データモデリングのデザインパターンで、エンタープライズ規模の分析向けのデータウェアハウスを構築する際に使用されます。データボルトには、ハブ、リンク、サテライトの 3 種類のエンティティがあります。
ハブは、ビジネスの中核となるコンセプトを、リンクは、ハブ間のリレーションシップを表します。サテライトは、ハブに属する情報やハブ間のリレーションシップに関するデータを格納します。
データボルトは、レイクハウスのパラダイムを採用する組織に適したデータモデルです。
- データモデリングのデザインパターン
- 下記の三種類のエンティティがある
- hubs
- ビジネスの中核となるコンセプト
- links
- ハブ間のリレーションシップを表す
- satellites
- ハブに属する情報、hubsのリレーションシップに関するデータを格納する
- hubs
イメージ
出典：Databricks＞Data Vault とはを元に整理します。
データボルトのモデリング：ハブ、リンク、サテライト
ハブ：それぞれのハブは、顧客 ID、製品番号、車両識別番号（VIN）など、ビジネスの中核となるコンセプトを表します。ユーザーはビジネスキーを使用して、ハブに関する情報を取得します。ビジネスキーには、ビジネスコンセプト ID やシーケンス ID、ロード日、その他のメタデータ情報の組み合わせを含めることができます。
リンク：リンクは、ハブ間のリレーションシップを表します。
サテライト：サテライトは、ビジネスの中核となるコンセプトに関する記述的情報の欠落を補うものです。ハブに属する情報とハブ間のリレーションシップに関するデータを格納します。
- hubs
- 顧客ID、製品番号、車両識別番号などビジネスの中核となるコンセプト
- ビジネスキーを使用して、ハブに反する情報を取得する
- ビジネスキーには、ビジネスコンセプトID、シーケンスID、ロード日、その他のメタデータ情報の組み合わせを含めることが可能
- Links
- ハブ間のリレーションを表す
- satellites
- ハブに関する情報とハブ間のリレーションに関するデータを格納する
データボルトのメリット
- アジャイル
- 構造化され、リファクタリングに柔軟に対応
- ペタバイト規模にも対応する優れたスケーラビリティ
- ETL コード生成をサポートするパターンを使用
- データレイヤー、ETL、スタースキーマなど、現行のアーキテクチャを使用可能
Data Vault がレイクハウスにどのように適合するか
考察
今回は、3つのデータモデリングを整理してみました。実装時の柔軟性や拡張性が高いData Vaultについて今後学んでみたいと思いました。
参考