Auto Optimize

Auto Optimize is an optional set of features that automatically compact small files during individual writes to a Delta Lake table. Paying a small cost during writes offers significant benefits for tables that are queried actively. Auto Optimize is particularly useful in the following scenarios:

  • Streaming use cases where latency in the order of minutes is acceptable
  • MERGE INTO is the preferred method of writing into Delta Lake
  • CREATE TABLE AS SELECT or INSERT INTO are commonly used operations

How Auto Optimize works

Auto Optimize consists of 2 complementary features: Optimized Writes and Auto Compaction.

Optimized Writes
Azure Databricks dynamically optimizes Spark partition sizes based on the actual data, and attempts to write out 128 MB files for each table partition.
Auto Compaction
After an individual write, Azure Databricks checks if files can further be compacted, and runs a quick OPTIMIZE job (with 128 MB file sizes instead of 1GB) to further compact files for partitions that have the most number of small files.
../_images/optimized-writes.png

Requirements

Auto Optimize is available in Databricks Runtime 5.5 and above.

Usage

Auto Optimize is designed to be configured for specific Delta Lake tables. You enable Optimized Writes for a table by setting the table property delta.autoOptimize.optimizeWrite = true. Similarly, you set delta.autoOptimize.autoCompact = true to enable Auto Compaction.

  • For existing tables, run:

    ALTER TABLE [table_name | delta.`<table-path>`] SET TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true, delta.autoOptimize.autoCompact = true)
    
  • To ensure all new Delta Lake tables have these features enabled, set the SQL configuration:

    spark.databricks.delta.properties.defaults.autoOptimize.optimizeWrite = true spark.databricks.delta.properties.defaults.autoOptimize.autoCompact = true
    

In addition, you can enable and disable both of these features for Spark sessions with the configurations:

  • spark.databricks.delta.optimizeWrite.enabled
  • spark.databricks.delta.autoCompact.enabled

The session configurations take precedence over the table properties allowing you to better control when to opt-in or opt-out of these features.

When to opt-in and opt-out

This section provides guidance on when to opt-in and opt-out of Auto Optimize features.

Optimized Writes

Optimized Writes aim to maximize the throughput of data being written to a storage service. This can be achieved by reducing the number of files being written, without sacrificing too much parallelism.

Optimized Writes require the shuffling of data according to the partitioning structure of the target table. This shuffle naturally incurs additional cost. However, the throughput gains during the write may pay off the cost of the shuffle. If not, the throughput gains when querying the data should still make this feature worthwhile.

The key part of Optimized Writes is that it is an adaptive shuffle. If you have a streaming ingest use case and input data rates change over time, the adaptive shuffle will adjust itself accordingly to the incoming data rates across micro-batches. If you have code snippets where you coalesce(n) or repartition(n) just before you write out your stream, you can remove those lines.

When to opt-in

  • Streaming use cases where minutes of latency is acceptable
  • When using SQL commands like MERGE, UPDATE, DELETE, INSERT INTO, CREATE TABLE AS SELECT

When to opt-out

When the written data is in the order of terabytes and storage optimized instances are unavailable.

Auto Compaction

Auto Compaction occurs after a write to a table has succeeded and runs synchronously on the cluster that has performed the write. This means that if you have code patterns where you make a write to Delta Lake, and then immediately call OPTIMIZE, you can remove the OPTIMIZE call if you enable Auto Compaction.

Auto Compaction uses different heuristics than OPTIMIZE. Since it runs synchronously after a write, we have tuned Auto Compaction to run with the following properties:

  • Azure Databricks does not support Z-Ordering with Auto Compaction as Z-Ordering is significantly more expensive than just compaction.
  • Auto Compaction generates smaller files (128 MB) than OPTIMIZE (1 GB).
  • Auto Compaction greedily chooses a limited set of partitions that would best leverage compaction. The number of partitions selected will vary depending on the size of cluster it is launched on. If your cluster has more CPUs, more partitions can be optimized.

When to opt-in

  • Streaming use cases where minutes of latency is acceptable
  • When you don’t have regular OPTIMIZE calls on your table

When to opt-out

When other writers may be performing operations like DELETE, MERGE, UPDATE or OPTIMIZE concurrently as Auto Compaction may cause a transaction conflict for those jobs. If Auto Compaction fails due to a transaction conflict, Azure Databricks does not fail or retry the compaction.

Example workflow: Streaming ingest with concurrent deletes or updates

This workflow assumes that you have one cluster running a 24/7 streaming job ingesting data, and one cluster that runs on a(n) hourly, daily, or ad-hoc basis to delete or update a batch of records. For this use case, Azure Databricks recommends that you:

  • Enable Optimized Writes on the table level using ALTER TABLE <table_name|delta.`table_path`> SET TBLPROPERTIES (delta.autoOptimize.optimizeWrite = true). This will make sure that the number of files written by the stream and the delete and update jobs are of optimal sizes.
  • Enable Auto Compaction on the session level using spark.sql("set spark.databricks.delta.autoCompact.enabled = true") on the job that performs the delete or update. This will allow files to be compacted across your table. Since it will happen after the delete or update, you will mitigate the risks of a transaction conflict.

Frequently asked questions (FAQ)

Does Auto Optimize Z-Order files?
Auto Optimize performs compaction only on small files. It does not Z-Order files.
Does Auto Optimize corrupt Z-Ordered files?
Auto Optimize ignores files that are Z-Ordered. It only compacts new files.
If I have Auto Optimize enabled on a table that I’m streaming into, and a concurrent transaction conflicts with the optimize, will my job fail?
No. Transaction conflicts that cause Auto Optimize to fail are ignored, and the stream will continue to operate normally.
Do I need to schedule OPTIMIZE jobs if Auto Optimize is enabled on my table?
For tables with size greater than 10 TB, we recommend that you keep OPTIMIZE running on a schedule to further consolidate files, and reduce the metadata of your Delta Lake table. Since Auto Optimize does not support Z-Ordering, you should still schedule OPTIMIZE ... ZORDER BY jobs to run periodically.