搭建大数据平台时最常被跳过、事后代价最大的一步就是容量规划。常见的两种翻车姿势一是照着别人家集群长什么样拍脑袋采购上线后发现磁盘三个月写满二是先小规模试点等流量真上来才发现 Kafka 带宽打满、ES 分片数爆表扩容窗口赶不上数据增长。这篇文章把我在实际项目里沉淀的一整套容量估算模型整理出来——覆盖Kafka、Elasticsearch、ClickHouse、Hadoop四大组件每个组件都给出估算公式、经验参数和完整算例拿去套上自己的业务参数就能出一份资源清单。一、容量规划的通用方法论三步法无论哪个组件容量估算都遵循同一条主线可以概括为三步测流速算出系统每秒/每天要吞多少数据条数 × 单条大小定窗口确定数据保留多久保留 7 天和保留 180 天磁盘需求差 25 倍这是最大的变量上系数用一组修正系数把裸数据量修正成真实资源需求——副本因子、存储膨胀/压缩系数、磁盘水位线、集群资源利用率。用公式表达就是磁盘需求 每日原始数据量 × 保留天数 × 副本因子 × 存储/膨胀系数 ÷ 磁盘可用水位 节点数 单组件资源总需求堆内存 / 吞吐量 / CPU 核 ÷ 单节点可承载能力后面每个组件的公式本质上都是这两条的变体。区别只在于不同组件的单节点可承载能力物理量不同——Kafka 看磁盘吞吐MB/sES 看堆内存管理的分片数ClickHouse 看单节点日写入量Hadoop 看 YARN 可分配的资源池。为了让大家方便对照本文全程用两个算例场景参数场景 A企业监控平台场景 B大规模数据管道指标/消息总数30 万个指标—采集/推送频率5 分钟一次288 次/天持续推送推送速率约 1000 条/秒3000 万条/秒单条数据大小200 B100 B每日原始数据量约 16 GB约 236 TB场景 A 的推导每天采集条数 300000 × (1440 ÷ 5) 8640 万条平均速率 8640 万 ÷ 86400 1000 条/秒每日原始量 8640 万 × 200 B ≈ 16 GB。注意实际采购要按峰值速率留余量监控类业务高峰通常在白天巡检和批量任务时段经验上按均值的 2~3 倍估峰值。二、Kafka 容量估算磁盘、Broker 数与单机内存Kafka 是数据链路的入口它的容量估算分三块磁盘、Broker 节点数、单机内存。2.1 磁盘容量每日落盘数据量 每秒条数 × 单条字节 × 86400 × 副本因子 × (1 其他数据预留) 磁盘总需求 每日落盘量 × 保留天数 ÷ (1 - 磁盘预留比例)以场景 A 为例副本因子取 21 份主 1 份副本其他类型数据预留 10%数据保留 7 天磁盘预留 20%每日落盘量 1000 × 200 B × 86400 × 2 × 1.1 ≈ 35.4 GB7 天保留量 35.4 × 7 ≈ 248 GB建议磁盘 248 ÷ 0.8 ≈ 310 GB再考虑分区分配不均3 节点各配 500 GB 数据盘绰绰有余Kafka 顺序写磁盘的效率极高中小规模下磁盘容量几乎总是先于吞吐成为约束所以保留时长直接决定成本。如果你们的 Kafka 同时还承接业务消息不只为大数据组件服务其他数据预留这一项要按实际业务量调大。2.2 Broker 节点数大吞吐场景规模上去之后瓶颈从容量转向吞吐Broker 数量按磁盘写入带宽推算Broker 数 每秒数据量(MB/s) × 副本因子 ÷ 单 Broker 承载能力单 Broker 的承载能力经验上按 100~150 MB/s 估普通机械盘顺序写SSD 可适当上调但不建议把 Kafka 建在 SSD 上——顺序写场景机械盘性价比更高。场景 B 算例3000 万条/秒 × 100 B 约 3 GB/s 的原始写入3 副本下总写入 9 GB/s按单 Broker 1 GB/s 计Broker 数 30000000 × 100 × 3 ÷ (1024 × 1024 × 1024) ÷ 1 ≈ 9 台2.3 单机内存五个部分加起来Kafka 单机内存是最容易被低估的一项它不是只给 JVM 的——页缓存Page Cache才是 Kafka 吞吐的命根子。生产上单 Broker 内存建议按五项拆解组成建议值说明Page Cache16 GB尽量让活跃分区的日志段驻留内存JVM 堆8 GBBroker 进程堆官方建议不低于 6 GBOS 预留4 GB操作系统自身Broker 进程开销2 GB堆外、DirectBuffer 等冗余缓冲16 GB应对流量抖动与页缓存倾斜合计约46 GB取整配 64 GB 内存的服务器。小规模集群可以降配但经验底线是单节点 8 GB 内存起步日活数据量较大的场景 16 GB 才稳。另外补充一个分区数的最佳实践Kafka 分区只能加、不能减。初次建 Topic 时分区数要按预期吞吐和消费者并发宁多勿少地设置——事后加分区虽然方便但会破坏按 key 分区的消息顺序性对顺序敏感的业务是隐性事故。三、Elasticsearch 容量估算磁盘、堆内存与节点数ES 的容量估算分磁盘和内存两条线历史上我写过一篇日增 30TB 日志集群的分片规划《Elasticsearch 日增 30TB 日志架构实战》本文补上更完整的估算框架。3.1 磁盘容量三个系数别漏ES 磁盘需求 每日原始数据量 × 保留天数 × (1 副本数) × 存储膨胀系数 ÷ 磁盘水位线三个系数逐一说明副本因子1 副本就是 ×2这是最常被漏算的一项存储膨胀系数ES 存的是_source原始 JSON 倒排索引 doc values实际占用与 mapping 强相关。我们一套汇算类索引1 小时粒度聚合数据生产实测的原始数据与存储数据系数是 3.38——即 1 GB 原始数据落盘约 3.38 GB。不同 mapping 差异极大建议拿真实样本灌一个测试索引实测校准磁盘水位线ES 有cluster.routing.allocation.disk.watermark.low/high水位保护默认 85%/90%磁盘用到 85% 就开始迁走分片所以容量规划必须按 85% 可用估算不能按标称容量。完整算例日增 420 GB 的日志流水场景热数据保留 7 天1 副本7 天 1 天冗余的原始量420 GB × 8 3.36 TB加 15% 高水位警戒3.36 ÷ 0.87 ≈ 3.86 TB该场景建议配置3 台 8C64G、1.4 TB 数据盘的节点总容量 4.2 TB满足水位约束后仍有余量3.2 堆内存与节点数从分片数倒推ES 集群的堆内存需求由分片总数决定估算链路是分片总数 每日新增索引数 × 主分片数 × (1 副本数) × 保留天数 集群堆内存 分片总数 ÷ 每 GB 堆可管理分片数(经验值 30) 物理内存 堆内存 × 2(堆内 : 堆外 ≈ 1 : 1) 节点数 ceil(集群堆内存 ÷ 单节点堆上限 31 GB) CPU 总核数 集群堆内存 ÷ 4(堆内存 : CPU 核 ≈ 4 : 1)每 GB 堆管理 30 个分片是这套模型的实测经验值。社区更早期的说法是 1 GB 堆管 50 个分片新版本集群7.x 之后分片管理开销上升普遍建议更保守按 20~30 取值更稳。算例假设指标按业务系统分索引metric-{系统}-{日期}50 个系统、每个索引 3 主分片、1 副本、保留 7 天分片总数 50 × 3 × 2 × 7 2100 个集群堆内存 2100 ÷ 30 70 GB物理内存 140 GB节点数 ceil(70 ÷ 31) 3 台每台 64 GB 内存、堆 31 GBCPU 总核 ≈ 70 ÷ 4 ≈ 18 核均摊每台 8 核够用单节点堆上限取 31 GB 是因为 JVM 压缩指针Compressed Oops在 32 GB 以下才生效超过后指针膨胀反而降低性能。四、ClickHouse 容量估算节点数与核内存比ClickHouse 的容量模型比 ES 简单核心公式只有一条节点数 每日写入数据量(TB) ÷ 单节点日写入能力(TB)单节点日写入能力取决于硬件与表引擎。我们按 16C64G、MergeTree 系列表的口径实测单节点日写入能力约64 TB含批量写入场景过碎的 insert 会大幅拉低这个值ClickHouse 官方建议每次批量不少于 1000 行或每秒 1 次 insert这也是大坑之一详见我之前的《ClickHouse 可观测数据建模实战》。场景 B 算例每日写入量 30000000 条/秒 × 86400 秒 × 100 B ÷ (1024)^4 ≈ 236 TB 节点数 236 ÷ 64 ≈ 3.7 → 4 台(16C64G)两个补充系数核 : 内存 1 : 4ClickHouse 是计算密集型内存主要用于查询执行16 核配 64 GB 是经典比例磁盘反向修正与前两个组件不同ClickHouse 的列式压缩是省磁盘的——LZ4 压缩比通常在 3~10 倍取决于数据重复度磁盘需求可以按原始量 ÷ 实测压缩比下调。上线前务必拿真实数据灌一张表看system.parts里的data_compressed_bytes比任何经验值都准。五、Hadoop/YARN 容量估算从任务数到服务器数流处理任务Flink on YARN 等的资源估算思路先算需要多少个 TaskManager再换算成物理机。TaskManager 数 每秒数据量(MB/s) ÷ 单 TM 吞吐能力(经验值 100 MB/s) 服务器数 TM 数 × (单 TM 核数 JobManager 核数) ÷ 单节点核数 ÷ 集群资源可分配比例场景 B 算例16C 的 TaskManagerJobManager 2C128 核物理机YARN 可分配比例 80%每秒数据量 3000 万 × 100 B ≈ 2861 MB/sTM 数 2861 ÷ 100 ≈ 29 个服务器数 29 × (16 2) ÷ 128 ÷ 0.8 ≈ 5.1 →6 台中小规模下还有一个更细的任务分类算法把任务按用途分成监控类、外部数据接入类、常驻计算类三类每类分别数任务数单任务按 2 核 4 GB 估再除以利用率0.6~0.8。任务粒度越小这种分类估算法越准。两个经验值值得记录实测9C15G 的资源配置可以达到 2 万条/秒的数据处理速度YARN 的可分配比例默认只有 0.6~0.8其余要留给 NodeManager、OS 和 DataNode别按标称核数满打满算。Flink 任务的实际吞吐调优可以参考我之前写的《Flink 实时交易监控实战》。六、汇总公式速查表与落地配置建议把四个组件的公式放进一张表方便直接取用组件磁盘节点数/内存关键经验参数Kafka每秒条数×单条字节×86400×副本×(1预留)×保留天数÷(1-磁盘预留)Broker吞吐÷单机承载内存PageCacheJVMOS进程冗余单 Broker 100~150 MB/s单机内存五项合计约 46 GB分区宁多勿少Elasticsearch日增量×保留天数×(1副本)×膨胀系数÷0.85堆分片数÷30节点堆÷31 GB物理内存堆×2膨胀系数实测 3.38堆:核≈4:1水位线 85%ClickHouse原始量÷压缩比(3~10)节点日写入量÷单节点能力16C64G 单节点日写约 64 TB核:内存1:4Hadoop任务日志盘 300 GB 级即可服务器TM×(162)核÷节点核数÷0.8单 TM 吞吐 100 MB/sYARN 可分配 0.6~0.89C15G≈2 万条/秒以场景 A日增 16 GB 级别的监控平台落地一份典型的起步配置清单组件单节点配置数量关键依据Kafka8C 16G500 GB3单节点官方建议 ≥8 GB 内存三节点满足最小副本分布ZooKeeper/KRaft与 Kafka 混部或 3×4C8G3多组件共用时独立部署更稳Hadoop/YARN8C 32G500 GB3覆盖监控接入常驻计算三类任务并留增长空间Elasticsearch8C 64G1 TB3日增 16 GB×副本×膨胀÷水位7 天保留余量充足数据链路的整体架构Kafka 削峰 → 计算 → ES/CK 存储可以参考我之前的《云原生日志采集与检索架构实战》。七、踩坑点五个最容易翻车的地方水位线不是标称容量。ES 到 85% 开始迁分片、Kafka 留 20% 预留、YARN 只能分出去 0.6~0.8——三个组件都要打折按裸容量采购的集群实际可用只有七成。副本因子最先被漏算。磁盘需求 ×21 副本是常态Kafka 3 副本生产标配更是 ×3评审时看到没乘副本的容量表直接打回。存储系数方向反了。ES 是膨胀实测 3.38ClickHouse 是压缩3~10 倍把 CK 的压缩逻辑套到 ES 上磁盘会准备小一半反之成本翻倍。上线前用真实数据各灌一个测试索引/表实测。按均值算死在峰值。1000 条/秒是均值巡检高峰、批量补数、故障重放都可能打到 3 倍流速。堆内存、broker 吞吐、TM 数都要按峰值校验一遍。保留策略才是最大的成本变量。同样流速保留 7 天和保留 180 天磁盘差 25 倍。容量规划前先和业务方把每一类数据的保留期限白纸黑字定下来——这比多算三遍公式都重要。结语容量规划的本质不是精确预测而是把拍脑袋变成带系数的估算流速是锚点副本、水位、膨胀、利用率是修正项最后再叠一层峰值安全边际。这套模型在两套不同规模的生产环境里验证过误差能控制在可接受范围——更重要的是出了偏差你能立刻定位是哪个系数估错了。你们团队的集群配置是算出来的还是拍出来的有没有踩过上线三个月磁盘写满的坑评论区聊聊。相关阅读Elasticsearch 日增 30TB 日志架构实战可变索引粒度、分片规划与检索调优云原生日志采集与检索架构实战K8s 日志和传统日志统一接入日志平台的设计方案Kafka ElasticsearchClickHouse 可观测数据建模实战指标、日志、链路、告警四类数据的 MergeTree 表设计与集群化改造Flink 实时交易监控实战交易日志解析与分钟级指标计算