数据源与交易所接口：行情数据的“第一公里”
做量化交易，尤其是高频交易，第一道坎儿就是怎么把行情数据拿回来。我常说，行情数据是量化交易的“原油”，你炼油技术再好，原油本身是掺了水的，那后面全白搭。今天我们就聊聊这个“第一公里”的问题——数据源和交易所接口。
说白了，你得知道数据从哪来，用什么协议传过来，以及你拿到的到底是“简讯”还是“全文”。
国内外主流交易所：你得知道谁在“发牌”
先看国内。沪深交易所，也就是上海证券交易所和深圳证券交易所，这是A股的主战场。它们的数据接口，嗯，怎么说呢，比较“传统”。
- 上海证券交易所（SSE）：主要用FAST协议推Level-2行情。我个人习惯把FAST理解为一种“压缩饼干”，它把数据压得很小，但解压起来需要点功夫。
- 深圳证券交易所（SZSE）：早期用Step协议（基于FIX），后来也转向了FAST。深交所的Level-2数据，我记得在2018年左右有一次大升级，增加了逐笔成交数据，这对做盘口分析太关键了。
- 中国金融期货交易所（CFFEX）：也就是中金所，做股指期货的。它的接口是CTP（综合交易平台）。CTP是个好东西，稳定、高效，但学习曲线有点陡。
- 币安（Binance）：加密货币的龙头。它的接口就“现代”多了，WebSocket是标配，REST API也做得很好。币安的文档，我建议所有做数字资产的同行都仔细读读，算是行业标杆了。
你想想看，这些交易所的接口风格差异很大。沪深交易所像老派的银行家，严谨但有点慢；币安像硅谷的创业公司，灵活但偶尔会出点小bug。做跨市场交易时，你得习惯这种“人格分裂”。
行情数据协议：数据是怎么“飞”过来的？
数据从交易所出来，得有个“运输工具”。常见的就三种：FIX/FAST、WebSocket、UDP组播。
1. FIX/FAST：金融界的“老大哥”与“新贵”
FIX协议，全称是金融信息交换协议。它出现得很早，几乎是金融电子化的代名词。但FIX有个问题——它太“啰嗦”了。每条消息都带着一堆标签，比如“35=D”表示这是一条新订单，“55=600519”表示股票代码。这在低延迟场景下，带宽浪费很严重。
FAST协议就是来解决这个问题的。它把FIX消息“压缩”了。怎么压缩的？它定义了一个模板，发送方只传变化的数据，不变的数据就不传了。接收方拿着模板和压缩后的数据，再“解压”出来。
核心区别：FIX是“全量”传输，FAST是“增量”传输。FAST的压缩比能做到10:1甚至更高。
我在项目中遇到过一个问题：用FAST解析深交所的Level-2行情，一开始总是丢包。后来发现是模板版本没对齐。交易所升级了模板，我这边还是老版本，解析出来的数据全是乱码。嗯，这里要注意，FAST的模板管理是个坑，一定要跟交易所保持同步。
2. WebSocket：互联网时代的“长连接”
WebSocket现在太流行了，尤其是币安这类交易所，几乎都在用。它跟HTTP不一样，HTTP是“请求-响应”模式，你问一句，它答一句。WebSocket是“订阅-推送”模式，你订阅了某个币种，交易所一有变化就主动推给你。
这样做的好处是实时性高，延迟低。坏处是，如果网络不稳定，连接断了，你得自己处理重连和补数据。我曾经因为WebSocket断线重连没处理好，导致策略跑了一整天，数据缺了5分钟，回测结果完全失真。从那以后，我写了个重连机制，每次重连后先拉一次全量快照，再补增量数据。
小技巧：WebSocket的心跳机制一定要开。很多交易所默认60秒无数据就断开连接。你设个30秒的心跳，能省很多麻烦。
3. UDP组播：极速玩家的“专属通道”
如果你做的是高频交易，尤其是期货、期权这类，UDP组播是你绕不开的。它跟TCP不一样，TCP是“可靠”的，但为了可靠，它做了很多额外工作（比如确认、重传），这增加了延迟。UDP是“尽力而为”的，它只管发，不管收没收到。
UDP组播的好处是，一份数据可以同时发给多个接收者，效率极高。坏处是，它不保证数据一定到达。所以，用UDP组播时，你通常需要自己实现一个“丢包重传”机制。
我记得有一次，我们团队做中金所的CTP行情接入。用的是UDP组播，延迟能做到微秒级。但有一次交易所网络波动，我们丢了大概0.1秒的数据。就这0.1秒，导致我们的套利策略开仓晚了，亏了十几万。从那以后，我坚持在UDP组播之外，再拉一条TCP的“补数据”通道。
警告：UDP组播不适合“弱网”环境。如果你在公网上用UDP组播，丢包率会高得吓人。它只适合在局域网或者专线环境下使用。
Level-1与Level-2行情：你看到的是“快照”还是“电影”？
这个区别，我打个比方你就懂了。Level-1行情，就像你每隔5秒钟拍一张照片，看到的是那个瞬间的静态画面。Level-2行情，就像你一直在录像，能看到每一帧的变化。
具体来说：
| 维度 | Level-1（基础行情） | Level-2（深度行情） |
|---|---|---|
| 更新频率 | 通常3-5秒一次 | 实时推送，毫秒级甚至微秒级 |
| 盘口深度 | 5档买卖盘（买1-买5，卖1-卖5） | 10档、20档甚至全量委托队列 |
| 逐笔成交 | 无 | 有，能看到每一笔成交的细节 |
| 数据量 | 小，一天几MB | 大，一天几十GB甚至上百GB |
| 典型用途 | 普通投资者看盘、低频策略 | 高频交易、做市商、盘口分析 |
为什么会有这种区别？说白了，就是成本问题。Level-2行情的数据量是Level-1的几十倍甚至上百倍。交易所要处理、传输、存储这些数据，成本很高。所以，Level-2行情通常是要收费的。沪深交易所的Level-2，一年大概几千块。币安的Level-2，如果你要全量深度，也得买VIP套餐。
我个人建议，如果你做的是高频策略，Level-2是必须的。没有逐笔成交数据，你根本没法分析“大单”和“小单”的博弈。但如果你只是做日频或者小时频的策略，Level-1完全够用，没必要花那个冤枉钱。
一张图看懂本章知识体系
下面这张图，我画了本章的核心逻辑。从数据源到协议，再到行情级别，你可以看到整个链路是怎么串起来的。
避坑指南：我踩过的那些坑
最后，分享几个我亲身经历过的坑，希望能帮你少走弯路。
- 坑一：FAST模板版本不一致。我曾经因为交易所升级了FAST模板，而我这边没更新，导致解析出来的行情数据全是错的。那段时间，我的策略一直在“裸泳”。后来我写了个脚本，每天开盘前自动检查模板版本。
- 坑二：WebSocket断线重连。有一次，币安的WebSocket连接因为网络波动断了，我的程序没有自动重连，导致策略在“真空”中运行了10分钟。那10分钟，我的账户亏了5%。从那以后，我强制要求所有WebSocket连接必须有自动重连和补数据机制。
- 坑三：UDP组播丢包。UDP组播虽然快，但丢包是常态。我见过最夸张的一次，一个晚上丢了30%的数据包。后来我加了双通道（UDP+TCP）和丢包重传机制，才把问题解决。
我的建议：不管用哪种协议，一定要有“数据完整性校验”。比如，你可以每收到1000条消息，校验一次序号是否连续。如果发现跳号，立刻触发补数据流程。
好了，这一章的内容就到这里。数据源和接口是行情采集的起点，也是整个量化交易系统的“地基”。地基不稳，上面盖再高的楼也是白搭。下一章，我们会深入聊聊数据格式与存储，看看拿到数据后，怎么把它“存好”和“用好”。