Databricks IO Cache

The Databricks IO cache accelerates data reads by creating copies of remote files in nodes’ local storage using fast intermediate data format. The data is cached automatically whenever a file has to be fetched from a remote location. Successive reads of the same data are then executed locally, which results in significantly improved reading speed.

The Databricks IO cache supports reading Parquet files from DBFS, HDFS, Azure Blob Storage, Azure Data Lake Storage Gen1, and Azure Data Lake Storage Gen2 (on Databricks Runtime 5.1 and above). It does not support other storage formats such as CSV, JSON, and ORC.

Important

To use Databricks IO cache, choose Ls series worker instance type for your cluster.

../_images/dbio-cache-cluster-creation-azure.png

The DBIO cache is configured to use at most half of the space available on the local SSDs provided with the worker nodes.

With Databricks Runtime 4.3 and above, the cache is enabled by default. With Databricks Runtime 4.0 to 4.2, enable the cache by setting spark.databricks.io.cache.enabled to true.

The DBIO cache is available only in the Azure Databricks Premium Plan.

Databricks IO and RDD cache comparison

There are two types of cache available in Azure Databricks:

  • Databricks IO (DBIO) cache
  • Apache Spark RDD (RDD) cache

You can use the DBIO cache and the RDD cache at the same time. This section outlines the key differences between them so that you can choose the best tool for your workflow.

Type of stored data

The DBIO cache contains local copies of remote data. It can improve the performance of a wide range of queries, but cannot be used to store results of arbitrary subqueries.

The RDD cache can store the result of any subquery data and data stored in formats other than Parquet (such as CSV, JSON, and ORC).

Performance
The data stored in the DBIO cache can be read and operated on faster than the data in the RDD cache. This is because the DBIO cache uses efficient decompression algorithms and outputs data in the optimal format for further processing using whole-stage code generation.
Automatic vs manual control

When the DBIO cache is enabled, data that has to be fetched from a remote source is automatically added to the cache. This process is fully transparent and does not require any action. However, to preload data into the cache beforehand, you can use the CACHE command (see Cache a subset of the data).

When you use the RDD cache, you must manually specify the tables and queries to cache.

Disk vs memory-based
The DBIO cache is stored entirely on the local disk, so that memory is not taken away from other operations within Spark. Due to the high read speeds of modern SSDs, the DBIO cache can be fully disk-resident without a negative impact on its performance. In contrast, the RDD cache uses memory.

DBIO cache consistency

The DBIO cache automatically detects when data files are created or deleted and updates its content accordingly.

You can write, modify, and delete table data with no need to explicitly invalidate cached data.

Warning

When working with the DBIO cache, the data files must not be overwritten. That is, files must not be replaced with files with the same name, but different content.

If the cached data files are overwritten, queries accessing these files can produce invalid results or read errors. Spark uses unique file names and never alters the data files. However, the data files can still be overwritten using shell commands or external programs.

If you need to overwrite the data files, disable the DBIO cache.

Cache a subset of the data

To explicitly select a subset of data to be cached, use following syntax:

CACHE SELECT column_name[, column_name, ...] FROM [db_name.]table_name [ WHERE boolean_expression ]

You don’t need to use this command for the Databricks DBIO cache to work correctly (the data will be automatically cached when first accessed). But it can be helpful when you require consistent query performance.

See Cache for examples and more details.

Monitor the DBIO cache

You can check the current state of the DBIO cache on each of the executors in the Storage tab in the Spark UI.

../_images/dbio-cache-spark-ui-storage-tab.png

When a node reaches 100% disk usage, the cache manager discards the least recently used cache entries to make space for new data.

Configure the DBIO cache

Tip

Azure Databricks recommends choosing cache-accelerated worker instance type for your clusters. Such instances are automatically configured optimally for the DBIO cache.

Configure disk usage

To choose how the DBIO cache uses the worker nodes’ local storage, specify the following Spark configuration settings during cluster creation:

  • spark.databricks.io.cache.maxDiskUsage - disk space per node reserved for cached data in bytes
  • spark.databricks.io.cache.maxMetaDataCache - disk space per node reserved for cached metadata in bytes
  • spark.databricks.io.cache.compression.enabled - should the cached data be stored in compressed format

Example configuration:

spark.databricks.io.cache.maxDiskUsage 50g
spark.databricks.io.cache.maxMetaDataCache 1g
spark.databricks.io.cache.compression.enabled false

Enable the DBIO cache

To enable and disable the DBIO cache, run:

spark.conf.set("spark.databricks.io.cache.enabled", "[true | false]")

Disabling the cache does not result in dropping the data that is already in the local storage. Instead, it prevents queries from adding new data to the cache and reading data from the cache.