Azure Databricks でテーブルをパーティション分割するタイミング

注

Databricks では、すべてのマネージド テーブルに対して液体クラスタリングが推奨されます。 Apache Iceberg を使用するマネージド テーブルの場合、Unity Catalog は液体クラスタリングのみをサポートし、 PARTITION BY 列をクラスタリング キーとして解釈します。 「パーティション テーブルを液体クラスタリングに変換する」を参照してください。

データが 100 TB 未満のAzure Databricks上のほとんどのテーブルでは、パーティション分割は必要ありません。 Azure Databricksでは、既定ですべてのテーブルに Delta Lake が使用され、インジェスト時間によってパーティション分割されていないテーブル内のデータが自動的にクラスター化されるため、手動チューニングなしでパーティション分割のようなパフォーマンスが得られます。 カスタム パーティション分割戦略は、これらの既定値を上回る場合にのみ検討してください。 「インジェスト時間クラスタリングを使用する」を参照してください。

カスタム パーティショニング戦略

Apache Spark と Delta Lake の上級ユーザーは、既定の インジェスト時間クラスタリングよりも優れたパーティション分割戦略を特定できます。

Warnung

非効果的なパーティション分割戦略は、クエリのパフォーマンスに悪影響を及ぼす可能性があり、修正するにはデータの完全な書き換えが必要になります。 大規模なテーブルでは、完全な書き換えは非常にコストがかかり、低速になる可能性があります。

Databricks では、カスタムパーティション分割戦略を使用する前に、すべてのテーブルに対して液体クラスタリングを使用し、Unity カタログマネージド テーブルの予測最適化を推奨しています。 テーブルにリキッドクラスタリングを使用する および Unity Catalog のマネージド テーブルの予測最適化を参照してください。

既存のパーティション分割された Delta Lake テーブルを液体クラスタリングに変換するには、 ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BYを使用します。 液体クラスタリングはカーディナリティの低い列と高いカーディナリティの両方の列に対して機能し、固定パーティション境界や静的パーティション分割に共通する小さなファイルの問題を回避します。 「パーティション テーブルを液体クラスタリングに変換する」を参照してください。

パーティション列でサポートされているデータ型

パーティション分割では、パーティション列に対して次のデータ型がサポートされています。

  • Date
  • タイムスタンプ
  • TimestampNTZ
  • インターバル
  • String
  • Binary
  • ブール値
  • Integer（整数）、Long（長整数）、Short（短整数）、Byte（バイト）
  • Float、Double、Decimal

パーティション列は最上位レベルの列である必要があります。 次のいずれかでパーティション分割することはできません。

  • 複合型 ( StructType、 MapType、 ArrayType、または VariantType
  • struct_col.fieldなどの構造体フィールド。 Delta Lake は、 PARTITIONED BY の構造体フィールドを列参照ではなく式として扱います。

テーブルを構造体フィールド別に整理するには、代わりに液体クラスタリングを使用します。これは、構造体フィールドをクラスタリング キーとして認識します。 液体クラスタリングは、最初に最上位の列に抽出することなく、構造体フィールドのデータスキップを行う唯一の方法です。 表に液体クラスタリングを使用するを参照してください。

最小サイズの推奨事項

これらの最小サイズを下回るパーティション分割は、クエリのパフォーマンスを向上させるのではなく、悪影響を及ぼす可能性があります。 テーブルをパーティション分割するかどうかを決定するときは、次の点を考慮してください。

  • テーブルの場合:
    • データが 1 TB 未満の場合は、パーティション分割しないでください。
    • データが 1 TB から 100 TB を超える場合は、パーティション分割ではなく液体クラスタリングを使用します。 パーティショニングは、パフォーマンス改善に役立つよりも、かえってパフォーマンスに悪影響を及ぼすことのほうが多いです。
    • 100 TB 以上のデータでは、パーティション分割によってパフォーマンスが向上する可能性がありますが、Databricks では最初に液体クラスタリングを使用し、パフォーマンスの向上を確認することをお勧めします。
  • パーティションの場合は、各パーティションに少なくとも 1 GB のデータが含まれていることを確認します。 パーティションの数が少なく、大きいテーブルの方が、小さいパーティションを多く持つテーブルよりパフォーマンスが優れている傾向にあります。

インジェスト時間クラスタリングを使用する

Delta Lake を使用すると、パーティション分割されていないテーブルで インジェスト時間クラスタリングが自動的に使用されます。 インジェスト時間には、datetime フィールドを使用したパーティション分割戦略と同様のクエリ パフォーマンスが向上しており、データを手動で最適化または調整する必要はありません。

注

テーブルで UPDATE または MERGE ステートメントを使用して多数の変更を実行する場合にインジェスト時間クラスタリングを維持するために、Databricks では、イベント タイムスタンプや作成日など、インジェスト順序に一致する列で液体クラスタリングを使用することをお勧めします。 表に液体クラスタリングを使用するを参照してください。

Delta Lake と Parquet のパーティション互換性

Delta Lake はデータの格納に Parquet を使用し、一部のパーティション分割された Delta Lake テーブルには Apache Spark で格納された Parquet テーブルと同様のデータ レイアウトがあります。 Apache Spark は、Parquet 形式でデータを保存するときに Hive スタイルのパーティション分割を使用します。 Hive スタイルのパーティション分割は Delta Lake プロトコルの一部 ではないため 、ワークロードはこのパーティション分割戦略に依存して Delta Lake テーブルと対話しないようにする必要があります。

Databricks では、公式にサポートされているクライアントと API を使用して Delta Lake に格納されているデータを操作することをお勧めします。 多くの Delta Lake 機能は、Parquet、Hive、または以前のバージョンの Delta Lake プロトコルで使用された可能性があるデータ レイアウトに関する前提を破ります。

注

Delta Lake テーブルの列マッピングを有効にすると、Hive スタイルのパーティション分割のために、パーティション ディレクトリ内の列名がランダム プレフィックスによって置き換えられます。 「Delta Lake の列マッピングを使用して列の名前変更と削除を行う」をご覧ください。

Delta Lake のパーティション分割と他のデータ レイクの比較

他のオープンソース テクノロジ (Apache Spark、Parquet、Hive、Hadoop など) で役立つパーティション分割手法は、常にAzure Databricksに当てはまるとは限りません。 テーブルをパーティション分割する場合は、次の点を考慮してください。

  • トランザクションはパーティション境界によって定義されません。 Delta Lake ではトランザクション ログを通じて ACID が保証されるため、アトミック性を保証するために、パーティションによってデータのバッチを分離する必要はありません。
  • Azure Databricks のコンピューティング クラスターには、物理メディアに関連付けられたデータの局所性がありません。 レイクハウスに取り込まれたデータは、クラウド オブジェクト ストレージに保存されます。 データはデータ処理中にローカル ディスク ストレージにキャッシュされますが、Azure Databricks で、ファイルベースの統計情報により並列読み込みが行われる最小限のデータ量が特定されます。

Z オーダーとパーティション

注

Databricks では、すべての新しいテーブルに対して、Z オーダーよりも液体クラスタリングが推奨されます。 表に液体クラスタリングを使用するを参照してください。

Z オーダー インデックスとパーティションを併用することで、大規模なデータセットに対するクエリを高速化することができます。 ほとんどのテーブルでは 、インジェスト時間クラスタリング を使用して、Z オーダーとパーティションを調整する必要がなくなります。

パーティション境界と Z オーダーに基づいてクエリ最適化戦略を計画する場合は、次の規則に注意してください。

  • Z オーダーには、 OPTIMIZE コマンドが必要です。 パーティション境界を越えてファイルを結合することはできません。そのため、Z オーダー クラスタリングはパーティション内でのみ行われます。 パーティション分割されていないテーブルの場合は、テーブル全体でファイルを結合できます。
  • パーティション分割は、カーディナリティが低いか既知のフィールド (日付フィールドや物理的な場所など) にのみ適しており、タイムスタンプなどカーディナリティの高いフィールドには適していません。 Z オーダーは、カーディナリティの高いフィールドや無限に増える可能性のあるフィールド (タイムスタンプまたはトランザクションや注文テーブルの顧客 ID など) を含むすべてのフィールドに対して有効です。
  • パーティション分割に使用するフィールドに Z オーダーを使用することはできません。

Azure Databricks が既存のパーティションを考慮して最適化する方法

多くのお客様は、Parquet ベースのデータ レイクから Delta Lake に移行します。たとえば、 CONVERT TO DELTA ステートメントを使用して、既存の Parquet ベースのテーブルを既存のデータを書き換えずに Delta Lake テーブルに変換します。 変換は既存のデータを書き換えないので、大きなテーブルは以前のパーティション分割戦略を継承する可能性があります。

一部の Databricks 最適化では、可能な限りこれらのパーティションが使用されるため、Delta Lake 用に最適化されていないパーティション分割戦略のパフォーマンス低下の影響が軽減されます。

Delta Lake と Apache Spark はオープンソース テクノロジです。 Databricks にはパーティション分割への依存を減らす機能が用意されていますが、オープンソース コミュニティは複雑さを増す新機能を構築する可能性があります。

  • Last updated on