流计算是一种持续处理数据的方式。数据源源不断进入系统，系统每收到一条或一小批记录就计算一次，结果随之更新。批处理则是另一种节奏：先把一天或一周的数据攒起来，统一跑一次任务，结果往往要等几个小时才看得到。
阿里云流计算是阿里云提供的实时数据计算服务，底层基于开源引擎 Apache Flink。用户可以在云上开发、部署和运维实时任务，不需要自己搭建和维护集群。
流计算适合解决什么问题
有些业务的数据价值衰减得很快。风控如果在交易完成一小时后才发现异常，损失已经发生了。运营如果第二天早上才看到昨晚活动的数据，调整策略的机会也就过去了。流计算把结果延迟从小时级压到秒级或分钟级，让决策跟得上业务节奏。
常见场景大致有这几类：
- 实时大屏：展示当前成交额、在线人数和订单量，给值班和运营一个即时参照。
- 实时风控：在支付或登录环节识别盗刷、刷单和异常登录，拦截得越早越好。
- 实时推荐与营销：根据用户刚刚的点击行为调整推荐内容，而不是等第二天画像更新。
- 设备监控：对物联网设备的温度、振动等指标设阈值，超限后尽快告警。
阿里云流计算的主要能力
从使用者的角度看，有四类能力比较常用：
- SQL 开发：多数统计逻辑可以直接用 SQL 写，比如按分钟统计 GMV、按用户去重计数。数据分析人员不必先学分布式编程。
- 状态管理与容错：聚合、去重、关联都要记住历史数据，这部分数据叫”状态”。平台会定期保存状态快照，任务故障后从最近的快照恢复，丢数据和重复计算的范围因此小得多。
- 弹性伸缩：大促流量可能是平时的数倍，任务可以按负载调整并行度，活动结束后再缩回去，不必一直占着资源。
- 生态对接：能直接读写消息队列、日志服务、数据仓库和在线数据库，也能接入自建的 Kafka 等组件。
实战案例：电商大促实时成交看板
下面用一个虚构但很典型的电商场景说明整个流程。某商家在大促期间需要每分钟更新一次成交额、各品类销量和支付转化率，供运营团队随时调整投放。
数据怎么流
每笔订单支付成功后，交易系统把订单事件写入消息队列。流计算任务订阅这个队列，经过清洗、关联和聚合，把结果写进实时数据库。大屏前端每隔几秒查询一次数据库，看到的就是最新数字。
任务里做了什么
任务主要完成三件事：
- 过滤与去重：先剔除测试订单。上游重试会产生重复消息，必须按订单号去重，否则同一笔成交会被算两次。
- 关联维度：订单事件只带商品编号，品类和店铺信息要从商品表补上。商品表改动频繁，所以任务通过维表关联读取最新数据。
- 窗口聚合：用一分钟的滚动窗口统计成交额和订单数，窗口关闭时输出一条结果，写入数据库。
上线前的回放对比
大促前，团队用历史高峰日的数据把任务回放了一遍，拿流计算结果和离线报表逐项对账。第一轮回放时成交额偏高约 0.3%，排查后发现上游重试消息没有完全去重，修好之后差异降到可接受范围。
这一步不能省。实时数字如果和离线账对不上，运营很快就不再看它了。
大促当天的注意事项
流量峰值是平时的数倍，团队提前调高了任务并行度，并设置了延迟告警：结果输出落后于当前时间超过两分钟，值班人员就会收到通知。这些设置的目的很简单，就是让问题在影响业务之前被发现。
选型与使用建议
- 先问清楚延迟要求。如果业务每小时更新一次就够用，批处理更便宜也更简单。只有确实需要秒级或分钟级结果时，再引入流计算。
- 统计逻辑优先用 SQL。只有 SQL 写不出来的复杂逻辑，才需要考虑自定义代码，维护成本会低很多。
- 提前设计去重和幂等。消息队列通常保证至少投递一次，不保证只投递一次。下游写入要能承受重复数据，例如用订单号作为主键做覆盖写。
- 给状态设置保留时间。去重和关联会让状态越攒越大，不设过期时间，迟早会拖慢任务。
- 上线前做回放对比。用历史数据核对实时结果和离线结果，差异说清楚之后再正式切换。
几个常见误区
第一个误区是觉得流计算一定比批处理好。实时方案的开发和运维成本都更高，业务用不上的时候，离线方案通常更稳。
第二个误区是忽略数据乱序。网络抖动和上游积压会让事件晚到，如果窗口只按处理时间切分，统计结果就会有偏差。更稳妥的做法是按事件时间划分窗口，并设定允许的迟到时长。
第三个误区是只盯着计算，不管输出。实时结果最终要被人或系统读取，目标库的写入吞吐和查询速度同样影响使用体验。
