3. 容量规划基础：目标、关键指标与容量模型
3.1 容量规划的目标：从“事后扩容”到“事前设计”
湖仓一体平台的容量规划，本质上是在业务增长预测、资源供给成本与服务质量（SLA）三者之间寻找平衡点。其核心目标并非“买够机器”，而是以可接受的成本，在可预见的时间窗口内，持续满足数据增长与计算负载的需求，同时避免两类典型失效：资源瓶颈（存储写满、计算队列积压）与资源浪费（峰值预留过度、低频任务占用高频资源）。
一个成熟的容量规划体系应具备三个特征：
- 可预测性：能根据业务指标（如日活用户数、API 调用量）与数据规模的历史趋势，提前 3~6 个月预判资源拐点。
- 可量化性：所有决策均基于明确的容量指标（如存储压缩比、CPU 核时单价），而非经验估算。
- 可回退性：规划方案支持弹性伸缩与缩容，避免因一次性采购造成长期闲置成本。
3.2 关键容量指标：存储、计算、网络的三维视图
湖仓一体环境的容量规划需同时关注存储、计算与网络三个维度，且三者相互制约。例如，增加存储节点会带来网络带宽压力，而计算引擎的 shuffle 操作则同时消耗磁盘 IO 与网络带宽。
下表列出了生产环境中必须跟踪的核心指标及其推荐监控粒度：
| 维度 | 核心指标 | 典型单位 | 监控粒度 | 规划阈值参考 |
|---|---|---|---|---|
| 存储 | 逻辑数据总量 | TB / PB | 日 | — |
| 物理存储占用（含副本与压缩） | TB / PB | 小时 | ≤ 集群总裸容量 70% | |
| 数据压缩比 | 比率（如 3.5:1） | 周 | 低于 2:1 时需检查文件格式 | |
| 计算 | CPU 核时消耗 | core-hour / 天 | 小时 | 峰值队列等待时间 < 5 分钟 |
| 内存分配率 | GB / 任务 | 任务级 | OOM 频率 = 0 | |
| 任务排队时长 | 秒 / 分钟 | 分钟 | P95 排队时长 < 30 秒 | |
| 网络 | 节点间南北向吞吐 | Gbps | 分钟 | ≤ 网卡带宽 60% |
| Shuffle 数据量 | GB / 作业 | 作业级 | 大作业需提前规划带宽 |
在存储指标中，尤其需要区分逻辑数据量与物理存储占用。湖仓中的 Iceberg 或 Hudi 表通常采用 Parquet/ORC 格式，并启用 Snappy/ZSTD 压缩，同时依赖 HDFS 三副本或云对象存储的 EC 策略。因此，物理空间 = 逻辑数据量 / 压缩比 × 副本系数。忽略压缩比变化（如小文件过多导致压缩失效）是容量规划失败的常见原因。
3.3 容量模型：构建可计算的资源预测公式
容量模型是将业务增长转换为资源需求的数学桥梁。一个实用的湖仓容量模型应包含存储模型与计算模型两部分。
3.3.1 存储容量模型
存储模型的核心是预测未来 N 个月的物理存储总量。其简化公式如下：
物理存储总量(T) = 当前物理基数 × (1 + 月增量率)^T
月增量率 = (日增数据量 × 30 × 压缩系数) / 当前物理基数其中，压缩系数需考虑快照副本（Iceberg 的 Snapshot 保留数量）与过期数据清理策略。例如，某平台当前物理存储 500 TB，日增逻辑数据 2 TB，压缩比 3:1，保留 7 天快照，则月增量率约为 (2×30/3)/500 = 4%。若不清理过期快照，实际增量率可能翻倍。
3.3.2 计算容量模型
计算模型需按负载类型拆分：离线批处理（Spark）、实时流处理（Flink）与交互式查询（Presto/Trino）。每种负载的资源估算方式不同：
离线批处理核时预算 = Σ(每日作业预估输入数据量 / 单核处理吞吐量)
实时流处理资源 = 峰值事件数 × 单事件处理CPU耗时 × 并行度系数
交互式查询资源 = 平均查询并发数 × 单查询峰值内存 × 超卖比(通常2~3)生产环境中，建议将计算模型与弹性伸缩策略结合。例如，固定池承载核心数仓任务，弹性池承载即席查询与实验性作业，弹性池在空闲时缩容至 0。
该平台以日志分析为主，日增数据 8 TB，压缩比 4:1，HDFS 三副本。存储模型预测：当前物理 1.2 PB，月增量率 = (8×30/4×3)/1200 ≈ 1.5%，半年后物理存储约 1.31 PB，需提前规划扩容节点。计算侧，其核心 Spark 任务日消耗 2.4 万核时，单核吞吐量约 150 MB/s，当业务量增长 30% 时，核时需求增至 3.1 万，需将弹性队列上限从 500 核调至 800 核，并配置抢占策略保障核心任务。
3.4 容量规划方法流程：四步法
标准化的容量规划流程可归纳为以下四个步骤，每一步都需输出可审计的文档：
- 数据采集与基线建立：收集过去 6~12 个月的存储增长曲线、计算资源使用率（CPU/内存）、任务失败率与排队时长。此阶段需排除一次性迁移或异常促销带来的噪声数据。
- 业务增长预测：与业务方确认未来 2~3 个季度的数据增量预期（如用户数、设备数、日志采集频率）。若业务无法提供明确数字，可采用时间序列预测（如 ARIMA）或保守的复合年增长率（CAGR）。
- 模型计算与场景模拟：将预测值代入 3.3 节的模型，分别计算标准增长与激进增长（1.5 倍）两种场景下的资源需求。同时模拟故障场景（如一个可用区宕机）下的资源冗余度。
- 预算对齐与采购/伸缩决策：将资源需求转换为云资源月度成本或物理机采购清单，与财务预算比对。若超出预算，则需调整数据生命周期策略（如将冷数据转至对象存储）或降低副本数。
3.5 常见误区与复盘要点
在多个企业的湖仓容量规划实践中，以下三类误区最具代表性，值得重点规避：
某金融客户曾按日增 500 GB 规划，但一次业务活动导致日志量激增 5 倍，同时 Iceberg 的孤儿文件未及时清理，最终在 2 周内写满可用空间。复盘结论：容量模型必须加入“峰值系数”（建议 1.5~2 倍），并建立每日孤儿文件清理任务。
湖仓的典型特征是负载昼夜波动大。若按平均 CPU 利用率 40% 规划，则晚间的 BI 报表高峰可能造成队列堆积。正确做法是分析 P95 或 P99 负载，并配置弹性队列应对突发。
在 Spark 大规模 Join 或窗口聚合时，Shuffle 数据量可能达到输入数据的 2~3 倍。若仅关注存储与 CPU，网络将成为隐性瓶颈。建议在容量模型中增加“网络峰值带宽 = 最大作业 Shuffle 量 / 期望完成时间”的校验项。
复盘建议：每次容量扩容或缩容后，应记录实际资源使用与预测值的偏差。若偏差超过 20%，需回溯是模型参数（如压缩比）失准，还是业务增长假设偏离。将复盘结果固化到下一轮规划中，形成持续优化的闭环。