[
https://issues.apache.org/jira/browse/FLINK-10461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16698751#comment-16698751
]
ASF GitHub Bot commented on FLINK-10461:
----------------------------------------
azagrebin commented on a change in pull request #6777: [FLINK-10461] [State
Backends, Checkpointing] Speed up download files when restore from DFS
URL: https://github.com/apache/flink/pull/6777#discussion_r236198988
##########
File path:
flink-state-backends/flink-statebackend-rocksdb/src/main/java/org/apache/flink/contrib/streaming/state/RocksDBStateBackend.java
##########
@@ -236,8 +239,25 @@ public RocksDBStateBackend(StateBackend
checkpointStreamBackend) {
* @param enableIncrementalCheckpointing True if incremental
checkpointing is enabled.
*/
public RocksDBStateBackend(StateBackend checkpointStreamBackend,
TernaryBoolean enableIncrementalCheckpointing) {
+ this(checkpointStreamBackend, enableIncrementalCheckpointing,
CheckpointingOptions.CHECKPOINT_RESTORE_THREAD_NUM.defaultValue());
+ }
+
+ /**
+ * Creates a new {@code RocksDBStateBackend} that uses the given state
backend to store its
+ * checkpoint data streams. Typically, one would supply a filesystem or
database state backend
+ * here where the snapshots from RocksDB would be stored.
+ *
+ * <p>The snapshots of the RocksDB state will be stored using the given
backend's
+ * {@link StateBackend#createCheckpointStorage(JobID)}.
+ *
+ * @param checkpointStreamBackend The backend write the checkpoint
streams to.
+ * @param enableIncrementalCheckpointing True if incremental
checkpointing is enabled.
+ * @param restoredThreadNum thread num used to download files from DFS
when restore.
+ */
+ public RocksDBStateBackend(StateBackend checkpointStreamBackend,
TernaryBoolean enableIncrementalCheckpointing, int restoredThreadNum) {
this.checkpointStreamBackend =
checkNotNull(checkpointStreamBackend);
this.enableIncrementalCheckpointing =
enableIncrementalCheckpointing;
+ this.restoredThreadNum = restoredThreadNum;
Review comment:
Actually, instead of changing and exploding the constructor signatures, I
would suggest to set it here to -1 (undefined). Then we could remove `final`
from `restoredThreadNum` and add setter method for it, like for
`predefinedOptions`. Users could use the setter to set this option per job.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Speed up download file procedure when restore
> ----------------------------------------------
>
> Key: FLINK-10461
> URL: https://issues.apache.org/jira/browse/FLINK-10461
> Project: Flink
> Issue Type: Improvement
> Components: State Backends, Checkpointing
> Reporter: Congxian Qiu
> Assignee: Congxian Qiu
> Priority: Major
> Labels: pull-request-available
>
> In the current master branch, the restore will download file from DFS, the
> download procedure are single-thread, this could speed up by using
> multi-thread for downloading states from DFS.
>
> In my company, the states will come to some terabytes, so the restore
> procedure will become a litter slow, after a bit digging, I find download
> states from DFS using single thread, this could using multi-thread for speed
> up.
> I test the time used for download states from DFS with ~2 terabytes states.
> With single thread it used 640+s, and 130+s when using 5 threads for download.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
