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, Amazon S3, HDFS, Azure Blob Storage, and Azure Data Lake. It does not support other storage formats such as CSV, JSON, and ORC.
There are two types of cache available in Databricks:
- Databricks IO (DBIO) cache
- Apache Spark RDD (RDD) cache
You can use the DBIO cache and the RDD cache at the same time. In this section we outline 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).
- 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
CACHEcommand (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.
In Databricks Runtime 3.3 and above, the DBIO cache is enabled by default and preconfigured to use at most half of the space available on the SSDs provided with the chosen instance type for i3 instance worker nodes.
No further configuration is required and you can skip the following steps.
To configure the DBIO cache, during cluster creation specify the following Spark configuration settings:
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.maxDiskUsage 14000000000 spark.databricks.io.cache.maxMetaDataCache 300000000
In Databricks Runtime 3.5 and above you can express the disk space value using suffixes k, m, g, and so on. For example, you can write the preceding examples as:
spark.databricks.io.cache.maxDiskUsage 14g spark.databricks.io.cache.maxMetaDataCache 300m
Databricks recommends that you use the following values:
spark.databricks.io.cache.maxDiskUsage: 50% of the total available storage space per node
spark.databricks.io.cache.maxMetaDataCache: 2% of the space dedicated to
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.
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.