動的ファイルプルーニング
クエリーが大きなDelta Lakeテーブルを小さなフィルター処理されたテーブルに結合する場合、クエリーをランするまでフィルター値は不明です。ランタイムプルーニングがない場合、クエリーは大きなテーブル内のすべてのファイルをスキャンします(一致する行が含まれていないファイルもスキャンされます)。ダイナミックファイルプルーニングは、この問題を解決します。ランタイム中に、オプティマイザーは結合の一方の側からDelta Lakeテーブルのスキャンまでフィルター結果をプッシュダウンし、一致する行を含まないファイルをスキップします。
ダイナミックファイルプルーニングはdefaultで有効になっています。これを活用するためにクエリーを変更する必要はありません。
動的ファイルプルーニングが適用される場合
動的ファイルプルーニングは、Delta Lake テーブル上の結合にのみ適用されます。MERGE ステートメントでは、マージ条件がソース列とターゲットカラムの等価性を比較する際に、ソースからの結合キー値を使用してターゲットファイルをスキップします。UPDATEおよびDELETEステートメントでは、条件に同じ種類の比較を行うサブクエリが含まれている場合に適用されます。
MERGE、 UPDATE、および DELETE ステートメントでの動的ファイルプルーニングには、Photon 対応のコンピュートが必要です。SELECT ステートメントの場合、 Photon にはより広範で信頼性の高い動的ファイルプルーニング機能があります。Photon を使用しない場合、クエリーの形状や実行プランによっては、動的ファイルプルーニングが SELECT ステートメントに適用される可能性があります。Photonとはを参照してください。
動的ファイルプルーニングは、パーティション化されていないテーブル、またはパーティション化されていない列での結合で最もパフォーマンスを向上させます。defaultでは、結合内の大きなDelta Lakeテーブルが少なくとも10 GBで、少なくとも10個のファイルがある場合にのみトリガーされます。構成を参照してください。
また、動的ファイルプルーニングにより、書き込みの競合も減少します。Delta Lake が commit の際に競合をチェックする際、動的ファイルプルーニングによってスキップされたファイルも考慮されます。これにより、失敗する取引の数が削減されます。分離レベルと書き込みの競合を参照してください。
ベストプラクティス
動的ファイルプルーニングのパフォーマンスへの影響は、データのクラスタリング方法と相関しています。結合対象の値がすべてのファイルに分散している場合、動的ファイルプルーニングではファイルはスキップされません。動的ファイルプルーニングでより多くのファイルをスキップできるようにするには、次のプラクティスに従ってください。
- 頻繁に結合する列にリキッドクラスタリングを使用すると、一致する行がより少ないファイルにまとめて配置されます。
- Photon を有効にしたコンピュートを使用してください。これは動的ファイルプルーニングに
MERGE、UPDATE、およびDELETEステートメントで必要です。
構成
ほとんどのワークロードでこれらの設定を変更する必要はありません。小さいDelta Lakeテーブルに対する結合がプルーニングの恩恵を受ける可能性はあるが、defaultのサイズまたはファイル数のthresholdを下回る場合は、thresholdのチューニングを検討してください。
これらのApache Spark構成プロパティは、動的ファイルプルーニングを制御します。
属性 | Type | デフォルト | 説明 |
|---|---|---|---|
|
|
| 動的ファイルプルーニングをオンまたはオフにします。 |
|
|
| 動的ファイルプルーニングをTriggerする結合内の大きな Delta Lake テーブルの最小サイズ(バイト単位)。小さなテーブルの場合、テーブル全体をスキャンする方が、フィルターをプッシュダウンするよりも通常は安価です。 Delta Lake テーブルのサイズを見つけるには、 |
|
|
| 動的ファイルプルーニングをTriggerする結合内の大きい Delta Lake テーブル内の最小ファイル数。テーブル内のファイル数がこの threshold より少ない場合、動的ファイルプルーニングは実行されません。ファイル数がわずかなテーブルでは、それを行う価値がない可能性があるためです。 Delta Lake テーブルのファイル数を確認するには、 |