基于本文回答

播面 播面

文图音视，全方位拆解八股文
0
评论
请从左侧选择一个分类

在线扩容 Doris 的完整步骤。当新加入一个 BE 节点时，Doris 是如何实现数据在后台自动负载均衡（Rebalance）且不影响在线读写业务的

在 Apache Doris 中，在线扩容 BE（Backend）节点是一个非常标准且平滑的操作。Doris 的架构设计天然支持高可用和动态扩容，整个过程无需停机，对上层业务几乎无感知。

下面将详细介绍 BE 扩容的完整步骤，以及 Doris 如何在后台实现数据自动负载均衡（Rebalance）且不影响在线读写的底层原理。

第一部分：在线扩容 BE 节点的完整步骤

步骤 1：准备新节点环境

在新服务器上完成与现有 BE 节点相同的系统环境配置。

  1. 安装 JDK（推荐 JDK 8 或 JDK 11，部分 External Catalog 依赖 JVM）。
  2. 修改系统最大打开文件数：
    bash 
    vi /etc/security/limits.conf
# 添加以下内容
* soft nofile 65536
* hard nofile 65536
* soft nproc 65536
* hard nproc 65536
  3. 修改虚拟内存映射限制：
    bash 
    sysctl -w vm.max_map_count=2000000
# 永久生效：echo "vm.max_map_count=2000000" >> /etc/sysctl.conf
  4. 关闭 Swap 交换分区（推荐以保障性能）。

步骤 2：分发并配置 BE 软件

  1. 从现有正常运行的 BE 节点，将 Doris 编译安装包复制到新节点。
  2. 修改新节点的 conf/be.conf：
    • storage_root_path：配置数据存储路径（多块盘用分号分隔，如 /data1/doris,medium:SSD;/data2/doris,medium:HDD）。
    • priority_networks：非常重要！如果机器有多块网卡，必须指定新 BE 绑定的网段（例如 priority_networks = 192.168.1.0/24）。
    • 检查各个端口（如 be_port=9060, heartbeat_service_port=9050 等）是否与现有集群一致且未被占用。

步骤 3：启动新 BE 节点

在新节点执行启动命令：

bash 
bin/start_be.sh --daemon

此时 BE 启动成功，但它还没有加入集群，处于孤立状态，会不断尝试与 FE 通信。

步骤 4：向 FE 注册新 BE 节点

使用 MySQL 客户端连接到 Doris 的 FE Leader 节点（需使用具有 Admin 权限的用户，如 admin 或 root）：

sql 
-- 执行添加 BE 命令，IP 为新 BE 节点的 IP，端口为 be.conf 中的 heartbeat_service_port（默认 9050）
ALTER SYSTEM ADD BACKEND "192.168.1.105:9050";

步骤 5：验证扩容结果

在 MySQL 客户端中查看后端节点状态：

sql 
SHOW BACKENDS\G

关注重点字段：

  • Alive：应为 true（表明 FE 与新 BE 心跳正常）。
  • SystemDecommissioned：应为 false。
  • TabletNum：新节点的 Tablet 数量一开始为 0，随着自动均衡的开始，该数值会逐渐增加。

第二部分：Doris 如何实现后台自动负载均衡（Rebalance）？

Doris 的数据分布是以 Tablet（分片/数据分片） 为物理基本单位的（一个表按照分区、分桶后，每个分桶在物理上就是一个 Tablet，通常默认有 3 副本）。

当新 BE 节点加入后，FE 的 Tablet Scheduler（分片调度器） 守护线程会自动感知到集群拓扑的变化，并启动后台负载均衡。

1. 核心流程：Tablet 迁移三步走

负载均衡的本质是 Tablet 的迁移。当决定将某一个 Tablet 从旧的、高负载的 BE-A 迁移到新的、低负载的 BE-B 时，过程如下：

plaintext 
[FE Scheduler] ──(1.下发 CLONE 任务)──> [新 BE-B]
                                           │ (2.拉取数据/增量同步)
                                           ▼
[旧 BE-A] <────────────────────────────────┘
                                           │ (3.确认同步完成)
[FE Scheduler] <──(4.汇报注册/更新元数据)───┘

  1. 计算与决策（FE 完成）：
    FE 周期性（默认每 20 秒）计算每个 BE 节点的磁盘使用率和Tablet 数量。

    • 新 BE 刚加入时，其负载指标极低。
    • FE 挑选出一些在旧 BE 上，但新 BE 上没有的 Tablet，生成 CLONE 任务 下发给新 BE。

  2. 数据克隆（BE 异步拉取）：
    新 BE 收到任务后，主动连接旧 BE（或者该 Tablet 的其他健康副本所在 BE），通过 HTTP 协议异步拉取该 Tablet 的历史数据文件（SSTable）。

  3. 双向同步与元数据生效：

    • 在拉取历史数据的同时，如果该表有实时写入（导入任务），新写入的数据也会同时写入该 Tablet 的其他旧副本。
    • 当历史数据克隆完成后，新 BE 会向 FE 汇报，FE 开启增量追赶（通过 Transcation ID 追赶克隆期间新写入的数据）。
    • 追赶一致后，FE 将新 BE 上的副本状态标记为 Active（可用）。

  4. 旧副本清理：
    新副本生效后，该 Tablet 的副本数超出了设定的数量（比如 3 副本变成了 4 副本）。FE 会向旧 BE 发送删除任务，安全地将旧 BE 上的老副本删除，最终恢复到 3 副本。

第三部分：为什么扩容和均衡不影响在线读写（No-Blocking）？

Doris 能够做到在线、无感知扩容，得益于其精妙的多副本管理与并发控制机制：

1. 多副本无锁设计（Read-Write-Clone 互不阻塞）

  • 写操作（Write）不阻塞：
    Doris 的写入采用 MVCC（多版本并发控制）。当新 BE 在克隆历史数据时，旧副本仍在继续接收新版本的数据写入。新 BE 只需在克隆完老版本后，向 FE 申请增量同步新版本即可，写入通道从未关闭。
  • 读操作（Read）不阻塞：
    读取时，FE 的 Query Plan 优先选择那些处于 Active 状态的旧副本。正在克隆的新副本在未完全同步前，对查询引擎是隐形的，绝对不会被路由到，因此不会影响查询正确性。

2. 极致的流量控制（QoS），避免抢占系统资源

为了防止后台数据迁移把网络带宽或磁盘 I/O 跑满，导致在线查询延迟飙升，Doris 提供了多重限流机制：

  • 网卡带宽限流：
    be.conf 中的 clone_bandwidth_limit_mbps 参数（默认 10MB/s 到 20MB/s 左右）限制了单个 BE 节点克隆数据的最大网速，防止拉取数据时把网卡塞满。
  • 并发任务限制：
    FE 严格限制了同时进行的 Clone 任务数量（通过 max_scheduling_tablets 和 max_balancing_tablets 控制，默认并发很小）。数据是以一个个 Tablet 为单位慢慢“蚕食”迁移的，而不是一股脑大流量拷贝。
  • 线程优先级：
    BE 节点内部，用于数据迁移（Clone）的线程优先级低于执行 SQL 查询的线程。一旦系统 CPU/IO 紧张，迁移线程会主动让路。

3. 智能温和的调度策略

Doris 的 Rebalance 不是瞬间完成的，而是一个极其温和、渐进式的过程。

  • 如果你的集群数据量特别大（比如几十 TB），扩容后可能需要数小时甚至一两天时间才会完全达到负载均衡。
  • 这种“以时间换空间”的设计，保证了集群在任何时刻都有充足的资源去响应用户的报表查询和高频写入。

总结

在线扩容 Doris 只需要：准备环境 -> 启动 BE -> FE 执行一条 ADD SQL。之后，你就可以放心地把一切交给 Doris 底层的 Tablet Scheduler，它会在后台悄无声息、安全限流地完成数据重平衡，保障生产业务稳如泰山。

00:00
00:00