この記事では、Azure Databricks でのデータ モデリングに関する考慮事項、注意事項、推奨事項について説明します。 新しいテーブルの設定や、ETL ワークロードの作成を行うユーザーを対象とし、生データを新しいデータ モデルに変換する際に影響を与える Azure Databricks の動作を理解することに重点を置いています。 データ モデリングの決定は、組織とワークロードがテーブルをどのように使うかによって異なります。 選んだデータ モデルは、クエリのパフォーマンス、コンピューティング コスト、ストレージ コストに影響を与えます。 ここでは、Azure Databricks を使ったデータベース設計の基本的な概念について説明します。
重要
この記事は、Delta Lake によってサポートされるテーブルのみに適用されます。これには、Unity Catalog で管理されるすべてのテーブルが含まれます。
Azure Databricks を使って、Lakehouse Federation に登録されているテーブルなどの他の外部データ ソースのクエリを実行できます。 外部データ ソースごとに、異なる制限、セマンティクス、トランザクション保証があります。 「データのクエリ」を参照してください。
データベース管理の概念
Azure Databricks で構築されたレイクハウスは、多くのコンポーネントおよび概念を他のエンタープライズ データ ウェアハウス システムと共有します。 データ モデルを設計する際には、次の概念と機能を考慮してください。
Azure Databricks でのトランザクション
Azure Databricks は、トランザクションのスコープを個々のテーブルに設定します。 これは、Azure Databricks が複数テーブル ステートメント (複数ステートメント トランザクションとも呼ばれます) をサポートしていないことを意味します。
データ モデリング ワークロードの場合、ソース レコードの取り込みで複数のテーブルに行を挿入または更新する必要がある場合、これは言い換えると、複数の独立したトランザクションを実行する必要があるということです。 これらの各トランザクションは、他のトランザクションとは独立して成功または失敗する可能性があり、ダウンストリーム クエリはトランザクションの失敗または遅延による状態の不一致を許容する必要があります。
Azure Databricks の主キーと外部キー
主キーと外部キーは情報提供のみを目的としており、強制されません。 このモデルは、多くのエンタープライズ クラウドベースのデータベース システムで一般的ですが、多くの従来のリレーショナル データベース システムとは異なります。 「Azure Databricks の制約」を参照してください。
Azure Databricks での結合
結合は、あらゆるデータベース設計において処理のボトルネックを引き起こす可能性があります。 Azure Databricks でデータを処理する場合、クエリ オプティマイザーは結合のプランを最適化しようとしますが、個々のクエリで多くのテーブルの結果を結合する必要がある場合には難航する可能性があります。 また、フィルター パラメーターが別のテーブルのフィールドにある場合、オプティマイザーはテーブル内のレコードをスキップできず、フル テーブル スキャンが発生する可能性があります。
「Azure Databricks での結合の操作」を参照してください。
注
具体化されたビューを使うと、一部の結合操作の結果を段階的に計算できますが、他の結合は具体化されたビューと互換性がありません。 具体化されたビューを参照してください。
入れ子になった複合データ型の操作
Azure Databricks は、JSON、Avro、ProtoBuff などの半構造化データ ソースの操作と、構造体、JSON 文字列、マップおよび配列としての複雑なデータの格納をサポートしています。 「モデルの半構造化データ」を参照してください。
正規化されたデータ モデル
Azure Databricks は、あらゆるデータ モデルで適切に機能できます。 Azure Databricks からクエリを実行するか、Azure Databricks に移行する必要がある既存のデータ モデルがある場合は、データを再設計する前にパフォーマンスを評価する必要があります。
新しいレイクハウスを設計している場合、または既存の環境にデータセットを追加している場合、Azure Databricks では、第 3 正規形 (3NF) などの高度に正規化されたモデルを使わないことを推奨しています。
スター スキーマやスノー フレーク スキーマのようなモデルは、標準クエリに存在する結合が少なく、同期を維持するキーも少ないため、Azure Databricks 上で良好に動作します。さらに、1 つのテーブルにさらに多くのデータ フィールドがあるため、クエリ オプティマイザーはファイル レベルの統計を使って大量のデータをスキップできます。 データ スキップの詳細については、「Delta Lake のデータ スキップ」を参照してください。