初期构建一个性能好的特征存储只是成功的一半。随着您的机器学习 (machine learning)应用发展，处理不断增长的数据量、更复杂的特征和更高的预测请求率变得十分重要。主动规划未来的资源需求，并严格测试系统在负载下的极限，是保证持续性能、可靠性和成本效益的重要做法。本节介绍特别适用于高阶特征存储系统实现的容量规划和负载测试方法。
特征存储的容量规划
容量规划需预测特征存储未来所需资源（计算、存储、网络），以达到预期的服务等级目标（SLOs），这涵盖了在线服务与离线处理。好的规划有助于避免性能瓶颈、减少服务中断，并通过避免资源过度或不足配置来控制运营成本。
影响容量需求的因素
有几个因素会影响特征存储的资源需求：
- 在线服务负载： 主要以在线存储服务API的每秒查询数（QPS）来衡量。需考虑峰值与平均负载、读写比以及每次查询所需的特征数量。低延迟要求（例如，p99延迟低于10毫秒）会很大程度上影响基础设施选择，通常要求使用内存数据库或大量缓存。
- 离线数据量和增长： 离线存储中历史数据的规模及其增长速度直接影响存储成本和批处理特征工程及训练数据集生成所需的计算资源。数据保留策略在此处有重要作用。
- 特征计算复杂度： 特征转换的计算成本，特别是复杂聚合（如时间窗口特征）或按需计算，决定了离线批处理作业以及（如果使用按需模式）在线服务所需的CPU和内存要求。
- 特征基数和数量： 大量不同特征或高基数实体ID会增加存储需求（尤其是在线存储中的索引），并可能影响查找性能和元数据管理开销。
- 训练作业频率和规模： 模型重训练的频率以及每次训练从离线存储获取的数据量，影响离线存储的存储和计算层所承受的需求。并发训练作业会增强这种影响。
- 数据摄取速率： 对于流式特征，传入数据点的速率影响流处理引擎所需资源和在线存储的写入负载。
估算方法
预测未来需求需要结合多种方法：
- 趋势分析： 分析在线和离线组件的历史资源利用指标（CPU、内存、网络I/O、存储使用量、QPS）。推断这些趋势，并考虑季节性和已知的增长模式。这通常是起点，但它依赖于过去行为预示未来的情况。
- 性能建模： 构建简单的分析模型。例如，将在线存储的CPU使用量建模为QPS和特征复杂度的函数，或根据每日数据摄取速率和保留期对离线存储进行建模。尽管这些模型有其用处，但它们通常假定线性可扩展性，这在重负载或复杂系统中可能不适用。一个在线服务节点的简化模型可以是：
所需节点数=⌈节点CPU容量×目标利用率目标QPS×每次查询平均CPU⌉
其中 每次查询平均CPU 通过负载测试经验性地确定。
- 业务和产品配合： 加入有关即将进行的产品发布、用户增长目标、新模型部署或计划中的A/B测试的信息，这些预计会显著改变负载模式或数据量。这种定性信息对于预测需求阶跃性变化十分重要。
资源分配策略
根据您的估算，规划以下资源的分配：
- 在线存储： 确定服务API层和底层低延迟数据库（例如Redis、Cassandra、DynamoDB）的实例类型/大小。考虑内存存储的内存需求、基于磁盘存储的IOPS以及网络带宽。规划跨可用区的冗余。
- 离线存储： 估算数据湖或数据仓库（例如S3、GCS、HDFS）所需的存储容量。确定批处理特征计算和回填所需的计算集群（例如Spark、Flink）的大小，同时考虑CPU、内存和数据混洗要求。
- 网络： 保证组件之间有充足的网络带宽，特别是数据同步（物化）期间离线和在线存储之间，以及客户端与在线服务API之间。
虽然云平台提供自动扩缩功能，但好的容量规划包括设定合适的最小/最大实例数，定义合理的基于相关指标（CPU利用率、延迟、队列深度）的扩缩触发器，并了解扩缩时间，以防止在快速负载变化期间服务性能下降。
特征存储系统的负载测试
容量规划给出估算值；负载测试则验证这些估算值，并展现特征存储在压力下的真实行为。它包含模拟真实的用户流量和数据处理负载，以找出性能瓶颈、核实服务等级目标（SLOs），并确定系统的运行限制。
负载测试的目标
- 验证容量规划： 确认已配置的资源能够处理预期和峰值负载，同时达成性能目标（延迟、吞吐量 (throughput)）。
- 找出瓶颈： 找出负载下特定组件（服务API、在线数据库、离线计算集群、网络）的局限。
- 衡量性能SLOs： 量化 (quantization)在不同负载水平下的延迟（p50、p90、p99、p99.9）、吞吐量（QPS、每秒计算特征数）和错误率。
- 评估稳定性与弹性： 确认系统在测试期间引入的瞬时高负载或组件故障（混沌测试）下能保持稳定并优雅恢复。
- 确定可扩展性限制： 了解随着负载增加性能如何下降，并找出系统崩溃点（压力测试）。
设计负载测试场景
一份全面的负载测试计划需要定义真实的场景：
- 定义目标和SLOs： 明确说明您的目标。示例：“验证在线存储在特征向量 (vector)获取时，能支持10,000 QPS并保持p99延迟低于20毫秒。”
- 确定使用模式： 模拟不同种类的交互：
- 在线读取： 大量特征向量读取请求（常见的推理 (inference)工作负载）。
- 在线写入： 实时特征的摄取（如果适用）。
- 混合读写： 读写流量混合。
- 离线计算： 模拟大规模批处理特征工程作业。
- 训练数据生成： 模拟获取大量时间点正确的训练数据集。
- 并发操作： 测试同时进行在线服务和离线处理。
- 定义负载模式： 明确负载如何施加：
- 逐渐增加： 逐渐将负载增加到目标水平。
- 稳定状态： 在一段时间内维持目标负载。
- 逐渐减少： 逐渐减少负载。
- 尖峰测试： 引入突然的、短时间的高负载爆发。
- 压力测试： 持续增加负载，直到系统崩溃或性能下降到无法接受的程度。
- 选择性能指标（KPIs）： 监控相关指标：
- 延迟： 分布（p50、p90、p99、p99.9）。
- 吞吐量 (throughput)： QPS、每秒请求数、每秒处理特征数。
- 错误率： HTTP错误码（例如5xx）、应用层错误。
- 资源利用率： 所有组件的CPU、内存、网络I/O、磁盘I/O、数据库连接。
工具与执行
- 负载生成： 使用k6、Locust或Apache JMeter等工具针对在线服务API生成HTTP请求。对于离线作业或复杂的交互，可能需要自定义脚本。确保您的负载生成客户端本身不是瓶颈。
- 测试环境： 理想情况下，在专门的、类似生产的预发布环境中进行负载测试。直接在生产环境中测试有风险，但有时为最终验证是必要的；如果这样做，务必极其谨慎。
- 监控： 测试期间进行全面的监控是必不可少的。使用Prometheus/Grafana、Datadog、CloudWatch或应用性能监控（APM）解决方案来收集系统指标和应用级性能数据。
结果分析与迭代
分析收集的指标以了解系统行为：
- 关联指标： 寻找负载增加、延迟上升、错误率和资源饱和度之间的关联。p99延迟的突然飙升通常预示着彻底的故障。
- 性能可视化： 使用仪表板和图表将延迟分布、随时间变化的吞吐量 (throughput)以及资源利用率与施加负载的关系可视化。
例如，延迟直方图展示了在某个负载水平下响应时间的分布。长尾表明部分请求性能不稳定。
- 找出瓶颈： 如果数据库节点CPU利用率达到100%时延 (latency)迟显著增加，数据库可能是瓶颈。如果网络传输速率趋于平稳而错误率上升，网络带宽可能是问题所在。
- 迭代： 负载测试很少一次成功。使用结果找出优化点（例如，调整数据库参数 (parameter)、扩充资源、优化特征转换代码、增加缓存）。实施更改并重新运行测试以验证改进。
规划与测试的整合
容量规划和负载测试是互补的活动。规划根据估算和预测确定初始资源分配。负载测试提供经验证据来验证或反驳这些估算，展现系统在真实条件下的实际性能特性和瓶颈。从负载测试中获得的信息会反馈到完善容量规划中，促成更准确的资源分配和更好的长期成本管理。
此外，这些活动不应局限于初始部署。应定期审查容量规划并进行负载测试，特别是预期的高流量事件、重大应用更改或特征存储基础设施本身的重要更新之前。将这些做法整合到您的常规MLOps周期中，可确保您的特征存储随着ML系统的发展保持高性能和可扩展性。
