データボルトモデリング設計の用途

Data Vault は、テクノロジーではなく、設計パラダイムです。あらゆるリレーショナルデータベースやデータレイクで使用できます。これは、データウェアハウスでよく使用されるスター/スタークラスター/コンステレーションやスノーフレーク（DB会社ではありません）スキーマ設計から脱却し、より優れたデータウェアハウス方法を見つけたいという思いから生まれました。

しかし、そうすることで、エンドユーザーを実質的に排除、あるいは少なくとも制限する異なるパターンが提供されます。エンドユーザーへのクエリ実行が難しく、エンティティの構成も直感的ではありません。主な対象がエンドユーザーではなくエンジニアであれば、ウェアハウスや運用データストアの代替となる可能性があります。ただし、データマートの代替にはなりません。

なぜそれらから遠ざかる必要があるのでしょうか？それらは機能しないのでしょうか？テクノロジー業界の多くのものと同様に、それらが「機能する」かどうかの答えはユースケースによって決まります。あなたはそれをどのような目的と機能で使用しようとしていますか？消費者と生産者の役割に参加するアクターが、一般的にユースケースのパラメータ、つまり焦点と境界を決定します。

前述のスタースキーマのバリエーションの場合、ユースケースの中心はエンドユーザーです。エンドユーザーは、インタラクティブなツールやクエリを用いてアドホックにデータにアクセスするか、生成されたレポートを参照します。上記のスキーマを視覚的に理解しやすくするために、以下にシンプルなスターダイアグラムを示しました。上部の3つのテーブルは、スタースキーマのソースデータであり、緑色で強調表示されています。

スノーフレークを除く、以下の図にバリエーションが示されています。スノーフレークは基本的に、以下のテーブルにディメンションのない参照テーブルを追加します。これらのテーブルはほとんどの場合、ディメンションに関連付けられています。例えば、ディメンション内のデータを分類するための様々なタイプのテーブルがあります。輸送の種類（航空、陸上、海上）とそれぞれの特性を考えてみてください。

星：多面性を持つ一つの事実

Typical Star Schema Pattern

星団 - 次元に関する多様な事実

Depiction of Potential Star Cluster Pattern

星座：複数の関連する事実と次元

Multiple related Facts and Dimensions

ご想像のとおり、これら 3 つの設計はすべて、クエリやレポートを使用するインタラクティブ ツールのいずれであっても、分析を作成して消費者に提供することに重点を置いています。

エンドユーザーの観点から見ると、ディメンション(Dim)テーブルにデータを書き込むために、舞台裏では大量のデータ品質の調整と変換が行われています。これは、ファクト(Facts)テーブルに分析データを入力する前の段階です。

すべてのディメンションとファクトは「ダム」キー、つまり代理キーを使用しています。これはマートやウェアハウスの設計ではほぼ標準的な手法ですが、このため重複が発生する可能性があります。これは、重複が有効なユースケースがあり、代理キーの設計パターンがそれに対応しているためです。これは、タイムスタンプ値が同じであっても、シーケンスによって区別できるため、時系列データを使用する場合に特に便利です。

データ品質

データ品質管理は正確である必要があります。そうでないと、データに「歪み」が入り込みやすくなります。歪んだデータから機械学習モデルを実行すると、モデルにドリフトが生じ、期待どおりの結果が得られなくなります。ドリフトが過度に発生する場合は、通常、データ品質の問題、または機械学習モデルの感度が問題であることを示しています。これは、Data Vault設計パターンを使用するメリットの少なくとも一部です。重複を防ぎ、特定のデータ分類の一意性を保証することで、データ品質管理の労力を軽減します。理論的には、ドリフトの問題をさらに防ぐのに役立つはずです。

唯一無二性という側面しか持たず、データ内容の検証には特に触れていません。例えば、列の値が9文字の英数字のみで構成されている場合、検証が必要です。また、列が値のリストに制限されている場合も、検証が必要です。データ品質検証の最も一般的な種類（私見ですが）は、制約に基づく列の値の検査です。長さ、データ型、単語数などです。すべてのデータソースが列に制約が適用されたリレーショナルデータベースであれば、データ品質の作業ははるかに容易になります。しかし、これは非常に稀なケースです。

データは、構造化、半構造化、非構造化といった様々な形式から生成されます。そのため、検査ユーティリティの寿命は長く、PythonスクリプトからSQLまで、様々な形式で正規表現（略してregex）を使用することは、「自作」ソリューションを構築する必要がある人にとっては非常に一般的です。pydanticやcerberusなど、Pythonには様々なデータ検証フレームワークやユーティリティがあります。長年にわたり多くのデータ品質ツールが存在してきましたが、価格が高騰して採用が難しく、結果として大企業に買収され、自社製品に統合されてきました。Informatica、 IBM 、 SAS 、 Ab Initioは、過去20年間にわたり、データ品質およびビジネスインテリジェンス製品を買収してきました。

Data Quality Remediation

他に最も一般的なデータ品質チェックはレコード数です。これは基本的に、ロード時に入力と出力が一致しているかどうかをチェックするものです。これは、データの変換を開始すると具体的なカウントは考慮されなくなるため、実行できる数少ない汎用的なデータ品質チェックの一つです。変換結果のカウント範囲を計算するには、変換の入出力比率のプロファイルが必要です。前述のように、Data Vault の開発における要因の一つはデータ品質でしたが、他にも要因はいくつかあります。

データボールト

開発者のダン・リンステッド氏は、これを「詳細指向で、履歴追跡が可能で、1つ以上の機能領域をサポートする、独自にリンクされた正規化テーブルセット」と説明しています。これは、第3正規形（3NF）とスタースキーマの最良の組み合わせを包含するハイブリッドアプローチです。ダン氏によると、これはニューロン、樹状突起、シナプスの単純な見方から着想を得たものです。

Data Vault には、すべてのリレーションシップがキー駆動型であることや、設計パターンが数ペタバイト（PB）規模のデータベースに拡張可能であることなど、いくつかの利点が挙げられています。Data Vault は、データモデリングにおけるアジャイルなアプローチであるアンカーモデリングの一例であり、変更を捕捉しながらも、必ずしも既存のモデルに広範囲な影響を与えることはありません。また、ビジネスプロセス駆動型であるため、スタースキーマとそのバリエーションも理想的にはビジネスプロセス駆動型であるべきです。

モデリング手法は、エンティティ・リレーションシップ・データモデルの作成に似ています。つまり、ビジネスプロセスとそれに関連するデータ要素を表す論理モデルを作成します。Data Vaultは、エンティティベースのモデルを作成するための高度に標準化されたアプローチであり、スキーマ全体でデータ要素を繰り返す必要がないため、高い柔軟性を実現します。

このモデリング手法のもう一つの利点は、完全な監査可能性とトレーサビリティが確保されることです。また、SEI CMMレベル5（反復可能、一貫性、冗長性を備えたアーキテクチャ）に準拠しており、サーベンス・オクスリー法、HIPPA、BASIL IIに準拠したモデルを提供します。

Data Vault Hubs, Satellites, and Links

では、具体的にはどのようなものなのでしょうか？Data Vaultは、論理データモデルフェーズ（前提条件）でモデル化されたビジネスプロセスを表すハブ、サテライト、リンクの集合です。これは、現在取り組んでいる領域を代表するものでなければなりません。以下に仮想的なビジネスケースを示します。最適なユースケースは、運用データストアまたはデータウェアハウスであり、スタースキーマの代替ではありません。

以下は、株式、債券、先物、オプションなどを取引する資産運用会社からの仮想的なデータフローです。金融取引の一部は24時間365日稼働しており、そのかなりの部分がアルゴリズム取引であるため、図中の「トレーダー」は実際にはソフトウェアです。また、ブローカーとマーケットメーカーは単一の当事者（単一の企業）である場合があり、大規模な機関投資家取引には複数のカストディアン銀行が関与する場合もあります。

カストディ銀行は、2つ以上のカストディ銀行間で資金を中継することを唯一の目的とする第三者である場合があります。これは国際市場でよく見られるケースです。こうしたニュアンスは取引の当事者が増えるだけで、プロセス自体に変化はありません。

Asset Manager Trade Flow

以下は、上記のデータフロー図に基づいた、属性付き論理データモデルです。特に目立つ一般的な属性を追加しましたが、通常はモデルの詳細化に役立つ要素が追加される一方で、この例ではノイズが増える可能性があるため、省略しました。

Trade Logical Data Model (LDM)

上記のLDMをデータボルトの物理フォーマットに変換する手順は以下の通りです。通常、LDMはエンティティからテーブルへの変換とほぼ同様の手順で物理フォーマットに変換されます。ただし、多対多の論理関係を連想テーブルで物理的に実装する必要がある場合は例外です。その場合、物理フォーマットの非正規化も行われる可能性がありますが、このフェーズは通常、パフォーマンスの問題を発見するテストサイクルの結果として行われます。冗談ではなく、非正規化は通常の手法ではありません。そもそも非正規化から始めるべきではなく、事後対応的、または既存のパターンに従うものです。

物理モデルにおけるデータボールトの実装は、LDMとは大きく異なります。スタースキーマやその派生モデルとは全く異なる点にご注目ください。

Trading Data Vault Example Schema

データ ボールトが設計パターンで従うコア概念がいくつかあります。

• Data Vaultの設計は、スタースキーマで実装されたOLAPやその派生製品の代替ではなく、データウェアハウスやオペレーショナルデータストアとして最適なOLTPにも適していません。いわばハイブリッドなものです。

• これは、第 3 正規形 (3NF) に厳密に準拠しているため、ユーザー主導のクエリではなく、ストレージ向けに最適化されています。

• ハブ、サテライト、リンクの3つのエンティティタイプがあります。静的なサテライトをサポートする参照テーブル（国または通貨テーブル、郵便番号、重量と寸法など）を作成できます。

• ハブとは、データの変更頻度が低いテーブルです。ビジネスキーが含まれている必要があります。ある意味では、非常にゆっくりと変化するディメンションに似ていると考えることができます。

• リンクはビジネスキー間の関連付けです。ビジネスキーは通常はハブですが、必ずしもハブとは限りません。リンクは、キー間の関係を解決する連想エンティティです。

• サテライトは、トランザクションコンテンツと同様に、日時生成データなどの時間的および説明的な属性に使用されます。サテライトは、他のサテライトとの関係、参照データ、ハブへのリンクを持つことができます。

• ハブ間にはリンクが存在し、リンクテーブルはハブの主キーを吸収します。ハブはサテライトを子として持つことができます。

• リンクはサテライトを子として持つことはできますが、親として持つことはできません。リンクの主キーはサテライトに吸収されます。

• 各テーブルには、各行のロード日とレコードソースがあります。これらをテーブル内の「自然」キーまたは「ビジネス」キーに追加すると、一意のキーが作成されます。「自然」キーがないテーブルの場合は、代理キーを使用できます。この制約を強制するには、一意キー制約または一意キーインデックスを使用します（最後のは私の個人的な意見です）。ただし、リレーショナルDBMSを使用している場合を想定しています。

• 制約やインデックスのないデータレイクにモデルを実装する場合は、代わりにパーティション定義を使用できます。もちろん、これを強制するロジックをコードに組み込む必要があります。ただし、Apache Iceberg に書き込む場合は、メタデータ層に制約を実装できます。

• 使用しているドキュメント データベースに応じて、制約を使用することもできます。

データ読み込み方法

テーブルのロード順序は重要です。特にキー/インデックスを使用して制約を行う場合は重要です。最初にロードするのはハブです。これは並列処理が可能で、新しい代理キーを作成します。次のステップはリンクです。属性値をロードし、ハブ間の関連付けを作成します。最後に、リンクまたはハブの受信側であるサテライトです。これらは互いに並列処理が可能です。

レコードの一意性を保証するために、3NF（3次元正規表現）のハッシュ法がETL/ELT処理の一部として一般的に使用され、入力レコードのハッシュと現在テーブル内にあるレコードのハッシュを比較します。レコードがデータボールトから削除されることはありません。

ユースケースデータヴォールト設計の主なユースケースは、オペレーショナルデータストア（ODS）とエンタープライズデータウェアハウス（EDW）です。これらのユースケースは、以下のいくつかの要因により、どちらも適しています。

• 第 3 正規形 (3NF) に厳密に準拠すると、テーブル内のフィールドが非正規化または重複されることがなくなり、最も効率的なストレージの使用が可能になります。

• データの一意性チェックは、ハッシュを使用して特定のレコードが既に保存されているかどうかを確認するロードプロセスに組み込まれているため、レコードの重複は発生しません。これによりストレージ容量も削減されます。

• エンドユーザー向けのクエリは難しい場合があります。データボルト設計では、一般的なエンドユーザー向けに比べて、テーブルへのクエリにはより高度なSQL知識が必要になります。エンジニアがデータにアクセスするのに適した設計であり、ユーザーフレンドリーではありません。エンドユーザーにデータを公開したい場合は、従来のRDBMSでビューを作成してアクセスを簡素化できます。

• 保存されるレコード数が少ないということは、クエリによってスキャンされるデータ数が少ないことを意味します。そのため、効率的なクエリを使用した出力の取得時間は、非正規化構造と比較して、実行する作業が少なくなります。

• テーブル設計はエンジニア向けです。正規化に厳密に重点を置き、ビジネスプロセスフローではなくデータの効率的な保存を反映した構造になっています。

Data Vault設計パターンは、特に文字通り可能な限り大量のデータを保持したい場合に、間違いなく役立つと思います。データレイクであれRDBMSであれ、それはおそらく、あらゆるスタースキーマやスタースキーマの派生スキーマと比べて、その問題を解決するのに最も効果的でしょう。ODSの場合、通常1週間から数か月分のデータが扱われますが、正規化があらゆる面で役立つため、ODSはこれにも適しています。こうした特殊な用途は、比較検討する価値があります。