Skip to content

HIVE-30053: Support multi-threaded CachedStore prewarm - #6785

Merged
dengzhhu653 merged 7 commits into
apache:masterfrom
neatHyperTxt-meesho:parallel-prewarm
Sep 21, 2026
Merged

dengzhhu653 merged 7 commits into
apache:masterfrom
neatHyperTxt-meesho:parallel-prewarm

Conversation

@neatHyperTxt-meesho

@neatHyperTxt-meesho neatHyperTxt-meesho commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

Adds metastore.cached.rawstore.prewarm.threads (default 1 = current single-threaded behavior). With N > 1, prewarm fans the per-table work (table + partitions + statistics + constraints) out to N worker threads, each with its own RawStore instance — mirroring how CacheUpdateMasterWork creates its private store. Workers drain the existing TablesPendingPrewarm stack, so each table is handed out exactly once and the prioritizeTableForPrewarm hot-table promotion keeps working. The memory-full early stop uses a shared flag with completePrewarm called exactly once, and the worker pool plus worker stores are torn down when prewarm finishes. The per-table logic is extracted verbatim into prewarmTable(); the single-threaded path runs through the same code.

Why are the changes needed?

Prewarm is single-threaded and latency-bound: one thread issues ~6-8 sequential queries per table. On our production deployment (Hive 4.2.0, 21k cached tables) prewarm takes ~10 minutes; with 8 threads it takes 195s vs 602s baseline (3.1x). Each worker uses one connection from the shared pool, so the config doc advises keeping the value below the pool size.

Does this PR introduce any user-facing change?

A new optional config, metastore.cached.rawstore.prewarm.threads, default 1 (no behavior change unless set).

How was this patch tested?

New unit test TestCachedStore#testPrewarmMultiThreaded runs a full prewarm with 4 threads against Derby and asserts every database, table and partition is cached. Full TestCachedStore suite passes (32/32). Benchmarked on a production deployment: 602s (1 thread) -> 195s (8 threads) for 21k tables.

@deniskuzZ

deniskuzZ commented Sep 15, 2026

Copy link
Copy Markdown
Member

cc @dengzhhu653, @saihemanth-cloudera

@neatHyperTxt-meesho

Copy link
Copy Markdown
Contributor Author

@dengzhhu653 @deniskuzZ @saihemanth-cloudera would appreciate a review when you get a chance

}
sharedCache.populateDatabasesInCache(databases);
LOG.info("Databases cache is now prewarmed. Now adding tables, partitions and statistics to the cache");
int numberOfDatabasesCachedSoFar = 0;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you separate the prewarm from this class please, and create an interface to warm up the cache?
An interface for example:

interface MetaCachePreWarm extends AutoClosable, Configurable {
   void initialize() throws MetaException;
   void preWarm() throws MetaException;
....
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, prewarm now lives behind a MetaCachePreWarm interface @dengzhhu653

… specifiers, interrupt handling, visibility, line length)
…interface declarations, dead throws, unused import)
@dengzhhu653

Copy link
Copy Markdown
Member

we can move TablesPendingPrewarm into MetaCachePreWarm, and adds a new prioritizeTableForPrewarm(TableName ... tableName) method in MetaCachePreWarm.

Rest looks goods to me

…izeTableForPrewarm(TableName...) to MetaCachePreWarm per review
@neatHyperTxt-meesho

Copy link
Copy Markdown
Contributor Author

Done @dengzhhu653

@sonarqubecloud

Copy link
Copy Markdown

@dengzhhu653
dengzhhu653 merged commit 21dc6c1 into apache:master Sep 21, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants