2. 数据源与采集挑战：交易所数据源（L1/L2行情）、数据经纪商、采集过程中的延迟与丢包问题

做量化交易，尤其是高频或中频策略，最怕什么？

我个人最怕的不是策略亏钱，而是数据本身有问题。你想想看，如果喂给模型的数据本身就是错的，那再牛逼的算法也是白搭。这一章，我们就来聊聊数据从哪里来，以及采集过程中那些让人头疼的坑。

2.1 交易所数据源：L1与L2行情

先说交易所。交易所是数据的源头，也是唯一权威的来源。但不同交易所、不同市场，提供的数据深度是不一样的。

2.1.1 Level 1 (L1) 行情

L1行情，说白了就是“最优报价”。它只告诉你当前市场上最好的买价（Bid）和卖价（Ask），以及最后一笔成交价和成交量。

• 包含内容：最新价、涨跌幅、最高价、最低价、成交量、持仓量。
• 特点：数据量小，带宽占用低，适合做趋势跟踪或低频策略。
• 缺点：看不到盘口的深度，你不知道买一后面还有多少单子，卖一后面有没有大单压着。

2.1.2 Level 2 (L2) 行情

L2行情，也叫“深度行情”或“逐笔委托”。它展示的是整个订单簿的挂单情况，通常能看到买一到买N档，卖一到卖N档。

• 包含内容：多档买卖价格、每档对应的挂单量、逐笔成交明细。
• 特点：数据量巨大，每秒可能产生数千甚至数万条更新。
• 优点：能真实反映市场微观结构，比如大单吃货、撤单行为。

我记得有一次做A股L2数据回测，发现某只股票在收盘前3分钟，买一档突然堆了5000手大单，但价格纹丝不动。这明显是主力在托盘，而不是真实买盘。这种信号，L1数据根本看不出来。

2.2 数据经纪商：中间人的角色

大部分个人或中小机构，没法直接连交易所。为什么？因为交易所的行情接口要么太贵，要么技术门槛太高。这时候就需要数据经纪商。

数据经纪商从交易所拿到原始数据，经过清洗、聚合、分发，再卖给你。常见的经纪商有：Bloomberg、Reuters、Quandl、以及国内的通联数据、万得等。

2.3 采集过程中的延迟与丢包

数据从交易所到你本地的数据库，中间要经过网络传输、协议解析、缓存写入等多个环节。每个环节都可能引入延迟或丢包。

2.3.1 延迟的来源

1. 网络延迟：物理距离决定光速延迟。比如从上海到纽约，单程光速延迟约40ms，加上路由跳转，实际可能60-80ms。
2. 协议解析延迟：交易所通常使用FIX协议或二进制协议。FIX协议是文本格式，解析慢；二进制协议解析快，但可读性差。
3. 操作系统调度延迟：数据到达网卡后，需要CPU中断处理。如果系统负载高，数据可能在内核缓冲区排队。
4. 应用层处理延迟：你的采集程序如果用了Python，GIL锁会限制并发处理能力。我建议用C++或Go写采集层。

2.3.2 丢包问题

丢包是Tick级数据采集的噩梦。一个Tick丢失，可能导致你的策略错过一个关键信号，或者回测时出现数据断层。

为什么会丢包？

• 网络拥塞：行情爆发时（比如开盘、收盘、重大新闻），数据量瞬间暴增，交换机或路由器可能丢包。
• 接收端处理不过来：你的程序处理速度跟不上数据产生速度，缓冲区溢出，数据被丢弃。
• UDP协议本身不可靠：很多交易所的行情推送使用UDP协议，它不保证数据一定到达。如果你用UDP，必须自己实现重传机制。

2.4 知识体系框架

下面这张图，是我自己总结的数据采集核心逻辑。你可以把它当作一个检查清单，每次搭建采集系统时对照着看。

2.5 实战建议

最后，给几个我踩过坑之后的实战建议：

• 永远不要相信数据是完美的。哪怕是从交易所直接拿的数据，也要做完整性校验。我习惯在采集端记录每个Tick的序列号，如果发现跳号，立即报警。
• 用双通道采集。对于关键数据源，同时从两个不同的经纪商拉数据，做交叉验证。虽然成本翻倍，但能避免单点故障。
• 监控延迟的分布。不要只看平均延迟，要看P99、P99.9延迟。我曾经遇到过一个经纪商，平均延迟只有5ms，但P99.9延迟高达500ms，这种抖动对高频策略是致命的。
• 本地缓存要够大。如果数据库写入慢，数据会在内存里堆积。我建议用环形缓冲区（Ring Buffer）来暂存Tick数据，避免内存溢出。

嗯，数据源和采集这块，说白了就是跟时间赛跑。你比别人快1毫秒，可能就多赚一个点。但前提是，你的数据得是准的。下一章我们会聊到数据清洗的具体方法，到时候再细说。

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