Databricks でテーブルをパーティション分割する場合
Databricks は、すべてのマネージドテーブルに対してリキッドクラスタリングを推奨しています。Apache Iceberg を使用するマネージドテーブルの場合、Unity Catalog はリキッドクラスタリングのみをサポートし、PARTITION BY 列をクラスタリングキーとして解釈します。パーティション分割されたテーブルをリキッドクラスタリングに変換するを参照してください。
Databricks のほとんどのテーブルは、データが100 TB未満の場合、パーティション分割は不要です。Databricks はデフォルトで、すべてのテーブルに Delta Lake を使用し、インジェスト時間別にパーティション分割されていないテーブルのデータを自動的にクラスタリングするため、手動でチューニングしなくてもパーティション分割のようなパフォーマンスが得られます。これらのデフォルトよりも優れたパフォーマンスを発揮する場合にのみ、カスタムパーティション分割戦略を検討してください。インジェスト時間クラスタリングを使用するを参照してください。
カスタムパーティション分割戦略
Apache Spark および Delta Lake の上級ユーザーは、デフォルトの インジェスト時間のクラスタリングを上回るパーティショニング戦略を特定する場合があります。
非効率なパーティション分割戦略は、クエリのパフォーマンスに悪影響を及ぼす可能性があり、修正するにはデータの完全な書き換えが必要になる場合があります。大規模なテーブルの場合、完全な書き換えは非常にコストがかかり、時間がかかる可能性があります。
カスタムパーティショニング戦略を使用する前に、Databricks はすべてのテーブルにリキッドクラスタリングを、そして Unity Catalog マネージドテーブルには予測的最適化を推奨しています。テーブルのリキッドクラスタリングを使用するとUnity Catalog マネージドテーブルの予測的最適化を参照してください。
既存のパーティション分割された Delta Lake テーブルをリキッドクラスタリングに変換するには、ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY を使用します。リキッドクラスタリングは、カーディナリティの低い列と高い列の両方で機能し、静的パーティション分割によく見られる固定パーティション境界や小さなファイルの問題を回避します。パーティション分割されたテーブルをリキッドクラスタリングに変換するを参照してください。
パーティション列でサポートされるデータ型
パーティション分割は、パーティション列に以下のデータ型をサポートしています。
- Date
- タイムスタンプ
- TimestampNTZ
- 間隔
- String
- Binary
- Boolean
- Integer、Long、Short、バイト
- フロート、ダブル、デシマル
パーティション列は最上位の列である必要があります。以下のいずれかではパーティション分割することはできません：
StructType、MapType、ArrayType、または、のような複合型VariantType- 構造体フィールド（例:
struct_col.field）。Delta Lake は、PARTITIONED BYの構造体フィールドを列参照としてではなく、式として扱います。
テーブルを構造体フィールドで整理するには、構造体フィールドをクラスタリングキーとして認識するリキッドクラスタリングを代わりに使用してください。リキッドクラスタリングは、最初に最上位の列に抽出することなく、構造体フィールドでデータスキップを行う唯一の方法です。「テーブルにリキッドクラスタリングを使用する」を参照してください。
最小サイズ推奨事項
これらの最小サイズを下回るパーティション分割は、クエリパフォーマンスを改善するどころか、悪影響を及ぼす可能性が高いです。テーブルをパーティション分割するかどうかを決定する際に、以下の点を考慮してください。
-
テーブルの場合:
- データが1 TB未満の場合、パーティション分割しないでください。
- 1 TB から 100 TB を超えるデータの場合、パーティショニングの代わりにリキッドクラスタリングを使用します。パーティショニングは、パフォーマンス向上に役立つことよりも、悪影響を与える可能性が高いです。
- 100 TB 以上のデータがある場合、パーティション分割によってパフォーマンスが向上する可能性がありますが、Databricks は最初にリキッドクラスタリングを使用し、パフォーマンスの改善を検証することを推奨しています。
-
パーティションについては、各パーティションに少なくとも1 GBのデータが含まれていることを確認してください。パーティションの数が少なく、サイズが大きいテーブルは、パーティションの数が多く、サイズが小さいテーブルよりも性能が優れている傾向があります。
インジェスト時間クラスタリングを使用する
Delta Lake を使用すると、パーティション分割されていないテーブルは、インジェスト時間クラスタリングを自動的に使用します。インジェスト時間には、日付/時刻フィールドを持つパーティション分割戦略に類似したクエリパフォーマンスの改善があり、データを手動で最適化またはチューニングする必要はありません。
テーブルに対してUPDATEまたはMERGEステートメントを使用して多数の変更を実行する際に、取り込み時間のクラスタリングを維持するために、Databricksは、イベントのタイムスタンプや作成日など、取り込み順序に一致する列でリキッドクラスタリングを使用することを推奨しています。テーブルにはリキッドクラスタリングを使用するを参照してください。
Delta Lake と Parquet のパーティション分割の互換性
Delta Lake はデータの格納に Parquet を使用し、一部のパーティション分割された Delta Lake テーブルは、Apache Spark で格納された Parquet テーブルと同様のデータレイアウトを持っています。Apache Spark は、Parquet 形式でデータを保存するときに Hive スタイルのパーティション分割を使用します。Hive スタイルのパーティション分割は Delta Lake プロトコルの一部では ありません 。ワークロードは、Delta Lakeテーブルと対話するためにこのパーティション分割戦略に依存すべきではありません。
Databricks では、公式にサポートされているクライアントと APIs を使用して、Delta Lake に格納されているデータと対話することをお勧めします。Delta Lake の多くの機能は、Parquet、Hive、またはそれ以前の Delta Lake プロトコルバージョンで使用されていた可能性のあるデータレイアウトに関する前提を破ります。
Delta Lake テーブルの列マッピングを有効にすると、Hive スタイルのパーティション分割のパーティションディレクトリ内の列名がランダムなプレフィックスに置き換えられます。Delta Lake 列マッピングを使用した列の名前変更と削除を参照してください。
Delta Lake のパーティショニングと他のデータレイクとの比較
他のオープンソース技術（Apache Spark、Parquet、Hive、および Hadoop など）で役立つパーティショニング手法が、Databricks では常に当てはまるとは限りません。テーブルをパーティショニングする場合は、以下を検討してください:
- トランザクションはパーティション境界によって定義されません。Delta Lake はトランザクション ログによって ACID を保証するため、バッチ データをパーティションで分割して原子性を保証する必要はありません。
- Databricks コンピュート クラスターには、物理メディアに関連付けられたデータの局所性はありません。 レイクハウスに取り込まれたデータは、クラウドオブジェクトストレージに保存されます。 データ処理中にデータがローカルディスクストレージにキャッシュされるのに対し、Databricksはファイルベースの統計を使用して、並列ロードの最小データ量を特定します。
Z-order とパーティション
Databricks 、すべての新しいテーブルに対してZ-Orderingではなくリキッドクラスタリングを推奨しています。 テーブルにはリキッドクラスタリングを使用するを参照してください。
大規模なデータセットに対するクエリを高速化するには、パーティションと併せてZ-orderインデックスを使用できます。ほとんどのテーブルは、Z-order とパーティションのチューニングを行う必要がないように、インジェスト時間クラスタリングを使用しています。
パーティション境界と Z-Order に基づくクエリ最適化戦略を計画する際には、以下のルールに留意してください：
- Z-order には
OPTIMIZEコマンドが必要です。パーティション境界を越えてファイルを結合することはできません。そのため、Z-orderクラスタリングはパーティション内でのみ発生します。パーティション分割されていないテーブルの場合、ファイルはテーブル全体で結合できます。 - パーティション分割は、カーディナリティの低いフィールドまたは既知のカーディナリティ フィールド (日付フィールドや物理的な場所など) に対してのみ有効で機能し、タイムスタンプなどのカーディナリティの高いフィールドには機能しません。 Z-order は、カーディナリティの高いフィールドや無限に増加する可能性のあるフィールド (タイムスタンプやトランザクション テーブルや注文テーブルの顧客 ID など) を含むすべてのフィールドで機能します。
- パーティション分割に使用されるフィールドの Z-order はできません。
Databricks が既存のパーティションを中心として最適化する方法
多くの顧客は、既存のデータを書き換えることなく、CONVERT TO DELTA ステートメントを使用して既存の Parquet ベースのテーブルを Delta Lake テーブルに変換するなど、Parquet ベースのデータレイクから Delta Lake に移行します。変換によって既存のデータが書き換えられるわけではないため、大規模なテーブルが以前のパーティション分割戦略を継承する可能性があります。
Databricks の一部の最適化では、可能な場合はこれらのパーティションを使用し、Delta Lake 向けに最適化されていないパーティション分割戦略に起因するパフォーマンスへの悪影響を軽減します。
Delta Lake と Apache Spark はオープンソーステクノロジーです。Databricks にはパーティション分割への依存を減らす機能がありますが、オープンソースコミュニティが複雑さを増す新機能を構築する可能性があります。