4、流式计算基础：流式数据处理模型
在低延迟VaR归因场景中，市场数据以每秒数万笔的速度持续涌入，传统的批处理模式无法满足亚秒级风险重估需求。流式计算将数据视为无界序列，通过时间窗口与状态管理实现“数据即到即算”。本章从流式模型的核心概念出发，对比批处理与流式处理的本质差异，并给出VaR归因中的典型应用模式。
4.1 无界数据与有界数据
批处理与流式处理的首要区别在于数据的有界性：
| 维度 | 有界数据（批处理） | 无界数据（流式处理） |
|---|---|---|
| 数据范围 | 已知起点与终点，数据集固定 | 持续产生，无自然终点 |
| 处理时机 | 数据全部到达后统一计算 | 数据到达即处理，持续输出 |
| 存储假设 | 可多次读取全量数据 | 通常只访问当前或最近窗口数据 |
| VaR场景 | 日终批量计算全量持仓VaR | 实时计算增量VaR与边际风险贡献 |
关键认知： 流式处理不要求“完整数据集”，而是通过时间窗口将无界数据切分为有界片段，在每个片段上执行增量计算。
4.2 时间窗口模型
流式计算通过三种基本窗口将无界数据转化为可计算的有限集合：
- 滚动窗口（Tumbling Window）：固定长度、不重叠。例如每5秒计算一次过去5秒的VaR变动。
- 滑动窗口（Sliding Window）：固定长度、可重叠。例如每1秒计算一次过去10秒的波动率，适合高频VaR监控。
- 会话窗口（Session Window）：基于不活动间隔划分。适合交易事件流，如连续报价中断超过2秒则视为新会话。
4.3 流式处理与批处理的架构差异
从系统架构角度看，流式处理在数据模型、计算模型、容错机制三个层面与批处理存在根本区别：
| 架构维度 | 批处理（如Spark Batch） | 流式处理（如Flink/Storm） |
|---|---|---|
| 数据模型 | 静态DataFrame/DataSet | 无界DataStream + 时间戳 |
| 计算模型 | 阶段式（Stage）全量计算 | 算子链（Operator Chain）增量计算 |
| 状态管理 | 无状态或外部存储 | 内置Keyed State + 状态后端 |
| 容错机制 | 重新执行失败任务 | 分布式快照（Checkpoint）+ 精确一次语义 |
| 延迟 | 分钟~小时级 | 毫秒~秒级 |
VaR归因选型建议： 对于日频VaR计算，批处理足够；对于盘中实时VaR监控与归因，必须采用流式处理，并配合滑动窗口实现连续风险度量。
4.4 流式VaR归因的典型数据流
以下SVG展示了流式VaR归因系统的核心数据流，从行情接入到风险指标输出的完整链路：
4.5 流式处理的核心挑战与应对
注意： 流式处理并非银弹。在低延迟VaR场景中，以下三个问题必须提前设计应对策略：
- 乱序事件（Out-of-Order）：网络延迟导致后发生的事件先到达。解决方案：使用事件时间（Event Time）而非处理时间，配合Watermark机制触发窗口计算。
- 状态膨胀：长时间运行的流作业可能积累大量状态。解决方案：设置状态TTL（Time-To-Live），定期清理过期协方差数据。
- 背压（Backpressure）：数据流入速度超过处理能力。解决方案：采用有界缓冲区 + 反压检测，或使用Kafka等消息队列削峰填谷。
4.6 批流一体趋势
现代大数据平台（如Apache Flink、Spark Structured Streaming）正在模糊批流边界。在VaR归因系统中，推荐采用Lambda架构的变体：
- 流式层：处理实时VaR监控与归因，延迟 < 1秒。
- 批式层：每日凌晨重新计算全量VaR，修正流式层的累积误差。
- 服务层：合并流式与批式结果，对外提供一致的风险视图。
实践要点： 流式层使用滑动窗口计算增量VaR，批式层使用全量历史数据计算标准VaR。两者通过时间戳对齐与归因因子映射实现无缝融合，确保风险报告在实时性与准确性之间取得平衡。