How to Optimize a Growing Delta Table with Frequent Updates and Deletes?
HOTSPOT
You have an Azure Databricks workspace that is enabled for Unity Catalog and contains a managed Delta table named Table1.
Table1 is written by batch jobs every hour and is queried frequently by filtering two columns named CustomerId and EventDate.
You expect Table1 to grow significantly over time.
The rows in Table1 are frequently updated and deleted to support compliance requests.
You need to keep query performance consistent as Table1 grows. The solution must minimize update and deletion effort.
What should you include in the solution? To answer, select the appropriate options in the answer area.
NOTE: Each correct selection is worth one point.
Community Insight
Tests whether you know that Liquid clustering is preferred over partitioning/Z-ORDER for evolving filter columns, and that deletion vectors avoid full file rewrites—the trap is choosing traditional partitioning or Z-ORDER.
This DP-750 hotspot question asks you to choose features that keep query performance consistent on a large, growing managed Delta table with frequent updates and deletes. The answer is Liquid clustering for query performance and deletion vectors for minimizing update and deletion effort.
The most common mistake is selecting partitioning on CustomerId or EventDate, or relying on Z-ORDER, because these approaches either create too many small files or require manual maintenance as the table grows.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Liquid clustering is the recommended layout optimization for large, growing Delta tables in Azure Databricks because it replaces partitioning and Z-ORDER with a flexible, automatic clustering strategy. It allows you to define clustering keys on CustomerId and EventDate without rewriting existing data, and it maintains performance as the table grows. Deletion vectors enable efficient row-level updates and deletes by marking rows as deleted in a separate vector instead of rewriting entire Parquet files, which directly minimizes update and deletion effort. Together, these features satisfy the requirement to keep query performance consistent while reducing the overhead of frequent compliance updates and deletes.Why Other Candidate Answers Are Wrong
Partitioning on CustomerId or EventDate is a common but flawed choice: CustomerId likely has high cardinality, leading to an explosion of small partitions and poor performance, while EventDate partitioning may become stale if query patterns change. Z-ORDER requires periodic OPTIMIZE ZORDER BY commands, which is manual maintenance and does not adapt automatically as data grows. Not enabling deletion vectors means every update or delete rewrites whole files, increasing I/O and latency. Predictive optimization can help with compaction but does not address row-level deletion efficiency.Community Comment Notes
The top community answer from dgerok explicitly identifies both selections: "Optimize query performance: Liquid clustering" and "Optimize updates and deletions: Enable deletion vectors." They note that "Liquid clustering is the modern Databricks recommendation for large, growing Delta tables" and that it "avoids the maintenance overhead of partitioning and repeated Z-Ordering." This aligns with the official Databricks guidance and confirms that combining liquid clustering with deletion vectors is the expected DP-750 answer.Official Reference
Exam Strategy
When a question describes a growing Delta table with frequent updates/deletes and filter columns, immediately think Liquid clustering + deletion vectors. Avoid options that involve partitioning or Z-ORDER unless the table is static and filter columns are fixed.
Frequently Asked Questions
Why choose Liquid clustering over partitioning for CustomerId and EventDate filters?
Liquid clustering handles high-cardinality columns and evolving filter patterns without re-partitioning, while partitioning on CustomerId would create too many small files and degrade performance.
How do deletion vectors reduce the effort of frequent updates and deletes?
Deletion vectors mark rows as deleted without rewriting full Parquet files, so compliance updates and deletes complete faster and with less write amplification.