本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
我々のお客さまの大多数が、自身のレガシーなデータウェアハウスをDatabricksレイクハウスに移行しています。これは、彼らのデータウェアハウスを近代化するだけではなく、成熟したストリーミングと高度な分析プラットフォームへのアクセスを即座に提供するためです。レイクハウスはストリーミング、ETL、BI、AIの要件のすべてに答えることで、これを達成し、皆様の企業におけるビジネス部門とデータチームが一つのプラットフォーム上でコラボレーションするサポートをします。
現場のお客さまの支援をしている中で、我々は多くのお客様が適切なデータモデリングやDatabricksにおける物理データモデル実装に関するベストプラクティスを探していることを知りました。
本書では、Databricksレイクハウスプラットフォームにおけるディメンションモデリングのベストプラクティスにディープダイブし、我々のテーブル作成とDDLのベストプラクティスを用いた物理モデル実装の実際のサンプルを提供することを狙いとしています。
この記事でカバーするハイレベルのトピックを以下に示します。
- データモデリングの重要性
- 一般的なデータモデリングのテクニック
- データウェアハウスのモデリングDDL実装
- Databricksレイクハウスにおけるデータモデリングのベストプラクティスと推奨事項
データウェアハウスにおけるデータモデリングの重要性
データモデルはデータウェアハウス構築におけるフロントと中心を担っています。通常、このプロセスはセマンティックなビジネス情報モデルからスタートし、論理データモデル、そして最後には物理データモデル(PDM)となります。すべては、ビジネス情報モデルとプロセスフローが最初に作成され、企業内のビジネスプロセスと同じ様に、キーとなるビジネスエンティティ、属性、それらのインタラクションがキャプチャされる適切なシステム分析と設計フェーズからスタートします。そして、エンティティが互いにどの様に関係するのかを示す論理データモデルが作成されますが、これは特定の技術に依存しないモデルとなります。最後に、背後の技術プラットフォームに基づいて、データの読み書きが効率的に行われることを保証するために、PDMが作成されます。我々はみんな知っていますが、データウェアハウスにおいては、スタースキーマやデータボルトのような分析フレンドリーなモデリングスタイルが非常に人気があります。
Databricksにおける物理データモデル作成のベストプラクティス
定義されたビジネス問題に基づき、データモデル設計の狙いは再利用可能性、柔軟性、スケーラビリティにおいて容易な方法でデータを表現することとなります。以下に、それぞれのトランザクションを保持するSalesファクトテーブルと、データをスライスアンドダイスするための顧客、商品、店舗、日付のような様々なディメンションテーブルを示す典型的なスタースキーマデータモデルを示します。特定の月において最も人気のある商品は何か、ある四半期で最もパフォーマンスが優れている店舗はどれかと言う様な特定のビジネス上の質問に答えるために、ディメンションがファクトテーブルとjoinすることができます。これらがDatabricksでどの様で実装されているのかを見ていきましょう。
レイクハウスにおけるディメンションモデル
DatabricksにおけるデータウェアハウスモデリングDDLの実装
以下のセクションでは、サンプルを用いて以下のことをデモンストレーションしていきます。
- 3レベルのカタログ、データベース、テーブルの作成
- 主キー、外部キーの定義
- サロゲートキーのためのアイデンティティカラム
- データ品質のためのカラム制約
- インデックス、最適化、解析
- 高度なテクニック
1. Unity Catalog - 3レベルの名前空間
Unity Catalogは一つのメタストアを用いて、Databricks管理者やデータスチュワードがDatabricksアカウント内のすべてのワークスペースに対して、ユーザーとデータアクセスを集中管理することを可能にする、Databricksのガバナンスレイヤーです。異なるワークスペースのユーザーは、Unity Catalogによって集中的に許可される権限に基づいて、同じデータに対するアクセスを共有することができます。Unity Catalogにはデータを整理するための3レベルの名前空間(catalog.shema(database).table)があります。Unity Catalogの詳細に関してはこちらをご覧ください。
データベースにテーブルを作成する前にどのようにカタログとスキーマをセットアップするのかを以下に示します。我々の例では、以下の様にカタログUS_Storesとスキーマ(データベース)Sales_DWを作成し、セクションの後半でこれらを使用します。
カタログとデータベースのセットアップ
以下に、3レベルの名前空間を用いてfact_salesにクエリーするサンプルを示します。
catalog.database.tablenameによるテーブルクエリーのサンプル
2. 主キー、外部キーの定義
データモデルを作成する際には、主キーと外部キーの定義は非常に重要となります。PK/FK定義をサポートする能力を持つことで、Databricksにおけるデータモデルの定義が非常に簡単になります。また、アナリストが効率的にクエリーを記述するために、Databricks SQLウェアハウスでjoinの関係をクイックに明らかにする役にも立ちます。多くの他のMassively Parallel Processing (MPP)、EDW、クラウドデータウェアハウスのように、PK/FK製薬は情報を提供するためだけのものです。Databricksでは、PK/FKリレーションシップの矯正をサポートしていませんが、セマンティックデータモデルの設計を容易にするために定義することが可能です。
アイデンティティカラムであると同時に主キーであるstore_idを持つdim_storeを作成する例を以下に示します。
主キー定義を持つstoreディメンションを作成するためのDDL実装
テーブルを作成すると、以下の様にテーブル定義の制約として主キー(store_id)が作成されていることを確認することができます。
テーブル制約として表示される主キーstore_id
主キーとしてのtransaction_idを持つfact_salesとディメンションテーブルを参照する外部キーを作成する例を以下に示します。
外部キー定義を持つsales factテーブルの作成のためのDDL実装
ファクトテーブルを作成すると、以下の様にテーブル定義の制約として主キー (transaction_id) と外部キーが作成されていることを確認することができます。
主キーとディメンションを参照する外部キーを持つファクトテーブル定義
3. サロゲートキーのためのアイデンティティキー
アイデンティティカラムは、データの新規の行のそれぞれにユニークなID番号を自動で生成するデータセット内のカラムです。通常これらはデータウェアハウスでサロゲートキーとして使用されます。サロゲートキーは、行のユニーク性を特定するために、自然な主キーや複数フィールドを結合したものに頼ることがない様に、システムが生成する無意味なキーです。通常、これらのサロゲートキーは、データウェアハウスで主キーや外部キーとして使用されます。アイデンティティカラムの詳細はこちらの記事で議論されています。以下に、1から始まる値が自動で割り当て、1づつ増えていくアイデンティティカラムであるcustomer_idの作成例を示します。
アイデンティティカラムを持つcustomerディメンションの作成におけるDDL実装
4. データ品質のためのカラム制約
主キーや外部キーの情報提供を目的とした制約に加え、Databricksではテーブルに追加されるデータの品質や統一性を保証するために強制される、カラムレベルのデータ品質チェック制約もサポートしています。これらの制約は自動で検証されます。これらの良い例はNOT NULL制約とカラム値の制約です。他のクラウドデータウェアハウスと異なり、特定のカラムのデータ品質を保証するために、カラム値チェックよりも先に進んだ機能を提供しています。以下に示している様に、valid_sales_amountチェック制約は、テーブルにデータを追加する前にすべての既存の行が制約(例: sales amount > 0)を満たしていることを検証します。詳細な情報はこちらから確認できます。
以下に、store_idとsales_amountが適切な値を持つことを保証するように、dim_storeとfact_salesに制約を追加する例を示しています。
データ品質を保証するために既存テーブルにカラム制約を追加
5. インデックス、最適化、解析
従来型のデータベースはb-treeとbitmapインデックスを持っていますが、Databricksはインデックスのより先進的な形態である、多次元Z-orderクラスターインデックスをサポートしており、Bloomフィルターインデックスもサポートしています。まず初めに、Deltaファイルフォーマットは、列指向圧縮ファイルフォーマットであるParquetファイルフォーマットを使用しており、カラムの刈り込みがすでに非常に効率的なものであり、z-orderインデックスを用いることで、ペタバイト規模のデータを数秒でスキャンすることができます。Z-orderとBloomフィルターインデックスの両方を用いることで、大規模なDeltaテーブルに対して高度に選択的なクエリーに答えるためにスキャンする必要があるデータの量を劇的に削減することができ、通常は数桁の実行時間の改善やコスト削減につながります。よく使われるjoinで使用される主キーと外部キーにZ-orderを使う様にしてください。また、必要に応じてBloomフィルターインデックスを使ってください。
パフォーマンス改善のために、fact_salesのcustomer_idとproduct_idを最適化
特定カラムのデータスキッピングを実現するためにBloomフィルターインデックスを作成
そして、他のデータウェアハウスと同じ様に、ベストなクエリープランを作成するためにクエリーオプティマイザがベストな統計情報を持てる様に、統計情報をアップデートするためにANALYZE TABLEを行うことができます。
優れたクエリー実行計画のためにすべてのカラムの統計情報を収集
6. 高度なテクニック
Databricksではテーブルパーティショニングのような高度なテクニックをサポートしていますが、これらの機能は必要な場合にのみ、大量のテラバイトの圧縮データを持っている場合にのみ使用してください。これは、多くの場合、OPTIMIZEやZ-ORDERインデックスがベストなファイルを提供し、日付や月によるテーブルのパーティショニングがバッドプラクティスになるためです。しかし、お使いのDDLで自動最適化や自動コンパクションを設定する雇用にすることは良いプラクティスと言えます。これらを用いることで、小さなファイルに頻繁に書き込まれるデータは、Deltaのより大きな列指向圧縮フォーマットにまとめられる様になります。
ビジュアルなデータモデリングツールを活用したいと考えていますか？リバースエンジアリング、スタースキーマ、データボルトやその他の業界データモデルを作成するために、我々のパートナーであるQuest Erwinを用いることで、数クリックでDatabricks上でこれらを行うことが可能となります。
Databricksサンプルノートブック
Databricksプラットフォームを用いることで、簡単に様々なデータモデルを設計、実装することができます。完全なワークフローの中で上述したすべての例を見るには、こちらのサンプルをご覧ください。
また、関連記事であるDelta Lakeを用いてDatabricksでスタースキーマを実装する5つのシンプルなステップもチェックしてみてください。
レイクハウスでディメンションモデルの構築に着手する
14日間のDatabricksフリートライアルを試してみてください。