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

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

内容整理自：

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

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

データウェアハウス (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 年までの時間スパンの時間次元を構築した場合、最上位のノードには Total のメンバーが一つだけあり、すべての 10 年間の時間を含み、年のレベルには 2006、2007…2015 の 10 個のメンバーが含まれ、各年には 4 つの四半期メンバーが含まれ、各四半期には 3 つの月メンバーが含まれます…… このように、自然に見えるように、Hierarchy に基づいて OLAP 操作を行うことができます。

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

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

データキューブは多次元モデルの一つの比喩的な表現です。キューブ自体は三次元ですが、多次元モデルは三次元モデルに限らず、より多くの次元を組み合わせることができます。一方では、より便利に説明し記述するためであり、同時に思考のイメージと想像の空間を提供するためです。もう一方では、従来の関係データベースの二次元テーブルと区別するためです。

基本操作#

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

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、データカプセル化、フロントエンド表示など、すべてのデータ処理プロセスをカバーします；
ビジネスメタデータ: ビジネスメタデータはデータシステム内のビジネス分野に関連する概念、関係、ルールを説明するデータであり、主にビジネス用語、情報分類、指標定義、ビジネスルールなどの情報を含みます；
管理メタデータ: 管理メタデータはデータシステム内の管理分野に関連する概念、関係、ルールを説明するデータであり、主に人員の役割、職務、管理プロセスなどの情報を含みます。

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