-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clean up the balancing code around the batched vs deprecated way of sampling segments to balance #11960
clean up the balancing code around the batched vs deprecated way of sampling segments to balance #11960
Conversation
…ampling segments to balance
@yuanlihan could you take a look at this since you wrote the original code for the batched sampler! I hope my code makes sense, but please comment on any mistakes I may have made! |
Iterator<BalancerSegmentHolder> segmentsToMove = strategy.pickSegmentsToMove( | ||
toMoveFrom, | ||
params.getBroadcastDatasources(), | ||
params.getCoordinatorDynamicConfig().useBatchedSegmentSampler() ? maxSegmentsToMove : DEFAULT_RESERVOIR_SIZE, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can delete this unused constant variable
Hi @capistrant |
docs/configuration/index.md
Outdated
@@ -886,7 +886,7 @@ Issuing a GET request at the same URL will return the spec that is currently in | |||
|`mergeSegmentsLimit`|The maximum number of segments that can be in a single [append task](../ingestion/tasks.md).|100| | |||
|`maxSegmentsToMove`|The maximum number of segments that can be moved at any given time.|5| | |||
|`useBatchedSegmentSampler`|Boolean flag for whether or not we should use the Reservoir Sampling with a reservoir of size k instead of fixed size 1 to pick segments to move. This option can be enabled to speed up segment balancing process, especially if there are huge number of segments in the cluster or if there are too many segments to move.|false| | |||
|`percentOfSegmentsToConsiderPerMove`|The percentage of the total number of segments in the cluster that are considered every time a segment needs to be selected for a move. Druid orders servers by available capacity ascending (the least available capacity first) and then iterates over the servers. For each server, Druid iterates over the segments on the server, considering them for moving. The default config of 100% means that every segment on every server is a candidate to be moved. This should make sense for most small to medium-sized clusters. However, an admin may find it preferable to drop this value lower if they don't think that it is worthwhile to consider every single segment in the cluster each time it is looking for a segment to move.|100| | |||
|`percentOfSegmentsToConsiderPerMove`|Deprecated. Will eventually be phased out by the batched segment sampler. Only used if `useBatchedSegmentSampler == false`. The percentage of the total number of segments in the cluster that are considered every time a segment needs to be selected for a move. Druid orders servers by available capacity ascending (the least available capacity first) and then iterates over the servers. For each server, Druid iterates over the segments on the server, considering them for moving. The default config of 100% means that every segment on every server is a candidate to be moved. This should make sense for most small to medium-sized clusters. However, an admin may find it preferable to drop this value lower if they don't think that it is worthwhile to consider every single segment in the cluster each time it is looking for a segment to move.|100| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a similar deprecation message in the web console description for this property?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, good call @a2l007
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we document what the preferred alternative is here?
Tagging this under Release Notes so that users are aware of the deprecation of |
@a2l007 @yuanlihan thank you both for reviewing! I synced up with master and plan on merging once CI is green. |
docs/configuration/index.md
Outdated
@@ -886,7 +886,7 @@ Issuing a GET request at the same URL will return the spec that is currently in | |||
|`mergeSegmentsLimit`|The maximum number of segments that can be in a single [append task](../ingestion/tasks.md).|100| | |||
|`maxSegmentsToMove`|The maximum number of segments that can be moved at any given time.|5| | |||
|`useBatchedSegmentSampler`|Boolean flag for whether or not we should use the Reservoir Sampling with a reservoir of size k instead of fixed size 1 to pick segments to move. This option can be enabled to speed up segment balancing process, especially if there are huge number of segments in the cluster or if there are too many segments to move.|false| | |||
|`percentOfSegmentsToConsiderPerMove`|The percentage of the total number of segments in the cluster that are considered every time a segment needs to be selected for a move. Druid orders servers by available capacity ascending (the least available capacity first) and then iterates over the servers. For each server, Druid iterates over the segments on the server, considering them for moving. The default config of 100% means that every segment on every server is a candidate to be moved. This should make sense for most small to medium-sized clusters. However, an admin may find it preferable to drop this value lower if they don't think that it is worthwhile to consider every single segment in the cluster each time it is looking for a segment to move.|100| | |||
|`percentOfSegmentsToConsiderPerMove`|Deprecated. Will eventually be phased out by the batched segment sampler. Only used if `useBatchedSegmentSampler == false`. The percentage of the total number of segments in the cluster that are considered every time a segment needs to be selected for a move. Druid orders servers by available capacity ascending (the least available capacity first) and then iterates over the servers. For each server, Druid iterates over the segments on the server, considering them for moving. The default config of 100% means that every segment on every server is a candidate to be moved. This should make sense for most small to medium-sized clusters. However, an admin may find it preferable to drop this value lower if they don't think that it is worthwhile to consider every single segment in the cluster each time it is looking for a segment to move.|100| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we document what the preferred alternative is here?
This should make sense for most small to medium-sized clusters. However, an admin may find | ||
it preferable to drop this value lower if they don't think that it is worthwhile to | ||
consider every single segment in the cluster each time it is looking for a segment to move. | ||
Deprecated. This will be phased out by the batched segment sampler. Only used if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we document what the preferred alternative is here as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you clarify what you mean by this? I take it as you asking me to state that the preferred alternative is to set useBatchedSegmentSampler == true
. so perhaps:
Deprecated. Will eventually be phased out by the batched segment sampler. You can enable the batched segment sampler now by setting the dynamic Coordinator config,
useBatchedSegmentSampler
, totrue
. Note that if you choose enable the batched segment sampler, this config has no effect on balancing. IfuseBatchedSegmentSampler == false
, this config defines the percentage of the total number of segments in the cluster that are considered every time a segment needs to be selected for a move. Druid orders servers by available capacity ascending (the least available capacity first) and then iterates over the servers. For each server, Druid iterates over the segments on the server, considering them for moving. The default config of 100% means that every segment on every server is a candidate to be moved. This should make sense for most small to medium-sized clusters. However, an admin may find it preferable to drop this value lower if they don't think that it is worthwhile to consider every single segment in the cluster each time it is looking for a segment to move.|100|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for ambiguity. Yes, encouraging using useBatchedSegmentSampler
instead will be enough. The one in your comment looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Please consider my comments before merging it.
@capistrant thank you for updating docs. Feel free to merge once the "docs" CI passes. |
The "docs' CI passed. Merging this PR. |
Start release notes suggestion
The dynamic coordinator config,
percentOfSegmentsToConsiderPerMove
has been deprecated and will be removed in a future release of Druid. It is being replaced by a new segment picking strategy introduced in #11257. This new strategy is currently toggled off by default, but can be toggled on if you set the dynamic coordinator configuseBatchedSegmentSampler
totrue
. Setting this as such, will disable the use of the deprecatedpercentOfSegmentsToConsiderPerMove
. In a future release,useBatchedSegmentSampler
will become permanently true.End release notes suggestion
Description
Fixed unintended code path execution in BalancerStrategy#pickSegmentsToMove
#11257 Introduced a new way of sampling segments for balancing that is much more performant than the legacy way that exists today. There is a case in the code where the deprecated code can be executed despite, the dynamic config for batched segment sampling being enabled. In this line of code, if
useBatchedSegmentSampler() == true
andmaxSegmentsToMove == 1
, you would expect the batched segment sampler code to execute. However, you can see here that the new batched sampler is not used in this case because reservoir size is 1. This PR fixes this behavior by splittingBalancerStrategy#pickSegmentsToMove(List<ServerHolder>, Set<String>, int, double)
into two methods using overloading - one for the new batched sampler, and one for the deprecated way of sampling one segment at a time. This change will also simplify cleanup of the deprecated code in what I assume will be the 0.24.X cycle.Cleaned up the code for the competing segment pick strategies (deprecated vs batched segment sampler)
I did a few things to make the code more understandable and to make it abundantly clear that the old way of sampling segments to move with the help of the dynamic config
percentOfSegmentsToConsiderPerMove
is deprecated:@Deprecated
annotations to theCoordinatorDynamicConfig
code related topercentOfSegmentsToConsiderPerMove
percentOfSegmentsToConsiderPerMove
is deprecated and will have no effect ifuseBatchedSegmentSampler
dynamic config istrue
BalancerStrategy#pickSegmentsToMove
into two methods with the same name and overloaded arguments. One implementation is deprecated and takes a double forpercentOfSegmentsToConsiderPerMove
while the other is the new batched sampler which takes anint
for the reservoir size.BalanceSegments#balanceServers
more understandable to those with limited familiarity with this work to migrate to the batched segment sampler. Before the call toBalancerStrategy#pickSegmentsToMove
was opaque because it included both the reservoir size and the percent of segments to consider per move despite only one of those arguments being used depending on the value of the reservoir size (this also relates to the unintended code execution I talk about above). The new way makes it clear that if batched segment sampling is enabled, the non-deprecatedpickSegmentsToMove
is called. And if it is not, the deprecatedpickSegmentsToMove
is called.Key changed/added classes in this PR
BalanceSegments
CoordinatorDynamicConfig
BalancerStrategy
This PR has: