背景
最近在研究了一下 Starrocks的tablet的Rebalance的能力,这里进行记录一下
本文基于 StarRocks 3.3.5
结论
数据的rebalance 主要以两种模式来进行:
- 按照磁盘的使用率进行移动,如果每个BE的磁盘使用率不足
tablet_sched_balance_load_disk_safe_threshold
(默认是50%),
或者 BE间磁盘的最大使用率和最小使用率相差不超过tablet_sched_balance_load_score_threshold
(默认10%),就认为不需要进行数据均衡 - 以tablet的副本数量进行移动,不断把副本从副本数多的BE节点 转移到 副本数少的节点上
- 以BE内的磁盘使用率为基准,按照高磁盘使用率往低磁盘使用率的原则进行数据迁移
- 以BE内的各个路径的tablets副本数据为基准 ,按照路径中副本数高的往副本数低的原则进行数据秦阿姨
其中里面设计到的移动都是以 tablet Replica(副本)为单位进行移动的,
且统计信息的来源是来自SystemInfoService
,对于每个磁盘类型(HDD,SSD)都会做Rebalance操作
分析
统计信息的来源
ClusterLoadStatistic
的统计信息,这个是来自于SystemInfoService
,而最终的信息是来源于 BE和 FE进行交互的FrontendServiceImpl
,BE会上报给FE信息,这些信息
在FE则会调用 ReportHandler的 exec
方法,从而更新到 SystemInfoService
中。
@Override
protected void exec() {
if (tasks != null) {
ReportHandler.taskReport(beId, tasks);
}
if (disks != null) {
ReportHandler.diskReport(beId, disks);
}
if (tablets != null) {
ReportHandler.tabletReport(beId, tablets, reportVersion);
}
if (activeWorkGroups != null) {
ReportHandler.workgroupReport(beId, activeWorkGroups);
}
if (resourceUsage != null) {
ReportHandler.resourceUsageReport(beId, resourceUsage);
}
if (dataCacheMetrics != null) {
ReportHandler.datacacheMetricsReport(beId, dataCacheMetrics);
}
}
tablet调度数据流
其中最主要的数据流如下:
TabletScheduler.runAfterCatalogReady
||
\/
TabletScheduler.schedulePendingTablets //一次性调度队列中剩余的所有的Rebalance任务
||
\/
TabletScheduler.handleRunningTablets // 取消超时的Rebalance任务,这个超时时间是根据 TabletSchedCtx.getApproximateTimeoutMs 方法获取的
||
\/
TabletScheduler.selectTabletsForBalance
||
\/
Rebalancer.selectAlternativeTablets => selectAlternativeTabletsForCluster
||
\/
balanceClusterDisk
||
\/
balanceClusterTablet
||
\/
balanceBackendDisk
||
\/
balanceBackendTablet
||
\/
handleForceCleanSchedQ // 如果有用户调用了`CLEAN TABLET SCHEDULER QUEUE`命令,则会强制清除包括正在运行的所有的数据Rebalance任务
||
\/
stat.counterTabletScheduleRound.incrementAndGet() // 记录tablet schedule调度的次数
其中 balanceClusterDisk balanceClusterTablet balanceBackendDisk balanceBackendTablet 分别对应上述的1 2 3 4 四点。