监控大屏上的实时成交额每一秒都在跳，风控系统在用户下单的瞬间就拦下异常订单——这类数据一到就处理、结果秒级产出的场景，靠的就是流计算。它和批处理的分水岭在于：批处理攒够一批再算，延迟以分钟到小时计；流计算来一条算一条，延迟以毫秒到秒计。

几个核心概念

  • 事件时间：数据真正发生的时间，和进入系统的时间可能差很远，统计一般按事件时间算
  • 窗口：把无边界的流切成段，滚动窗口每 5 分钟一段互不重叠，滑动窗口会重叠，会话窗口按活跃间隔切
  • 水位线：应对乱序数据的机制，等一等迟到的事件再结算窗口
  • exactly-once：任务重启后结果不重复也不丢失的语义保证

主流框架怎么选

目前用得最多的是 Flink，流批一体，状态管理和窗口支持最全；Spark Streaming 以微批方式实现，延迟秒级，团队本来就用 Spark 的话上手快；Kafka Streams 轻量，嵌在应用进程里跑，适合不想单独维护集群的场景。选型别只看功能清单，社区资料、团队熟悉度、云厂商有没有托管服务，往往比跑分更能决定项目走得顺不顺。

什么场景值得上

实时风控、监控告警、大屏指标、实时数仓的明细层，这些对延迟敏感的活儿是流式计算的主场。反过来，日报、月度报表这类 T+1 需求，批处理更省资源也更稳，没必要为了技术新潮硬上流。

成本也要算清楚：流任务要长期占用集群资源，还得维护 checkpoint、状态后端和延迟监控，运维负担比一个定时跑的 SQL 脚本重得多，人手紧张的团队尤其要想好。

一句话判断：业务要求秒级以内见结果、数据持续不断产生，才值得上流计算；能容忍小时级延迟的统计，批处理依然是最经济的选择。