Databricks SQL を使用した次元データウェアハウスの実装：パート 1

ますます多くの組織がデータウェアハウスのワークロードをDatabricksに移行しています。 プラットフォームの弾力性とクエリ実行エンジンの大幅な強化により、Databricksはデータウェアハウスのクエリパフォーマンスとコストパフォーマンスの両方で世界記録を樹立することができ、分析インフラストラクチャの統合にとってますます魅力的な選択肢となっています。

これらの取り組みをサポートするために、Databricksがさまざまなデータウェアハウス設計アプローチをどのようにサポートしているかについては、以前にブログで紹介しました。このブログシリーズでは、データウェアハウジングの最も人気のあるアプローチの1つである次元モデリングに焦点を当てます。これは、 starスキーマと snowflakeスキーマによって特徴付けられる設計パターンであり、このアプローチをサポートするために広く採用されている標準化された抽出、変換、およびロード（ETL）パターンを深く掘り下げます。

この情報を次元モデリングコミュニティに広く提供するために、このモデリングアプローチに関連する従来のパターンに厳密に従います。この情報は、次のブログ投稿にわたって展開されます。

• パート1：(次元)データオブジェクトの定義（この記事）
• パート2：ディメンションETLワークフローの構築 
• パート3：ファクトETLワークフローの構築 

さらに、Microsoftによって作成され、データウェアハウスおよびビジネスインテリジェンストレーニング目的で広く使用されているサンプルデータベースである AdventureWorksDWデータベースでより一般的に使用されるスター スキーマの1つ（図1）を中心に設計議論を行います。

データウェアハウジングにおける次元モデリングとは何ですか？

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

データウェアハウスの4つのディメンションとは何ですか？

図1が示すように、データウェアハウジングのスター スキーマにはいくつかのディメンションが関与していますが、データウェアハウジングの4つの主要なディメンションは通常、次のとおりです。 

時間： これは履歴追跡フレームワークを提供し、傾向の評価や比較の実施に不可欠です。特定の時間間隔（日、週、年）に基づいてデータをカテゴリ化して、季節的なビジネスの変更や在庫管理を最適化できます。

顧客： 組織は、誰が製品を購入しているかについての正確な洞察を必要としています。名前、連絡先情報、人口統計などの情報は、有用な市場セグメンテーションを提供し、広告費や全体的なマーケティング戦略などの決定を判断するのに役立ちます。

製品： このディメンションは、分析されている商品またはサービスを定義し、販売されている量、販売率、および将来の成長の機会を判断するためのパフォーマンス分析を実施するのに役立つ場合があります。

場所： イベントが発生した場所（地理的または運用上）をコンテキスト化することは、顧客がどこに居住する可能性が高いかに基づいて、組織が重要な意思決定を行うのに役立ちます。 

物理モデル

Databricksプラットフォーム内では、ファクトとディメンションは物理テーブルとして実装されます。これらは、Databricksがサポートする情報資産の広範な柔軟性により、データベースに似たカタログ内に編成されます。次に、カタログはスキーマにサブ分割され、カタログ内のオブジェクトのサブセット（図2）の周りに論理的およびセキュリティ上の境界を作成します。

 

ディメンションテーブル

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

 

Identity columns

In this example, for the surrogate key column, CustomerKey, we employ an identity column that automatically creates a sequential BIGINT value for the field as we insert rows. Whether we use the ALWAYS or BY DEFAULT option with the identity column depends on whether we want to prohibit or permit the insertion of our own values for this field.

 

Missing member entry

A common pattern implemented with dimension tables is creating a missing member entry.  This entry is used in scenarios where fact records arrive with missing or unknown linkage to a dimension and can be created with a pre-determined surrogate key value like what is shown here when the BY DEFAULT option is employed:

 

Identity fields

As a best practice, whenever inserting values into an identify field, it is best to ensure the metadata for the identify field is updated through the use of an ALTER TABLE statement with the SYNC IDENTITY option employed:

 

Data types

For the business/natural key and other fields tied to data in source systems, we will need to align source system data types with those data types supported by the Databricks Platform (Table 1). For metadata fields where a bit value is employed, like 0 or 1, please note that we often use an INT data type instead of the BOOLEAN or TINYINT data types to make handling literals a bit easier.

Table 1. The data types supported by the Databricks Platform

Fact tables

Fact tables, too, follow their structural conventions. Composed primarily of measures and foreign key references to related dimensions, fact tables may also include unique identifiers for transactional records (or other descriptive attributes in a nearly one-to-one relationship with the fact records), referred to as degenerate dimensions. They may also include metadata fields to support the incremental loading (aka delta extract) of data from source systems.  Within the Databricks Platform, we might implement a fact table using the CREATE TABLE statement similar to what is shown here for the Internet sales fact:

 

外部キー参照

前のセクションで説明したディメンションテーブルで述べたように、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 Catalog Explorer のユーザーインターフェイス（図3）および各カタログ内の組み込み 情報スキーマ のオブジェクトを通じてアクセスできます。

最後に、このブログでは、ディメンショナルデザイン原則の遵守という観点からのみ、ファクトテーブルとディメンションテーブルの作成について説明します。パフォーマンスとメンテナンスの最適化を考慮したテーブル定義の追加オプションを検討したい場合は、このブログでスター スキーマのパフォーマンスを最適化する方法について確認してください。

 

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

事実テーブルとディメンションテーブル作成の基本を説明した後、次のブログでは、PythonとSQLの両方を使用して、Type-1およびType-2の遅延変更ディメンション（SCD）パターンに特に重点を置いて、ディメンションテーブルをサポートするETLパターンの実装に焦点を当てます。最後に、パート3では、これらのテーブルのETLをどのように実装できるかについて説明します。

Databricks SQLの詳細については、ウェブサイトをご覧いただくか、ドキュメントをお読みください。Databricks SQLの製品ツアーもご覧いただけます。既存のデータウェアハウスを、優れたユーザーエクスペリエンスと低い総所有コストを備えた、高性能なサーバーレスデータウェアハウスに移行したいとお考えの場合は、Databricks SQLがそのソリューションです。無料でお試しください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事