chenzihao5 opened a new pull request, #28402:
URL: https://github.com/apache/flink/pull/28402
## What is the purpose of the change
This pull request introduces a pluggable archive storage backend for the
HistoryServer, so that downloaded job archives no longer have to be unpacked
into a large number of small JSON files on the local filesystem. And this PR
adds a RocksDB backend that stores all archive entries as key-value pairs
inside a single embedded RocksDB instance, while keeping the existing FILE
backend as the default to preserve backwards compatibility.
## Brief change log
- Introduce the ArchiveStorage abstraction with two implementations:
- FileArchiveStorage — existing behavior, one JSON file per entry under
historyserver.web.tmpdir (default).
- RocksDBArchiveStorage — stores all entries as key-value pairs in a
single embedded RocksDB instance under historyserver.web.tmpdir/rocksdb.
- Add new ConfigOptions in HistoryServerOptions:
- historyserver.archive.storage.type (FILE | ROCKSDB, default FILE)
- historyserver.archive.rocksdb.native-lib-dir
- historyserver.archive.rocksdb.compression
- historyserver.archive.rocksdb.bottommost-compression
- Wire the selected backend into HistoryServer /
HistoryServerArchiveFetcher so archive read/write paths go through
ArchiveStorage.
- Standardized the resource request processing workflow in
AbstractHistoryServerHandler.
- Add documents for this feature.
## Verifying this change
This change added tests and can be verified as follows:
- Added unit tests for ArchiveStorage covering exists / get / put / delete
/ deletePrefix / getByPrefix and lifecycle of archive data.
- Added common unit tests in AbstractHistoryServerHandlerTest for
different archive storage.
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): yes
- The public API, i.e., is any changed class annotated with
`@Public(Evolving)`: no
- The serializers: no
- The runtime per-record code paths (performance sensitive): no
- Anything that affects deployment or recovery: JobManager (and its
components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
- The S3 file system connector: no
## Documentation
- Does this pull request introduce a new feature? yes
- If yes, how is the feature documented? docs
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes (Claude-4.7-Opus 1M Context)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
