Day 21｜生产架构与容量规划：CPU、内存、磁盘、网络、节点与副本

前二十天完成了 Doris 的定位、表设计、导入、查询加速、优化器、执行引擎、存储引擎以及写入更新机制。今天开始进入第五阶段，关注生产环境的长期可用性。实验环境只要进程能启动、SQL 能执行就算达到目标；生产集群需要承接真实数据增长、业务高峰、补数任务、Compaction、节点故障、版本升级和扩容过程，还要在这些变化发生时守住约定的 SLA。

容量规划的结果通常表现为一组机器规格和节点数量，真正有价值的部分位于结果之前：输入数据怎样定义，压缩率怎样测量，复杂查询消耗多少 CPU seconds，单条查询在各 BE 的内存分布怎样，Shuffle 会产生多少网络流量，故障后剩余节点能否继续承载核心业务。缺少这些证据时，机器规格只能算经验猜测。

完成今天的学习后，你应当能够：

• 把业务数据量、增长率、保留周期、并发和 SLA 转换成容量规划输入；
• 用实测压缩率、副本数、索引开销、Compaction 余量和磁盘水位估算物理容量；
• 用 Query Profile 的 CPU Time、Peak Memory、Scan Bytes 和 Shuffle Bytes估算计算资源；
• 分别规划 FE 与 BE 的 CPU、内存、磁盘和网络；
• 设计 3 FE、多 BE、多副本和多故障域的生产拓扑；
• 解释物理机、虚拟机、Kubernetes 与存算分离的适用条件；
• 执行操作系统、端口、网络、K8s 存储和安全策略预检；
• 输出一份可以进入采购、上线评审和持续复审的《Doris 生产容量规划书》。

零、先校准当前 4.x 的生产口径

你提供的培训材料第 230–235 页已经形成一条清晰主线：生产环境采用至少 3 个 FE、至少 3 个 BE，FE 侧重点是元数据和查询规划，BE 侧重点是 CPU、内存、磁盘 I/O，网络需要 10GbE 以上，同时关闭 Swap、调整文件句柄并配置监控。Day 21 保留这套框架，并按照 2026 年 8 月的 Doris 4.x 官方文档更新具体数值与部署边界。

0.1 当前官方硬件基线

官方环境检查给出的生产建议包括：FE 16 核以上、64 GB 以上、100 GB 以上 SSD；BE 16 核以上、64 GB 以上，生产至少 3 台；网络推荐 10GbE，并建议多网卡环境使用链路聚合。BE 内存的通用参考是最低 CPU cores × 4 GB、推荐 CPU cores × 8 GB。Doris 支持 x86-64 和 ARM64，CPU 推荐支持 AVX2；高并发点查、高频更新和大规模数据分析优先使用 SSD。[1]

这些数值适合作为最低起点。50 并发复杂查询、数百 TB 热数据、频繁 CDC 和大规模物化视图刷新，通常需要更高规格。最终规格应由目标数据和目标硬件上的混合负载 POC 决定。

0.2 当前官方磁盘快速估算

官方环境检查为存算一体提供了保守快速公式：BE 空间按“数据量 × 3 副本 × 1.4”估算，其中 40% 用于后台 Compaction 余量。文档同时说明，存算分离场景的持久数据位于共享存储，本地盘主要承担热数据缓存，磁盘大小应根据热工作集规划。[1]

正式容量规划需要进一步定义“数据量”的口径。源系统导出的 100 TB 文本、Doris 单副本压缩后 40 TB、包含倒排索引与 Row Store 后 48 TB，含义完全不同。本文提供两套口径：

1. 官方保守快算：用于早期预算，输入当前已存储数据量；
2. POC 实测公式：从原始数据开始，逐项乘入压缩、索引、副本、Compaction、增长和水位系数。

0.3 当前操作系统基线

4.x 官方操作系统检查要求关闭 Swap，将 THP 设置为 madvise，配置 vm.max_map_count=2000000，把文件句柄提高到 1,000,000，CPU Governor 使用 performance，配置 tcp_abort_on_overflow=1，并通过 NTP 保证节点时间误差小于 5000 ms。[2]

旧培训材料中的 nofile=655350 已被当前文档中的 1,000,000 取代。旧材料还列出了统一设置 vm.overcommit_memory=1，当前 4.x 官方生产检查没有把它列为通用必选项，本文不把它写入默认基线。Swap 也应直接关闭，单独把 swappiness 调低无法覆盖全部交换风险。

0.4 当前节点与版本基线

当前官方集群规划建议生产环境部署至少 3 个 FE Follower；Observer 可以按连接与元数据读取压力增加。存算一体模式下，生产至少 3 个 BE，以支持三副本；BE 支持水平扩容。[3]

截至 2026 年 8 月 17 日，官方下载页将 4.1.3 标记为 Latest，4.0.8 标记为 Stable。本文所有系统参数和 Operator 说明均以当前 4.x 文档为准，网站后续更新时应重新核验默认值。[4]

一、容量规划是一条持续运行的闭环

容量规划可以分成六个连续阶段：

业务画像
→ POC 测量
→ 容量公式
→ 拓扑设计
→ 上线验收
→ 运行复审

1.1 业务画像决定输入变量

第一张表先写业务变量，暂时不写机器型号：

“并发 50”仍然太粗。50 条点查、50 条扫描 10 GB 的报表、50 条扫描 1 TB 并做多表 Join 的查询，对资源需求的差异很大。容量规划书应把并发拆成查询模板和参数分布，再从 Profile 获得 CPU、内存、扫描和网络数据。

1.2 POC 负责提供测量值

POC 需要使用真实 Schema、真实数据分布、真实索引和目标版本。建议至少保存以下测量值：

• 单副本存储量与原始数据量的比值；
• 每条核心 SQL 的 CPU Time、Wall Time、Scan Bytes、Rows Returned；
• Join 和聚合的 Peak Memory、Spill Bytes、Shuffle Bytes；
• 峰值 Stream Load、Routine Load 或 Flink CDC 写入吞吐；
• 写入与复杂查询同时运行时的 Compaction Score、磁盘吞吐和 p99；
• 冷缓存、热缓存、节点故障、数据倾斜和补数期间的表现。

官方 POC 指南也强调真实表模型、分区分桶、批次、索引、Explain、Profile 和数据湖缓存的联合验证。[5]

1.3 运行复审让公式保持有效

上线以后，压缩率可能因字段增加而变化，倒排索引会扩大单副本体积，业务增长可能超出预测，热门报表会改变 CPU 和缓存分布。容量规划书应至少每月更新一次核心指标，每季度重跑关键负载，出现大规模回灌、模型调整、版本升级或硬件更换时立即重算。

二、存储容量：从原始数据走到真实物理磁盘

2.1 推荐使用显式公式

存算一体模式下，可以使用以下公式形成初始容量：

单副本存储量
= 原始热数据量
× 实测压缩系数
× (1 + 索引与附加结构开销)

集群物理容量
= 单副本存储量
× 副本数
× (1 + Compaction 余量)
× (1 + 规划期增长余量)
÷ 目标磁盘利用率

变量解释：

• 压缩系数：Doris 单副本实际存储量 ÷ 原始输入量；0.40 表示压缩后保留 40%；
• 附加结构开销：倒排索引、BloomFilter、Row Store、物化视图、Delete Bitmap 和元数据的综合增量；
• Compaction 余量：合并期间新旧 Rowset 同时存在、临时文件和后台写放大的空间；
• 增长余量：规划周期内的业务增长和临时补数；
• 目标利用率：让扩容在磁盘满之前完成，常见起点是 70%–80%，具体值由采购和扩容周期决定。

2.2 100 TB 热数据示例

本篇实验使用以下假设：

原始热数据：100 TB
实测压缩系数：0.40
索引与附加结构：10%
副本数：3
Compaction 余量：40%
6 个月增长：25%
目标磁盘利用率：80%

计算过程：

100 × 0.40 × 1.10 = 44 TB        单副本
44 × 3 = 132 TB                   三副本
132 × 1.40 = 184.8 TB             Compaction 后
184.8 × 1.25 = 231 TB             含增长
231 ÷ 0.80 = 288.75 TB            需要的可用原始磁盘

这组结果的前提是 0.40 和 10% 已经通过 POC 测得。缺少实测值时，可以先使用官方保守公式形成预算上限，再安排样本导入校准。

2.3 Tablet 数量同样属于容量

物理字节只是存储容量的一部分。Tablet 元数据同时存在于 FE 和 BE。当前官方表设计文档给出的经验边界包括：单 Tablet 建议 1–10 GB；单 BE 承载的 Tablet 数应低于 20,000；每 1000 万 Tablet，FE 至少需要约 100 GB 内存；单分区 Bucket 通常控制在 128 以内。[6]

Tablet 过多会增加 FE Catalog、BE 元数据、调度、文件句柄、统计信息和 Compaction 管理成本。单 Tablet 过大又会限制并行度、拉长副本修复和迁移时间。容量规划书需要同时列出：

预计 Partition 数
× 每 Partition Bucket 数
× 索引数量
× 副本数
= Tablet / Replica 规模

2.4 存算分离的容量模型

存算分离把持久数据放入对象存储或共享存储，本地盘主要承担 File Cache、临时文件和 Spill。此时需要分别计算：

共享存储容量
= 压缩数据 × 保留期 × 历史增长 × 版本/快照开销

本地缓存容量
= 热工作集 × 预期命中覆盖率 × 缓存副本/计算组数量

对象存储容量低廉，查询 SLA 仍然受网络、对象存储吞吐、请求数、缓存命中和冷启动影响。新计算组扩容后的第一次查询必须进入验收范围。

三、CPU：用核心秒解释并发

3.1 CPU 规划从 Profile 开始

Query Profile 中的 CPU Time 可以换算成一条查询平均占用的核心数：

单查询平均核心数
≈ CPU seconds ÷ Wall seconds

某条复杂查询 p95 CPU Time 为 16 core-seconds，目标响应时间 4 秒，则其平均占用约 4 个核心。目标并发为 50，安全系数 1.30，后台写入和 Compaction 预留 20%：

50 × 4 × 1.30 × 1.20 = 312 cores

312 核属于初始计算包络。真实查询会分布到多个 BE，热点 Tablet、Join Build 侧、数据倾斜和不同 SQL 的重叠会改变单节点峰值，因此还要检查各 BE 和各 Instance 的 max、avg、min。

3.2 CPU 型和 I/O 型查询需要不同配置

典型 CPU 型负载包括：

• 高基数 Hash Join 和聚合；
• 大量表达式、字符串处理、JSON Path 和正则；
• 排序、窗口函数、Bitmap 集合计算；
• 高并发短查询带来的解析、调度和线程切换。

典型 I/O 型负载包括：

• 大范围列扫描；
• 低选择率过滤；
• 对象存储或 HDFS 冷读；
• Compaction、补数、Spill 和副本迁移。

CPU 型查询更依赖核心数、频率、向量化和合理并行度；I/O 型查询更依赖列裁剪、数据跳过、磁盘吞吐、缓存和网络。只提高核心数，磁盘和网络无法同步供数时，CPU 会等待 I/O；只增加磁盘，Join 和聚合已经吃满核心时，延迟也不会下降。

3.3 FE CPU 与 BE CPU 分别规划

FE 负责连接入口、解析、绑定、Nereids 优化、元数据管理和调度。复杂 SQL、海量 Partition/Tablet、外部 Catalog 小文件和高连接数会抬高 FE CPU。BE 承担 Scan、Join、Aggregation、Sort、Exchange、导入和 Compaction，通常消耗集群的大部分计算资源。

生产环境建议 FE 与 BE 分开部署。FE 扩容 Observer 可以提高连接和元数据读取能力；BE 水平扩容可以增加扫描、计算、缓存和存储资源。[3]

四、内存：总量、单节点和资源边界都要成立

4.1 FE 内存主要随元数据和规划复杂度增长

FE JVM 内存需要容纳 Catalog、Tablet、Partition、统计信息、连接、Session、查询计划、Nereids Memo、Profile 和后台任务状态。当前官方生产建议为 64 GB 以上；大规模 Tablet、复杂 SQL 和高并发入口需要继续增加。[1]

FE 元数据目录应放在独立 SSD，避免与 BE 数据盘争抢 I/O。三台 Follower 的 JVM、磁盘和网络配置尽量一致，降低选主后的性能差异。

4.2 BE 内存由多类任务共同使用

单个 BE 的内存同时服务于：

• Query Operator：Hash Join、Aggregation、Sort、Window；
• Scan Buffer、Page Cache、Row Cache 和其他缓存；
• Stream Load、Routine Load、MemTable 与写入解析；
• Compaction、Delete Bitmap 和主键更新；
• BRPC、线程栈、Allocator 和系统运行时；
• Spill 前的内存状态和预留空间。

官方推荐 BE 内存按 CPU cores × 8 GB 规划，例如 32 核对应 256 GB、64 核对应 512 GB。[1] 这条规则适合形成硬件起点，业务侧还需要用 Profile 和混合负载校准。

4.3 集群总内存无法覆盖热点节点问题

某个 Join Key 倾斜、某个 Tablet 过大、某个 BE 承担更多热数据时，单节点 Peak Memory 会显著高于平均值。容量验收应记录：

• 各 BE 进程内存；
• 单查询在各 Instance 的 Peak Memory；
• Workload Group 使用量和排队情况；
• Load、Compaction 与查询重叠时的峰值；
• Spill 触发次数、读写字节和延迟增量。

Spill 可以提高大查询完成率，但会把内存压力转化为磁盘 I/O 和更长的查询时间。生产规划应给 Spill 配置专用 SSD 路径或确认数据盘仍有足够吞吐。[7]

五、磁盘：容量、吞吐、IOPS 和延迟是四个维度

5.1 扫描型负载看吞吐

列式扫描和 Compaction 常以连续读写为主，核心指标是每盘和每节点的 MB/s、GB/s。数据已经通过分区、前缀索引、ZoneMap 和倒排索引大幅裁剪时，扫描量会降低；模型或 SQL 无法裁剪时，再快的盘也会被大量无效读取消耗。

5.2 点查和 MoW 更新看 IOPS

高并发主键点查、Unique Key MoW 主键查找、宽表部分更新补列更依赖随机 IOPS 和 p99 延迟。此类场景优先使用 NVMe SSD。Row Store 可以减少部分更新补齐旧列时打开大量列页的随机 I/O，代价是空间和写入开销增加。

5.3 Compaction 同时读旧文件和写新文件

Compaction 会读取多个 Rowset、执行排序或合并、写出新 Rowset，然后等待旧文件进入回收。磁盘容量尚有余量时，磁盘带宽也可能已经被写入、查询和 Compaction 共同打满。容量 POC 需要在持续写入状态下运行复杂查询，观察：

磁盘读吞吐
磁盘写吞吐
I/O wait
Compaction Score
Rowset / Version 增长
查询 p99

5.4 多盘配置与目录隔离

官方手工部署文档支持通过 storage_root_path 配置多个 BE 数据盘，并建议 FE 元数据盘、BE 数据目录和安装目录分离。[8] 多盘可以提高总容量和 I/O 并行度，仍要确认每块盘的健康、容量分布和故障替换流程。

对于 Spill，官方建议使用专用盘路径；对于存算分离，本地盘容量围绕热工作集和缓存命中规划。[7]

六、网络：Shuffle、复制、均衡和对象存储都在抢带宽

Doris 是 MPP 系统，网络容量直接进入查询和写入路径。主要流量包括：

1. 客户端到 FE/BE 的 SQL、Stream Load 和结果返回；
2. FE 到 BE 的 Fragment 调度、状态和 Profile；
3. BE 之间的 Shuffle、Broadcast、Runtime Filter 和结果汇聚；
4. 多副本写入、副本修复和扩容后的 Rebalance；
5. 存算分离或湖仓查询访问对象存储、HDFS；
6. 监控、日志和备份流量。

官方推荐 10GbE 以上，并建议多网卡环境使用链路聚合。[1] 对大规模 Shuffle、高并发复杂查询、频繁均衡或对象存储回源场景，25GbE 或更高带宽通常更稳妥，具体等级应使用真实 Shuffle Bytes / 查询时长 / 重叠并发 测量。

一个实用估算式是：

节点所需带宽
≥ max(写入复制流量, Shuffle 峰值, Balance 流量, 远端读取流量)
÷ 有效链路利用率
× 安全系数

网卡标称 25Gbps 不代表应用可以长期使用完整 25Gbps。协议、交换机、队列、跨机架链路、其他业务和故障重平衡都会占用带宽。生产压测应记录主机网卡、交换机端口和 Doris Profile 三层数据。