3. 容量规划方法论
容量规划不是“等报警了再加机器”，而是一套把业务增长、负载特征、资源水位和扩容动作串起来的可重复方法。它的核心目标只有两个：在业务需要之前准备好资源，同时不让资源长期闲置。本节围绕四个关键环节展开：业务增长预测、峰值与均值负载分析、容量水位设定、扩容触发条件，最后给出一份可直接使用的容量规划模板，并用一个示例演练完整走一遍。
一、业务增长预测：把业务语言翻译成资源语言
容量规划的起点是业务增长预测。业务侧通常给出的是日活、订单量、查询次数、报表订阅数等指标，而集群侧关心的是 CPU、内存、磁盘、IO、并发连接数。因此第一步是建立业务指标到资源指标的换算关系。
常用做法是取历史数据做回归。例如某 OLAP 集群过去 12 周，每周新增数据量约 1.2 TB，查询并发峰值约 180，CPU 峰值利用率 62%。若业务预计未来半年订单量月均增长 8%，则可按“查询量随订单量近似线性增长”的假设，推算半年后并发峰值约为 180 × (1.08)^6 ≈ 285。这个数字不是精确值，而是用于提前判断“现有资源能否撑住”的量级参考。
预测时要区分三类增长：存量增长（历史数据累积，主要影响存储）、增量增长（每日新增数据，影响存储与写入）、访问增长（查询频次与并发，影响计算资源）。三者增速往往不同，必须分开预测，不能用一个总增长率笼统覆盖。
二、峰值与均值负载分析：容量由峰值决定，成本由均值决定
OLAP 集群的负载具有明显的潮汐特征：白天报表查询密集，夜间 ETL 写入密集，月末、季末、大促期间出现尖峰。容量规划必须同时看均值和峰值。
均值决定长期资源占用和成本基线，峰值决定系统是否会被压垮。实践中常用峰值均值比（Peak-to-Average Ratio，PAR）来衡量负载波动。例如某集群日均 CPU 利用率 35%，日峰值 78%，则 PAR ≈ 2.23。PAR 越高，说明负载越不均衡，越需要弹性伸缩或错峰调度，而不是简单按峰值配置固定资源。
分析峰值时要注意三个维度：时间维度（日峰、周峰、月峰、大促峰）、业务维度（不同报表、不同租户的查询压力）、资源维度（CPU 密集、内存密集、IO 密集的查询混在一起会互相放大压力）。建议至少采集连续 4 周的分钟级监控数据，按 P50、P95、P99 分位统计，而不是只看平均值。
三、容量水位设定：给系统留出安全缓冲
容量水位是“资源用到多少算安全、多少算危险”的量化标准。设定水位时要考虑三个因素：突发流量、故障冗余、性能拐点。
以 CPU 为例，OLAP 查询在 CPU 利用率超过 70% 后，排队延迟往往非线性上升；超过 85% 后，P99 响应可能翻倍。因此常见做法是：安全水位 ≤ 70%，警戒水位 80%，扩容水位 85%。内存水位通常更保守，因为内存不足会触发磁盘溢写，性能断崖式下跌，建议安全水位 ≤ 75%。存储水位则要考虑副本因子和压缩比，例如三副本、压缩比 3:1 时，实际可用容量约为裸容量的 1/9，安全水位建议 ≤ 80%。
水位不是固定值，要随业务重要性调整。核心报表集群水位应更保守，离线分析集群可以更激进。同时要区分瞬时水位和持续水位：瞬时冲高不一定需要扩容，持续超过阈值才说明容量真的不足。
四、扩容触发条件：从“人盯”到“规则驱动”
扩容触发条件应满足三个要求：可量化、可复现、可回滚。推荐用“指标 + 阈值 + 持续时长 + 冷却期”四元组定义。例如：
触发条件示例：
- CPU P95 利用率 ≥ 80%，持续 15 分钟，冷却期 30 分钟
- 查询排队时长 P95 ≥ 5 秒，持续 10 分钟
- 存储使用率 ≥ 80%，且按当前增速预计 30 天内耗尽
- 内存使用率 ≥ 85%，持续 20 分钟
扩容动作：
- 优先增加查询节点（计算扩容）
- 存储不足时增加存储节点或冷热分层
- 扩容后观察 30 分钟，确认水位回落至安全线以下触发条件要避免“一超就扩”。建议设置分级响应：黄色预警只通知，橙色预警触发自动扩容，红色预警触发人工介入并限流。同时要记录每次扩容的原因、时间、资源量和效果，用于后续修正预测模型。
五、容量规划模板与实战演练
下面给出一份可直接填写的容量规划模板，字段围绕本节四个环节设计，不引入无关管理字段。
| 字段 | 填写说明 | 示例值 |
|---|---|---|
| 业务指标 | 驱动增长的核心业务量 | 日订单 50 万，月增 8% |
| 资源换算系数 | 单位业务量对应的资源消耗 | 每万订单 ≈ 0.6 核 CPU |
| 当前资源 | 现有集群规格与数量 | 查询节点 12 台 × 16 核 |
| 均值 / 峰值 | 近 4 周 P50 与 P95 利用率 | CPU 35% / 78% |
| PAR | 峰值 ÷ 均值 | 2.23 |
| 安全 / 警戒水位 | 按资源类型设定 | CPU 70% / 80% |
| 扩容触发条件 | 指标 + 阈值 + 时长 + 冷却 | P95 ≥ 80% 持续 15 min |
| 预计扩容时间 | 按预测增速倒推 | 约 4 个月后 |
| 扩容方案 | 加节点 / 升配 / 分层 | 增加 4 台查询节点 |
实战演练：假设某电商 OLAP 集群当前查询节点 12 台 × 16 核，日均 CPU 35%，日峰值 78%，P95 查询排队 1.8 秒。业务预计未来 6 个月订单月增 8%，查询量同步增长。按换算系数，6 个月后 CPU 峰值预计达到 78% × (1.08)^6 ≈ 124%，远超安全水位。按每台 16 核、目标峰值 70% 计算，所需核数约为当前核数的 124/70 ≈ 1.77 倍，即需要约 21 台查询节点，建议分两批扩容：第 3 个月先加 4 台，第 5 个月再加 5 台，并同步设置 P95 ≥ 80% 持续 15 分钟自动扩容规则。扩容后观察一周，若峰值回落至 65% 以下、P95 排队降至 1 秒内，说明容量规划达到预期。