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 図を作成して設計します。一般的に普及するデータベース設計です。

ディメンショナルモデリング：スタースキーマ

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

ディメンショナルモデリング：スノーフレークスキーマ

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

Data Vault データモデリング

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

目的に応じたデータの切り出し

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

再モデリング

目的別に切り出したテーブルの中から、必要なものを選択し、データモデルを再構築します。

データモデル全容

上記イメージを見ながら、データモデリングの説明を進めます。
薄黄色の背景が 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 テーブルを作成するためのクエリーは以下のようなものです。

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;

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

Link テーブル

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>;

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

その他アーキテクチャー

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

レイヤー

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

①各種データソースから集められるデータが、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 にコピーされ、再活用される動きもあるでしょう。

アジャイル開発への適用

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

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

プレゼンテーションレイヤーにおける展開例

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

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

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

ELT との親和性

従来の ETL に代わり、ELT という考え方も浸透してきています。両社の具体的な違いは、『ETL と ELT』をご参照ください。
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 に適した製品を開発・販売しています。

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

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

参考情報