阿里云预测没有单独的产品入口,它分布在多个产品里,是一组时间序列预测能力。它读取过去一段时间的指标,比如每分钟的请求量、每天的订单数、每小时的CPU使用率,然后给出未来一段时间的预测值。结果通常还带有置信区间,告诉你实际数值可能会在哪个范围内波动。

使用方式大致有两条路。一条是直接用产品自带的功能,例如云服务器弹性伸缩里的预测式伸缩策略。配好之后,计算和扩缩容由系统自动完成。另一条是借助机器学习平台PAI,自己训练和部署模型。这条路适合业务规则特殊、需要自定义特征的场景,但前期投入也更大。
三类常见用法
一、弹性伸缩
这是最直接的用法。系统根据历史负载规律,预测下一时段的访问量,提前把实例加上去。阈值伸缩要等CPU涨上来才动,而预测式伸缩能提前一步。实例启动本身需要几分钟,如果等指标已经飙高再扩容,用户早就感觉到卡顿了。
二、销量与库存规划
零售和电商企业经常用预测结果指导备货。模型可以把节假日、促销活动和季节因素考虑进去,输出分商品、分仓库的需求量,采购部门据此决定补多少、什么时候补。
三、业务指标预警
预测结果还能用来做异常检测。实际指标一旦明显偏离预测区间,就发出告警。比如支付成功率在凌晨突然跌破预测下限,多半是某个支付渠道出了问题,值班同学能更早介入,不用等客服接到投诉才发现。
案例一:电商大促前的服务器扩容
这是一个示例场景,具体数字要以你自己的项目为准。某服装电商每年有几次大促。以前运维人员凭去年的经验手动扩容,结果有两次下单接口超时,还有一次资源闲置了三天以上,成本偏高。
团队分三步处理。第一步,整理过去两年的访问日志,按分钟汇总请求量,并把大促、节假日和营销活动的时间标注出来。第二步,在弹性伸缩里开启预测式策略,预测窗口设为未来一小时,目标CPU利用率控制在60%左右,给突发流量留出缓冲。第三步,大促前一周每天对比预测值和实际值。团队发现首日晚间的预测偏低,于是调高了促销启动时间的权重,重新训练了模型。
大促当天,实例数在晚八点前已经扩充到位,下单接口的超时率降到接近零。活动结束后,系统按负载自动缩容,闲置时间明显变短。对这个团队来说,预测最有用的地方是提前量,单个数字准不准反而没那么关键。
案例二:连锁门店的补货
另一个示例来自一家约200家门店的便利连锁。门店常见的问题有两个:热销饮品断货,或者临期食品积压。采购员每天凭感觉下单,问题一直压不下去。
团队用PAI搭建了销量预测流程,输入数据包括门店每日销量、天气、周边活动和节假日标记。模型按门店和品类分别预测未来七天的销量,并给出上下限。采购系统以预测中位数作为基础订单量,只有实际库存低于下限时才触发紧急补货。
运行三个月后,热销品的缺货天数少了一半左右,临期损耗也有所下降。新开的门店历史数据不够,团队先用同类门店的平均曲线过渡,积累满四周数据后再切换到门店自己的模型。这一点很容易被忽略,新店直接套用成熟门店的模型,结果通常偏差很大。
选型与使用步骤
- 先定目标。写清楚要预测什么指标、预测多长时间、结果用来做什么决策。目标不清楚,后面连模型好不好都没法判断。
- 检查数据。时间序列要求时间戳连续、单位统一。缺失的数据要补齐或说明处理方式,异常峰值要先确认是真实业务还是采集出错。
- 选产品路径。常规伸缩需求优先用内置预测策略,维护成本低。只有业务规则复杂、内置功能覆盖不了时,再考虑在PAI里自建模型。
- 设置基线。拿“上周同一时段”或简单移动平均当参照,确认预测模型确实比它准,再投入使用。
- 定期回测。每周或每次活动结束后,对比预测和实际。偏差连续扩大时就重训,不要等到出事故再看。
常见误区
- 把预测当承诺。预测给出的是概率范围。资源和库存成本较高时,决策要留出余量,不能只按中位数硬卡。
- 数据越多越好。很久以前的数据可能已经不能反映当前的业务模式。业务变过的话,要截断老数据或者降低它的权重。
- 忽略外部因素。促销、天气、竞品动作都会影响结果。只盯着历史曲线,关键时刻很容易失准。
- 不做效果评估。没有对比数据,就分不清预测到底带来了收益,还是只是碰巧没出问题。
小结
阿里云预测比较适合有稳定历史数据、而且预测结果能直接影响决策的场景。从弹性伸缩到库存规划,关键步骤其实是一样的:定目标、理数据、设基线、持续回测。建议先在一个指标、一个环节上试点,跑顺了再逐步扩大范围。