Azure Databricks での低シャッフル マージ

Note

低シャッフル マージは、Databricks Runtime 10.4 LTS 以降で一般提供 (GA) されており、Databricks Runtime 9.1 LTS ではパブリック プレビュー段階です。 Databricks では、プレビューのお客様は Databricks Runtime 10.4 LTS 以降に移行することを推奨しています。

MERGE コマンドは、Delta Lake テーブルからの同時更新、挿入、および削除を実行するために使用されます。 Azure Databricks には、シャッフル操作の数を減らすことで、一般的なワークロードのパフォーマンスを大幅に向上させる MERGE の最適化された実装があります。

Databricks の低シャッフル マージでは、合理化に優れた別個の処理モードで未変更行を処理し、未変更行と変更済み行を一緒に処理しないことでパフォーマンスを上げます。 その結果、シャッフルされるデータの量が大幅に減り、パフォーマンスが改善されます。 低シャッフル マージではまた、MERGE 操作の実行後、OPTIMIZE ZORDER BY コマンドを再実行する必要性が軽減されます。

最適化されたパフォーマンス

多くの MERGE ワークロードでは、テーブル内の比較的少数の行のみ更新されます。 ただし、Delta テーブルはファイル単位でのみ更新できます。 MERGE コマンドで、特定のファイルに保存されている少数の行を更新または削除する必要がある場合は、同じファイルに保存されている残りの行もすべて (それらの行が変更されていなくても) 処理および再書き込みする必要があります。 低シャッフル マージは、変更されていない行の処理を最適化します。 以前は、それらは、変更された行と同じ方法 (複数のシャッフル ステージとコストの高い計算を通過) で処理されました。 低シャッフル マージでは、変更されていない行は代わりに、シャッフル、コストの高い処理、その他の追加されるオーバーヘッドなしで処理されます。

最適化されたデータ レイアウト

実行速度が速くなることに加えて、低シャッフル マージは後続の操作にもメリットがあります。 以前の MERGE 実装が原因で、変更されていないデータのデータ レイアウトが完全に変更され、後続の操作のパフォーマンスは低下しました。 低シャッフル マージでは、ベストエフォート ベースの Z オーダー最適化を含む、変更されていないレコードの既存のデータ レイアウトの保持が試行されます。 そのため、低シャッフル マージを使用すると、1 つ以上の MERGE コマンドの実行後に Delta テーブルに対する操作のパフォーマンスが低下します。

注意

低シャッフル マージでは、変更されていない既存データのデータ レイアウトを保持しようとします。 更新されたか、新しく挿入されたデータのデータ レイアウトは最適ではない可能性があるため、OPTIMIZE または OPTIMIZE ZORDER BY コマンドの実行が依然として必要な場合があります。

可用性

低シャッフル マージは Databricks Runtime 10.4 以降では既定で有効になっています。 サポートされている早期の Databricks Runtime バージョンは、構成 spark.databricks.delta.merge.enableLowShuffle を true に設定することで有効にできます。 このフラグは Databricks Runtime 10.4 以降では無効です。