Data Vault 2.0とは：Hub・Link・Satelliteで作る、変化に強いデータモデリング

営業の単位が変わった。顧客の属性に項目が増えた。商品コードの体系が変わった。データ基盤を運用していると、業務側の変更がそのまま追加開発の依頼として降りてきます。スタースキーマで素直に作っていると、ディメンションを直し、ファクトを直し、過去データを再生成し、と作業が膨らみがちです。「変更に弱い」のが、整然としたスタースキーマの泣きどころでした。

Data Vault 2.0は、この「変化への弱さ」を正面から解こうとしたデータモデリング手法です。Hub・Link・Satelliteという3つの構成要素で、ビジネス上の概念（誰・何・どこ）と関係、そしてそれらの履歴を分けて持ち、追加・変更があってもテーブルを再構築せずに「足す」だけで対応できる構造を目指します。提唱者はDan Linstedtで、書籍『Building a Scalable Data Warehouse with Data Vault 2.0』（2015年）にまとまっています。

Hub・Link・Satellite ：3つの構成要素

Data Vaultは、データを3種類のテーブルに分けて持ちます。役割が明確に分かれていることが、変化に強い源泉です。

テーブル種別	持つもの	例（小売）
Hub	ビジネス上の「概念」のキーだけ。属性は持たない	HUB_CUSTOMER（顧客番号のみ）、HUB_PRODUCT（商品コードのみ）
Link	Hub同士の「関係」だけ。属性は持たない	LINK_ORDER（顧客×商品×注文番号の組み合わせ）
Satellite	HubやLinkの「属性」と「履歴」。時系列で追加されていく	SAT_CUSTOMER_ADDRESS（住所の変遷）、SAT_PRODUCT_PRICE（価格の変遷）

Hubには「顧客とは何か」のキーしか入れず、住所や氏名のような属性はSatelliteに分けて持ちます。属性が変わってもSatelliteに新しい行を追加するだけで、Hub本体は触りません。関係の構造（誰が何を買ったか）はLinkに集約され、属性の変遷とは独立に管理されます。

-- Hub：顧客の存在を表す。キーだけ。
CREATE TABLE hub_customer (
  hub_customer_hk    BINARY(16),    -- ハッシュキー（顧客番号から生成）
  customer_bk        VARCHAR,        -- ビジネスキー（顧客番号そのもの）
  load_date          TIMESTAMP,      -- 最初に観測した日時
  record_source      VARCHAR         -- どのソースから来たか
);

-- Satellite：顧客の属性と履歴。Hubに紐づく。
CREATE TABLE sat_customer_profile (
  hub_customer_hk    BINARY(16),    -- 親Hubへの参照
  load_date          TIMESTAMP,      -- この行を観測した日時
  hash_diff          BINARY(16),    -- 属性のハッシュ（変化検知用）
  customer_name      VARCHAR,
  address            VARCHAR,
  email              VARCHAR,
  record_source      VARCHAR
);

なぜ「変化に強い」のか

新しい属性が追加されたいときを考えます。スタースキーマだと、ディメンションテーブルにカラムを足し、過去レコードの扱いを決め、依存するマートを直し、と連鎖します。

Data Vaultでは、新しい属性のためのSatelliteを「もう一つ」追加します。既存のHubもSatelliteも触りません。Satelliteは複数持てるので、ソースシステムごと、機密度ごと、更新頻度ごとに分けて作るのも自然です。例えば「公開可能な顧客属性のSatellite」と「機密の顧客属性のSatellite」を分け、アクセス制御を別々にかけられます。

関係の変化（新しい商品カテゴリーが追加された、注文と配送の紐付け方が変わった）も同様で、新しいLinkを足して対応します。既存のLinkは過去の関係をそのまま残します。「壊さずに足す」のがData Vaultの基本動作です。

スタースキーマとの違い

「では既存のスタースキーマと、どちらで作ればいいのか」が現場の最大の疑問だと思います。両者は目的が違うので、敵対する話ではありません。

	スタースキーマ	Data Vault 2.0
主な用途	分析・BI（読みやすさ最優先）	統合保管・履歴管理（拡張性最優先）
履歴の持ち方	SCD Type 2などで都度設計	Satelliteで標準的に保持
新属性の追加	テーブル変更・過去データの扱いを設計	新しいSatelliteを足すだけ
クエリの書きやすさ	易しい（少ないJOIN）	難しい（多くのJOIN）
向く層	マート（Gold）	統合層（Silver寄り）

Data Vaultは「統合・履歴管理に強いが、そのままBIに使うには重い」モデルです。実務では、Data Vaultで作った統合層の上に、用途別のスタースキーマやワイドテーブルを別途用意する二段構成にするのが定石です。詳しい使い分けはData Vault とスタースキーマの判断軸で深掘りします。

メダリオンアーキテクチャの中での位置づけ

Data Vaultは、メダリオンアーキテクチャ（Bronze/Silver/Gold）の中ではSilver層の選択肢の一つとして使われます。Bronzeでソースの生データを保管し、Silverでビジネス概念に統合する。そのSilverの統合の作り方として、Data Vaultが効きます。

層	主な内容	Data Vaultの役割
Bronze（Raw）	ソースの生データ	使わない
Silver（Integrated）	クレンジング・統合	Raw Vault／Business Vaultで構築
Gold（Consumption）	用途別のマート	使わない（スタースキーマやワイドテーブル）

メダリオンの考え方はメダリオンアーキテクチャの解説に、層を分けた変換の実装はdbtでの実装ガイドにまとめています。Data Vaultは、これらの「Silverをどう作るか」という問いへの一つの強い回答です。

Data Vault 2.0と「1.0」の違い

名前に「2.0」が付くのは理由があります。初期のData Vaultは、サロゲートキーをシーケンスで採番していました。並列ロードのときに採番待ちが発生し、分散環境では足かせになります。

2.0では、ビジネスキーをハッシュ化したキー（ハッシュキー）に切り替えました。これにより、各テーブルが他のテーブルを参照せずに独立にキーを生成でき、並列ロード・分散処理に強くなりました。SnowflakeやBigQuery、Databricksのようなクラウド基盤と素直に組み合わせられるのは、この設計のおかげです。Snowflakeでの具体的な実装はData Vault on Snowflakeで解説します。

どこから始めるか

Data Vaultを最初から完璧に設計しようとすると、抽象度が高くて手が止まります。実務でうまくいく進め方は、小さく始めて育てることです。

主要な業務概念（顧客・商品・注文など）を3〜5個だけ特定し、Hubを作る
その間の主要な関係（注文＝顧客×商品）をLinkで結ぶ
各Hub・Linkに紐づく属性を、変更頻度や機密度でグルーピングしてSatelliteを作る
BIで使うマートは、Data Vaultの上にスタースキーマで別途用意する

具体的な手順とdbtでの実装例はData Vaultモデリングの手順にまとめています。

まとめ

Data Vault 2.0は、Hub（概念）・Link（関係）・Satellite（属性と履歴）の3要素で構成する。
「壊さずに足す」のが基本動作で、業務変更に追従しやすい。
BIにそのまま使うには重いので、上にスタースキーマのマートを別途載せる二段構成が定石。
メダリオンアーキテクチャのSilver層の有力な作り方として位置づけられる。
2.0でハッシュキーを採用し、クラウド基盤の分散処理と相性がよくなった。

Data Vaultの導入や、既存のスタースキーマからの移行を一緒に詰めたいときは、DE-STKの初回相談（30分・無料）を壁打ち相手にお使いください。

よくある質問（FAQ）

Q. スタースキーマで困っていないなら、Data Vaultは不要ですか？

A. 困っていなければ、無理に切り替える必要はありません。Data Vaultが効くのは、ソースシステムが複数あり、業務側の変更が頻繁で、変更履歴を厳密に残す必要がある場面です。小規模で安定した業務領域だと、スタースキーマだけで十分こなせます。導入は「変化への弱さ」を実際に感じている領域から始めるのが現実的です。

Q. Data Vaultを使うと、BIのクエリは遅くなりませんか？

A. Data VaultはJOINが多くなるため、そのままBIから叩くと重くなります。だからこそ、上にスタースキーマやワイドテーブルのマート（Gold層）を別途用意するのが定石です。Data Vaultは「統合・履歴の元」、マートは「読みやすい配膳」と役割を分けます。マート側はGold層で常に最新の集計を持ち、BIはそちらを参照します。

Q. dbtでData Vaultを実装できますか？

A. 可能です。dbtで標準的にData Vaultを書く方法に加え、AutomateDVやdbtvaultといったコミュニティ製のパッケージがあり、Hub・Link・Satelliteのマクロを使ってボイラープレートを大幅に減らせます。Hubのハッシュキー生成、Satelliteの差分検知などをマクロで実装する流儀が広まっています。dbtを使った具体例はモデリング手順で示します。

Q. すぐにData Vaultにすべて移行すべきですか？

A. 一気に移行は避けてください。既存のスタースキーマは残したまま、新しい統合領域から少しずつData Vaultを適用するのが安全です。変更が頻繁で履歴管理が課題になっている1〜2業務だけを切り出して試し、運用感を掴んでから広げます。dbt導入と同様、小さく始めて育てる進め方が、結果的に最短距離になります。

参考

Dan Linstedt 公式サイト datavaultalliance.com
Dan Linstedt, Michael Olschimke『Building a Scalable Data Warehouse with Data Vault 2.0』Morgan Kaufmann, 2015
AutomateDV（旧dbtvault）公式ドキュメント automate-dv.com