【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 …），并设置合理的磁盘配额监控。