数仓シリーズ - 基本概念整理

データウェアハウスシリーズ - 基本概念整理#

内容整理自：

データウェアハウスの基本概念整理

一、データウェアハウスとデータマート#

データウェアハウス (Data Warehouse)#

データウェアハウス（Data Warehouse）は情報システムの資料保存理論であり、この理論は特定の資料保存方法を利用して、含まれる資料が特に分析や処理に有利であることを強調し、価値のある情報を生成し、それに基づいて意思決定を行うことを目的としています。
データウェアハウスはテーマ指向、統合、更新不可（安定性）、時間とともに変化する（異なる時間）のデータ集合であり、経営管理における意思決定支援システム（DDS：Decision Support System、主に報告システム）をサポートします。
データウェアハウスの方法で保存された資料は、必ず時間属性を含み、一度保存されると時間とともに変化しない特性を持っています。しかし、データウェアハウスは時間の経過とともにデータが増加し変化する可能性があります。

データマート (Data Market)#

小規模な部門または作業グループレベルのデータウェアハウスです。

比較#

	データウェアハウス	データマート
データソース	レガシーシステム、OLTP システム、外部データ	データウェアハウス
範囲	企業レベル	部門レベルまたは作業グループレベル
テーマ	企業テーマ	部門または特定の分析テーマ
データ粒度	最小粒度	より粗い粒度
データ構造	正規化構造（第三正規形）	星型スキーマ、雪片スキーマ、またはその混合
歴史データ	大量の歴史データ	適度な歴史データ
最適化	大量データの処理、データ探索	アクセスと分析が容易、迅速なクエリ
インデックス	高度なインデックス	高度なインデックス

二、次元とメトリック#

次元：
データを観察する角度を指し、通常はデータ記録の属性の一つです。例えば、時間、場所などです。一般的には離散的な値のセットであり、時間次元上の各独立した日付や商品次元上の各独立した商品などです。したがって、統計を取る際には、同じ次元値の記録を集約し、集約関数を適用して合計、平均、重複カウントなどの集約計算を行います。

次元の基数 (Cardinality)
その次元がデータセットに現れる異なる値の数を指します。例えば「国」は一つの次元であり、200 の異なる値がある場合、この次元の基数は 200 です。通常、次元の基数は数十から数万まで様々であり、特定の次元（例えば「ユーザー ID」）の基数は百万や千万を超えることがあります。基数が百万を超える次元は通常超高基数次元（UltraHighCardinality、UHC）と呼ばれます。

メトリック：
データに基づいて計算された評価値であり、通常は連続的な値です。例えば、総売上高、異なるユーザー数などです。

例を挙げると:
SQL クエリの中で、GroupBy の属性は通常次元であり、計算された値はメトリックです。以下の例を見てみましょう：

SELECT
department,
site_id,
sum(price) AS total_sales,
count(DISTINCT seller_id) AS sellers
FROM kylin_sales
GROUP BY department, site_id

上記のクエリでは、departmentとsite_idは次元であり、sum（price）とcount（distinct seller_id）はメトリックです。

三、Cube 基本概念#

与えられたデータモデルに対して、すべての次元を組み合わせることができます。N 個の次元に対して、組み合わせのすべての可能性は 2^n 通りです。

一つの次元の組み合わせに対して、メトリックを集約運算し、その運算結果を物化ビューとして保存することをCuboidと呼びます。
すべての次元の組み合わせの Cuboid を一つの全体として、Cubeと呼びます。簡単に言えば、Cube は多くの次元で集約された物化ビューの集合です。
Cube Segmentは、ソースデータの特定のセグメントに対して計算された Cube データを指します。通常、データウェアハウスのデータ量は時間の経過とともに増加し、Cube Segment も時間順に構築されます。

四、階層、レベル、メンバー#

Cube は座標系のようなもので、各Hierarchyは座標軸を表し、Hierarchy 内の各Memberは座標軸上の一つの値を表します。以下の図は時間次元の例を示しています：

次元は物事の特徴を異なる角度から説明するために使用され、一般的に次元には多層（Level）があります。各 Level にはいくつかの共通または特有の属性（Attribute）が含まれます。以下の図で次元の構造と構成を示します：

時間次元の例を挙げると、時間次元には通常、年、四半期、月、日などの Level が含まれます。各 Level には一般的に ID、NAME、DESCRIPTION などの共通属性があり、これらの共通属性は時間次元だけでなく、他のさまざまなタイプの次元にも適用されます。ID は一般に代理主キー（Agent）と見なされ、唯一性の指標としてのみ使用され、多次元モデルの関連性の代理者であり、ビジネスレベルでは意味を持ちません。NAME は一般にビジネス主キー（Business）であり、ビジネスレベルで唯一性を制限し、通常はデータのロード時の関連キーとして使用されます。DESCRIPTION は詳細な説明情報を記録し、多次元表示や分析時には具体的な意味を表現するために DESCRIPTION を使用します。

上記の構造の次元はOLAP に直接適用できません。OLAP は階層に基づく上から下へのドリルダウン、または下から上への集約が必要です。したがって、各次元には Hierarchy が必要であり、少なくとも一つのデフォルトが必要ですが、もちろん複数の Hierarchy を持つこともできます。以下の図を参照してください：

Hierarchy があれば、次元内の Level には上から下へのツリー構造関係が生まれます。つまり、上位の各メンバー（Member）は下位の 0 個または複数のメンバーを含むことになります。ここで注意が必要なのは、各 Hierarchy ツリーの根ノードは一般にすべてのメンバーの集約（Total）に設定されます。この次元が OLAP で使用されていない場合、デフォルトで表示されるのはその次元の集約ノード、つまりその次元のすべてのデータの集約（またはその次元が細分化されていないこと）です。Hierarchy の各レベルにはいくつかのメンバー（Member）が含まれます。時間次元の例を挙げると、2006 年から 2015 年までの時間スパンの時間次元を構築した場合、最上位のノードには 1 つの Total メンバーしかなく、これには 10 年間のすべての時間が含まれます。年のレベルには 2006、2007…2015 の 10 個のメンバーが含まれ、各年には 4 つの四半期メンバーが含まれ、各四半期には 3 つの月メンバーが含まれます…… このように、Hierarchy に基づいて OLAP 操作を行うことができます。

五、データキューブ (Data Cube)#

データキューブは、データ分析とインデックスに一般的に使用される技術であり、原始データに対して多次元インデックスを構築できます。Cube を使用してデータを分析することで、データのクエリ効率を大幅に向上させることができます。

データキューブは多次元モデルの一形態の表現です。キューブ自体は三次元ですが、多次元モデルは三次元モデルに限らず、より多くの次元を組み合わせることができます。一方では、より便利に説明し、描写するためであり、また思考のイメージや想像の余地を与えるためでもあります。もう一方では、従来のリレーショナルデータベースの二次元テーブルと区別するためです。

基本操作#

ドリルダウン（Drill-down）：次元の異なるレベル間の変化であり、上位から下位に降りること、または集約データをより詳細なデータに分解することです。例えば、2010 年第二四半期の総売上データをドリルダウンして、2010 年第二四半期の 4、5、6 月の消費データを確認することができます。もちろん、浙江省をドリルダウンして杭州市、波市、温州市…… これらの都市の売上データを確認することもできます。
ロールアップ（Roll-up）：ドリルダウンの逆操作であり、細粒度データから高レベルの集約へと移行します。例えば、江苏省、上海市、浙江省の売上データを集約して江浙沪地域の売上データを確認することができます。
スライス（Slice）：次元内の特定の値を選択して分析します。例えば、電子製品の売上データや 2010 年第二四半期のデータを選択します。
ダイス（Dice）：次元内の特定の範囲のデータや特定の値のセットを選択して分析します。例えば、2010 年第一四半期から 2010 年第二四半期の売上データや電子製品と日用品の売上データを選択します。
ピボット（Pivot）：次元の位置を入れ替えることです。二次元テーブルの行と列の変換のように、図の中でピボットを使用して製品次元と地域次元を入れ替えます。

六、ファクトテーブルと次元テーブル#

ファクトテーブル (FactTable)#

ファクトテーブル（FactTable）は事実記録を保存するテーブルであり、各イベントの具体的な要素や具体的に発生した事柄を含みます。例えば、システムログ、売上記録などです。
ファクトテーブルには実際の内容は保存されていません。これは主キーの集合であり、これらの ID はそれぞれ次元テーブルの一つの記録に対応します。
ファクトテーブルの記録は常に動的に増加しているため、そのサイズは通常他のテーブルよりも大きくなります。
現実世界で発生する操作型イベントから生じる測定可能な数値は、ファクトテーブルに保存されます。最小の粒度レベルから見ると、ファクトテーブルの行は一つのメトリックイベントに対応し、その逆も同様です。

次元テーブル (DimensionTable)#

次元テーブルは、時にはルックアップテーブル（LookupTable）とも呼ばれ、ファクトテーブル内のイベントの要素に関する説明情報です。
次元の属性値を保存し、ファクトテーブルと関連付けることができます。これは、ファクトテーブルで頻繁に繰り返される属性を抽出し、標準化して一つのテーブルで管理することに相当します。
一般的な次元テーブルには、日付テーブル（日付に対応する週、月、四半期などの属性を保存）、場所テーブル（国、州、都市などの属性を含む）などがあります。
各次元テーブルには単一の主キー列が含まれています。次元テーブルの主キーは、関連するファクトテーブルの外部キーとして使用できます。もちろん、次元テーブルの行の説明環境はファクトテーブルの行と完全に対応する必要があります。次元テーブルは通常、広く、平坦な非正規テーブルであり、大量の低粒度のテキスト属性を含んでいます。

七、OLAP と OLTP#

OLAP(Online Analytical Process)#

オンライン分析処理は、データウェアハウスの多次元モデルに基づいて実現される分析指向の各種操作の集合であり、柔軟にロールアップ（Roll-up）、ドリルダウン（Drill-down）、ピボット分析（Pivot）などの操作を提供します。これは統合的な意思決定情報を提示する方法であり、主に意思決定支援システム、ビジネスインテリジェンス、またはデータウェアハウスで使用されます。
機能は、大規模データ分析や統計計算を容易にし、意思決定に対する参考とサポートを提供します。
OLAP は大量の歴史データを基にし、時間点の差異と組み合わせて、多次元および集約型の情報を複雑に分析する必要があります。
OLAP はユーザーが主観的な情報ニーズを定義する必要があるため、システム効率が良好です。

OLAP の概念は、実際のアプリケーションにおいて広義と狭義の二つの異なる理解方法が存在します。広義の理解は文字通りの意味と同じで、データを更新しないすべての分析処理を指します。しかし、より多くの場合、OLAP は狭義の意味、すなわち多次元分析に関連し、Cube（キューブ）計算に基づく分析として理解されます。

タイプ#

MOLAP (Multidimensional), 多次元 OLAP#

OLAP 分析に使用される多次元データを物理的に多次元配列の形式で保存し、「キューブ」の構造を形成します。次元の属性値は多次元配列のインデックス値またはインデックスの範囲にマッピングされ、集約データは多次元配列の値として配列のセルに保存されます。
この構造は高度に最適化されると、クエリ性能を最大限に向上させることができます。
新しい保存構造を採用しているため、物理的なレイヤーから実現され、物理 OLAP（Physical OLAP）と呼ばれます。一方、RLOAP は主にソフトウェアツールや中間ソフトウェアを通じて実現され、物理的にはリレーショナルデータベースの保存構造を使用しているため、仮想 OLAP（Virtual OLAP）と呼ばれます。
MOLAP の利点は、データが多次元的に前処理されているため、分析中のデータ計算効率が高いことです。主な欠点は、データ更新に一定の遅延があることです。

ROLAP (Relational)，関係 OLAP#

リレーショナルデータベースに基づく OLAP 実装を指します。リレーショナルデータベースを中心に、リレーショナル構造で多次元データを表現し、保存します。ROLAP は多次元データベースの多次元構造を二種類のテーブルに分けます。一つはファクトテーブルで、データと次元のキーワードを保存します。もう一つは次元テーブルで、各次元に少なくとも一つのテーブルを使用して次元の階層、メンバーの種類などの次元の説明情報を保存します。
次元テーブルとファクトテーブルは主キーと外部キーで結びつき、「星型スキーマ」を形成します。
階層が複雑な次元については、冗長データが過度にストレージスペースを占有しないように、複数のテーブルを使用して説明することができます。この星型スキーマの拡張は「雪片スキーマ」と呼ばれます。
RLOAP ストレージとして使用される RDBMS も OLAP に対して適切な最適化を行います。例えば、並列ストレージ、並列クエリ、並列データ管理、コストベースのクエリ最適化、ビットマップインデックス、SQL の OLAP 拡張（cube、rollup）などです。

HOLAP (Hybrid) 混合型 OLAP#

混合データ組織に基づく OLAP 実装を指します（Hybrid OLAP）。ユーザーは自分のビジネスニーズに応じて、どのモデルを ROLAP にし、どのモデルを MOLAP にするかを選択できます。

比較分析#

一般的に、あまり使用されないか柔軟な定義が必要な分析には ROLAP 方式を使用し、一般的で標準的なモデルには MOLAP を実装します。例えば、詳細データはリレーショナルデータベースのファクトテーブルに保持し、集約されたデータは Cube に保存します。集約時には RLOAP よりも多くの時間が必要ですが、クエリ効率は RLOAP より高く、MOLAP より低いです。

OLTP (On-line Transaction Processing)#

データ量が少なく、DML が頻繁で、並列トランザクション処理が多いですが、一般的には非常に短いです。
オンライン取引処理は、基本的な日常のトランザクション処理に重点を置いており、データの追加、削除、更新、検索を含みます。

OLAP と OLTP の違い#

データベースとデータウェアハウスの違いに似ています：

データベースシステムの設計目標はトランザクション処理です。データベースシステムは記録の更新とトランザクション処理のために設計されており、データアクセスの特徴は主キーに基づいており、大量の原子性、隔離された小さなトランザクション、並行性と回復可能性が重要な属性です。最大トランザクションスループットが重要な指標であるため、データベースの設計はこれらのニーズを反映しています。
データウェアハウスの設計目標は意思決定支援です。歴史的、要約された、集約されたデータは原始的な記録よりもはるかに重要です。クエリ負荷は主に即席クエリや結合、集約などの操作を含む複雑なクエリに集中しています。データベースシステムに対して、クエリスループットと応答時間はトランザクション処理スループットよりも重要です。

データ処理タイプ	OLTP	OLAP
オブジェクト指向	ビジネス開発者	分析意思決定者
機能実現	日常のトランザクション処理	分析意思決定指向
データモデル	リレーショナルモデル	多次元モデル
データ量	数件または数十件の記録	百万千万件の記録
操作タイプ	クエリ、挿入、更新、削除	主にクエリ

八、メタデータ#

メタデータ（Meta Data）はデータに関するデータであり、人々が現実世界の現象を説明する際に生成される抽象情報であり、これらの抽象情報はメタデータと見なすことができます。メタデータは主にデータの文脈情報を説明するために使用されます。一般的に言えば、図書館の各本の内容がデータであるならば、各本のインデックスを見つけることがメタデータです。説明対象の違いに応じて、メタデータは三つのカテゴリーに分けることができます：技術メタデータ、ビジネスメタデータ、管理メタデータ：

技術メタデータ: 技術メタデータはデータシステム内の技術分野に関連する概念、関係、ルールを説明するデータであり、データ構造、データ処理に関する特徴の説明を含み、データソースインターフェース、データウェアハウスとデータマートの保存、ETL、OLAP、データカプセル化、フロントエンド表示など、すべてのデータ処理プロセスをカバーします；
ビジネスメタデータ: ビジネスメタデータはデータシステム内のビジネス分野に関連する概念、関係、ルールを説明するデータであり、主にビジネス用語、情報分類、指標定義、ビジネスルールなどの情報を含みます；
管理メタデータ: 管理メタデータはデータシステム内の管理分野に関連する概念、関係、ルールを説明するデータであり、主に役割、職務、管理プロセスなどの情報を含みます。

具体的な参考リンク: データウェアハウスにおけるメタデータ管理システムについて話しましょう