3、数据获取:从交易所API获取Level-2行情数据、解析订单簿快照

好,咱们进入实战环节。数据获取是量化交易的地基,地基不稳,策略再牛也白搭。我个人习惯把这一步叫做“数据管道”,你得确保它干净、快速、稳定。

Level-2行情,说白了就是比普通行情更“深”的数据。普通行情只给你买一卖一,Level-2能给你看十档甚至更深的挂单。你想想看,做订单簿不平衡策略,没有深度数据,那不就是盲人摸象吗?

3.1 交易所API的选择与接入

国内主流交易所,比如上交所、深交所,都有官方行情接口。但说实话,直接对接交易所API门槛不低。我在项目中遇到过,光申请权限、搭建网络环境就能折腾一周。

更常见的做法是:

  • 量化平台数据服务:像聚宽、米筐、掘金等,它们封装好了Level-2数据接口,直接用SDK拉取就行。
  • 第三方数据商:比如万得、通联数据,提供HTTP或WebSocket接口。
  • 交易所直连:适合机构,延迟最低,但开发成本高。

我个人建议,初期先用量化平台的接口。原因很简单——省时间。你想想看,策略逻辑还没跑通,花大量时间搞数据接入,不值当。

小提示: 如果你用WebSocket订阅行情,记得做好心跳重连机制。我曾经因为网络抖动,断连了5分钟没发现,回测数据缺了一段,排查了半天。

3.2 解析订单簿快照

拿到原始数据后,得解析成我们能用的结构。Level-2快照数据,通常包含以下字段:

字段 含义 示例
asks 卖盘十档,按价格升序排列 [[10.01, 1000], [10.02, 2000], ...]
bids 买盘十档,按价格降序排列 [[9.99, 1500], [9.98, 3000], ...]
timestamp 快照时间戳,精确到毫秒 1696000000123
symbol 股票代码 600519.SH

嗯,这里要注意:不同交易所的字段命名可能不一样。比如上交所叫Asks,深交所叫SellOrders。你得先看API文档,别想当然。

下面是我常用的解析代码,用Python写的,清晰易懂:

import json

def parse_orderbook_snapshot(raw_data):
    """
    解析订单簿快照数据
    :param raw_data: 从API获取的原始JSON字符串
    :return: 字典,包含asks、bids、timestamp、symbol
    """
    data = json.loads(raw_data)
    
    # 提取买卖盘数据
    asks = [[float(price), int(volume)] for price, volume in data['asks']]
    bids = [[float(price), int(volume)] for price, volume in data['bids']]
    
    # 按价格排序,确保一致性
    asks.sort(key=lambda x: x[0])   # 卖盘升序
    bids.sort(key=lambda x: x[0], reverse=True)  # 买盘降序
    
    snapshot = {
        'symbol': data['symbol'],
        'timestamp': data['timestamp'],
        'asks': asks,
        'bids': bids
    }
    
    return snapshot

# 使用示例
raw = '{"symbol":"600519.SH","timestamp":1696000000123,"asks":[[10.01,1000],[10.02,2000]],"bids":[[9.99,1500],[9.98,3000]]}'
snapshot = parse_orderbook_snapshot(raw)
print(snapshot)
核心要点: 解析后的数据,一定要按价格排序。卖盘升序、买盘降序,这是行业惯例。你如果不排序,后面算不平衡指标时,结果全是错的。

3.3 数据校验与清洗

数据拿到手,别急着用。先做校验。我在项目中遇到过好几次,交易所偶尔会推送空数据或者重复数据。

我一般做这几步:

  • 空值检查:asks或bids为空?直接丢弃。
  • 价格合理性:价格不能为0或负数,量也不能为0。
  • 时间戳单调性:后一个快照的时间戳,必须大于前一个。否则说明数据乱序了。
  • 去重:同一时间戳的重复快照,只保留一份。
避坑指南: 我曾经因为没做时间戳校验,把乱序数据喂给了策略,结果回测曲线漂亮得不像话。后来才发现,是数据顺序错了,策略“预知未来”了。嗯,这种错误,犯一次就够了。

3.4 数据存储与缓存

解析好的快照,建议存到内存数据库里,比如Redis。为什么?因为策略计算需要频繁读取最新数据,磁盘IO太慢了。

我常用的存储结构:

  • Keyorderbook:{symbol},比如orderbook:600519.SH
  • Value:JSON序列化的快照数据
  • TTL:设置过期时间,比如60秒。防止旧数据堆积。

当然,如果你做回测,那就存到本地文件或数据库里。回测不追求实时性,磁盘存储完全够用。

3.5 知识体系总览

下面这张图,是我自己梳理的数据获取流程。你看一眼,心里就有谱了。

数据获取与解析流程 交易所API接入 WebSocket / HTTP 解析订单簿快照 JSON → 结构化数据 数据校验与清洗 去重 / 排序 / 空值检查 数据存储 Redis(实盘) / 数据库(回测) 实时计算 策略引擎消费 订单簿不平衡指标计算 基于清洗后的快照数据 整个流程,核心就三步:接入 → 解析 → 校验。后面的事,都是基于干净数据展开的。

你看,整个流程并不复杂。但每一步都有坑。我个人经验是,数据校验这一步最容易被忽视。很多人拿到数据就开算,结果策略上线后,各种异常数据导致误交易。

嗯,关于数据获取,今天就聊这么多。记住一句话:垃圾数据进,垃圾策略出。把数据管道打磨好,后面的策略开发才能事半功倍。

本章小结:
  • Level-2行情是订单簿策略的基础,必须用深度数据
  • 解析快照时,注意排序和字段映射
  • 数据校验不能省,尤其是时间戳和空值检查
  • 实盘用内存存储,回测用磁盘存储,各取所需

公众号:蓝海数据掘金营,微信deep3321