Data Vault 2.0

## はじめに
国内では、2 年ほど前から Data Vault 2.0 という言葉が聞かれ始めました。
Yellowfin のグループ会社が Data Vault 2.0 に関わるソリューションを手掛けているのですが、担当者曰く、欧州、北米の順に、Data Vault 2.0 の考え方が一般企業にも広まってきているようですが、まだまだ日本には浸透してきていないとのことでした。
なぜ、日本市場には広まってきていないのでしょう。少々中途半端と捉えられるかもしれないこのタイミングで、敢えて Data Vault 2.0 を取り上げてみようと思います。

## Data Vault 2.0 とは
Data Vault は、アメリカ人のデータアーキテクトであるDaniel Linstedt 氏が、DWH や BI 向けに開発したデータモデリングの手法です。同氏は、1990 年代にモデルを開発し、第 １ 版を 2000 年代初旬に出版。2012 年に Data Vault 2.0 が提唱され、第 2 版を出版しました。1.0 ではデータモデルの概念中心だったものが、2.0 では、データモデリングに加え、プロセスのデザイン、ETL / ELT 向けの性能向上、アジャイル開発なども考慮されています (出所 Wikipedia)。

## 従来型データ構造

まずは一般的に普及する、従来型データ構造から話を始めます。

#### Third Normal Form (3NF)
第 3 正規化と呼ばれるデータベースの設計手法です。冗長性を最小化するためにテーブルを切り出し、テーブル間にリレーションを張ることで、データの関連性を担保します。一般的には ER 図を作成して設計します。一般的に普及するデータベース設計です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2128512/e211c4f1-de0f-d5e4-8719-fca607abc7bd.png)

#### ディメンショナルモデリング：スタースキーマ
中央に位置するファクトテーブルから、周囲に位置するそれぞれのディメンションテーブルにリレーションが張られている形状です。その形状がスターに似ていることからスタースキーマと呼ばれ、DWH の設計時にはできる限りスタースキーマに近づけることが望まれます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2128512/6ab5e513-494c-c0aa-84b2-a572fb4870d2.png)

#### ディメンショナルモデリング：スノーフレークスキーマ
その名の通り、雪の結晶のようにディメンションテーブルが複数連携している形状を指します。スタースキーマ同様に、DWH の設計に一般的な手法です。スタースキーマと比較して正規化が丁寧に行われる一方、パフォーマンス面ではスタースキーマが優れます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2128512/722c6c4e-1f9a-3e75-162c-741fd77e2c98.png)

## Data Vault データモデリング
ここまで従来型の3NF やディメンショナルモデリングに関して説明しました。これらとは異なる Data Vault のデータモデリングとはどのようなものなのか、順を追って説明します。
なお、Data Vault データモデリングの説明に際して、英国の Data Vault ユーザーグループの情報を多いに参考にさせていただきました。参考情報へのリンクを文末に記述しておいたので、深く知りたい方は、是非そちらもご参照ください。

#### 目的に応じたデータの切り出し
旅行の予約サイトに関わるテーブル (BOOKING) があるとします。このテーブルから、目的に応じて BOOKING DETAILS (予約詳細)、CUSTOMER (予約者)、PRODUCT (商品)、ADDRESS (住所)、FLIGHT (航空券)、TRANSACTION (取引)、ACCOMODATION (宿泊) の7 テーブルを切り出します

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2128512/f759efb7-9881-6270-4ccd-31f3714286f3.png)

#### 再モデリング
目的別に切り出したテーブルの中から、必要なものを選択し、データモデルを再構築します。
 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2128512/b2d7c1b7-e4e6-e000-495a-076c5e485a7b.png)

##### データモデル全容
上記イメージを見ながら、データモデリングの説明を進めます。
薄黄色の背景が Satellite、薄青が Hub、薄桃が Link テーブルです。
各テーブル内の列に関しては、緑文字がメタデータ、黒文字が実データを指します。

##### Link
Link テーブルは Entity (実体) どうしを結びつける役割で、メタデータを含むものです。実データは含みません。例えば、customer booking hush はCUSTOMER BOOKING SAT とリレーションを張るために発行されたハッシュ値、load date はデータがロードされた日時、source はデータソースを指します。

##### Hub
Hub テーブルは Link テーブルと Satellite テーブルを結ぶ役割で、メタデータとビジネスキーを含みます。ここでいうビジネスキーとは、簡単に言えば Satellite の主キー (自然キー) とお考え下さい。

##### Satellite
Satellite テーブルは実データを含むものです。実データ以外にも、effective from / effective to のように、データの有効期限を適宜する情報や、行の変更にかかる処理を最適化する目的の hash diff などのメタデータを含みます。

なお、一般的な慣習として、Link と ディメンション Satellite 間には Hub を配置しますが、Link と ファクト Satellite 間には Hub を配置しないそうです。

#### SQL
各テーブルを作成するための SQL 分はシンプルで、テンプレート化しやすいものです。
例えば、Link テーブルを作成するためのクエリーは以下のようなものです。
```sql:Link テーブル
insert ignore into customer_booking_link (customer_booking_hash, load_date,
source, customer_hash, booking_hash)
select md5(concat(customer_number, booking_reference)),
load_date, source, md5(customer_number),
md5(booking_reference) from bookings;
```

タグに置き換えると以下のようになり、類似の処理への使い回しが比較的容易です。

```sql:Link テーブル <tag>
insert ignore into <tgt_link> (<pk_hash>, load_date,
source, <fk1_hash>, <fk2_hash>)
select md5(concat(<fk1>,<fk2>)),
load_date, source, md5(<fk1>), md5(<fk2>)
from <stage_table>;
```

テンプレート化した処理を、関数やストアドプロシージャ化しておくことで、処理の自動化につながります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2128512/85252af4-584e-a825-be82-29cf571d8a40.png)

## その他アーキテクチャー
ここまで、Data Vault データモデリングに関して説明してきました。冒頭でも述べたように、Data Vault 2.0 では、データモデリングに加え、プロセスのデザインやアジャイル開発なども考慮されます。

#### レイヤー
データ処理の流れに従って、プロセスのデザイン例を見てみます。下記のように、Data Lake に蓄積されたデータを目的に応じた Mart に切り出すまでの処理を順に追ってみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2128512/17c9d7a7-4e0f-3c64-0aa8-e6e4b5cbd82d.png)

①各種データソースから集められるデータが、Data Lake に蓄積されます。
②Data Lake から Stage にデータが移行され、Stage を介して、Data Vault として扱うデータに適した構造に修正します。もちろん、Data Lake を介さず、直接 ソースから Stage にコピーされるデータもあり得ます。
③上記の流れを、Data Streaming として管理します。
④Staging を通じて Data Vault のデータモデルとして扱うことができるようになったら、Raw Vault に移行します。Raw Vault 領域には、Link、Hub、Satellite など、Data Vault データモデリングにひつような各種テーブルが存在します。
⑤ビジネスルールを適用して、新たなデータが生成されることもあります。これらデータは Business Vault で管理されます。
⑥Raw Vault のデータは目的に応じて、Data Mart として切り出されます。
⑦上記一連のデータの流れに関しては、カタログ化され、監査や検索に活用されます。
⑧BI が生成するデータや、Business Vault に生成されたデータが、Data Lake にコピーされ、再活用される動きもあるでしょう。

#### アジャイル開発への適用
上記レイヤーにおけるプロセスの流れを、アジャイル開発に適用してみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2128512/697ac10b-3e27-4065-48ea-9277daa40922.png)

複数ダッシュボードを作成するアジャイル開発プロジェクトの中で、予約、宿泊など、目的別ダッシュボードを開発する単位でスクリプトを区切る場合、それぞれのスクリプト期間に応じたデータを切り出すことが求められます。そんな時、Raw Vault で管理するテーブルの中から、必要なものだけを取り出して、Mart に切り出すなどの手段を取ることができます。

#### プレゼンテーションレイヤーにおける展開例
アジャイル開発への適用例を説明しましたが、もう少しデータモデルに近い視点で考えてみます。
以下のようなData Vaultのモデルがあるとします。link と直接連結されるsatellite がファクト (薄灰、濃灰)、link と hub を介して連結される satellite がディメンション (青、橙、黄、桃) です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2128512/c8e9b4fa-4a3d-3333-c1df-c7c7c48095bd.png)

このモデルを、ビューを介して展開することができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2128512/29965386-8ef2-2ad7-5c08-4ae24227eb3a.png)

あるいは実テーブルとして、Data Mart にスタースキーマを展開することも可能です。パフォーマンスを求める場合、実テーブルとしての展開が望まれます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2128512/647b813b-f0a2-a067-ade6-58e6896a1714.png)

## ELT との親和性
従来の ETL に代わり、ELT という考え方も浸透してきています。両社の具体的な違いは、[『ETL と ELT』](https://qiita.com/ExtremeCarvFJ/items/d4bca89792efea7332b1)をご参照ください。
Data Vault のアーキテクチャーは、ELT との親和性が高いため、様々なデータの処理に対して、クラウド上のデータベースのリソースを活用することが可能です。大規模なデータ処理にも対応できます。

## Data Vault 2.0 の特長
ここまで、Data Vault 2.0 に関する内容を説明してきました。Data Vault 2.0 の特長をまとめると、おおよそ以下の感じでしょうか。

|特長|
|---|
|アジャイル開発との親和性の高さ|
|クラウドに情報資産を移行する中で、スモールスタートから、次第にテラバイト、ペタバイトまで拡張できる柔軟性の高さ|
|監査制や追跡性に優れ、コンプライアンスの要件への対応|

## 最後に
欧州では、クラウドにデータが集約される中で、伝統的な３NFに代わり、Data Vault が主流になってきている (WhereScape 社 Endika 氏談) そうです。必ずしもコンプライアンスがけん引力となっている訳ではなく、本当に優れたソリューションとして、Data Vault 2.0 の考え方が市場に広まっているとのことでした。
この流れは北米にも伝達しつつありますが、まだまだ日本では浸透してきていないようです。

ちなみに、データモデルの作成や、データ更新に関しては、基本的には処理を自動化することが望まれます。
そのためには、パッケージの導入などの検討を進めなくてはいけません。
実は、Yellowfin と同じ Idera グループ傘下の WhereScape 社が、Data Vault に適した製品を開発・販売しています。

https://qiita.com/ExtremeCarvFJ/items/316e74c3e090736a6c78

加えて、Data Vault 2.0 の考え方は、あくまでベストプラクティスとしての扱いです。そのため、自分たちが必要とする部分だけを取り入れることが重要です。

では皆様、良いデータ分析を！

## 参考情報

https://data-vault.com/

https://www.youtube.com/@Datavault