4、数据采集与清洗：交易所接口对接、行情数据解析、交易日志处理、数据质量校验
做市业务里，数据就是命根子。这话一点都不夸张。
我见过太多团队，策略模型跑得飞起，结果一上线就亏钱。查到最后，往往是数据源出了问题。要么行情延迟了，要么订单状态没对上，要么日志里藏着个隐蔽的bug。所以这一章，咱们就聊聊数据采集与清洗——说白了，就是怎么把交易所的原始数据，变成咱们系统能用的干净数据。
4.1 交易所接口对接：不止是调个API那么简单
很多人觉得对接交易所接口就是调几个API，拿数据。嗯，如果真这么简单，我就不用专门写一节了。
我个人习惯，把接口对接分成三层：协议层、业务层、容错层。
- 协议层：FIX协议还是REST/WebSocket？FIX虽然老，但稳定，适合高频场景。REST简单，但延迟高。WebSocket实时性好，但连接管理麻烦。我建议做市业务优先考虑WebSocket + FIX双通道，一个拿行情，一个做交易。
- 业务层：每个交易所的订单类型、字段定义、状态机都不一样。比如“已成交”在A所叫Filled，在B所叫Executed。你得建一个统一的数据模型，把各家差异抹平。
- 容错层：接口会断，网络会抖，交易所会升级。我曾经遇到过一次，交易所突然改了字段长度，导致我们整个订单解析模块崩溃。从那以后，我要求所有接口对接必须加字段校验和版本兼容逻辑。
核心原则：对接交易所时，永远假设对方会出错。你的代码要能优雅地处理各种异常，而不是直接崩溃。
4.2 行情数据解析：从二进制到可用的价格
行情数据，说白了就是交易所告诉你“现在谁在买、谁在卖、价格多少”。但原始数据往往是一串二进制流，或者JSON字符串。
举个例子，某所的深度行情数据长这样：
{
"bids": [
[100.50, 2000],
[100.49, 1500]
],
"asks": [
[100.51, 1800],
[100.52, 2200]
]
}看着简单吧？但实际处理时，有几个坑：
- 时间戳对齐：交易所给的时间戳可能是毫秒、微秒甚至纳秒。你得统一成系统内部的时间基准。我习惯用纳秒级时间戳，因为做市业务对时间敏感，差一微秒可能就错过一笔交易。
- 价格精度：有的交易所价格是整数，有的是浮点数，有的是字符串。浮点数计算会有精度问题。我建议统一转成整数（最小价格单位），比如用“分”而不是“元”。
- 增量更新 vs 全量快照：大部分交易所会先发一个全量快照，然后不断发增量更新。你得维护一个本地的订单簿，把增量合并进去。这里最容易出错的是序号乱序——增量包可能后发先至。解决办法是加一个序列号校验，丢弃或重排乱序的包。
避坑指南：我曾经因为没处理增量更新的序号，导致本地订单簿和交易所差了整整一层深度。那笔亏损，够我买好几台服务器了。所以，序列号校验一定要做。
4.3 交易日志处理：把每一笔操作都记下来
交易日志，就是你的系统做了什么、什么时候做的、结果如何。它不仅是事后分析的依据，更是清算结算的核心凭证。
我见过有些团队，日志写得乱七八糟，出了事根本查不到原因。我个人习惯，交易日志必须包含以下字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 时间戳 | 精确到纳秒 | 2025-03-20 14:30:00.123456789 |
| 订单ID | 全局唯一 | ORD-20250320-001234 |
| 操作类型 | 下单、撤单、成交、拒绝 | NEW / CANCEL / FILL / REJECT |
| 价格 | 整数形式（最小单位） | 10050（代表100.50） |
| 数量 | 整数形式 | 2000 |
| 状态 | 当前订单状态 | PENDING / PARTIAL / COMPLETE |
| 错误码 | 如果有异常，记录错误码 | E1001（余额不足） |
日志的存储，我建议用列式存储（比如Parquet）或者时序数据库（比如InfluxDB）。因为交易日志是典型的写多读少、按时间查询的场景。别用MySQL硬扛，扛不住的。
注意：日志不能只写成功操作。失败的、被拒绝的、超时的，统统要记。这些才是排查问题的关键线索。
4.4 数据质量校验：别让脏数据毁了你的策略
数据采集完了，解析完了，日志也记了。但你能直接用吗？不能。你得先做数据质量校验。
为什么？因为交易所的数据也可能出错。比如：
- 行情数据突然跳变（价格从100跳到1000，然后又跳回来）
- 订单状态更新丢失（成交了但没收到成交回报）
- 时间戳错乱（未来的时间戳出现在当前数据里）
我总结了一套四步校验法，你可以参考：
- 完整性校验：检查字段是否缺失。比如订单日志里没有价格，那这条数据就是废的。
- 一致性校验：检查数据之间是否矛盾。比如成交价格和行情价格差太多，那肯定有问题。
- 时效性校验：检查数据是否过期。比如行情数据延迟超过1秒，就不能用于做市决策。
- 逻辑校验：检查数据是否符合业务逻辑。比如买单价格高于卖单价格，这在正常情况下不可能发生。
举个例子：行情数据里突然出现一个卖单价格是0.01，而当前市场价是100。这明显是异常数据。我的做法是：直接丢弃这条数据，并触发告警。宁可少做一笔交易，也不能让脏数据影响策略。
4.5 整体流程：一张图说清楚
说了这么多，咱们用一张图把整个数据采集与清洗的流程串起来。你一看就明白了。
你看，整个流程其实不复杂。从交易所接口拿到原始数据，分两路走：一路解析行情，一路处理交易日志。然后汇合到数据质量校验模块，经过四步校验，最终输出干净数据。干净数据才能喂给策略模型和清算结算系统。
我的经验：数据质量校验这一步，千万别省。我见过太多团队，为了省几毫秒的延迟，跳过校验直接使用数据。结果策略跑偏了，亏的钱够买几十倍的服务器。所以，该花的功夫一定要花。
好了，数据采集与清洗就聊到这儿。记住一句话：垃圾进，垃圾出。数据质量不过关，后面的一切都是白搭。