【Doris】集群介绍

【一】Doris 集群搭建步骤

Doris 采用 ​Master/Slave​ 架构，由 ​Frontend（FE）​​ 和 ​Backend（BE）​​ 两种角色组成。一个最小的高可用生产集群通常需要 ​3个FE​ 和 ​3个BE。

【1】​环境准备 (所有节点)​​

（1）​硬件要求​：

​CPU​： 8核+，推荐 16核。
​内存​： 16GB+，推荐 64GB。BE 节点的内存直接决定查询和导入性能。
​磁盘​： SSD 推荐。BE 数据目录配置多块 SSD 并做 RAID 0 或直接使用多目录，提升 IO 能力。
​网络​： 万兆网卡，低延迟。FE 和 BE 之间、BE 和 BE 之间需要高速内网连接。

（2）​软件要求​：

（1）​OS​： CentOS 7.x / Ubuntu 16.04+ 等主流 Linux 发行版。
（2）​Java​： JDK 1.8+ (必须)。yum install java-1.8.0-openjdk-devel或安装 Oracle JDK。
（3）​创建用户​ (可选但推荐)： sudo useradd doris && sudo passwd doris
（4）​关闭防火墙​ 或 ​开放端口​：
1-​FE 端口​： 8030(HTTP Web)，9020(BEFE通信)，9030(MySQL客户端)
2-​BE 端口​： 9060(BE<->FE)，9070(BE<->BE)，8040(HTTP Web)
（5）​时间同步 (NTP)​​： 所有节点时间必须同步！sudo ntpdate ntp.aliyun.com
（6）​文件句柄数​： 增大 nofile和 nproc(在 /etc/security/limits.conf)。

【2】安装包准备与解压​

（1）从 Apache Doris 官网或 Github Release下载最新稳定版安装包，例如 apache-doris-1.2.4.1-x86_64.tar.gz。
（2）将安装包上传到所有服务器节点的相同目录下，例如 /opt/software/。
（3）解压安装包：

tar -zxvf apache-doris-1.2.4.1-x86_64.tar.gz
mv apache-doris-1.2.4.1-x86_64 /opt/doris
chown -R doris:doris /opt/doris # 如果创建了doris用户

【3】部署 Frontend (FE)​​

（1）​在第一个 FE 节点 (Master) 上操作：​​

（1）​进入 FE 目录​： cd /opt/doris/fe
（2）​配置 conf/fe.conf​：

# 主要修改以下参数：
priority_networks = 192.168.1.10/24 # 指定内网IP，避免绑定到127.0.0.1
meta_dir = ${DORIS_HOME}/doris-meta  # 元数据目录，建议使用独立SSD盘
# 如果内存较大，可以调整JVM参数，例如：
JAVA_OPTS="-Xmx16384m -XX:+UseMembar -XX:SurvivorRatio=8 ..."

（3）启动 FE​：

./bin/start_fe.sh --daemon

（4）检查启动状态​：
1-查看日志： tail -f log/fe.log。看到 14662 [INFO]字样表示启动成功。
2-通过 MySQL 客户端连接： mysql -h 192.168.1.10 -P 9030 -uroot。-uroot是默认用户，无密码。

（2）添加第二、第三个 FE (Follower/Observer)：​​

（1）在另外两个节点上，同样修改 fe.conf中的 priority_networks。
（2）通过 ​第一个 FE​ 的 MySQL 客户端执行添加命令：

-- 添加 Follower (高可用必需)
ALTER SYSTEM ADD FOLLOWER "192.168.1.11:9010";
ALTER SYSTEM ADD FOLLOWER "192.168.1.12:9010";-- 或者添加 Observer (用于扩展读，非高可用必需)
-- ALTER SYSTEM ADD OBSERVER "192.168.1.13:9010";

（3）在第二、第三个节点上启动 FE： ./bin/start_fe.sh --daemon --helper 192.168.1.10:9010。​注意：​​ --helper参数指向第一个已启动的 FE。

【4】部署 Backend (BE)​​

（1）​在所有 BE 节点上操作：​​

（1）进入 BE 目录​： cd /opt/doris/be
（2）配置 conf/be.conf​：

priority_networks = 192.168.1.20/24 # 指定内网IP
storage_root_path = /data1/doris-storage,/data2/doris-storage;... # 数据存储目录，多个用分号隔开
# 例如： storage_root_path = /ssd1/doris,/ssd2/doris

（3）​启动 BE​：

./bin/start_be.sh --daemon

（4）检查启动状态​： tail -f log/be.log。看到 14662 [INFO]字样表示启动成功。

（2）​通过 FE 添加 BE：​​

（1）连接到 ​任一 FE​ 的 MySQL 客户端 (mysql -h … -P 9030 -uroot)。
（2）执行添加 BE 的命令：

ALTER SYSTEM ADD BACKEND "192.168.1.20:9050";
ALTER SYSTEM ADD BACKEND "192.168.1.21:9050";
ALTER SYSTEM ADD BACKEND "192.168.1.22:9050";

（3）检查 BE 状态： SHOW BACKENDS\G;。确保 Alive字段为 true。

【二】安装包目录与文件详解​

【1】解压后的 Doris 目录结构

apache-doris-1.2.4.1-x86_64/
├── fe/                          # Frontend 节点目录
│   ├── bin/
│   │   ├── start_fe.sh          # FE 启动脚本
│   │   └── stop_fe.sh           # FE 停止脚本
│   ├── conf/
│   │   └── fe.conf              # FE 主配置文件
│   ├── doris-meta/              # 元数据目录 (启动后生成)
│   ├── lib/                     # 存放所有依赖 Jar 包
│   │   └── palo-fe.jar          # FE 主程序 Jar 包
│   ├── log/                     # 日志目录 (启动后生成)
│   │   └── fe.log               # FE 主日志文件
│   └── webroot/                 # FE Web UI 的静态文件
├── be/                          # Backend 节点目录
│   ├── bin/
│   │   ├── start_be.sh          # BE 启动脚本
│   │   └── stop_be.sh           # BE 停止脚本
│   ├── conf/
│   │   └── be.conf              # BE 主配置文件
│   ├── lib/
│   │   ├── palo-be.jar          # BE 主程序 Jar 包
│   │   └── ...                  # 其他依赖库
│   ├── log/                     # 日志目录 (启动后生成)
│   │   └── be.log               # BE 主日志文件
│   └── storage/                 # 数据存储目录 (由配置指定，此为默认名)
├── extension/                   # 扩展目录，存放 UDF 等扩展功能
│   └── ...
├── apache_hdfs_broker/          # Broker 组件，用于外部数据访问 (如HDFS)
│   ├── bin/
│   │   ├── start_broker.sh
│   │   └── stop_broker.sh
│   ├── conf/
│   │   └── broker.conf
│   └── log/
└───── ...

【2】核心目录/文件作用总结：​​

| 路径 | 角色 | 作用 |

| — | — | — |
| fe/bin/| FE | 启动/停止控制脚本 |
| fe/conf/fe.conf| FE | ​核心配置文件，定义元数据目录、端口、JVM参数等 |
| fe/doris-meta/| FE | ​极其重要，存储集群元数据，​必须备份​ |
| fe/log/| FE | 存放日志文件，排查问题首要查看位置 |
| be/bin/| BE | 启动/停止控制脚本 |
| be/conf/be.conf| BE | ​核心配置文件，定义数据目录、端口等 |
| be/storage/| BE | 数据存储目录（默认名，实际由 storage_root_path配置） |
| be/log/| BE | 存放日志文件 |
| apache_hdfs_broker/| Broker | 用于读写 HDFS、S3 等外部存储系统的辅助组件 |

【3】FE 和 BE 的区别与作用

Doris 采用经典的对等 Master-Slave 架构，主要由 Frontend（FE）和 Backend（BE）两类进程组成，它们职责分明。

详细作用：​​

（1）​FE (Frontend)：​​

（1）​管理元数据​：存储和维护所有表、分区、分片（Tablet）、副本的元信息。这些元数据通过 Berkeley DB Java Edition (BDB JE) 在多个FE副本间同步。
（2）​用户请求入口​：接收用户的 MySQL 客户端连接（端口 9030）和查询请求。
（3）​查询协调​：
1-解析 SQL，进行语法分析、语义分析、权限校验。
2-基于元数据生成最优的分布式查询计划，并拆分成多个片段（Fragment）。
3-将查询计划片段分发给相关的 BE 节点执行。
4-接收各个 BE 返回的中间结果，进行最终聚合（如排序、聚合计算等），并将结果返回给客户端。
5-​集群管理​：提供 Web UI（端口 8030）来监控集群状态，管理节点。

（2）​BE (Backend)：​​

（1）​数据存储​：负责存储表数据的实际分区和分片（Tablet）。每个 Tablet 通常会有多个副本（默认3），存储在不同的 BE 上，以实现高可用和负载均衡。
（2）​查询执行​：接收并执行 FE 下发的查询计划片段，在本机进行数据的扫描、过滤、聚合等操作。
（3）​数据维护​：负责数据的压缩（Compaction）、副本管理、数据修复等后台任务。

【三】集群细节

【1】FE 主节点选举机制

当 FE ​Leader​ 节点挂掉后，集群如何选举出新的 Leader？其核心是基于 ​Berkley DB Java Edition (BDB JE)​​ 的分布式一致性协议。

（1）节点角色：​​

1-​Leader​： 只有一个。负责所有元数据的写操作​（如建表、导入事务提交）。同时也提供读服务。
2-​Follower​： 有多个。​同步​ Leader 的元数据日志，参与选举投票。当 Leader 挂掉时，Follower 有资格被选为新的 Leader。提供元数据读服务。
3-​Observer​： 有多个。​异步同步 Leader 的元数据日志，​不参与选举投票。主要用于扩展集群的读能力，分担读压力。

（2）选举过程：​​

1-​心跳检测​： Follower 和 Observer 会定期与 Leader 通信。
2-​Leader 失效​： 当 Follower 节点在一定时间内（meta_dir/bdb/下的日志可配置超时时间）无法与 Leader 取得联系时，它们会认为 Leader 已宕机。
3-​发起选举​： 剩余的 Follower 节点会基于 BDB JE 的 ​Paxos​ 协议发起一轮新的选举投票。
4-选举规则​： BDB JE 协议要求集群中超过半数的 ​有投票权节点（即 Follower）​​ 达成一致才能选出新的 Leader。
假设你有 1 Leader + 2 Follower 的配置，总共有投票权的节点是 3 个。法定票数为 3/2 + 1 = 2（取整）。
当 Leader 挂掉，剩下 2 个 Follower。它们必须都投票给同一个候选者（通常是其中元数据最新的那个），才能满足多数派（2票），选举成功。
5-​新 Leader 诞生​： 选举出的新 Leader 开始接管服务，接受元数据写入请求，并将日志同步给其他 Follower 和 Observer。
​

（3）重要结论：​​

1-要保证 FE 高可用，​必须部署至少 3 个 FE，且其中包含至少 1个 Leader 和 2个 Follower。
2-如果只有 1个 Leader 和 1个 Follower，当 Leader 挂掉后，剩下的 1 个 Follower 无法达到多数派（2个有投票权节点，法定票数为2，但只剩1票），导致选举失败，集群将无法提供写服务。
3-Observer 不参与投票，因此增加 Observer 不会影响选举的容错性，但能提升读性能。

这个过程是完全自动的，无需人工干预。

【2】节点挂了如何重启

重要前提：​​ 在重启任何节点前，务必先通过 SHOW PROC /frontends;和 SHOW PROC /backends;命令确认当前集群所有节点的状态。

（1）重启 BE 节点​

BE 重启相对简单，因为数据是通过多副本来保证高可用的。

​步骤：​​
1.​登录目标 BE 服务器。
2.进入 BE 部署目录：cd /opt/doris/be
3.停止 BE​： ./bin/stop_be.sh
4.检查进程是否已退出​： ps aux | grep doris_be。确保进程已杀死。
5.启动 BE​： ./bin/start_be.sh --daemon
6.查看日志​： tail -f log/be.log，观察是否有错误。看到 thrift server started等字样表示启动成功。
7.在 FE 上验证​： 用 MySQL 客户端连接 FE，执行 SHOW BACKENDS;。等待该 BE 的 Alive列变为 true。

注意：​​
重启期间，访问该 BE 上副本的查询可能会短暂失败，但 FE 会自动重试到其他副本，​对用户透明。
该 BE 重启上线后，如果期间有数据写入，系统会自动修复该节点上的数据副本，使其保持最新。

（2）重启 FE 节点（Follower/Observer）​​

​步骤：​​
1.登录目标 FE 服务器。
2.进入 FE 部署目录：cd /opt/doris/fe
3.停止 FE​： ./bin/stop_fe.sh
4.检查进程是否已退出​： ps aux | grep doris_fe
5.启动 FE​： ./bin/start_fe.sh --daemon(注意：​​ 对于 Follower/Observer，​不需要再加 --helper参数)
6.查看日志​： tail -f log/fe.log，观察是否有错误。看到 transfer to MASTER或 start as OBSERVER等字样表示成功加入集群。
7.在 FE 上验证​： 执行 SHOW PROC /frontends;，等待该 FE 的 Alive列变为 true。

（3）重启 FE Leader 节点（特殊操作）​​

​原则上，不要主动重启 FE Leader！​​ 如果必须重启（例如机器维护），建议先通过 ​​ graceful 方式进行 Leader 切换。

​优雅切换 Leader 步骤：​​
1.连接到当前 Leader FE 的 MySQL 端口。
2.执行命令：ALTER SYSTEM STEP DOWN LEADER;
3.该命令会主动让出 Leader 角色，触发集群重新选举，新的 Leader 会在剩余的 Follower 中产生。
4.原 Leader 在 step down 后会自动转换为 Follower 角色。
5.此时，你再重启这个已经变为 Follower 的节点，操作就变成了上面第2种情况，非常安全。

如果 Leader 已意外宕机：​​
1.直接按上述步骤重启它。
2.如果重启失败，或者机器彻底故障，​集群已经通过选举产生了新的 Leader。
3.你需要做的是修复宕机的机器，然后以 Follower 的身份重新启动这个 FE 进程。
4.启动后，它会自动从新的 Leader 同步元数据，追赶数据日志。

总结：​​
（1）BE 重启​： 简单粗暴，直接重启，系统自动处理数据一致性。
（2）FE Follower/Observer 重启​： 直接重启。
（3）FE Leader 重启​： ​先 step down，再重启，避免不必要的选举和服务抖动。

【3】数据是如何存储的

（1）数据存储在哪里？​​

Doris的所有业务数据都存储在 ​Backend (BE) 节点​ 上。每个BE节点都会管理一台物理机器上的本地存储（通常是SSD或HDD）。Frontend (FE) 节点只存储元数据​（如表结构、数据分布位置等），不存储业务数据。

（2）如何存储的？（存储模型详解）​​

Doris采用了非常精巧的“分而治之”策略来存储海量数据，其核心概念是表（Table）> 分区（Partition）> 分桶（Bucket）> 副本（Replica）​。
（1）分区（Partition） - 粗粒度划分，基于时间​
​目的​：主要用于管理数据的生命周期和进行粗粒度的数据裁剪。最常见的用法是按时间分区（如每天一个分区）。
​举例​：一张记录用户行为的数据表，可以按 date字段进行分区，每天的数据存储在一个独立的分区（如 p20230901, p20230902）。
​好处​：
​高效淘汰旧数据​：要删除某天的数据，只需直接删除整个分区（ALTER TABLE … DROP PARTITION …），这是一个非常高效的操作。
​查询加速​：如果查询只涉及某几天的数据，Doris可以自动跳过（Pruning）​​ 不相关的分区，极大减少需要扫描的数据量。

（2）分桶（Bucket） - 细粒度划分，基于哈希​
​目的​：将数据均匀分布到各个BE节点，实现并行计算和负载均衡，并优化点查询（如按用户ID查询）。
​过程​：在一个分区内，Doris会根据用户指定的分桶键（如 user_id），通过哈希算法将数据打散，分布到多个分桶（Bucket）​​ 中。
​细节​：
每个分桶就是一个数据分片（Tablet）​，是数据移动、复制和恢复的最小单位。
每个Tablet在物理上就是一个文件目录，里面包含了该Tablet的所有数据副本（.dat文件）和索引（.idx文件）。
​好处​：
​并行计算​：查询时，每个Bucket（Tablet）都可以被调度到一个BE节点上进行并行处理，充分利用多机多核的计算能力。
​数据均匀​：哈希分桶保证了数据在不同BE间均匀分布，避免了数据倾斜。

（3）副本（Replica） - 保证高可用和读性能​
​目的​：​数据高可用和负载均衡。
​机制​：Doris会为每个Tablet创建多个副本（默认3副本），并将这些副本分布到不同的BE节点上。
​好处​：
​高可用​：即使一个BE节点宕机，数据依然可以从其他副本读取，保证服务不中断。
​读负载均衡​：查询可以从多个副本中任意选择一个进行读取，提升了并发读取能力。

​（4）存储格式：列式存储（Columnar Storage）​​
在物理文件层面，Doris采用了列式存储格式。这意味着数据不是按行存储，而是按列存储。
例如，一张表有user_id, username, age三列，在磁盘上会分别存储为：
1-user_id.dat(包含所有行的user_id)
2-username.dat(包含所有行的username)
3-age.dat(包含所有行的age)
​列存的好处是查询时无需读取整行数据，而只需读取查询所涉及的列，​极大减少了I/O吞吐量，这是实现高速查询的基石。

【4】如何做到快速查询

Doris的极致性能来源于其融合架构，它巧妙地将MPP架构、列式存储和智能索引等技术结合在了一起。

（1）MPP架构（大规模并行处理）​​

​原理​：Doris的查询引擎采用MPP架构。当一个查询请求发到FE后，FE的查询优化器会生成一个分布式查询执行计划，将这个计划拆分成多个可以在不同BE节点上并行执行的片段（Fragment）。
​过程​：每个BE节点只处理本地存储的数据分片（Tablet），进行扫描、过滤、聚合等操作（本地化计算），然后将中间结果通过网络传递给其他BE或最终汇总到FE。这实现了计算靠近存储和并行处理，避免了单点瓶颈，能充分利用整个集群的计算和存储资源。

（2）列式存储（Columnar Storage）​​

如上文所述，列式存储大幅降低了查询时的磁盘I/O。特别是对于聚合查询（如SUM, COUNT, AVG），只需要读取少数几个列，性能提升巨大。

（3）智能索引与物化视图（Pre-Aggregation）​​

1-​前缀索引（Prefix Index）​​：Doris底层数据存储时，每1024行数据构成一个数据块（Data Page）。对于每块数据，Doris会将表的前36个字节（可配置）作为这1024行数据的稀疏索引。当进行条件查询时，可以快速定位到可能包含目标数据的数据块，避免全表扫描。
2-​ZoneMap索引​：Doris会对每个数据块内的每一列自动维护极值信息（Min、Max）。如果查询条件远大于某块的Max或远小于某块的Min，就可以直接跳过整个数据块。
3-​Bloom Filter索引​：特别适用于高基数列​（如user_id）的点查询。它可以快速判断“某值肯定不存在于本数据块中”，从而有效减少不必要的磁盘读取。
4-​物化视图（Materialized Views）​​：这是Doris的王牌功能。用户可以预先定义好一个查询的聚合结果（如按天、按省份的PV/UV）。Doris会自动维护这个预计算结果。当用户查询命中该视图时，Doris会直接读取已经计算好的结果，速度极快，无需现场扫描原始海量数据。

（4）向量化执行（Vectorized Execution）​​

1-​原理​：传统的数据库执行引擎一次只处理一行数据（Tuple-at-a-time），函数调用开销大。而向量化执行引擎一次处理一批数据​（Batch-of-Tuples）。
2-​好处​：
减少了虚函数调用次数。
充分利用CPU的SIMD指令（单指令多数据）进行并行计算，大幅提高了CPU的利用率和缓存命中率。
这是现代高性能数据库引擎的标配技术。

（5）查询优化器（CBO）​​

Doris拥有一个基于成本的优化器（Cost-Based Optimizer）。它根据表的统计信息（如行数、列 distinct值数量等）来估算不同执行计划的成本，并选择最优的执行路径​（如选择最佳的Join顺序、是否应该广播小表等），避免了慢查询。

（6）总结

Doris的快速海量查询能力是其架构设计哲学的胜利：
​存储层​：通过分区+分桶将数据打散，为并行计算打下基础；通过列式存储+多副本极大减少I/O并保证可用性。
​计算层​：通过MPP架构将计算任务并行化，分布到所有节点，实现横向扩展。
​加速层​：通过智能索引（前缀、ZoneMap、BloomFilter）​​ 快速过滤无用数据；通过物化视图空间换时间，提供亚秒级查询响应。
​执行层​：通过向量化执行引擎压榨出每一颗CPU核心的极致性能。

【四】注意事项

注意事项​
（1）​元数据备份​： fe/doris-meta/目录必须定期备份。丢失此目录意味着集群元数据丢失。
（2）​时间同步​： 所有节点时间必须严格同步，否则会导致 FE 无法启动、证书错误等诡异问题。
（3）端口开放​： 确保 FE 和 BE 的所有必要端口在内网是互通的。使用 telnet命令检查。
（4）版本一致​： 集群所有节点的 Doris 版本必须完全一致。
（5）磁盘规划​：
1-FE 元数据目录建议使用 ​SSD。
2-BE 数据目录强烈建议使用多块 ​SSD，并在 be.conf中配置多个路径，用逗号分隔，以充分利用 IO。
（6）JVM 调优​： 生产环境需要根据内存大小调整 fe.conf和 be.conf中的 JAVA_OPTS，避免 GC 频繁。
​

常见报错与解决方案​
（1）FE 启动失败：fe.log中出现 Exception in FE或 failed to init​
1-原因​： 端口被占用、元数据目录损坏或不完整、Java 环境问题。
2-解决​：
检查端口 9030, 9020, 9010是否被占用： netstat -tunlp | grep 。
检查 meta_dir路径权限是否正确。
如果是新安装，可以尝试清空元数据目录后重新启动。
（2）通过 MySQL 客户端连接 FE 失败：ERROR 2003 (HY000)： Can‘t connect to MySQL server​
1-原因​： FE 节点未启动、网络不通、防火墙阻止、priority_networks配置错误。
2-解决​：
确认 FE 进程存在： ps aux | grep fe。
在 FE 本机尝试连接： mysql -h 127.0.0.1 -P 9030 -uroot，如果成功，说明是网络或配置问题。
检查 priority_networks配置是否正确绑定到了内网 IP。
（3）添加 BE 失败：SHOW BACKENDS显示 Alive = false​
1-原因​： BE 与 FE 之间网络不通、BE 未成功启动、priority_networks配置错误。
2-解决​：
检查 BE 的 be.log是否有错误日志。
在 FE 节点上 telnet <BE_IP> 9050，看端口是否通。
确认 BE 和 FE 的 priority_networks配置在同一个网段。
（4）数据导入或查询失败：Backend node not found. Check if any backend is down​
1-原因​： 有 BE 节点宕机或离线。
2-解决​：
执行 SHOW BACKENDS\G;，查看是否有 Alive为 false的 BE。
检查该 BE 节点的状态和日志，进行重启或修复。
（5）磁盘空间不足：No space left on device​
1-原因​： BE 数据目录磁盘写满。
2-​解决​： 这是非常严重的问题。需要紧急扩容磁盘，或删除不用的表/分区数据（ALTER TABLE … DROP PARTITION …），并设置合理的磁盘配额监控。