DatabricksレイクハウスによるEDWディメンションモデルのリアルタイムのロード

What’s a Dimensional Model and How to Implement It on the Databricks Lakehouse Platform - The Databricks Blogの翻訳です。

本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。

Delta Live Tablesを用いたモダンレイクハウスにおけるディメンションモデリングの実装

ディメンションモデリングは、モダンデータウェアハウスを構築する際に最も人気のあるデータモデリング手法です。お客様は、企業におけるビジネスニーズに基づいて、クイックにファクトとディメンションを開発することができます。現場でお客様を支援する際、我々はお客さまがDatabricksからのベストプラクティスと実装のリファレンスアーキテクチャを求めていることを知りました。

本書では、Databricksのレイクハウスプラットフォームにおけるディメンションモデリングのベストプラクティスと、Delta Live Tablesを用いたリアルタイムのEDWディメンションモデルのロードの実際のサンプルにディープダイブします。

以下に、本記事でカバーするハイレベルのステップを示します。

1. ビジネス課題の定義
2. ディメンションモデルの設計
3. ディメンションモデリングにおけるベストプラクティスと推奨事項
4. Databricksレイクハウスにおけるディメンションモデルの実装
5. まとめ

1. ビジネス課題の定義

ディメンションモデリングはビジネス指向です。常にビジネス課題からスタートします。ビジネス課題がどの様にデータ資産を表現し、エンドユーザーに消費されるのかを示唆するので、ディメンションモデルを構築する前に解決すべきビジネス課題を理解する必要があります。データモデルがよりアクセスしやすく、高速なクエリーをサポートする様に設計する必要があります。

ビジネスマトリクスはディメンションモデリングにおける重要なコンセプトであり、以下にカラムが共有されるディメンションであり行がビジネスプロセスを表現するビジネスマトリクスのサンプルを示します。定義されたビジネス課題は、ファクトデータと必要なディメンションの粒度を決定します。ここでキーとなる考え方は、ビジネスマトリクスと共有され準拠されるディメンションに基づいて、簡単にインクリメンタルに追加のデータ資産を開発できるというものです。

共有されるディメンションとビジネスプロセスを持つビジネスマトリクス

ここでは、ビジネススポンサーがチームに対して以下の洞察を与えるレポートを構築してほしいものとします。

1. 製品の人気を理解するために、最も売れている製品は何か
2. 優れた店舗のプラクティスを学ぶために、最も売上をあげている店舗はどこか

2. ディメンションモデルの設計

定義されたビジネス課題に基づき、データモデルの設計では再利用性、柔軟性、スケーラビリティのためにデータを効率的に表現することを目指します。上述した質問を解決しうるハイレベルのデータモデルを示します。

レイクハウスにおけるディメンションモデル

デザインは理解しやすく、データに対する異なるクエリーパターンに対して効率的であるべきです。我々はモデルからビジネス上の質問に答えるためにsalesファクトテーブルを設計しました。見てわかる様に、ディメンションに対する外部キー(FK)以外には、sales_amountの様なビジネスを計測するための数値メトリクスのみが含まれています。

また、ファクトデータに文脈を与えるために、Product、Store、Customer、Dateのようなディメンションテーブルを設計しました。ディメンションテーブルは通常、特定の月で最も人気のある製品は何か、ある四半期で最もパフォーマンスが良かった店舗はどこかという様な特定のビジネス上の質問に答えるために、ファクトテーブルとjoinされます。

3. ディメンションモデリングのベストプラクティスと推奨事項

Databricksレイクハウスプラットフォームを用いることで、ディメンションモデルを容易にデザイン&実装でき、特定の問題領域でファクトとディメンションを容易に構築することができます。

ディメンションモデルを実装する際に推奨されるベストプラクティスをいくつかを示します。

• ディメンションテーブルを非正規化すべきです。モデルの第三正規形あるいはスノーフレーク型ではなく、通常ディメンションテーブルは単一のディメンションテーブルの中で多対1リレーションシップによってflattenすることで、高度に非正規化されます。

• 異なるディメンションテーブルの属性が同じカラム名やドメインコンテンツを持つ際には、準拠したディメンションを使用してください。この利点は、異なるファクトテーブルからのデータを、それぞれのファクトテーブルと関連づけられた準拠ディメンション属性を用いて、単一のレポートで結合することができるということです。

• ディメンションテーブルにおける通常のトレンドは、as-isあるいはas-wasレポートをサポートするために、ディメンションの経年変化を追跡します。異なる要件に基づいてディメンションをハンドリングするために以下の基本的なテクニックを容易に適用することができます。

  • タイプ1のテクニックでは、ディメンション属性の初期値を上書きします。
  • 最も人気のあるSCDテクニックであるタイプ2のテクニックでは、時間経過と共に追跡される正確な変更点を使用します。

  これらは、Delta Live Tables(DLT)実装を用いることで容易に達成することができます。

  • APPLY CHANGES INTOを用いたDelta Live Tablesによって、容易にSCDタイプ1やSCDタイプ2を実行することができます。

• 主キーと外部キー制約によって、ユーザーはテーブル間のリレーションシップを理解することができます。

• アイデンティティカラムを用いることで、新規行が追加された際にユニークな整数値が自動で生成されます。アイデンティティカラムはサロゲートキーの一形態です。詳細はこちらのブログ記事をご覧ください。

• CHECK制約の強制によって、あなたに這い寄るデータ品質や正確性の問題に心配する必要が無くなります。

4. Databricksレイクハウスにおけるディメンションモデルの実装

それでは、ディメンションモデリング実装に基づくDelta Live Tablesのサンプルを見ていきましょう。

以下のサンプルコードでは、ソースシステムの変更データが捕捉されるSCDタイプ2を用いたディメンションテーブル(dim_store)の作成方法を示しています。

SQL

-- create the gold table
CREATE INCREMENTAL LIVE TABLE dim_store
TBLPROPERTIES ("quality" = "gold")
COMMENT "Slowly Changing Dimension Type 2 for store dimension in the gold layer";

-- store all changes as SCD2
APPLY CHANGES INTO live.dim_store
FROM STREAM(live.silver_store)
  KEYS (store_id)
  SEQUENCE BY updated_date
  COLUMNS * EXCEPT (_rescued_data, input_file_name)
  STORED AS SCD TYPE 2;

以下のコードでは、ロードされたすべてのファクトレーコードに適切な製品が関連づけられることを保証できるvalid_product_idの制約を持つファクトテーブル(fact_sale)の作成方法を示しています。

SQL

-- create the fact table for sales in gold layer
CREATE STREAMING LIVE TABLE fact_sale (
  CONSTRAINT valid_store_business_key EXPECT (store_business_key IS NOT NULL) ON VIOLATION DROP ROW,
  CONSTRAINT valid_product_id EXPECT (product_id IS NOT NULL) ON VIOLATION DROP ROW
) 
TBLPROPERTIES ("quality" = "gold", "ignoreChanges" = "true")
COMMENT "sales fact table in the gold layer" AS
  SELECT
    sale.transaction_id,
    date.date_id,
    customer.customer_id,
    product.product_id AS product_id,
    store.store_id,
    store.business_key AS store_business_key,
    sales_amount
  FROM STREAM(live.silver_sale) sale
  INNER JOIN live.dim_date date
  ON to_date(sale.transaction_date, 'M/d/yy') = to_date(date.date, 'M/d/yyyy') 
  -- only join with the active customers
  INNER JOIN (SELECT * FROM live.dim_customer WHERE __END_AT IS NULL) customer
  ON sale.customer_id = customer.customer_id
  -- only join with the active products
  INNER JOIN (SELECT * FROM live.dim_product WHERE __END_AT IS NULL) product
  ON sale.product = product.SKU
  -- only join with the active stores
  INNER JOIN (SELECT * FROM live.dim_store WHERE __END_AT IS NULL) store
  ON sale.store = store.business_key

Delta Live Tablesパイプラインのサンプルはこちらから参照できます。Delta Live Tablesパイプラインの作成方法に関しては、Delta Live Tablesクイックスタートを参照ください。以下に示しているように、DLTは、ETLパイプラインとレイクハウスのメダリオンアーキテクチャに従ったブロンズ、シルバー、ゴールドレイヤーにまたがる様々なオブジェクト間の依存関係に対する完全な可視性を提供します。

エンドツーエンドのDLTパイプライン

以下に、投入される変更に基づいてディメンションテーブルdim_storeがどのようにアップデートされるのかを示しています。以下では、店舗Brisbane AirportがBrisbane Airport V2にアップデートされ、元々のレコードは2022/1/7に終了し、同じ日にスタートし、オープンの終了日(NULL)を持つ新規レコードが作成されており、これはBrisbane airportの最新レコードであることを示しています。

Storeディメンションに対するSCDタイプ2

5. まとめ

本書では、ディメンションモデリングのコンセプトの詳細、ベストプラクティス、Delta Live Tablesを用いた実装方法を学びました。

ディメンションモデリングの詳細に関しては、Kimball Technologyをご覧ください。

レイクハウスでディメンションモデルの構築を始める

Databricks 14日間無料トライアル