HIVE-30053: Support multi-threaded CachedStore prewarm - #6785
Merged
Merged
Conversation
neatHyperTxt-meesho
force-pushed
the
parallel-prewarm
branch
from
September 15, 2026 10:19
1b7b13b to
5e8da00
Compare
neatHyperTxt-meesho
force-pushed
the
parallel-prewarm
branch
from
September 15, 2026 19:02
5e8da00 to
8eb7afe
Compare
Member
neatHyperTxt-meesho
force-pushed
the
parallel-prewarm
branch
from
September 16, 2026 04:56
8d3330a to
7144bc2
Compare
neatHyperTxt-meesho
force-pushed
the
parallel-prewarm
branch
from
September 16, 2026 07:12
7144bc2 to
d74ecb0
Compare
saihemanth-cloudera
requested review from
dengzhhu653
and
a lite review from Copilot
September 16, 2026 21:53
…make size estimators concurrency safe
neatHyperTxt-meesho
force-pushed
the
parallel-prewarm
branch
from
September 17, 2026 15:05
d74ecb0 to
d3f88cd
Compare
Contributor
Author
|
@dengzhhu653 @deniskuzZ @saihemanth-cloudera would appreciate a review when you get a chance |
dengzhhu653
reviewed
Sep 18, 2026
| } | ||
| sharedCache.populateDatabasesInCache(databases); | ||
| LOG.info("Databases cache is now prewarmed. Now adding tables, partitions and statistics to the cache"); | ||
| int numberOfDatabasesCachedSoFar = 0; |
Member
There was a problem hiding this comment.
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;
....
}
Contributor
Author
There was a problem hiding this comment.
Done, prewarm now lives behind a MetaCachePreWarm interface @dengzhhu653
… specifiers, interrupt handling, visibility, line length)
…interface declarations, dead throws, unused import)
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
Contributor
Author
|
Done @dengzhhu653 |
|
dengzhhu653
approved these changes
Sep 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



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.