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