Uh oh!
There was an error while loading. Please reload this page.
[opt](split) get file splits in batch mode - #34032
Conversation
doris-robot
commented
Apr 23, 2024
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
clang-tidy review says "All clean, LGTM! 👍" |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
clang-tidy review says "All clean, LGTM! 👍" |
9e436b6 to
380cea0Compareclang-tidy review says "All clean, LGTM! 👍" |
1 similar comment
clang-tidy review says "All clean, LGTM! 👍" |
AshinGau
commented
May 7, 2024
run buildall |
clang-tidy review says "All clean, LGTM! 👍" |
AshinGau
commented
May 7, 2024
run buildall |
clang-tidy review says "All clean, LGTM! 👍" |
AshinGau
commented
May 8, 2024
run buildall |
clang-tidy review says "All clean, LGTM! 👍" |
doris-robot
commented
May 8, 2024
TeamCity be ut coverage result: |
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
| SplitSource splitSource = new SplitSource( | ||
| this::splitToScanRange, backend, locationProperties, splits, pathPartitionKeys); | ||
| splitSources.add(splitSource); | ||
| SplitSourceManager.registerSplitSource(splitSource); |
| import java.util.Map; | ||
| import java.util.concurrent.ConcurrentHashMap; | ||
| public class SplitSourceManager { |
There was a problem hiding this comment.
Suggest:
- not using singletion
- extends
MasterDaemonclass
| return QeProcessorImpl.INSTANCE.reportExecStatus(params, getClientAddr()); | ||
| } | ||
| public TFetchSplitBatchResult fetchSplitBatch(TFetchSplitBatchRequest request) throws TException { |
| LOG(WARNING) << "Failed to get batch of split source: {}, try to reopen" << e1.what(); | ||
| RETURN_IF_ERROR(coord.reopen()); | ||
| try { | ||
| coord->fetchSplitBatch(result, request); |
There was a problem hiding this comment.
Maybe we should not retry when failure.
If first call fail, it is highly possible the second would fail too.
Simply fail this query to avoid avalanche
| @ConfField(mutable = true, masterOnly = false, description = { | ||
| "如果切片数量超过阈值,BE将通过batch方式获取scan ranges", | ||
| "If the number of splits exceeds the threshold, scan ranges will be got through batch mode."}) | ||
| public static int num_splits_in_batch_mode = 10000; |
There was a problem hiding this comment.
Better be a session varible?
doris-robot
commented
May 13, 2024
TPC-H: Total hot run time: 41933 ms |
doris-robot
commented
May 13, 2024
TPC-DS: Total hot run time: 187732 ms |
doris-robot
commented
May 14, 2024
TeamCity be ut coverage result: |
PR approved by at least one committer and no changes requested. |
When scanning a table with many files, It will take a lot of time to transfer splits to backends.(20s of the following 1209172 splits). Therefore, using batch mode to fetch the file splits, BE can do scanning while fetch the file splits.
When scanning a table with many files, It will take a lot of time to transfer splits to backends.(20s of the following 1209172 splits). Therefore, using batch mode to fetch the file splits, BE can do scanning while fetch the file splits.
When scanning a table with many files, It will take a lot of time to transfer splits to backends.(20s of the following 1209172 splits). Therefore, using batch mode to fetch the file splits, BE can do scanning while fetch the file splits.
When scanning a table with many files, It will take a lot of time to transfer splits to backends.(20s of the following 1209172 splits). Therefore, using batch mode to fetch the file splits, BE can do scanning while fetch the file splits.
PR #34032 introduce a new method to get splits batch by batch, but it removed a logic that BE will merge scan ranges to avoid too many scan ranges being scheduled. This PR mainly changes: 1. Add scan range merging logic back. 2. Change the default file split size from 8MB to 64MB, to avoid too many small split.
PR apache#34032 introduce a new method to get splits batch by batch, but it removed a logic that BE will merge scan ranges to avoid too many scan ranges being scheduled. This PR mainly changes: 1. Add scan range merging logic back. 2. Change the default file split size from 8MB to 64MB, to avoid too many small split.
PR #34032 introduce a new method to get splits batch by batch, but it removed a logic that BE will merge scan ranges to avoid too many scan ranges being scheduled. This PR mainly changes: 1. Add scan range merging logic back. 2. Change the default file split size from 8MB to 64MB, to avoid too many small split.
PR #34032 introduce a new method to get splits batch by batch, but it removed a logic that BE will merge scan ranges to avoid too many scan ranges being scheduled. This PR mainly changes: 1. Add scan range merging logic back. 2. Change the default file split size from 8MB to 64MB, to avoid too many small split.
When scanning a table with many files, It will take a lot of time to transfer splits to backends.(20s of the following 1209172 splits). Therefore, using batch mode to fetch the file splits, BE can do scanning while fetch the file splits.
PR apache#34032 introduce a new method to get splits batch by batch, but it removed a logic that BE will merge scan ranges to avoid too many scan ranges being scheduled. This PR mainly changes: 1. Add scan range merging logic back. 2. Change the default file split size from 8MB to 64MB, to avoid too many small split.
Proposed changes
When scanning a table with many files, It will take a lot of time to transfer splits to backends.(20s of the following 1209172 splits).
Therefore, using batch mode to fetch the file splits, BE can do scanning while fetch the file splits.
Further comments
If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...