E-MapReduce:Data cache for data lakes

Overview

In data lake analytics, StarRocks acts as an OLAP query engine that frequently scans data files on HDFS or object storage. For scenarios that repeatedly access the same data, such as ad-hoc queries, extensive remote I/O can become a performance bottleneck.

Available since v2.5, the Data Cache feature caches raw data from external storage on local BE nodes by splitting it into blocks. This approach avoids redundant data fetching from remote sources and accelerates query and analytics performance for hot data.

Limitations

• Data Cache for data lakes is supported in StarRocks v2.5 and later, and is enabled by default starting from v3.3.0.

• It applies only to queries on external tables and External Catalogs, not to queries on native tables.

• It supports External Catalog types that use the StarRocks Native File Reader (such as Hive, Iceberg, Hudi, Delta Lake, and Paimon). It does not support catalogs that access data via JNI (such as JDBC Catalog).

Cache media

StarRocks uses the memory and disks of BE/CN nodes as cache media and supports the following caching modes:

• Memory-only cache: Offers the fastest caching speed but is limited by memory capacity.

• Two-tier cache (memory + disk): Expands cache capacity, balancing performance and cost.

Cache eviction mechanism

The memory and disk tiers of Data Cache evict data independently. In a two-tier (memory and disk) cache, the mechanism works as follows:

• The system first attempts to read data from memory. If a cache miss occurs in memory, it reads from disk and then tries to load the data into memory.

• Data evicted from memory is written to disk. Data evicted from disk is discarded.

StarRocks Data Cache supports two eviction policies: LRU and SLRU (Segmented LRU). SLRU is the default policy.

SLRU divides the cache space into an eviction segment and a probationary segment, both of which use an LRU policy. When data is first accessed, it enters the eviction segment. If data in the eviction segment is accessed again, it is promoted to the probationary segment. Data evicted from the probationary segment is moved back to the eviction segment. Data evicted from the eviction segment is removed from the cache. Compared to LRU, SLRU is more resistant to sudden, sparse traffic and protects frequently accessed data from being evicted by a single large-scale query.

Enable and disable Data Cache

Data Cache for data lakes is controlled by the system variable enable_scan_datacache and the BE parameter datacache_enable. It is enabled by default starting from v3.3.0. You can query its current status with the following SQL statement:

SHOW VARIABLES LIKE 'enable_scan_datacache';

The main configuration parameters are as follows:

To disable Data Cache, run the following command:

SET GLOBAL enable_scan_datacache = false;

Cache population rules

Since v3.3.2, to improve the cache hit rate, StarRocks uses the following rules to determine whether to populate the Data Cache:

• Non-SELECT queries (such as ANALYZE TABLE and INSERT INTO SELECT) do not populate the cache.

• Queries that scan all partitions of a table do not populate the cache (unless the table has only a single partition).

• Queries that scan all columns of a table do not populate the cache (unless the table has only a single column).

• Queries on tables other than Hive, Paimon, Delta Lake, Hudi, or Iceberg do not populate the cache.

You can use EXPLAIN VERBOSE to check if a query triggers cache population:

EXPLAIN VERBOSE SELECT col1 FROM hudi_table;

In the query plan, dataCacheOptions={populate: false} indicates that the query will not populate the cache. To force cache population, set the following variable:

SET populate_datacache_mode = 'always';

Footer Cache

StarRocks supports caching Parquet Footer objects. You can enable this feature by setting the following system variable:

SET GLOBAL enable_file_metacache = true;

I/O adaptiveness

When the I/O load on the cache disk is too high, the I/O adaptiveness feature of Data Cache automatically routes some cache requests to remote storage. This approach uses both the local cache and remote storage to increase I/O throughput and prevent significant long-tail disk latency. This feature is enabled by default. To enable it manually, run the following command:

SET GLOBAL enable_datacache_io_adaptor = true;

Monitor Data Cache

The information_schema.be_datacache_metrics view shows the capacity and usage of the memory and disk cache on each BE node:

SELECT * FROM information_schema.be_datacache_metrics;

Monitor SQL cache hits

You can monitor the following metrics in a query profile to evaluate the performance of Data Cache for a given query: