Data Vault における技術キーとビジネスキー
ソースシステムはビジネスキーをマスターレコードに保持していますが、リレーションシップはすべて技術キーで成り立っています。これに対処する 4 つの方法とそれぞれの代償、そして私たちが使っているパターンを紹介します。技術キー用の PSA ハブを設け、それをビジネスキーのハブにマッピングするパターンです。
さまざまな業界のデータチームから信頼されるデータウェアハウス自動化ソリューション
このような課題はありませんか？
- 受注テーブルにはシステム内部の顧客 ID しかなく、顧客番号は別のテーブルにある。
- ソースごとに顧客ハブを作った結果、データが統合されることはなかった。
- ステージングの結合でソースからビジネスキーを引いているため、ソースが実際に何を提供したのかを誰も証明できなくなっている。
Data Vault はビジネスキーを土台にしています。ビジネスキーは安定していて、システム間で共有され、移行を経ても残ります。問題が始まるのは、ソースシステムが実際にリレーションシップをどう保存しているかを見たときです。
問題：リレーションシップは技術キーで成り立っている
ほとんどのソースシステムは、ビジネスキーを、そのキーが定義するエンティティ自体に保持しています。顧客テーブルには顧客番号があります。ところが、リレーションシップにはシステム独自の技術キーが使われます。
| テーブル | カラム |
|---|---|
Customer |
customer_id = 10492、customer_number = CUST-9921、氏名、住所 |
Order |
order_id = 884102、order_number = SO-1018、customer_id = 10492 |
受注にとって、顧客は 10492 でしかありません。CUST-9921 をキーとする顧客ハブにつなぐには、一方をもう一方に変換する何かが必要です。
従来のモデリングの用語で言えば、ソースは外部キーにサロゲートキーを使っていますが、Data Vault が求めているのは自然キーです。問題は、その変換をどこで行うかです。
4 つの解決方法
| アプローチ | 仕組み | 代償 |
|---|---|---|
| 1. システムごとのソース Vault | CRM の顧客と請求システムの顧客に別々のハブを設け、技術 ID をキーにする | 技術的には可能だが、データが統合されることはない |
| 2. ビジネスキーを返すソース API | すべてのリレーションシップをビジネスキーで提供するよう、各ソースに求める | 実現すれば非常に便利だが、そうなることはめったにない |
| 3a. ステージング中の独自ルックアップ | ステージング中にソースへ問い合わせ、技術キーをビジネスキーに置き換える | 機能し、自分で管理できるが、データが書き込み前に変更されるため監査可能ではなくなる。また、ルックアップが本来負荷をかけるべきでない本番システムに負荷をかける |
| 3b. ステージング後のルックアップ | ステージング後に、ステージングテーブルまたは Vault と結合して技術キーを置き換える | ステージングテーブルとの結合ではテーブル全体が必要になるため、差分ロードができなくなる。Vault との結合は機能するが、やはりデータがロード前に変更される |
| 4. PSA ハブ | 技術キーを専用のハブにロードし、ビジネスキーのハブにマッピングする | クエリ時に自動生成される結合が 1 つ増える。Business Vault のロードによって、それを不要にできる。 |
私たちが使っているパターン：PSA ハブ
PSA ハブは、ソースシステムの技術キーのためのハブです。PSA は persistent staging area（永続ステージング領域）の略ですが、データレイクの文脈でよく言われる、ソーステーブルをフラットにコピーしたものとは違います。この PSA はすでに Vault の形式になっており、ハブとリンク、そして必要な箇所にはサテライトを持っています。以下の例では、PSA は属性をまったく持たず、技術的なリレーションシップだけを保持します。説明的なデータはビジネスキーのハブにあります。
各概念に割り当てるハブは 2 つです。ソースシステムごとに 1 つずつ作ることは決してありません。
- PSA ハブは、すべてのシステムの技術キーを、それぞれの Business Key Prefix 付きで保持します。
CRM|10492、ERP|80012のようになります。 - Raw Vault のハブは、ビジネスキーをプレフィックスなしで保持します。
CUST-9921のようになります。
こうすると、ロード時には変換がまったく必要ありません。
- トランザクションは提供されたとおりにロードします。 受注
884102は、受注の PSA ハブと顧客の PSA ハブを結ぶリンクを介して、顧客CRM|10492と関係付けられます。使うのは、ソースが保持しているとおりの技術キーです。 - マスターレコードがマッピングを担います。 顧客レコードは
10492とCUST-9921の両方を持っているため、PSA のキーとビジネスキーを多対一で関係付けます。複数のシステムの技術キーが、同じ顧客を指すことができます。 - サテライトはビジネスキーのハブに付けます。 顧客の氏名と住所は、どのシステムから提供されたかにかかわらず、
CUST-9921を説明するものです。
受注、製品、契約と、どの概念でも同じパターンを繰り返します。
クエリ：1 つの経路と近道
受注を統合済みの顧客とともに出力するには、クエリは受注から受注の PSA ハブへ進み、技術的なリレーションシップをたどって顧客の PSA ハブへ、そこから顧客へと進みます。
Order → Order PSA → Customer PSA → Customer
これが加工されていない、完全に追跡可能な経路です。クエリを高速化する必要がある箇所では、探索リンクを作成する Business Vault のロードを設定します。探索リンクは経路を一度だけ解決し、受注と顧客の直接のリレーションシップを保存します。 レポートは短い経路を読み、長い経路は監査証跡として残ります。
得られるもの
- 書き込み前に何も変更されません。 技術キーはソースが提供したとおりにロードされるため、すべての行が監査可能なまま保たれます。
- 本番システムへのルックアップがありません。 変換はデータウェアハウスの中で行われます。
- 書き込みが高速です。 ロードにルックアップがまったく不要なため、各ソースは提供される速さのままロードされ、探索リンクはその後で非同期に作成されます。
- 出力が統合されます。 すべての顧客がビジネスキーをキーとして一度だけ出力され、すべてのシステムのトランザクションが結び付いています。
- 移行の影響が限定されます。 ソースシステムが置き換えられても、新しい技術キーは同じビジネスキーにマッピングされ、履歴は引き続き一致します。
Datavault Builder で何が変わるか
Datavault Builder は PSA、Raw Vault、Business Vault に対応しており、この 3 つが 1 つの統合されたモデルを形成します。各レイヤーは、必要に応じてアジャイルに段階的に開発できます。まず PSA ハブから始め、ビジネスキーのマッピングを加え、クエリが必要とする箇所に探索リンクを設定します。
CRM|10492 と ERP|10492 を区別する Business Key Prefix はモデルの一部であり、このパターンのハブ、リンク、ロード処理は他のものと同様に自動生成されます。モデリング上の判断はご自身に委ねられます。どの概念にするか、どのビジネスキーにするか、そしてどこに探索リンクを設ける価値があるかです。
貴社のデータソースで実際の動作をご確認ください
無料デモをお申し込みいただき、費用や保守工数が最もかかっているコネクタをお持ち寄りください。
技術キーからビジネスキーへの3つのステップ
-
Raw Vault をいつもどおりロードする
ビジネスキーのハブとそのサテライトを、文献に書かれているとおりにマスターレコードからロードします。
-
技術キー用の PSA ハブを追加する
PSA ハブは技術キーを Business Key Prefix 付きで保持し、リレーションシップはそのキーで PSA ハブ同士を結びます。
-
その価値があれば経路を短縮する
クエリに本当に速度が必要な箇所では、探索リンクが直接のリレーションシップを一度だけ保存します。
Datavault Builder がデータ取り込みの摩擦を解消する仕組み
-
取り込み機能を標準で統合
データベース、ファイル、REST API、NoSQL、Python ソースからのバッチ・差分・CDC ロードに対応し、Kafka などのストリームもマイクロバッチとして取り込み可能。ウェアハウス生成と同一の単一プラットフォームで完結し、追加のツール費用は不要です。
-
ベンダー仕様ではなく自社設計のスキーマ
ソーステーブルは自社で設計した Data Vault 2.0 モデルにマッピングされます。カラム追加やテーブル名変更が発生しても、マッピングを調整するだけで対応でき、ロード後のスクリプト修正作業は不要です。
-
差分（デルタ）のみを転送・処理
Hub、Link、Satellite は変更分のみを効率的にロードします。フルリロードデータはステージングに留まり、下流で毎晩再処理されるような無駄な負荷を発生させません。
-
設計段階から変更履歴を確実に保持
すべての変更履歴が到着順に記録されるため、ソース側でレコードが上書きされても過去時点の正確な状態（as-was）を遡って集計・レポーティングできます。
-
手作業でのコーディングは一切不要
ロード処理、履歴管理、データリネージはモデルからリアルタイムで自動生成され、Snowflake、Databricks、BigQuery、SQL Server、Fabric、Oracle、PostgreSQL 上でネイティブに実行されます。
-
1 つのプラットフォームで最大 9 つのツールを集約
モデリング、ETL、CI/CD、ドキュメント生成、リネージ管理を 1 つの環境に統合。要件定義から本番環境へのデプロイまでわずか 14.7 分という迅速なデリバリーを実現します。
BARC「The Data Fabric Survey 26」で高評価を獲得
専門家にご相談ください
弊社のセールスディレクターが 20 分間で、貴社の技術スタックに適合するか率直にお答えします。
Matt Collett
Sales Director
ご都合の良い日時をお選びください：
本シリーズで解説するその他の課題
-
Data Vault のビジネスキーとは？
ビジネスキーとは、従業員や顧客が実際に使っている識別子です。顧客番号、請求書番号、契約 ID などがこれに当たります。安定していて、システムをまたいで共有されており、Data Vault のすべてのハブはこのキーを土台に構築されます。
-
Data Vault のサテライトとは？
サテライトは、ハブを説明するすべての情報を保持します。名称、ステータス、金額、そしてそれらに対するすべての変更です。変更は追記され、更新されることはありません。UPDATE を使わない Slowly Changing Dimension タイプ2 であり、完全な監査証跡が最初から組み込まれています。
-
Data Vault のリンクとは？
リンクはビジネスキー間のリレーションシップを記録します。この受注はこの顧客のものである、といった関係です。Datavault Builder は Data Vault の従来型のリンクに対応するとともに、グレインハブを基点とするトランザクションリンクを備えています。トランザクションリンクはトランザクションの粒度を固定し、トランザクション同士を関連付けられるようにします。
-
Data Vault のハブとは？
ハブは、顧客、製品、口座といったビジネス上の中核概念を、そのキーの一覧として表します。データウェアハウスがこれまでに受け取ったすべてのキーを、それぞれ一度だけ保持します。保存するのは状態ではなく識別情報であり、この割り切りによって、ハブはソースシステムごとのサイロが解消される場所になります。
よくあるご質問
- Dan Linstedt です。1990 年代にこの手法を開発し、2000 年ごろに公開しました。モデルにハッシュキー、方法論、アーキテクチャを加えた Data Vault 2.0 は 2013 年に登場しました。
- 標準的な参考書は、Dan Linstedt と Michael Olschimke による Building a Scalable Data Warehouse with Data Vault 2.0（Morgan Kaufmann、2015 年）です。
- いいえ。Bill Inmon は Data Vault を、第3正規形に基づくエンタープライズデータウェアハウスという自身の考え方を発展させたものと位置づけており、競合するアプローチとは見ていません。
- いいえ。ディメンショナルな出力は、多くの場合 Data Vault 実装の一部です。Vault が統合された履歴を保持し、その上にレポート用のスタースキーマを構築します。同じ Vault から、フラットなテーブルや Unified Star Schema を提供することもできます。
- 自動化を利用すれば、Data Vault の上に第3正規形のビューを完全に決定論的に生成できます。データは Vault に一度だけ保持され、3NF のレイヤーはモデルから導出されます。その仕組みはこちら。
- 自動化せずに取り組むことです。Data Vault は、少数の厳密で繰り返し現れるパターンの上に成り立っています。だからこそ手作業で書くと手間がかかり誤りも生じやすく、逆に生成するのは容易です。Datavault Builder を使うべき理由はそこにあります。
- はい。キー、リレーションシップ、履歴をハブ、リンク、サテライトに分けるため、正規化モデルやディメンショナルモデルよりもテーブルは多くなります。そのため物理レイヤーは、Datavault Builder のようなモデル駆動型のアプローチで抽象化すべきです。作業はビジネスモデルに対して行い、テーブルは自動生成されます。
- デモを予約して自社のソースで Data Vault が構築される様子をご覧いただくか、トレーニング環境を注文してご自身で試してみてください。
- Datavault Builder は年間ライセンスで、ソフトウェアを利用するためのサブスクリプションとして提供されます。永続ライセンスはご要望に応じてご用意します。各エディションとその内容は料金ページに掲載しています。