データモデリング

この記事では、Databricks でのデータ モデリングに関する考慮事項、注意点、推奨事項について説明します。 これは、新しいテーブルを設定したり、ETL ワークロードを作成したりするユーザーを対象としており、生データを新しいデータ モデルに変換する際に影響を与える Databricks の動作を理解することに重点を置いています。 データ モデリングの決定は、組織とワークロードがテーブルをどのように使用するかによって異なります。 選択したデータ モデルは、クエリ パフォーマンス、コンピュート コスト、およびストレージ コストに影響します。 これには、Databricks を使用したデータベース設計の基本的な概念の紹介が含まれます。

重要

この記事は、Unity Catalog で管理されるすべてのテーブルを含む、Delta Lake によってサポートされるテーブルにのみ適用されます。

Databricksを使用して、レイクハウスフェデレーションに登録されたテーブルを含む他の外部データソースをクエリできます。 各外部データソースには、異なる制限、セマンティクス、およびトランザクションの保証があります。 「 データのクエリ」を参照してください。

データベース管理の概念

Databricksで構築されたレイクハウスは、他のエンタープライズ データウェアハウジング システムと多くのコンポーネントと概念を共有しています。 データ モデルを設計する際には、次の概念と機能を考慮してください。

Databricks でのトランザクション

Databricks はトランザクションの範囲を個々のテーブルに限定します。 つまり、Databricks はマルチテーブル ステートメント (マルチステートメント トランザクションとも呼ばれます) をサポートしていません。

データ モデリング ワークロードの場合、ソース レコードの取り込みで 2 つ以上のテーブルに行を挿入または更新する必要がある場合、複数の独立したトランザクションを実行する必要があります。 これらの各トランザクションは、他のトランザクションとは無関係に成功または失敗する可能性があり、ダウンストリーム クエリは、トランザクションの失敗または遅延による状態の不一致を許容する必要があります。

Databricks の主キーと外部キー

主キーと外部キーは情報提供用であり、強制ではありません。 このモデルは多くのエンタープライズ クラウド ベースのデータベース システムで一般的ですが、多くの従来のリレーショナル データベース システムとは異なります。 Databricks の制約を参照してください。

Databricks での結合

結合は、あらゆるデータベース設計で処理のボトルネックを引き起こす可能性があります。 Databricks でデータを処理する場合、クエリ オプティマイザーは結合のプランを最適化しようとしますが、個々のクエリで多数のテーブルの結果を結合する必要がある場合は問題が発生する可能性があります。 フィルター パラメーターが別のテーブルのフィールドにある場合、オプティマイザーはテーブル内のレコードをスキップできず、テーブル全体のスキャンが発生する可能性があります。

「Databricks での結合の操作」を参照してください。

入れ子になったデータ型と複雑なデータ型の操作

Databricks 、 JSON 、 Avro 、ProtoBuff などの半構造化データソースの操作と、複雑なデータを構造体、 JSON文字列、マップ、配列として保存することをサポートしています。 「半構造化データのモデル化」を参照してください。

正規化されたデータモデル

Databricks はあらゆるデータ モデルで適切に動作します。 既存のデータ モデルがあり、それをクエリしたり Databricks に移行したりする必要がある場合は、データを再設計する前にパフォーマンスを評価する必要があります。

新しいレイクハウスを設計する場合、または既存の環境にデータセットを追加する場合、Databricks では、第 3 正規形 (3NF) などの高度に正規化されたモデルを使用しないことを推奨します。

スター スキーマやスノーフレーク スキーマなどのモデルは、標準クエリに存在する結合が少なく、同期を維持するキーも少ないため、Databricks ではパフォーマンスが良好です。 さらに、1 つのテーブルにより多くのデータ フィールドを含めると、クエリ オプティマイザーはファイルレベルの統計を使用して大量のデータをスキップできます。 データ スキップの詳細については、 「Delta Lake のデータ スキップ」を参照してください。