Apache Doris 实时分析数据库生产运维实战
Apache Doris 面向实时分析、报表、用户画像、日志查询和数据仓库加速。它提供 MySQL 协议、列式存储、向量化执行、物化视图和多种数据导入方式，但生产稳定性取决于 FE 元数据、BE 存储、Compaction、数据分布、导入作业和查询资源治理。本文不以单机体验为目标，而是围绕集群规划、容量、备份恢复和故障排查建立完整运维方法。
一、核心组件与数据路径
FE 负责元数据、SQL 解析、查询计划、调度和集群管理；BE 负责数据存储、计算执行、Compaction 与副本管理。存算一体模式中 BE 同时保存数据和执行查询；存算分离模式把持久数据放到共享对象存储，计算节点主要承担缓存与执行。
客户端 / BI / JDBC
│ MySQL Protocol / HTTP
FE 集群
│ 查询计划、元数据、调度
BE 集群 ── 本地磁盘或共享对象存储
│
导入、查询、Compaction、副本修复
生产环境通常将 FE 和 BE 分开部署，至少使用多个 FE 保证元数据服务可用，并使用至少三个 BE 承载多副本数据。实际节点数应通过数据量、导入速率、查询并发和故障余量计算。
二、部署模式选择
1. 存算一体
适合规模相对固定、重视本地低延迟、没有稳定对象存储或希望架构简单的环境。扩容会同时增加计算与存储，缩容前必须迁移副本。磁盘故障、热点和数据均衡是主要运维工作。
2. 存算分离
适合云环境、弹性查询、冷热分层和计算资源独立扩缩容。它降低本地持久盘依赖，但引入对象存储可用性、缓存命中、网络带宽和共享存储成本问题。不能把测试环境的 MinIO 单节点直接作为生产对象存储。
选择模式前列出：
- 数据保留量和每日增量；
- 查询高峰与导入高峰是否重叠；
- 对象存储和网络 SLA；
- 计算弹性需求；
- 恢复时间目标；
- 机房与云成本；
- 运维团队对共享存储的掌控能力。
三、服务器与操作系统基线
FE 关注稳定 CPU、内存、元数据磁盘延迟和网络；BE 关注 CPU、内存、磁盘吞吐、IOPS、容量和 10GbE 以上网络。生产中应使用独立用户，统一时钟，禁用 Swap 或按官方建议处理，设置足够文件句柄和 vm.max_map_count，避免 FE、BE 与其他重负载服务争抢资源。
容量估算示例：
原始数据量 × 压缩后比例 × 副本数
+ Compaction 临时空间
+ 导入暂存与错误日志
+ 未来增长和故障迁移余量
不要只按压缩后的稳定数据计算磁盘。Compaction、Clone、Schema Change 和副本恢复都需要额外空间，生产应保留显著的空闲容量并设置分级告警。
四、FE 高可用与元数据保护
FE 角色需要明确 Master、Follower 和 Observer。Follower 参与选举，Observer 用于扩展只读能力但不参与多数派。节点部署在不同故障域，网络延迟稳定，优先使用固定域名或明确地址规划。
日常检查：
SHOW FRONTENDS;
SHOW PROC '/frontends';
关注 Alive、Join、Role、IsMaster、LastHeartbeat 和元数据版本。FE 元数据目录必须位于可靠存储，定期执行官方支持的元数据备份。不能把“有三个 FE”误认为已经备份；多数副本同时损坏、误删除或升级失败仍需离线备份恢复。
变更 FE 时先确认多数派健康，一次只操作一个参与选举的节点。不要在网络抖动时同时重启多个 FE。
五、BE 节点、磁盘与副本治理
SHOW BACKENDS;
SHOW PROC '/backends';
检查 Alive、Tablet 数量、磁盘使用率、版本、心跳和副本状态。新增 BE 后观察数据均衡，删除节点应使用安全下线流程，让 Tablet 迁移完成后再移除主机。
多块数据盘要分别监控容量、IO 延迟、坏盘和路径状态。单盘容量达到阈值时，调度和 Compaction 可能恶化。硬盘故障后先确认副本安全，再隔离路径或节点，避免“清理空间”时误删仍需恢复的数据。
副本异常排查顺序：
- FE 是否健康并能调度；
- BE 心跳和磁盘路径是否正常；
- 是否有足够健康节点和不同故障域；
- Tablet 是否长期处于 Clone；
- 网络和磁盘是否限制复制；
- 是否因为标签或资源限制无法放置副本。
六、表模型、分区与分桶
Doris 表设计会直接决定运维难度。Duplicate、Aggregate、Unique 等模型应按数据语义选择；不能仅为了“去重”盲目使用 Unique Key。
分区用于生命周期、裁剪和批量管理，通常按日期；分桶影响并行度、数据分布和 Join。桶数过少会限制并发并产生大 Tablet，过多则增加元数据、文件和 Compaction 压力。
检查数据倾斜：
- 各 Tablet 行数与大小差异；
- 热点 Key；
- 分区数据是否符合预期；
- 分桶 Key 基数；
- Colocate Group 分布；
- 单分区或单 Tablet 是否成为查询瓶颈。
分区保留应自动化，但删除必须有保护窗口和审计。动态分区策略要监控是否真正创建、删除成功。
七、数据导入可靠性
Doris 支持 Stream Load、Broker Load、Routine Load、INSERT、Flink Connector 等方式。生产平台需要为每种导入定义幂等、重试、标签、错误率和对账方法。
Stream Load
适合批次可控的 HTTP 导入。使用唯一 Label 防止重复提交，记录返回状态、过滤行数、耗时和错误 URL。HTTP 200 不等于数据一定满足业务预期。
Routine Load
常用于 Kafka 持续导入。重点监控消费延迟、暂停原因、错误行、分区变化、并发任务和 Offset。作业暂停后不能只执行 Resume，还要先定位数据格式、权限或资源问题。
SHOW ROUTINE LOAD;
SHOW ROUTINE LOAD TASK WHERE JobName = 'job_name';
导入对账
至少比较源端数量、目标分区行数、时间范围、业务主键和金额类汇总。Exactly-Once 的连接器语义不能替代端到端业务对账。
八、Compaction 与小文件治理
导入会产生多个 Rowset，Compaction 把它们合并，减少查询读取和版本数量。高频小批次写入、磁盘慢、BE 负载高或空间不足会导致 Compaction 积压。
表现包括：
- 查询延迟逐步升高；
- Tablet 版本过多；
- 导入报版本限制；
- BE 磁盘和 CPU 持续繁忙；
- Compaction Score 长期高位。
治理顺序：先降低异常写入频率和小批次数量，再确认磁盘、线程和资源，最后才考虑调整 Compaction 参数。盲目提高线程数可能把磁盘压垮。
九、查询性能与资源隔离
慢查询排查应从 Profile 开始，而不是只看 SQL 文本。关注扫描数据量、分区裁剪、Tablet 数、Join 分布、Shuffle、聚合、排序、内存、运行时过滤器和节点倾斜。
常见问题：
- 未命中分区，扫描全表；
- 维表或事实表统计信息过期；
- Join Key 倾斜；
- 大量
SELECT *； - 高并发小查询挤压大查询；
- 大查询超出内存；
- 物化视图未命中；
- BI 工具重复刷新。
通过 Workload Group、查询队列、内存限制和并发控制隔离不同租户与任务。资源组不能替代容量规划，配置过度承诺会在高峰同时失效。
十、物化视图与统计信息
异步物化视图可以加速复杂聚合，但会引入刷新、依赖、存储和一致性问题。监控刷新成功率、耗时、滞后、命中率和存储增长。业务变更后要确认查询重写是否仍然成立。
统计信息影响优化器选择。大批量导入、分区变化和数据分布改变后，应按计划更新统计信息。不要在高峰对所有大表同时执行高成本分析。
十一、监控与告警
FE：存活与角色、查询 QPS、失败率、元数据日志、JVM 堆与 GC、连接数、调度任务、Checkpoint。
BE：存活、CPU、内存、磁盘容量与延迟、网络、Tablet、Compaction Score、查询执行、导入、缓存、线程池和副本修复。
业务层：数据新鲜度、导入延迟、分区是否生成、关键报表耗时、结果对账、资源组排队时间。
告警必须带集群、节点、数据库、表、分区和作业维度。只报警“BE CPU 高”不能快速判断是查询、导入还是 Compaction。
十二、备份与恢复
根据版本和部署模式使用官方支持的 Backup/Restore、Snapshot、对象存储和元数据备份能力。备份内容至少包括：
- FE 元数据；
- 关键数据库和表数据；
- 用户、权限和资源配置；
- Catalog、外表与连接参数；
- Routine Load、物化视图和调度定义；
- 集群配置和部署制品。
恢复演练要验证：表结构、分区、行数、权限、物化视图、导入作业和查询结果。备份任务成功不等于能够在目标时间内恢复。
十三、滚动升级
升级前阅读源版本到目标版本的全部发布说明，核对 JDK、操作系统、FE/BE 协议、表格式和已弃用参数。先备份元数据和关键数据，在预生产复制真实负载验证。
通常按官方文档规定的顺序逐节点升级，一次只处理一个 FE 或 BE，观察心跳、查询、导入、Compaction 和副本。跨大版本不要跳过中间要求。回退前确认元数据和数据格式是否向后兼容。
十四、常见故障排查
FE 无法选主
检查多数派、节点地址、时钟、网络、磁盘和元数据目录。不要在没有多数派时反复重启所有节点。
BE 心跳正常但查询失败
检查磁盘路径、Tablet、执行线程、内存、网络和版本一致性。Alive 只代表心跳，不代表所有数据路径健康。
Routine Load 暂停
查看 Reason、错误日志、Kafka Offset、认证、Schema 变化和最大错误率，修复原因后再恢复。
磁盘快速增长
区分数据增长、Compaction 临时空间、垃圾文件、日志、失败导入和副本迁移。不要直接手工删除 BE 数据目录。
查询突然变慢
比较执行 Profile、统计信息、分区裁剪、数据倾斜、物化视图命中、并发和节点资源，检查近期导入或 Schema Change。
十五、生产检查清单
- [ ] FE/BE 分离并跨故障域部署；
- [ ] FE 多数派和元数据备份已验证；
- [ ] BE 磁盘保留 Compaction 与恢复空间；
- [ ] 表模型、分区和分桶经过数据验证；
- [ ] 导入具备幂等 Label 与业务对账；
- [ ] Routine Load 延迟和暂停有告警；
- [ ] Compaction、Tablet 和副本状态可观测；
- [ ] 查询资源按租户或任务隔离；
- [ ] 物化视图和统计信息有维护计划；
- [ ] 备份已完成异机恢复演练；
- [ ] 升级具备兼容矩阵与回退方案；
- [ ] 禁止直接手工删除 FE/BE 数据目录。