3、订单簿数据获取：REST API与WebSocket、数据频率选择、数据清洗与对齐
做量化交易，数据就是你的弹药。弹药不行，枪法再好也白搭。
订单簿数据，说白了就是交易所里所有挂单的实时快照。买一卖一、深度分布、盘口变化，全在这。我见过太多人策略写得花里胡哨，结果数据源没选对，一跑实盘就崩。今天咱们就把数据获取这件事聊透。
3.1 REST API vs WebSocket：什么时候用哪个？
这两个东西，本质上都是拿数据。但用法完全不同。
REST API，就像你去图书馆借书。你问一句「有没有这本书？」，管理员翻一翻告诉你结果。一问一答，简单直接。但如果你每隔1秒就问一次，管理员会烦，你也会累。
WebSocket，就像你订阅了一份报纸。每天早上报纸自动送到你家门口，你不用天天去报摊问「今天有报纸吗？」。交易所主动把数据推给你，实时性极好。
我个人习惯这样分配：
- REST API：用来做初始快照、历史数据补全、交易对信息查询。频率低，偶尔用一次。
- WebSocket：用来接收实时订单簿增量更新。高频交易必备，延迟低到毫秒级。
核心原则：别用REST API去轮询订单簿。你想想看，每秒请求一次，不仅浪费带宽，还会被交易所限流。我在项目中遇到过有人用REST API做高频策略，结果被交易所封了IP，整个策略瘫痪了三天。
3.2 数据频率选择：快不一定好
很多人一上来就选「最快」的频率。其实这是个误区。
订单簿数据，交易所通常提供两种模式：
| 模式 | 特点 | 适用场景 |
|---|---|---|
| 全量快照（Snapshot） | 每次返回完整订单簿，数据量大 | 低频策略、回测数据准备 |
| 增量更新（Delta/Incremental） | 只返回变化的部分，数据量小 | 高频策略、实时监控 |
我建议你这样选：
- 做T+0或高频做市：用增量更新，频率选100ms或更低。但要注意，有些交易所的WebSocket推送频率是固定的，比如币安是100ms一次。
- 做日内趋势或套利：用全量快照，1秒一次就够了。数据太多反而增加噪音。
- 做回测：用1秒或3秒的快照数据。太细的数据会让回测过拟合，你想想看，实盘哪有那么完美的执行？
我的经验：我曾经为了追求极致速度，把WebSocket频率调到10ms一次。结果数据量太大，本地数据库写入成了瓶颈，反而导致延迟增加。后来我改成100ms一次，配合本地缓存，效果反而更好。有时候，慢就是快。
3.3 数据清洗与对齐：脏数据是隐形杀手
数据拿到了，但能用吗？不一定。
交易所的数据，尤其是WebSocket推送的增量数据，经常会出现这些问题：
- 乱序：网络波动导致后发的数据先到，先发的数据后到。
- 重复：同一个更新被推送了两次。
- 缺失：某次增量更新丢了，导致本地订单簿和交易所不一致。
- 时间戳不一致：交易所服务器时间和本地时间有偏差。
怎么处理？我总结了一套「三板斧」：
第一板斧：序列号校验
每个增量更新都带一个序列号（sequence ID）。本地维护一个变量，记录上一次收到的序列号。新来的数据，序列号必须比上一个大1。如果跳号了，说明有数据丢了，立即请求一次全量快照重新同步。
// 伪代码示例
let lastSeq = 0;
function onDelta(data) {
if (data.seq !== lastSeq + 1) {
// 数据丢了，重新同步
requestSnapshot();
return;
}
// 正常处理
updateOrderBook(data);
lastSeq = data.seq;
}第二板斧：时间戳对齐
交易所的时间戳通常是Unix毫秒时间戳。本地收到数据后，记录本地接收时间。两者对比，如果偏差超过500ms，说明网络延迟严重，这条数据可能需要标记为「低可信度」。
我个人习惯在数据入库时，同时保存两个时间戳：交易所时间戳和本地接收时间戳。这样回测时可以灵活选择用哪个。
第三板斧：去重与排序
收到增量更新后，先检查这个更新是否已经处理过。可以用一个哈希表，key是「交易对+序列号」。如果已经存在，直接丢弃。
排序的话，按序列号从小到大处理。别按时间戳排序，因为时间戳可能不准。
注意：数据对齐这件事，做不好会直接导致策略逻辑错误。我曾经因为没处理好乱序问题，导致订单簿的买一卖一价格颠倒了，策略在实盘里疯狂吃对手盘，亏了十几万。从那以后，我再也不敢轻视数据清洗了。
3.4 知识体系总览
下面这张图，是我自己总结的订单簿数据获取全流程。你可以把它当作一个检查清单：
嗯，这张图基本概括了咱们这节课的核心。从数据源选择，到频率确定，再到清洗对齐，每一步都不能省。
最后说一句：数据获取这件事，看起来简单，但坑最多。我建议你先把这部分跑通、跑稳，再去做策略。地基不牢，楼盖得再高也得塌。
公众号:蓝海资料掘金营，微信deep3321