Databricks SQLを使用したディメンショナルデータウェアハウスの実装：パート1

ますます多くの組織がデータウェアハウスのワークロードをDatabricksに移行しています。このプラットフォームの柔軟性とクエリ実行エンジンへの大幅な改善により、Databricksはデータウェアハウスのクエリパフォーマンスとコストパフォーマンスの世界記録を設定し、分析インフラの統合においてますます魅力的な選択肢となっています。

これらの取り組みを支援するために、以前にDatabricksがさまざまなデータウェアハウス設計アプローチをどのようにサポートしているかについてブログで紹介しました。このブログシリーズでは、データウェアハウジングの最も人気のあるアプローチの1つである、スタースキーマとスノーフレークスキーマに特徴付けられる次元（ディメンショナル）モデリング、つまり設計パターンについて詳しく見ていきたいと思います。そして、このアプローチを支援するために広く採用されている標準化された抽出、変換、ロード（ETL）パターンについて深く掘り下げます。

次元モデリングは、クエリパフォーマンスを高速化するためにデータストレージを最適化します。データを事実（ファクト）と次元（ディメンション）に構造化することで、データを複数の視点から簡単に分析することができます。また、データを同時に複数の角度から探索する（多次元分析）ことも可能になります。

このアプローチを広く次元モデリングコミュニティに普及させるために、私たちはこのモデリングアプローチに関連する古典的なパターンに密接に従います。この情報は、以下のブログ投稿で広められます：

• パート1：（次元）データオブジェクトの定義（この投稿）
• パート2：ディメンショナルETLワークフローの構築
• パート3：ファクトETLワークフローの構築（近日公開）

さらに、ここでは、Microsoftが作成したサンプルデータベースであり、データウェアハウスとビジネスインテリジェンスのトレーニング目的で広く使用されているAdventureWorksDWデータベースでよく使用されるスタースキーマの1つ（図1）を中心に設計について説明します。

 

物理モデル

Databricksプラットフォーム内では、ファクトとディメンションは物理的なテーブルとして実装されています。これらはカタログという、データベースに似たものの中に組織化されていますが、プラットフォームがサポートする情報資産の幅に対してより大きな柔軟性を持っています。カタログはその後、スキーマに分割され、カタログ内のオブジェクトのサブセット周りに論理的かつセキュリティの境界を作り出します（図2）。

 

ディメンション表

ディメンションテーブルは、比較的厳格な構造パターンに従います。一般的に、ファクトテーブルとディメンションとの間の安定した効率的なリンクをサポートするために、代理キーという連続した識別子が定義されます。運用システムからの一意の識別子（通常は自然キーまたはビジネスキーと呼ばれる）と、関連するビジネス属性の非正規化されたコレクションが続きます。識別子の背後には、通常、継続的なETLプロセスをサポートするための一連のメタデータ列が存在します。Databricksプラットフォーム内では、次のようにしてディメンションテーブルを実装できます。CREATE TABLE文を使用して、ここでは顧客ディメンションを示しています。

 

ID列

この例では、代理キー CustomerKey 列に対して、私たちはID列を使用して、行を挿入するたびにフィールドに対して連続したBIGINT値を自動的に生成します。ID列にALWAYSオプションまたはBY DEFAULTオプションを使用するかどうかは、このフィールドに対して独自の値を挿入することを禁止するか許可するかによって決まります。

 

メンバーエントリがありません

ディメンションテーブルで実装される一般的なパターンは、欠損メンバーエントリーを作成することです。このエントリーは、ファクトレコードがディメンションへのリンクが欠落または不明な状況で使用され、ここに示されているようにBY DEFAULTオプションが使用されると、予め決定された代理キー値で作成できます：

 

識別フィールド

ベストプラクティスとして、識別フィールドに値を挿入する際は、ALTER TABLE文を使用してSYNC IDENTITYオプションを適用し、識別フィールドのメタデータが更新されるようにすることが最善です。

 

データの種類

ソースシステムのデータに関連するビジネス/自然キーと他のフィールドについては、ソースシステムのデータ型をDatabricksプラットフォーム（表1）がサポートするデータ型に合わせる必要があります。メタデータフィールドでビット値が使用される場合、0または1のようなリテラルの処理を少し簡単にするために、BOOLEANまたはTINYINTデータ型の代わりにINTデータ型を使用することがよくあります。

表1：Databricksプラットフォームがサポートするデータ型

ファクトテーブル

ファクトテーブルもまた、その構造的な規則に従います。主にメジャーと関連するディメンションへの外部キー参照から構成されるファクトテーブルには、トランザクションレコードの一意の識別子（またはファクトレコードとほぼ1対1の関係にある他の記述的属性）も含まれることがあり、これらは縮退ディメンションと呼ばれます。また、ソースシステムからのデータの増分ロード（別名デルタ抽出）をサポートするためのメタデータフィールドも含むことがあります。Databricksプラットフォーム内では、以下に示すようなインターネット販売ファクトの場合と同様に、CREATE TABLE文を使用してファクトテーブルを実装することがあります。

 

外部キー参照

前のセクションでディメンションテーブルについて述べたように、Databricks環境のデータ型はソースシステムで使用されるものに対して緩やかにマッピングされます。ファクトテーブルとディメンションテーブルの間の外部キー参照も、以下に示すようにALTER TABLE文を使用して明示的に行うことができます。

注：外部キー制約をCREATE TABLE文の一部として定義することを好む場合は、カンマで区切られたFOREIGN KEY節のリスト（形式は FOREIGN KEY (foreign_key) REFERENCES table_name (primary_key)  を列定義リストの直後に追加することができます。

メタデータとその他の考慮事項

ディメンションモデルのメリットは、ビジネスアナリストにとっての相対的なアクセシビリティです。このことを念頭に置いて、多くの組織はファクトとディメンションの命名規則を採用し、上記の例のようなFactとDimの接頭辞を使用し、テーブルやフィールドの長く、自己説明的な名前を使用することを推奨しています。これらの名前は、運用ソースシステムで使用される名前から大きく逸脱することがよくあります。

これを念頭に置いて、Databricksのオブジェクト命名に関する制限事項を注意深く確認することが重要です。これには以下のようなものが含まれます：

• オブジェクト名は255文字を超えることはできません
• 次の特殊文字は使用できません：
  • ピリオド (.)
  • スペース ( )
  • スラッシュ (/)
  • すべてのASCII制御文字（16進数 00-1F）
  • DELETE文字（16進数 7F）

さらに、オブジェクト名は大文字と小文字を区別せず、実際にはメタデータリポジトリにすべて小文字で保存されます。これがオブジェクトの可読性に問題を生じさせる可能性がある場合は、一部のオブジェクト名の可読性を向上させるためにスネークケースの規則を採用することを検討することがあります。

命名規則に関係なく、データウェアハウス内のすべてのオブジェクトとフィールドに対して説明的なコメントを定義することは良い考えです。これは、テーブルオブジェクトに対してはCOMMENT ON文を使用し、個々のフィールドに対してはALTER TABLE文を使用して行うことができます。以下に示すように：

これらと他のメタデータ（リネージ情報を含む）は、Databricksカタログエクスプローラーユーザーインターフェース（図3）および各カタログ内の組み込みインフォーメーションスキーマのオブジェクトを通じてアクセスできます。

最後に、このブログでは、ディメンション設計原則に従う観点からのファクトテーブルとディメンションテーブルの作成について説明しています。パフォーマンスとメンテナンスの最適化を考慮したテーブル定義の追加オプションを探求したい場合は、このブログをご覧ください。スタースキーマパフォーマンスの最適化について説明しています。

 

次のステップ：ディメンションテーブルETLの実装

ファクトテーブルとディメンションテーブルの作成に関する基本を解説した後、次のブログでは、ディメンションテーブルをサポートするETLパターンの実装に焦点を当てます。特に、PythonとSQLを使用したType-1およびType-2の緩やかに変化するディメンション（SCD）パターンに重点を置きます。

Databricks SQLについて詳しく知りたい場合は、私たちのウェブサイトを訪れるか、ドキュメンテーションを読んでください。また、Databricks SQLのプロダクトツアーもチェックしてみてください。既存のウェアハウスを高性能でサーバーレスのデータウェアハウスに移行し、素晴らしいユーザーエクスペリエンスと低コストを実現したいと考えているなら、Databricks SQLが解決策です。-無料で試してみてください。