次の方法で共有

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

  • [アーティクル]

Note

Databricks では、すべての新しい Delta テーブルに対してリキッド クラスタリングの使用をお勧めしています。 「Delta テーブルに Liquid Clustering クラスタリングを使用する」を参照してください。

リキッド クラスターは、“リキッド パーティション” とも呼ばれます。 この記事では、従来の Delta パーティション分割のみを言及し、リキッド クラスタリングは言及しません。

この記事では、Azure Databricks でテーブルをパーティション分割する方法の概要と、Delta Lake によってサポートされるテーブルのパーティション分割を使用する場合の具体的な推奨事項について説明します。 組み込みの機能と最適化により、データが 1 TB 未満のほとんどのテーブルではパーティションは必要ありません。

Azure Databricks では、既定ですべてのテーブルに Delta Lake が使用されます。 以下の推奨事項は、すべてのテーブルに Delta Lake を使用することを前提としています。

Databricks Runtime 11.3 LTS 以降では、Azure Databricks ではインジェスト時間によってパーティション分割されていないテーブルのデータが自動的にクラスター化されます。 「インジェスト時間クラスタリングを使用する」を参照してください。

小さなテーブルをパーティション分割する必要がありますか?

Databricks では、データが 1 テラバイト未満のテーブルをパーティション分割しないことを推奨しています。

テーブル内の各パーティションの最小サイズは?

Databricks では、すべてのパーティションに少なくとも 1 ギガバイトのデータを含めることを推奨しています。 パーティションの数が少なく、大きいテーブルの方が、小さいパーティションを多く持つテーブルよりパフォーマンスが優れている傾向にあります。

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

Delta Lake と Databricks Runtime 11.3 LTS 以降を使用すると、パーティション分割されていないテーブルを作成した場合にインジェスト時間クラスタリングのメリットを自動的に得ることができます。 インジェスト時間では、データの最適化や調整を必要とせず、datetime フィールドに基づくパーティション分割戦略と同様のクエリの利点が得られます。

注意

テーブルに対して UPDATE または MERGE ステートメントを使用して多数の修正を行う場合、インジェスト時間クラスタリングを維持するために、Databricks では取り込みの順序に一致する列で OPTIMIZE と ZORDER BY を実行することを推奨しています。 たとえば、イベントのタイムスタンプや作成日を含む列が該当する可能性があります。

Delta Lake と Parquet ではパーティション分割戦略が共有されますか?

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

Delta Lake の機能の多くについて、Parquet、Hive、またはそれ以前の Delta Lake プロトコル バージョンから転送される可能性があるデータ レイアウトは想像を超えています。 Delta Lake に保存されているデータの操作には、常に公式にサポートされているクライアントと API を使用する必要があります。

Delta Lake パーティションは、他のデータ レイクのパーティションとどのように異なりますか?

Azure Databricks と Delta Lake は、Apache Spark、Parquet、Hive、Hadoop などのオープンソース テクノロジに基づいていますが、これらのテクノロジで有用なパーティション分割の動機と戦略は、一般的に Azure Databricks には当てはまりません。 テーブルをパーティション分割する場合は、戦略を選択する前に、次の点を考慮してください。

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

Z オーダーとパーティションはどのように連携しますか?

Z オーダー インデックスとパーティションを併用することで、大規模なデータセットに対するクエリを高速化することができます。

注意

ほとんどのテーブルでは、インジェスト時間クラスタリングにより、Z オーダーとパーティションのチューニングを気にする必要はありません。

パーティション境界と Z オーダーに基づくクエリ最適化戦略を計画する際には、次の規則に留意することが重要です。

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

パーティションが適さないのに一部の Azure Databricks 機能で使用されるのはなぜですか?

パーティションは、特に非常に大きなテーブルの場合に有効なことがあります。 パーティション分割に関するパフォーマンス向上の多くは、非常に大きなテーブル (数百テラバイト以上) に焦点を当てたものです。

多くのお客様が、Parquet ベースのデータ レイクから Delta Lake に移行しています。 CONVERT TO DELTA ステートメントを使用すると、既存のデータを書き換えることなく、既存の Parquet ベースのテーブルを Delta テーブルに変換することができます。 そのため、多くのお客様は、以前のパーティション分割戦略を継承した大きなテーブルをお持ちです。 Databricks によって開発された最適化の中には、可能な限りこれらのパーティションを活用し、Delta Lake に最適化されていないパーティション分割戦略の潜在的な欠点を軽減しようとするものがあります。

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

カスタム パーティション分割で Azure Databricks 組み込みの最適化を上回ることは可能ですか?

Apache Spark と Delta Lake の経験豊富なユーザーであれば、場合によってはインジェスト時間クラスタリングよりも優れたパフォーマンスを提供するパターンを設計して実装することができるかもしれません。 不適切なパーティション分割戦略を実装すると、ダウンストリームのパフォーマンスに非常に悪い影響を及ぼすおそれがあり、修正するためにデータの完全な書き換えが必要になる場合があります。 Databricks では、コストのかかる非効率性が発生しないよう、既定の設定を使用することをほとんどのユーザーにお勧めしています。