Data Vaultのマルチアクティブサテライト

著者：Petr Beles（2150 GmbH / Datavault Builder）
公開日：2018-11-07

ドキュメントサテライトとしてのマルチアクティブサテライトの実装

Data Vault標準には、「マルチアクティブサテライト（Multi-Active Satellite: MAS）」と呼ばれるモデリングパターンが存在します。これはData Vault内でバイテンポラル（二重時間軸）データを格納するためにも一部利用されています。

マルチアクティブサテライトでは、特定の粒度を持つハブの単一ビジネスキーに対して、同一の時点（DWHの認識・アサーション時刻）においてサテライト側に複数の有効エントリが紐付けられます。

本稿では、どのようなケースでマルチアクティブサテライトが採用されるのか、なぜ避けるべきなのか、そして採用せざるを得ない場合にどのように実装すべきかを解説します。

マルチアクティブサテライトを使用する主な理由

1. 同一ビジネスキーに対して複数行を区別するキーが本当に存在しない場合

現実のプロジェクトにおいて、筆者の経験上このようなケースは極めて稀であり、データの解釈誤りであることが大半です。例えば複数の分類されていない電話番号を持つ顧客であっても、各電話番号自体が自然な識別子（キー）として機能します。
また、識別子が存在しない場合、ソース側の重複データを検知できません。そのため、可能であればソースシステム側にデータ連携形式の改善を求めるべきです。

2. パフォーマンス上の理由

一意なサブキーが存在する場合、マルチアクティブサテライトの代替策として、より細かい粒度で別のハブを定義し、リンクを介して整然と接続することができます。これにより標準的なロード・クエリパターンを維持できますが、追加で2つのオブジェクト（ハブとリンク）を管理する必要があります。

マルチアクティブサテライトを避けるべき理由

差分ロード（デルタロード）の困難さ： 特定ハブキーの全アクティブレコードが差分抽出データ内に一度に含まれていない限り、差分更新が極めて困難になります（フルロードを強いられがちです）。
ファンアウト（行の増殖）による複雑化： ハブとサテライトの粒度が異なるため、特定の時点を指定してクエリした場合であっても、ハブ側のレコードが増殖（ファンアウト）します。これが下流の情報マート層やレポーティング層のクエリを大幅に複雑化させます。
直積（デカルト積）地獄： 同一ハブに対して2つ以上のマルチアクティブサテライトが存在し、それらに対してPITテーブルを作成しようとすると、組み合わせ爆発による直積地獄に陥ります。
より細かい粒度へのリレーションシップの欠落： 最も決定的な理由は、より細かい粒度に対して別オブジェクトからリンクを張る必要がある場合、独立したハブとして切り出すべきだという点です。例えば保険契約において、特定の契約インスタンス（年度ごとの補償内容）は独立したエンティティであり、事故（Claim）は契約全体ではなく特定の契約インスタンスにリンクされるべきです。筆者であれば、マルチアクティブサテライトではなく「契約ハブ」と「契約インスタンスハブ」を明示的にモデリングします。

解決策の提案：ドキュメントサテライト（Document Satellite）

それでもマルチアクティブサテライトの実装が不可避な場合、どのようなロードパターンが最適でしょうか。

2018年10月にハンブルクで開催されたドイツData Vaultユーザーグループ（DDVUG）において、Torsten Glunde氏、Andreas Heitmann氏、Matthias Müller氏、そして筆者らで議論を重ね、実装上の問題を解決する画期的な手法を考案しました。

ステージング層において特定ビジネスキーのすべてのアクティブ行が一度に揃うのであれば、それらの複数行を1つの「集合（Set）」として集約します。

現代の主要データベース（PostgreSQL、Snowflake、Oracleなど）の多くは、配列型やJSONドキュメント型をネイティブにサポートしています。JSONドキュメントは階層構造だけでなく、要素の集合を自然に表現できます。

同一ビジネスキーの複数行を1つのJSONドキュメントとして単一サテライトレコードに格納すれば、**ハブとサテライトの粒度は同一時点において再び完全に一致（1対1）**します。

これにより以下の絶大なメリットが得られます：

すべてのサテライトに対して完全に標準的なロードパターンをそのまま適用できる。
下流のPITテーブル作成やビュー定義において、ファンアウトによる複雑化が一切発生しない。
集合を行に展開（JSONパース）する必要がある場合のみ、プレゼンテーション層やレポート側の必要な箇所で意図的に展開できる。

データベースにおけるJSONドキュメントの比較処理

JSONドキュメントの普及に伴い、PostgreSQLのバイナリ比較（JSONB）など、無関係な差分（キーの順序等）を無視して実質的な変更のみを検知する機能が充実してきています。なお、JSON配列は順序を持つため、配列生成時にタプルを決定論的にソートしておく必要があります。

データベースがテキストベースのJSON比較しかサポートしていない場合は、差分検知の誤作動を防ぐためにJSONの整形（正規化）処理を挟むと良いでしょう。

まとめ

サテライト内でのJSONの活用は、変化の激しい動的なソースデータの取り込みにおいても有効な手法として、Data Vaultの提唱者ダン・リンステッド（Dan Linstedt）氏自身も提唱しています。マルチアクティブサテライトの課題に直面した際は、安易にテーブルを複雑化させる前に、ドキュメントサテライトというアプローチを検討する価値が大いにあります。

Data Vaultにおけるマルチアクティブサテライトの考察：ドキュメントサテライトによる解決策