Databricks でテーブルをパーティション分割する場合

注

Databricks 、すべての新しいDeltaテーブルにリキッドクラスタを使用することを推奨しています。 Deltaテーブルについては、「リキッドクラスタリングを使用する」を参照してください。

リキッドクラスタリングは「リキッドパーティション」と呼ばれることもあります。この記事では、従来のDeltaパーティショニングについてのみ説明し、リキッドクラスタリングについては説明しません。

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

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

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

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

Databricks では、テラバイト未満のデータを含むテーブルをパーティション分割しないことをお勧めします。

テーブル内の各パーティションの最小サイズはいくつですか?

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

取り込み時間クラスタリングを使用する

Delta Lake と Databricks Runtime 11.3 LTS 以上を使用すると、作成するパーティション分割されていないテーブルは、取り込み時間クラスタリングのメリットを自動的に享受できます。インジェスト時間は、データを最適化または調整することなく、datetime フィールドに基づくパーティション分割戦略と同様のクエリの利点を提供します。

注

テーブルに対して UPDATE ステートメントまたは MERGE ステートメントを使用して多数の変更を実行するときにインジェスト時間クラスターを維持するために、Databricks では、インジェスト順序に一致する列を使用して ZORDER BY で OPTIMIZE を実行することをお勧めします。たとえば、イベントのタイムスタンプや作成日を含む列などです。

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

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

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

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

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

注

ほとんどのテーブルでは、インジェスト時間クラスターを利用して、Z オーダーとパーティションの調整について心配する必要がなくなります。

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

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

パーティションが非常に悪い場合、なぜ一部の Databricks 機能がそれらを使用するのですか?

パーティションは、特に非常に大きなテーブルの場合に有益です。パーティション分割に関する多くのパフォーマンス強化は、非常に大きなテーブル (数百テラバイト以上) に重点を置いています。

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

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

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

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