前回の記事では、DATA VAULT の基本について説明し、DATA VAULT の主な要素とその目的について説明しました。 DATA VAULT のトピックがこれで終わったとは考えられません。DATA VAULT の進化における次のステップについて話す必要があります。
この記事では、DATA VAULT の開発と、BUSINESS DATA VAULT または単に BUSINESS VAULT への移行に焦点を当てます。
BUSINESS DATA VAULT登場の理由
DATA VAULT には一定の長所がある一方で、欠点がないわけではないことに注意してください。 これらの欠点の XNUMX つは、分析クエリの作成が難しいことです。 クエリには大量の JOIN が含まれており、コードは長くて面倒です。 また、DATA VAULT に入力されるデータはいかなる変換も受けないため、ビジネスの観点から見ると、純粋な形式の DATA VAULT には絶対的な価値がありません。
これらの欠点を解消するために、DATA VAULT 方法論が次のような要素で拡張されました。
- PIT (時点) テーブル。
- BRIDGE テーブル。
- 事前定義された導出。
これらの要素の目的を詳しく見てみましょう。
PITテーブル
通常、XNUMX つのビジネス エンティティ (HUB) には、異なる更新レートのデータが含まれる場合があります。たとえば、個人を特徴付けるデータについて話している場合、電話番号、住所、または電子メールに関する情報の方が更新レートが高いと言えます。フルネーム、パスポートの詳細、婚姻状況または性別。
したがって、衛星を決定するときは、その更新頻度に留意する必要があります。 どうしてそれが重要ですか？
更新頻度が異なる属性を同じテーブルに格納する場合、最も頻繁に変更される属性が更新されるたびにテーブルに行を追加する必要があります。 その結果、ディスク容量が増加し、クエリの実行時間が増加します。
更新頻度によって衛星を分割し、個別にデータをロードできるようになったので、最新のデータを受信できることを確認する必要があります。 不必要な JOIN を使用しない方が良いでしょう。
たとえば、更新レートが異なる衛星から最新の (最終更新日による) 情報を取得する必要があると説明します。 これを行うには、JOIN を作成するだけでなく、最大更新日 MAX (更新日) を選択して、(情報を含む衛星ごとに) 複数のネストされたクエリを作成する必要もあります。 新しい JOIN が追加されるたびに、そのようなコードは増大し、すぐに理解するのが困難になります。
PIT テーブルは、このようなクエリを簡素化するように設計されており、新しいデータを DATA VAULT に書き込むと同時に PIT テーブルが埋められます。 PITテーブル：
したがって、各時点におけるすべての衛星のデータの関連性に関する情報が得られます。 PIT テーブルへの JOIN を使用すると、PIT が毎日隙間なく埋められるという条件で、ネストされたクエリを完全に排除できます。 PIT にギャップがある場合でも、PIT 自体に対するネストされたクエリを XNUMX つ使用するだけで最新のデータを取得できます。 XNUMX つのネストされたクエリは、各サテライトへのネストされたクエリよりも高速に処理されます。
BRIDGE
BRIDGE テーブルは、分析クエリを簡素化するためにも使用されます。 ただし、PIT と異なるのは、さまざまなハブ、リンク、およびそのサテライト間のリクエストを簡素化し、高速化する手段です。
テーブルには、すべての衛星に必要なすべてのキーが含まれており、クエリでよく使用されます。 さらに、分析にキーの名前が必要な場合は、必要に応じて、ハッシュ化されたビジネス キーにテキスト形式のキーを追加できます。
実際には、BRIDGE を使用しない場合、異なるハブに属する衛星にあるデータを受信する過程で、衛星自体だけでなく、ハブを接続するリンクの JOIN も行う必要があります。
BRIDGE の有無は、ストレージ構成とクエリ実行速度の最適化の必要性によって決まります。 BRIGE の普遍的な例を思いつくのは困難です。
事前定義された導出
BUSINESS DATA VAULT にさらに近づける別のタイプのオブジェクトは、事前に計算された指標を含むテーブルです。 このようなテーブルはビジネスにとって非常に重要であり、所定のルールに従って集約された情報が含まれており、比較的簡単にアクセスできます。
アーキテクチャ的には、PREDEFINED DERIVATIONS は、特定のハブの別のサテライトにすぎません。 通常の衛星と同様に、ビジネス キーと衛星内のレコードの作成日が含まれています。 ただし、類似点はここで終わります。 このような「特殊な」衛星の属性のさらなる構成は、最も一般的な、事前に計算された指標に基づいてビジネス ユーザーによって決定されます。
たとえば、従業員に関する情報を含むハブには、次のようなインジケーターを備えたサテライトが含まれる場合があります。
- 最低賃金;
- 最高給与;
- 平均給与。
- 未払賃金等の累計額
同じハブの PIT テーブルに PREDEFINED DERIVATIONS を含めることは論理的です。そうすれば、特定の選択された日付の従業員のデータ スライスを簡単に取得できます。
結論
実践が示すように、ビジネス ユーザーによる DATA VAULT の使用は、次のような理由からやや困難です。
- クエリ コードは複雑で面倒です。
- JOIN の多さはクエリのパフォーマンスに影響します。
- 分析クエリを作成するには、ストレージ設計に関する優れた知識が必要です。
データ アクセスを簡素化するために、DATA VAULT は追加のオブジェクトで拡張されています。
- PIT (時点) テーブル。
- BRIDGE テーブル。
- 事前定義された導出。
次 私の考えでは、BI に携わる人々にとって最も興味深いことを伝えるつもりです。 DATA VAULT に基づいてファクト テーブルとディメンション テーブルを作成する方法を紹介します。
記事の資料は以下に基づいています。
- На Kenta Graziano、詳細な説明に加えて、モデル図が含まれています。
- 書籍: 「DATA VAULT 2.0 を使用したスケーラブルなデータ ウェアハウスの構築」;
- 記事 .
出所： habr.com