Safie Engineers' Blog!

Safieのエンジニアが書くブログです

DataVaultモデリングで遭遇した課題とその解決策

データ分析

​データ分析基盤グループでデータエンジニアをしている平川です。 DataVaultに関する記事の第3回目となります。 第3回の記事は、DataVaultモデリングをしている際に困った状態の対処方法についてまとめていきます

第1回: DataVaultってなに？どんな特徴があるの?

第2回: automate_dvを使ってDataVaultモデリングの中心となるテーブルを作ってみてわかったこと　

第3回: BusinessVault、発展的なSatelliteテーブルやキーがNullだった場合の対処方法についてなど ← 今回はここ　

前回のおさらい

前回は、DataVaultモデリングの実装を簡易化するパッケージであるautomate_dvの紹介をさせていただきました。
特にDataVaultモデリングの中心となるHub/Link/Satelliteの生成について紹介させていただきました。

はじめに

今回の記事では、以下3つのトピックについて紹介させていただきます。

  • Hub/Link/Satelliteを利用する際に出くわす課題への対処法の1つとしてBusinessVaultについて
  • 通常のSatelliteに追加機能を持たせたStatusTrackingSatelliteとEffectivitySatelliteについて
  • ソーステーブルのキーの欠損などに対応するゼロキーやゴーストレコードについて

BusinessVaultとは

BusinessVaultとはRawVaultのデータを使いやすく整理し、特定のビジネスルールや変換処理を適用したモデルです。
この層は、RawVault層とユーザーが直接アクセスする層の間に位置しています。
このモデルを作るメリット・デメリットはいくつかあります。

  • メリット

    • ビジネスロジックやデータ変換ルールを集約することで、Rawデータをルールに従った形で整理できます。これにより、分析が容易になることが考えられます。
    • 多数のJOINや複雑な条件を含むクエリを事前に処理することで、パフォーマンス面での向上が見込めます

  • デメリット

    • BusinessVaultを生成する際にしばしば非正規化をするのでデータが冗長になります
    • 適用するビジネスルールが頻繁に変わる場合、管理が困難になる可能性があります

StatusTrackingSatellite, EffectivitySatelliteの紹介

Status Tracking Satelliteとは

StatusTrackingSatelliteは、CDCが作用しない場合のデータの状態を追跡・管理する際にとても役に立ちます。
データソースでCDCが作用しない場合、ステータスの追跡が重要となり、ステータスの追跡をしない場合、いつレコードが消えたのかをSatelliteで把握するのは非常に困難です。
CDCが作用しない場合にはこのテーブルは非常に有用ですが、StatusTrackingSatelliteから必要なデータを取得するのは通常のSatelliteと比べるとSQLが複雑になります。

Status Tracking Satelliteのテーブル構造

Satelliteのテーブル構造とほぼ一緒ですが、record_statusというカラムを追加します。このカラムは名前の通りですが、レコードの状態を表し以下の3つのステータスを持ちます。

  • 挿入("I"): 新しく追加されるレコードはrecord_status = 'I'としてレコードが追加されます。
  • 更新("U"): 既存のレコードの属性情報が変わった際は、record_status = 'U'のレコードが追加されます
  • 削除("D"): Satelliteテーブルには存在して、データソースに存在しないレコードには、record_status = 'D'としてレコードが追加されます

Effectivity Satelliteとは

Effectivity Satelliteはビジネスキー間の開始日と終了日を保持することで、有効期間を追跡することが可能になります。

Effectivity Satelliteの構造

StatusTrackingSatellite同様に、Satelliteテーブルが持つ基本的なカラムを持ちます。
Effectivity Satelliteには、開始日と終了日が追加されます。(automate-dvのeff_satではEFFECTIVE_FROMも追加されるようです)
それぞれのカラムには以下のような値を格納します。
- 開始日: ビジネスキー間の関係性が開始した日付。 - 終了日: ビジネスキー間の関係性が終了した日付。関係性が続いている場合は、9999-12-31のように未来日が格納される。

StatusTrackingSatelliteとEffectivity Satelliteの使い分け

  • データソースからレコードが削除された場合も、終了日を取っていれば対応できますが、StatusTrackingSatelliteとEffectivitySatelliteの違いは、追跡する対象が異なる点にあります。
    • 前者はデータ自体の時間変化を追跡しますが、後者はビジネスキー同士の関係の有効期間を追跡します。
  • 期間に関するデータを保持したい際には、EffectivitySatelliteが有用であると言えます。
    • 例えば、EffectivitySatelliteを活用してキャンペーン情報と製品情報の関係性を保持することにより、売上情報との組み合わせで特定のキャンペーンがどのような影響を与えていたかを期間を絞って分析することが可能になります。
  • Effectivity Satelliteは終了日を更新する必要があるため、頻繁に終了日に値が入る場合はその都度updateされることになります。
  • 両者で共通しているのは、データを抽出する際のクエリが複雑になる点です。(期間の指定やrecord_statusの絞り込みが必要になります)

ゴーストレコード、ヌルキーとゼロキー

ゴーストレコードとは

データ(レコード)が存在しない場合に利用される仮のレコードです。このレコードを追加することで、各種モデルを結合するときのクエリを単純化することが可能になります。

ゼロキー(≒ ヌルキー)とは

ビジネスキーが不明瞭であったり、欠落している場合に用いられる概念です。このキーを導入することで、データの品質を理解する手助けをし、品質改善の対策をする際に用いることが可能になります。
また、ゼロキーの概念を取り入れていない場合もしくはautomate-dvを使用してハッシュ化している場合、ハッシュ化したキーの値がnullになります。

これらの概念を取り入れるメリット

データボルトモデリングをしているデータレイヤーの整合性や一貫性を保つことができます。
特にキーに欠落が発生する場合はゼロキーの概念を取り入れるべきだと思います。
ゴーストレコードについては、一時的にレコードが生成されていないという状況(例えば不具合等でデータが遅れて連携されるなど)であれば導入しなくても良いかなと思います。

まとめ

今回の記事では、DataVaultモデリングをする際に特定の場面で有効である概念の紹介をさせていただきました。
今回紹介したSatelliteを派生させたものや、キーなどがゴーストレコード、ゼロキー等である場合の対処方法は登場頻度は少ないかもしれないですが、データソースの状態や構造を直接的に変更することは難しいので、そのような時にこれらの概念を適用することでDataVaultモデリングの整合性を保ったままモデリングをすることが可能になります。

参考資料

© Safie Inc.