第2章数据源获取

第二章：数据源获取——从交易所API获取Level2快照数据、增量数据、WebSocket实时流

做订单簿回溯，第一步就是搞数据。这步要是没做好，后面所有分析都是空中楼阁。我个人习惯把数据获取分成三个层次：快照、增量、实时流。今天咱们就一个一个来拆解。

快照数据，说白了就是某一时刻订单簿的完整状态。比如现在这个毫秒，买一到买十各有多少挂单，卖一到卖十各有多少挂单。我刚开始做的时候，以为直接拿个快照就能开始分析了——结果发现，快照的获取频率和深度，直接决定了你的回溯精度。

大部分交易所的REST API都提供快照接口。以币安为例：

GET /api/v3/depth?symbol=BTCUSDT&limit=1000

这个接口返回的就是当前时刻的订单簿快照。limit参数控制深度，我个人建议至少取500档，不然做高频分析时数据太稀疏。

  关键点：快照数据是“点状”的，它只告诉你某个瞬间的状态。如果你只靠快照做回溯，那中间所有变化都丢了。

嗯，这里要注意：不同交易所的快照频率不一样。有的每秒更新一次，有的每100毫秒一次。你想想看，如果做高频策略，100毫秒的间隔里可能已经成交了几十笔。所以，光靠快照是不够的。

增量数据，就是订单簿的变化记录。比如“有人在10:00:00.123秒撤单了”、“有人在10:00:00.456秒挂了一笔新单”。把这些增量按时间顺序回放，你就能重建出完整的订单簿演变过程。

我在项目中遇到过一个问题：某交易所的增量数据只保留最近1000条，如果你没及时拉取，中间就断了。所以，增量数据的获取策略很重要。

一般流程是这样的：

为什么需要校验？因为增量数据在传输过程中可能丢包。我曾经因为没做校验，导致回放出来的订单簿和真实情况差了十几个档位，策略回测结果完全失真。

我的经验：建议每拉取1000条增量后，主动拉一次快照做对比。如果发现偏差超过阈值（比如5档），就重新初始化。

增量数据的格式，各家交易所大同小异。一般包含：

REST API是“你问它答”，WebSocket是“它主动推给你”。做实时交易或者高频回溯，WebSocket是必须的。

为什么？因为REST API有延迟。你发一个请求，交易所处理，再返回，这个来回至少几十毫秒。而WebSocket是长连接，数据一有变化就推过来，延迟可以控制在几毫秒内。

我习惯的做法是：

WebSocket的订阅格式，以币安为例：

{
  "method": "SUBSCRIBE",
  "params": [
    "btcusdt@depth20@100ms"
  ],
  "id": 1
}

这个订阅会每100毫秒推送一次前20档的订单簿变化。如果你需要全量数据，可以订阅 btcusdt@depth，但数据量会非常大。

注意：WebSocket连接可能会断开。一定要实现自动重连机制，并且重连后要重新拉取快照做同步。我曾经因为重连后没做同步，导致数据错位了整整10分钟。

数据源类型	特点	适用场景	延迟
快照数据	完整状态，但频率低	低频分析、初始化基准	几十毫秒
增量数据	变化记录，可还原过程	高频回溯、策略回测	几毫秒
WebSocket实时流	实时推送，延迟最低	实时交易、监控	亚毫秒级

说白了，没有哪个数据源是万能的。我个人的建议是：

下面这张图是我自己总结的数据获取流程，你可以参考：

这个流程看起来简单，但实际做起来坑不少。我记得有一次，某个交易所的WebSocket突然改了数据格式，我这边没及时适配，结果整整一天的数据都废了。所以，一定要做好数据格式的校验和异常处理。

避坑指南：我曾经因为没处理WebSocket的ping/pong心跳，导致连接被服务器断开。建议每30秒发送一次ping，确保连接存活。

好了，数据获取这块就讲到这里。记住：数据质量决定了你的回溯结果是否可信。花时间把数据源搞扎实，后面分析起来才顺手。