4. 实时计算概念
在金融数据工程中，实时计算并不是“把批处理跑得更快”这么简单。它涉及数据到达方式、计算触发机制、时间语义以及系统架构选择等一系列根本问题。理解这些概念，是设计行情推送、风控预警、实时估值和交易监控系统的前提。
一、核心原理：批处理与流处理的本质差异
批处理将数据按固定周期切分为有界数据集，例如每日收盘后计算全市场估值。它的优势是吞吐高、状态管理简单、结果可重放；代价是延迟以分钟、小时甚至天计。流处理则把数据视为持续到达的无界事件序列，每来一条或一小批就触发计算，延迟可压到毫秒到秒级。
两者最关键的差异不在速度，而在“边界”。批处理有明确的开始与结束，流处理没有终点。因此流处理必须回答：窗口何时关闭？迟到数据如何处理？状态如何持久化？
一句话区分：批处理是“先存后算”，流处理是“边来边算”。金融场景中，日终清算适合批处理，实时行情风控必须用流处理。
二、Lambda 架构与 Kappa 架构：两条工程路线
Lambda 架构用两条链路解决“快”与“准”的矛盾：批处理层负责全量、准确的历史结果，速度层负责低延迟的近似结果，服务层合并两者对外提供查询。它的优点是容错强、结果可修正；缺点是同一套逻辑要维护两份代码，批流结果口径容易不一致。
Kappa 架构则主张“只用流处理”：所有数据都进入流处理引擎，历史重算通过重放消息队列中的日志完成。它简化了链路，避免双份逻辑，但对消息队列的保留能力、流处理引擎的状态管理和重放性能要求极高。
| 对比维度 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 计算链路 | 批处理 + 流处理双链路 | 仅流处理单链路 |
| 代码维护 | 两套逻辑，成本高 | 一套逻辑，成本低 |
| 结果准确性 | 批处理层保证最终准确 | 依赖重放与状态一致性 |
| 历史重算 | 重跑批任务 | 重放消息日志 |
| 典型适用 | 报表 + 实时监控并存 | 事件驱动、实时优先 |
三、事件时间与处理时间：时间语义决定结果正确性
处理时间是指计算节点实际处理该条数据的系统时间；事件时间是指数据在业务现场真正发生的时间，通常由事件自带时间戳表示。金融场景中，一笔成交在交易所产生的时间是事件时间，而它到达风控引擎的时间是处理时间，两者可能相差几十毫秒到数秒。
如果按处理时间开窗，网络抖动或消费积压会导致同一批业务事件被分到不同窗口，结果随负载变化而不稳定。按事件时间开窗，配合水位线机制，可以容忍一定程度的乱序和迟到，使结果可复现。水位线本质是一个“我认为事件时间已经推进到 T”的进度信号，超过允许迟到阈值的数据会被丢弃或进入侧输出流。
// Flink 中基于事件时间开窗的典型写法
stream
.assignTimestampsAndWatermarks(
WatermarkStrategy.<Trade>forBoundedOutOfOrderness(Duration.ofSeconds(5))
.withTimestampAssigner((event, ts) -> event.getTradeTime())
)
.keyBy(Trade::getSymbol)
.window(TumblingEventTimeWindows.of(Time.seconds(10)))
.aggregate(new VwapAggregate());水位线延迟设置过小，迟到数据被大量丢弃；设置过大，窗口结果输出延迟增加。金融行情场景通常取 2～10 秒，需结合链路抖动实测调整。
四、案例与场景：实时行情监控中的架构选择
假设要构建一个“实时行情异常波动监控 + 日终合规报表”系统。实时部分需要在 1 秒内识别某只股票 10 秒内涨跌幅超过阈值并告警；日终部分需要输出全市场逐笔成交的准确统计。若采用 Lambda，实时链路用 Flink 做事件时间窗口聚合，日终链路用 Spark 重算全量，服务层合并结果。若采用 Kappa，则所有逐笔数据先写入 Kafka 并长期保留，实时告警与日终报表都通过重放同一份日志计算。
选择时重点看三点：历史数据是否可重放、团队是否具备流处理运维能力、业务能否接受“只靠流处理保证最终准确”。
五、常见误区与复盘要点
- 误区一：把处理时间当事件时间用。在行情剧烈波动时，处理时间窗口会把不同时刻的成交混在一起，导致指标失真。应优先使用事件时间并配置水位线。
- 误区二：认为流处理一定比批处理快。流处理延迟低，但吞吐和状态恢复成本可能更高。高吞吐历史回算仍应交给批处理或重放式流处理。
- 误区三：Lambda 架构中批流逻辑“看起来一样”。实际中窗口边界、去重规则、迟到处理策略常不一致，必须建立统一口径测试。
- 误区四：Kappa 架构不需要考虑存储。消息日志保留时长直接决定可重算的历史范围，保留不足会导致无法回溯。
复盘时重点检查三件事：窗口时间语义是否与业务时间一致；迟到数据策略是否明确；批流或重放结果是否经过一致性比对。任何一项缺失，实时计算结果都可能在极端行情下不可信。
掌握批处理、流处理、Lambda、Kappa 以及事件时间与处理时间的区别，核心目的是在金融数据工程中做出可解释、可验证、可运维的架构选择。延迟、准确性、成本与复杂度之间没有唯一答案，只有与业务场景匹配的取舍。