4. 行情数据质量监控：Tick级数据完整性校验
行情数据，说白了就是高频交易系统的「眼睛」。眼睛要是花了，后面再牛逼的策略也是白搭。我做了这么多年运维，见过太多团队在策略优化上砸了几百万，结果行情数据本身就有问题——嗯，这种坑我踩过不止一次。
今天我们就聊聊Tick级数据的质量监控。别小看这个环节，它往往是系统稳定性的第一道防线。
4.1 序列号连续性检查
先问个问题：你怎么知道行情数据有没有丢？
最简单的方法就是看序列号。交易所发出来的每一条Tick，都会带一个递增的序列号。如果中间跳号了，那肯定是有数据丢了。
核心逻辑：序列号必须严格递增，且步长为1。
我在项目中遇到过这么一件事：某次我们监控到某个合约的序列号从10001直接跳到了10005，中间少了3条。排查下来发现是网卡驱动的一个bug，在特定流量下会丢包。要不是序列号检查，这种问题根本发现不了。
代码实现其实不复杂：
// 伪代码示例：序列号连续性检查
bool checkSequence(uint64_t prevSeq, uint64_t currSeq) {
if (currSeq != prevSeq + 1) {
// 跳号了！触发告警
uint64_t lostCount = currSeq - prevSeq - 1;
alert("序列号不连续，丢失 " + to_string(lostCount) + " 条数据");
return false;
}
return true;
}避坑指南：我曾经遇到过交易所重启后序列号重置的情况。所以检查时要注意：如果跳号超过某个阈值（比如1000），先确认是不是交易所端的问题，别急着报自己的故障。
4.2 时间戳合理性校验
时间戳这东西，看着简单，坑特别多。我见过最离谱的一次，某条Tick的时间戳比当前时间晚了整整两小时——后来发现是系统时钟同步出了问题。
时间戳校验一般分三步：
- 单调性检查：后一条Tick的时间戳不能比前一条还早
- 范围检查：时间戳不能是未来的，也不能是太早以前的
- 精度检查：纳秒级时间戳的精度是否合理
举个例子，如果某条Tick的时间戳是2025-01-01 00:00:00.000000001，但当前服务器时间是2025-06-15 14:30:00，那这条数据明显有问题。
// 时间戳合理性校验
bool checkTimestamp(uint64_t timestamp, uint64_t currentTime) {
// 1. 不能是未来的时间（允许5秒误差）
if (timestamp > currentTime + 5 * 1000000000) {
alert("时间戳异常：未来时间戳");
return false;
}
// 2. 不能是太早以前的数据（比如超过1小时）
if (currentTime - timestamp > 3600 * 1000000000) {
alert("时间戳异常：过期数据");
return false;
}
return true;
}注意：不同交易所的时间戳精度不一样。有的用微秒，有的用纳秒。我曾经因为没处理好精度转换，导致所有数据都被标记为「异常」——那场面，相当尴尬。
4.3 异常行情实时告警
闪电崩盘、数据断层，这些词听着就吓人。但说实话，真正做监控的时候，你得先定义清楚：什么叫「异常」？
我个人习惯用以下几个维度来判断：
| 异常类型 | 判断标准 | 告警级别 |
|---|---|---|
| 闪电崩盘 | 价格在1秒内波动超过5% | P0（最高） |
| 数据断层 | 连续3秒以上无数据 | P1 |
| 价格异常跳变 | 相邻Tick价格差超过阈值 | P1 |
| 买卖价差异常 | 价差超过正常值的10倍 | P2 |
这里有个关键点：阈值怎么设？
我的做法是：先跑一周的历史数据，统计出正常波动范围，然后在这个基础上乘以一个系数。比如正常价差是0.01，那阈值可以设成0.1。太严了容易误报，太松了又漏报——这个平衡点，得靠经验慢慢调。
实战经验：我曾经遇到过一次「假闪电崩盘」。某只股票价格瞬间跌了8%，但仔细一看，是交易所发了一条错误数据，3秒后就撤回了。从那以后，我加了一个「确认机制」：异常告警触发后，等500毫秒再确认一次，避免被「幽灵数据」忽悠。
4.4 整体监控架构
说了这么多，我们来看看整体架构长什么样。下面这张图是我自己设计的监控流程：
这个流程看着简单，但每个环节都有不少细节。比如序列号检查，你不仅要检查当前数据，还要维护一个「期望的序列号」状态。时间戳校验则要考虑不同时区、不同精度的问题。
我的建议：刚开始做监控的时候，别想着一步到位。先把序列号和时间戳这两个基础检查做好，跑一周看看效果，再慢慢加异常检测的逻辑。我见过太多团队一上来就想搞「智能告警」，结果基础的数据完整性都没保证。
最后说一句：行情数据质量监控，说白了就是「防呆」。你永远不知道交易所那边会出什么幺蛾子，也不知道网络会怎么丢包。我们能做的，就是把这些「意外」变成「可预期的异常」，然后及时处理。
嗯，今天就聊到这儿。下一节我们聊聊延迟监控——那又是另一个有意思的话题了。
公众号:蓝海数据掘金营，微信deep3321