本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
Kimball、Inmon、Data Vault方法論のように業界固有のドメインモデルのように、分析システムの設計を行う際に活用できる様々なデータモデルが存在します。皆様固有の要件によって、レイクハウスを設計する際にこれら異なるモデリング技術を活用することができます。それぞれはすべて、自身の強みを持っており、異なるユースケースにフィットします。
究極的にデータモデルは、1:1、1:多、多:多で定義されるリレーションシップを用いて様々なテーブルを定義する構造以外の何者でもありません。データプラットフォームは、情報取得をより容易にし、優れたパフォーマンスを提供できるように、データモデルの物理化においてベストプラクティスを提供すべきです。
以前の記事では、Delta Lakeを用いてDatabricksでスタースキーマを実装する5つのシンプルなステップをカバーしました。この記事では、Data Vaultとは何か、Bronze/Silver/Goldレイヤーでどのようにそれを実装するのか、DatabricksレイクハウスプラットフォームにおけるData Vaultでどのようにベストなパフォーマンスを得るのかを説明します。
Data Vaultモデリング
Data Vaultモデリングのゴールは、設計によって早いペースで変化するビジネス要件に適応し、データウェアハウスの高速かつ迅速な開発をサポートすることです。Data Vaultは、ハブ、リンク、サテライトデザインを用いてデータモデルを容易に拡張し、きめ細かくできるので、設計とETLの変更を容易に実装することができ、レイクハウスの方法論に非常にフィットします。
Data Vaultのいくつかのビルディングブロックを理解しましょう。通常は、Data Vaultモデルには3つのタイプのエンティティがあります:
- Hubs - ハブは、顧客、製品、注文のようなコアのビジネスエンティティを表現します。アナリストは、ハブに関する情報を取得するために自然なビジネスキーを使用します。ハブテーブルの主キーは通常、ビジネスコンセプトのID、ロード日、その他のメタデータ情報の組み合わせから作成されます。
- Links - リンクはハブのエンティティ間の関係を表現します。joinのキーのみを持ちます。これは、ディメンショナルテーブルのFactless Factテーブルのようなものです。属性はなく、joinキーのみです。
- Satellites - サテライトテーブルは、ハブやリンクにおけるエンティティの属性を保持します。これらは、コアなビジネスエンティティの説明的な情報となります。これらは、ディメンションテーブルの正規化されたバージョンのようなものです。例えば、顧客ハブには、顧客の位置的属性、顧客のクレジットスコア、ロイヤリティレイヤーのような多くのサテライトテーブルがあります。
Data Vault方法論の大きな利点は、データモデルを変更した際に既存のETLジョブのリファクタリングが非常に少ないと言うことです。Data Vaultは「書き込み最適化」方法論のスタイルであり、迅速な開発アプローチをサポートし、データレイクやレイクハウスアプローチにとてもフィットします。
Data Vaultモデリングが互いに接続されたハブ、リンク、サテライトを用いてどのように動作するのかを示す図
Data Vaultはどのようにレイクハウスにフィットするのか
いくつかのお客様でDatabricksレイクハウスアーキテクチャでData Vaultモデリングをどのように活用しているのかを見ていきましょう。
レイクハウスにおけるData Vaultアーキテクチャ
DatabricksレイクハウスにおけるData Vault実装における検討
- Data Vaultモデリングは、主キーとしてビジネスキーの八種を使用することを推奨しています。Databrikcsでは、ビジネスキーをサポートするためにすぐに利用できるhash、hash、SHA関数をサポートしています。
- Data Vaultレイヤーには、ランディングゾーン(そして、時にはステージングゾーン)の概念があります。これら両方の物理レイヤーはデータレイクハウスのブロンズレイヤーに自然にフィットします。Avro、CSV、parquet、XML、JSONフォーマットのようなデータがランディングゾーンに到着すると、後続のETLが非常に高速になるように、ステージングゾーンでDeltaフォーマットのテーブルに変換されます。
- 生のVaultはランディングゾーン、あるいはステージングゾーンから作成されます。生のData Vaultのハブ、リンク、サテライトテーブルとしてデータはモデリングされます。生のData Vaultをロードする際には通常、追加の「ビジネス」ETLルールは適用されません。
- ETLビジネスルール、データ品質ルール、クレンジング、準拠ルールのすべては、生のVaultとビジネスVaultの間で適用されます。ビジネスVaultテーブルは、標準化されクレンジングされたデータの企業の「中央リポジトリ」として機能するデータドメインごとに整理することができます。データスチュワードやSMEは、ビジネスVaultの自分たちの領域におけるデータ品質やビジネスルール、ガバナンスのオーナーシップを持ちます。
- Point-in-Time (PIT)やブリッジテーブルのようなクエリーヘルパーテーブルは、ビジネスVaultの上にあるプレゼンテーションレイヤー向けに作成されます。PITテーブルは、いくつかのサテライト、ハブが事前にjoinされ、「ポイントインタイム」のフィルタリングのWHERE条件を提供するので、クエリー性能を向上させます。ブリッジテーブルは、エンティティに対するビューのようなflattenされた「ディメンショナルテーブル」を提供するために、事前にハブやエンティティをjoinします。Delta Live Tablesはまさにマテリアライズドビューなようなものであり、ビジネスData Vaultの上のGold/プレゼンテーションレイヤーのポイントインタイムテーブル、ブリッジテーブルを作成するのに活用することができます。
- ビジネスプロセスは変化し、適応するので、Data Vaultモデルはディメンショナルモデルのように膨大なリファクタリングを必要とすることなしに、容易に拡張することができます。追加のハブ(対象領域)を容易にリンク(純粋なjoinテーブル)に追加でき、追加のサテライト(顧客セグメントなど)を最小限の変更でハブ(顧客)に追加することができます。
- また、Goldレイヤーのデータウェアハウスへのディメンショナルモデルのロードも、以下の理由から容易なものになります:
- ハブによってキー管理が容易になります(ハブから得られる自然なキーはIdentity columnsを通じてサロゲートキーに変換することができます)。
- サテライトにはすべての属性が含まれているので、ディメンションのロードが容易になります。
- リンクにはすべてのリレーションシップが含まれているので、ファクトテーブルのロードが非常にわかりやすいものになります。
DatabricksレイクハウスでData Vaultモデルのベストなパフォーマンスを得るためのTips
- 生のVault、ビジネスVault、GoldレイヤーのテーブルにはDeltaフォーマットを使いましょう。
- ハブ、リンク、サテライトのすべてのjoinキーにOPTIMIZEとZ-orderを使うようにしてください。
- テーブル、特に小規模なサテライトテーブルをパーティショニングしすぎないでください。Z-orderとは別に追加のインデックスを作成する必要がある場合には特にベストなパフォーマンスを提供できるように、フィルタリングを行う日付カラム、最新を示すフラグのカラム、述語カラムにはBloom filter indexingを使用してください。
- Delta Live Tables(マテリアライズドビュー)によって、PITテーブルの作成、管理が非常に容易になります。
-
optimize.maxFileSizeをデフォルトの1GBではなく、32-64MBのような小さい値にしてください。小規模なテーブルを作成することで、ファイルプルーニングの恩恵を受けることができ、joinの際に必要なデータの取得におけるI/Oを最小化することができます。 - Data Vaultモデルでは比較的多いjoinが発生するので、ベストなjoin戦略が自動で採用されるAdaptive Query Executionがデフォルトでオンになっている最新のDBRを使用してください。(高度なパフォーマンスチューニングで)必要であればJoin hintsを使用してください。
Data Vaultモデリングの詳細については、Data Vault Allianceをご覧ください。