[LoadBalance] make BeLoadRebalancer extends from base class Rebalancer

[vagetablechicken]

Proposed changes

Create a base class Rebalancer, support to delete the specified replica(actually add a new priority in handling redundant replica).
The origin LoadBalancer, which will named as BeLoadRebalancer, just need to extend from Rebalancer without any logic change.

Types of changes

• Code refactor (Modify the code structure, format the code, etc...)

Checklist

• I have create an issue on (Fix [Proposal] refactor the LoadBalancer to support more rebalance strategies #4763), and have described the bug/feature there in detail
• Compiling and unit tests pass locally with my changes

[kangkaisen]

In Apache Druid. https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/server/coordinator/BalancerStrategy.java

pickSegmentToMove will choose which tablet replica to balance, naturally, the BE for the tablet replica is the src backend.

findNewSegmentHomeBalancer will choose the dest backend.

I think the Apache Druid BalancerStrategy interface logic and naming is clear.

[vagetablechicken]

How to choose the dest be is core for balance strategy, if the base class doesn't limit it, what's the meaning of balance base class.

It's based on the specific strategies. Some strategies can delay choosing the dest be until create a clone task, but some
strategies can't . So we don't overemphasize this.
The meaning of balance base class is to support delete the src replica, which the current class can't do.

In Apache Druid. https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/server/coordinator/BalancerStrategy.java

pickSegmentToMove will choose which tablet replica to balance, naturally, the BE for the tablet replica is the src backend.

findNewSegmentHomeBalancer will choose the dest backend.

I think the Apache Druid BalancerStrategy interface logic and naming is clear.

We want to import the kudu's rebalance strategy, it'll calculate a concrete move{partition id, src be, dest be}, so it's no need to separate into choose one tablet and src be & find dest be.

In Doris, rebalance has 2 steps:

1. select tablet, and clone a replica on dest be, so the tablet is redundant
2. delete redundant replica

The key point is, step 2 will generate another TabletSchedCtx , we can't know which replica is the replica we want to delete. So we should try to get it from rebalancer.

[kangkaisen]

@vagetablechicken Hi, I see what's your mean.

I agree with your interface logic. But for the method naming, I think we would better rename it.

For selectAlternativeTabletsForCluster method, the nameing or comment should let other people know we
select {tablet id, src be, dest be} at one time in this method.

For getSrcReplicaId, rename it to getDeleteReplicaId ?

[morningman]

I have a question about the problem described in #4763. If we implement a new LoadBalancer that allow users to specify a tablet to migrate from node A to node B. But after the migration is completed, how to ensure that this tablet will not be migrated back again by the default balance strategy?

[kangkaisen]

I have a question about the problem described in #4763. If we implement a new LoadBalancer that allow users to specify a tablet to migrate from node A to node B. But after the migration is completed, how to ensure that this tablet will not be migrated back again by the default balance strategy?

I think in one cluster, we could only enable one balance strategy?

[vagetablechicken]

I have a question about the problem described in #4763. If we implement a new LoadBalancer that allow users to specify a tablet to migrate from node A to node B. But after the migration is completed, how to ensure that this tablet will not be migrated back again by the default balance strategy?

I think in one cluster, we could only enable one balance strategy?

Yes, only one.

[kangkaisen]

+1

[morningman]

LGTM