数据源与采集：主流交易所API对比、WebSocket实时流、RESTful历史数据、数据频率选择

做订单簿数据清洗，第一步不是写代码，而是搞清楚——数据从哪来？

我见过不少新手，一上来就撸代码，结果数据源选错了，后面全白干。说白了，数据源选不对，特征工程做得再漂亮也是空中楼阁。今天咱们就聊聊交易所API那点事。

主流交易所API对比

目前市面上主流的数字货币交易所，API风格大同小异，但细节上各有千秋。我个人习惯把交易所分成三个梯队：

交易所	REST限频	WebSocket深度	历史数据	我的评价
Binance	1200次/分钟	5级/20级/全量	支持	业界标杆，文档最清晰
OKX	600次/分钟	400档/全量	支持	深度数据丰富，但限频严格
Bybit	600次/分钟	50级/200级	有限支持	速度不错，历史数据偏少
Coinbase	300次/分钟	全量	支持	合规性强，但延迟略高

WebSocket实时流

做订单簿特征工程，实时数据是主食。WebSocket就是你的筷子。

为什么不用REST轮询？你想想看，订单簿每秒可能变化几百次，REST请求还没回来，数据已经过时了。WebSocket是长连接，数据主动推给你，延迟低到毫秒级。

我建议的WebSocket接入策略：

• 深度快照 + 增量更新：先拉一次全量深度，后面只接收变化数据。这样带宽省了，处理也快。
• 心跳保活：交易所WebSocket一般30秒发一次ping，你得回pong。我曾经忘了写心跳逻辑，半夜三点程序断连，第二天才发现，亏大了。
• 重连机制：网络波动是常态。写个自动重连，指数退避，别一断就连，容易触发限频。

RESTful历史数据

实时数据用来交易，历史数据用来回测。两者缺一不可。

RESTful接口拉历史数据，有几个坑要注意：

• 限频问题：大部分交易所对历史数据请求限制很严。Binance允许每分钟1200次，但如果你一次拉太多K线，会被封IP。
• 数据精度：不同交易所的历史数据精度不一样。有的精确到毫秒，有的只到秒。做特征工程时，时间戳对齐是个大麻烦。
• 数据完整性：交易所偶尔会漏数据。我建议拉完数据后，做一次完整性校验——检查时间戳是否连续，价格是否有跳空。

# 伪代码：拉取历史深度数据
def fetch_historical_depth(symbol, start_time, end_time):
    data = []
    while start_time < end_time:
        resp = requests.get(
            f"{BASE_URL}/depth",
            params={
                "symbol": symbol,
                "limit": 1000,
                "startTime": start_time
            }
        )
        # 检查返回数据是否完整
        if len(resp.json()['bids']) == 0:
            break
        data.extend(resp.json()['bids'])
        start_time = resp.json()['lastUpdateId']
        time.sleep(0.1)  # 限频控制
    return data

数据频率选择

这个问题其实没有标准答案。选什么频率，取决于你的策略类型。

我一般这样分：

• 毫秒级（高频做市）：需要全量深度，每秒更新几十次。数据量大，存储成本高，但信号灵敏。
• 秒级（日内交易）：5秒或10秒快照一次。大部分策略够用了，数据量适中。
• 分钟级（趋势跟踪）：1分钟或5分钟聚合一次。适合长线策略，数据量小，好处理。

嗯，这里要注意：频率越高，噪声越大。我刚开始做高频策略时，恨不得每秒取100次数据，结果发现大部分都是市场微结构噪声，反而把信号淹没了。后来我学乖了，先做降噪处理，再提取特征。

知识体系总览

下面这张图，是我自己梳理的数据源与采集的核心逻辑。你看一眼，心里就有谱了。

这张图把整个数据采集的流程串起来了。从选交易所、到实时流和历史数据、再到频率选择，每一步都有讲究。你照着这个框架走，基本不会跑偏。

---

公众号:蓝海资料掘金营，微信deep3321