📚 课程目录第4章数据回放核心概念

4. 数据回放核心概念

在金融实时数据链路中，数据回放并不是简单地把历史行情重新“播一遍”。它本质上是一次受控的、可重复的、可观测的数据重演：把已经落库或落盘的逐笔、快照、订单簿、成交等数据，按照原始时间语义重新注入到目标系统，使下游消费者获得与当时几乎一致的输入序列。理解回放，必须同时抓住五个维度：定义、粒度、速度、一致性，以及它与实时链路的边界关系。

核心判断：回放解决的是“历史数据如何以正确顺序、正确节奏、正确语义重新进入系统”的问题，而不是“把文件读出来发出去”这么简单。

一、回放定义：重演的是时间语义，不是文件内容

回放的定义可以概括为：以原始事件时间为基准，将历史数据按可配置的粒度与速度重新投递到目标链路，并保证消费端看到的事件顺序、字段语义和状态演化与原始过程一致。这里的关键词是“原始事件时间”。金融数据通常带有两类时间：事件时间（交易所撮合时间、行情生成时间）和接收时间（本地网关收到时间）。回放必须明确以哪类时间为排序和推进依据，否则会出现“数据对了，顺序错了”的严重问题。

例如，逐笔委托和逐笔成交在交易所侧有严格的先后关系。如果回放时仅按本地入库顺序发送，可能因为网络抖动导致成交先于委托到达消费端，从而让订单簿重建出现负挂单。因此，回放系统通常需要维护一个事件时间水位线，并允许配置乱序容忍窗口。

回放配置示例：
replay.source = tick_orderbook
replay.time_field = exchange_event_time
replay.order = event_time, seq_no
replay.watermark_delay_ms = 50
replay.speed = 10x
replay.granularity = tick

二、回放粒度：决定“重演到什么程度”

回放粒度是回放系统最容易被低估的设计点。粒度太粗，下游无法复现微观结构；粒度太细，又会带来巨大的存储与计算压力。常见粒度包括：

逐笔级（Tick）：每一笔委托、成交、撤单都独立回放，适合订单簿重建、策略回测、微结构研究。
快照级（Snapshot）：按固定频率（如每 100ms、500ms）回放盘口快照，适合行情展示、风控估值。
K 线级（Bar）：按 1 分钟、5 分钟等聚合后回放，适合中低频策略和报表系统。
批次级（Batch）：按文件或数据块整体投递，适合离线补数、数仓同步。

粒度选择不是越细越好，而是要与消费端的状态模型匹配。如果下游只维护最新盘口，快照级即可；如果下游要计算订单簿斜率、撤单率，则必须逐笔级。

粒度	典型数据	适用场景	主要代价
逐笔级	委托、成交、撤单	订单簿重建、回测	存储大、顺序要求高
快照级	盘口十档、最新价	行情展示、估值	丢失微观事件
K 线级	OHLCV	中低频策略、报表	无法还原盘中过程
批次级	文件块、分区	补数、数仓同步	无实时节奏

三、回放速度：从“原速”到“加速”再到“尽力而为”

回放速度决定了历史时间与真实时间的映射关系。常见模式有三种：

原速回放：1 秒历史数据用 1 秒真实时间播放，最接近实盘节奏，适合联调、演练和实时风控验证。
加速回放：如 10x、100x，用于快速回测和压力测试，但会改变系统对时延和背压的感知。
尽力而为（As-fast-as-possible）：不考虑时间间隔，尽可能快地投递，适合补数和数据修复，但消费端必须能处理突发流量。

加速回放时，消费端的处理能力、队列积压和超时逻辑会与实盘完全不同。用 100x 回放验证通过的策略，不代表在实盘 1x 下不会因为延迟而失效。

速度控制通常通过令牌桶或时间轮实现。下面是一个简化的速度控制伪代码：

for event in replay_stream:
    target_ts = start_wall + (event.event_time - start_event_time) / speed
    sleep_until(target_ts)
    send(event)

四、回放一致性：顺序、状态与幂等

回放一致性包含三个层面：顺序一致性、状态一致性和投递一致性。顺序一致性要求同一标的、同一通道内的事件按事件时间严格有序；状态一致性要求消费端重建出的订单簿、持仓、指标与原始过程一致；投递一致性则要求回放可重入、可断点续传，且重复投递不会破坏状态。

实践中，回放系统通常会给每条消息带上replay_id、seq_no和event_time，消费端据此做去重和排序。若下游是有状态服务，还必须支持快照 + 增量的回放模式：先加载某个时间点的状态快照，再从该点之后回放增量事件。

判断回放是否一致，最直接的方法是：用同一批数据回放两次，比较消费端最终状态和中间关键指标是否完全一致。若不一致，优先检查乱序窗口、去重逻辑和状态恢复点。

五、回放与实时链路的关系

回放与实时不是两套孤立系统，而是共享同一套数据模型和消费语义的两种输入模式。实时链路强调低延迟、背压和容错；回放链路强调可重复、可观测和可暂停。二者关系可以用“同构不同源”来概括：

同构：回放和实时应使用相同的消息格式、相同的序列化协议、相同的消费端处理逻辑。
不同源：实时来自行情网关，回放来自历史存储或消息队列的历史分区。
可切换：消费端应能在实时与回放之间切换，而不需要修改业务代码。

如果实时和回放使用两套不同的解析逻辑，就会出现“回放正常、实盘异常”或反之的经典问题。因此，成熟团队会把回放视为实时链路的镜像测试通道，而不是临时脚本。

六、常见误区与复盘要点

在实际项目中，回放链路最容易踩的坑集中在以下四点：

误区一：用接收时间代替事件时间。 结果是在网络抖动时段，订单簿重建出现负挂单或价格穿越。
误区二：忽略乱序窗口。 跨交易所、跨通道数据合并时，必须设置合理的水位线延迟，否则会丢事件或重复触发。
误区三：加速回放后直接上实盘。 加速回放掩盖了背压、超时和队列积压问题，必须补充原速演练。
误区四：回放与实时两套代码。 短期看似灵活，长期必然导致语义漂移，应统一消息模型和处理逻辑。

复盘建议：每次回放任务结束后，记录三个指标——事件总数、乱序丢弃数、状态校验差异数。这三个指标能快速定位回放链路是否真正可信。

总结来看，回放定义回答“重演什么”，回放粒度回答“重演到多细”，回放速度回答“以什么节奏重演”，回放一致性回答“重演得对不对”，而回放与实时关系回答“这套能力如何与生产链路共存”。五者共同构成金融实时数据回放的核心概念框架，也是后续补数链路设计的基础。