モダンレイクハウスにおけるディメンションモデリングのベストプラクティスと実装

[What’s a Dimensional Model and How to Implement It on the Databricks Lakehouse Platform \- The Databricks Blog](https://www.databricks.com/blog/2022/10/20/dimensional-modeling-best-practice-implementation-modern-lakehouse.html)の翻訳です。

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

我々のお客さまの大多数が、自身のレガシーなデータウェアハウスをDatabricksレイクハウスに移行しています。これは、彼らのデータウェアハウスを近代化するだけではなく、成熟したストリーミングと高度な分析プラットフォームへのアクセスを即座に提供するためです。レイクハウスはストリーミング、ETL、BI、AIの要件のすべてに答えることで、これを達成し、皆様の企業におけるビジネス部門とデータチームが一つのプラットフォーム上でコラボレーションするサポートをします。

現場のお客さまの支援をしている中で、我々は多くのお客様が適切なデータモデリングやDatabricksにおける物理データモデル実装に関するベストプラクティスを探していることを知りました。

本書では、Databricksレイクハウスプラットフォームにおけるディメンションモデリングのベストプラクティスにディープダイブし、我々のテーブル作成とDDLのベストプラクティスを用いた物理モデル実装の実際のサンプルを提供することを狙いとしています。

この記事でカバーするハイレベルのトピックを以下に示します。

1. データモデリングの重要性
1. 一般的なデータモデリングのテクニック
1. データウェアハウスのモデリングDDL実装
1. Databricksレイクハウスにおけるデータモデリングのベストプラクティスと推奨事項

# データウェアハウスにおけるデータモデリングの重要性

データモデルはデータウェアハウス構築におけるフロントと中心を担っています。通常、このプロセスはセマンティックなビジネス情報モデルからスタートし、論理データモデル、そして最後には物理データモデル(PDM)となります。すべては、ビジネス情報モデルとプロセスフローが最初に作成され、企業内のビジネスプロセスと同じ様に、キーとなるビジネスエンティティ、属性、それらのインタラクションがキャプチャされる適切なシステム分析と設計フェーズからスタートします。そして、エンティティが互いにどの様に関係するのかを示す論理データモデルが作成されますが、これは特定の技術に依存しないモデルとなります。最後に、背後の技術プラットフォームに基づいて、データの読み書きが効率的に行われることを保証するために、PDMが作成されます。我々はみんな知っていますが、データウェアハウスにおいては、[スタースキーマ](https://en.wikipedia.org/wiki/Star_schema)や[データボルト](https://en.wikipedia.org/wiki/Data_vault_modeling)のような分析フレンドリーなモデリングスタイルが非常に人気があります。

# Databricksにおける物理データモデル作成のベストプラクティス

定義されたビジネス問題に基づき、データモデル設計の狙いは再利用可能性、柔軟性、スケーラビリティにおいて容易な方法でデータを表現することとなります。以下に、それぞれのトランザクションを保持する`Sales`ファクトテーブルと、データをスライスアンドダイスするための顧客、商品、店舗、日付のような様々なディメンションテーブルを示す典型的なスタースキーマデータモデルを示します。特定の月において最も人気のある商品は何か、ある四半期で最もパフォーマンスが優れている店舗はどれかと言う様な特定のビジネス上の質問に答えるために、ディメンションがファクトテーブルとjoinすることができます。これらがDatabricksでどの様で実装されているのかを見ていきましょう。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-1.png)
*レイクハウスにおけるディメンションモデル*

# DatabricksにおけるデータウェアハウスモデリングDDLの実装

以下のセクションでは、サンプルを用いて以下のことをデモンストレーションしていきます。

- 3レベルのカタログ、データベース、テーブルの作成
- 主キー、外部キーの定義
- サロゲートキーのためのアイデンティティカラム
- データ品質のためのカラム制約
- インデックス、最適化、解析
- 高度なテクニック

## 1. Unity Catalog - 3レベルの名前空間

Unity Catalogは一つのメタストアを用いて、Databricks管理者やデータスチュワードがDatabricksアカウント内のすべてのワークスペースに対して、ユーザーとデータアクセスを集中管理することを可能にする、Databricksのガバナンスレイヤーです。異なるワークスペースのユーザーは、Unity Catalogによって集中的に許可される権限に基づいて、同じデータに対するアクセスを共有することができます。Unity Catalogにはデータを整理するための3レベルの名前空間(`catalog.shema(database).table`)があります。Unity Catalogの詳細に関しては[こちら](https://qiita.com/taka_yayoi/items/15aede468bdca58ec6a3)をご覧ください。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-2.png)
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-3.png)

データベースにテーブルを作成する前にどのようにカタログとスキーマをセットアップするのかを以下に示します。我々の例では、以下の様にカタログ**US_Stores**とスキーマ(データベース)**Sales_DW**を作成し、セクションの後半でこれらを使用します。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-4.png)
*カタログとデータベースのセットアップ*

以下に、3レベルの名前空間を用いて**fact_sales**にクエリーするサンプルを示します。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-5.png)
*catalog.database.tablenameによるテーブルクエリーのサンプル*

## 2. 主キー、外部キーの定義

データモデルを作成する際には、主キーと外部キーの定義は非常に重要となります。PK/FK定義をサポートする能力を持つことで、Databricksにおけるデータモデルの定義が非常に簡単になります。また、アナリストが効率的にクエリーを記述するために、Databricks SQLウェアハウスでjoinの関係をクイックに明らかにする役にも立ちます。多くの他のMassively Parallel Processing (MPP)、EDW、クラウドデータウェアハウスのように、PK/FK製薬は情報を提供するためだけのものです。Databricksでは、PK/FKリレーションシップの矯正をサポートしていませんが、セマンティックデータモデルの設計を容易にするために定義することが可能です。

アイデンティティカラムであると同時に主キーである**store_id**を持つ**dim_store**を作成する例を以下に示します。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-6.png)
*主キー定義を持つstoreディメンションを作成するためのDDL実装*

テーブルを作成すると、以下の様にテーブル定義の制約として主キー(store_id)が作成されていることを確認することができます。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-7.png)
*テーブル制約として表示される主キーstore_id*

主キーとしての**transaction_id**を持つ**fact_sales**とディメンションテーブルを参照する外部キーを作成する例を以下に示します。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-8.png)
*外部キー定義を持つsales factテーブルの作成のためのDDL実装*

ファクトテーブルを作成すると、以下の様にテーブル定義の制約として主キー **(transaction_id)** と外部キーが作成されていることを確認することができます。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-9.png)
*主キーとディメンションを参照する外部キーを持つファクトテーブル定義*

## 3. サロゲートキーのためのアイデンティティキー

**アイデンティティカラム**は、データの新規の行のそれぞれにユニークなID番号を自動で生成するデータセット内のカラムです。通常これらはデータウェアハウスでサロゲートキーとして使用されます。サロゲートキーは、行のユニーク性を特定するために、自然な主キーや複数フィールドを結合したものに頼ることがない様に、システムが生成する無意味なキーです。通常、これらのサロゲートキーは、データウェアハウスで主キーや外部キーとして使用されます。アイデンティティカラムの詳細は[こちらの記事](https://qiita.com/taka_yayoi/items/f4076d1be4ffe017564f)で議論されています。以下に、1から始まる値が自動で割り当て、1づつ増えていくアイデンティティカラムである`customer_id`の作成例を示します。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-10.png)
*アイデンティティカラムを持つcustomerディメンションの作成におけるDDL実装*

## 4. データ品質のためのカラム制約

主キーや外部キーの情報提供を目的とした制約に加え、Databricksではテーブルに追加されるデータの品質や統一性を保証するために強制される、カラムレベルのデータ品質チェック制約もサポートしています。これらの制約は自動で検証されます。これらの良い例は`NOT NULL`制約とカラム値の制約です。他のクラウドデータウェアハウスと異なり、特定のカラムのデータ品質を保証するために、カラム値チェックよりも先に進んだ機能を提供しています。以下に示している様に、**valid_sales_amount**チェック制約は、テーブルにデータを追加する前にすべての既存の行が制約(例: **sales amount > 0**)を満たしていることを検証します。詳細な情報は[こちら](https://docs.databricks.com/tables/constraints.html)から確認できます。

以下に、**store_id**と**sales_amount**が適切な値を持つことを保証するように、**dim_store**と**fact_sales**に制約を追加する例を示しています。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-11.png)
*データ品質を保証するために既存テーブルにカラム制約を追加*

## 5. インデックス、最適化、解析

従来型のデータベースはb-treeとbitmapインデックスを持っていますが、Databricksはインデックスのより先進的な形態である、多次元Z-orderクラスターインデックスをサポートしており、Bloomフィルターインデックスもサポートしています。まず初めに、Deltaファイルフォーマットは、列指向圧縮ファイルフォーマットであるParquetファイルフォーマットを使用しており、カラムの刈り込みがすでに非常に効率的なものであり、z-orderインデックスを用いることで、ペタバイト規模のデータを数秒でスキャンすることができます。[Z-order](https://qiita.com/taka_yayoi/items/4bd090229b5b13a533f5)と[Bloomフィルターインデックス](https://qiita.com/taka_yayoi/items/76c6fe647d334d9650b6)の両方を用いることで、大規模なDeltaテーブルに対して高度に選択的なクエリーに答えるためにスキャンする必要があるデータの量を劇的に削減することができ、通常は数桁の実行時間の改善やコスト削減につながります。よく使われるjoinで使用される主キーと外部キーにZ-orderを使う様にしてください。また、必要に応じてBloomフィルターインデックスを使ってください。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-12.png)
*パフォーマンス改善のために、fact_salesのcustomer_idとproduct_idを最適化*

![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-13.png)
*特定カラムのデータスキッピングを実現するためにBloomフィルターインデックスを作成*

そして、他のデータウェアハウスと同じ様に、ベストなクエリープランを作成するためにクエリーオプティマイザがベストな統計情報を持てる様に、統計情報をアップデートするために[ANALYZE TABLE](https://docs.databricks.com/sql/language-manual/sql-ref-syntax-aux-analyze-table.html)を行うことができます。
![](https://cms.databricks.com/sites/default/files/inline-images/db-387-blog-img-14.png)
*優れたクエリー実行計画のためにすべてのカラムの統計情報を収集*

## 6. 高度なテクニック

Databricksでは[テーブルパーティショニング](https://qiita.com/taka_yayoi/items/f5a4219ae9ef0d82ad0d)のような高度なテクニックをサポートしていますが、これらの機能は必要な場合にのみ、大量のテラバイトの圧縮データを持っている場合にのみ使用してください。これは、多くの場合、OPTIMIZEやZ-ORDERインデックスがベストなファイルを提供し、日付や月によるテーブルのパーティショニングがバッドプラクティスになるためです。しかし、お使いのDDLで[自動最適化や自動コンパクション](https://qiita.com/taka_yayoi/items/240590bf16f03085157f)を設定する雇用にすることは良いプラクティスと言えます。これらを用いることで、小さなファイルに頻繁に書き込まれるデータは、Deltaのより大きな列指向圧縮フォーマットにまとめられる様になります。

ビジュアルなデータモデリングツールを活用したいと考えていますか？リバースエンジアリング、スタースキーマ、データボルトやその他の業界データモデルを作成するために、我々のパートナーである[**Quest Erwin**](https://bookshelf.erwin.com/bookshelf/public_html/2021R2/Content/User%20Guides/erwin%20Help/Databricks_Support_Summary.html?Highlight=databricks)を用いることで、数クリックでDatabricks上でこれらを行うことが可能となります。

## Databricksサンプルノートブック

Databricksプラットフォームを用いることで、簡単に様々なデータモデルを設計、実装することができます。完全なワークフローの中で上述したすべての例を見るには、[こちらのサンプル](https://github.com/dbsys21/databricks-lakehouse/blob/main/lakehouse-buildout/dimensional-modeling/Dimensional-Model-DDL.sql)をご覧ください。

また、関連記事である[Delta Lakeを用いてDatabricksでスタースキーマを実装する5つのシンプルなステップ](https://qiita.com/taka_yayoi/items/f644b9c6d01feb853ab1)もチェックしてみてください。

# レイクハウスでディメンションモデルの構築に着手する

[14日間のDatabricksフリートライアルを試してみてください](https://databricks.com/jp/try-databricks)。



### Databricks 無料トライアル

[Databricks 無料トライアル](https://databricks.com/jp/try-databricks)