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

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

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

これを次元モデリングコミュニティに広く利用可能にするために、このモデリングアプローチに関連する古典的なパターンに厳密に従います。この情報は、次のブログ投稿に分散されます。

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

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

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

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

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

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

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

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

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

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

物理モデル

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

ディメンションテーブル

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

ID列

この例では、代理キー列 CustomerKey に、行を挿入する際にフィールドのシーケンシャルなBIGINT値を自動的に作成する ID列 を使用します。ID列でALWAYSオプションを使用するかBY DEFAULTオプションを使用するかは、このフィールドに独自の値を挿入することを禁止するか許可するかによって決まります。

欠損メンバーエントリ

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

IDフィールド

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

データ型

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

表1。Databricks Platformでサポートされているデータ型

ファクトテーブル

ファクトテーブルも構造上の規則に従います。主にメジャーと関連ディメンションへの外部キー参照で構成されるファクトテーブルには、トランザクションレコードの一意の識別子（またはファクトレコードとほぼ1対1の関係にあるその他の記述属性）が含まれる場合があり、これらは デジェネレートディメンションと呼ばれます。また、ソースシステムからのデータの増分ロード（ 別名デルタ抽出）をサポートするためのメタデータフィールドが含まれる場合もあります。Databricks Platform内では、インターネット販売ファクトの例のように 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 Catalog Explorer のユーザーインターフェイス（図3）および各カタログ内の組み込み 情報スキーマ のオブジェクトを通じてアクセスできます。

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

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

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

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

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