订单簿数据结构：Level 1、Level 2、Level 3数据的区别

做高频交易，第一件事就是搞懂订单簿。说白了，订单簿就是交易所里所有挂单的集合。但不同交易所、不同场景下，你能拿到的数据深度完全不一样。

我个人习惯把订单簿数据分成三个层级。就像看一座冰山——Level 1 只看到水面上的尖尖，Level 2 能看到水下的大块，Level 3 则是把整座冰山的每一块冰都看清楚。

Level 1：最浅层的数据

Level 1 数据，也叫市场数据（Market Data）。它只告诉你当前市场的最佳报价。

• 最佳买价（Best Bid）：当前最高的买入价格
• 最佳卖价（Best Ask）：当前最低的卖出价格
• 最新成交价（Last Price）：上一笔交易的价格
• 成交量（Volume）：累计成交数量

嗯，这里要注意。Level 1 数据其实非常有限。你只知道「有人想用 100 块买，有人想用 101 块卖」，但你看不到 100 块那里有多少单子，也看不到 99 块那里有没有人埋伏。

Level 2：市场深度数据

Level 2 数据，也叫市场深度（Market Depth）。它展示了多个价位的挂单情况。

举个例子，一个典型的 Level 2 快照长这样：

卖五：101.50  200股
卖四：101.40  150股
卖三：101.30  300股
卖二：101.20  100股
卖一：101.10  500股
-------------------
买一：101.00  400股
买二：100.90  600股
买三：100.80  200股
买四：100.70  350股
买五：100.60  100股

你看，Level 2 不仅告诉你价格，还告诉你每个价位上有多少单子。这就有意思了。

我在项目中遇到过一件事：有一次我发现某个股票在 100 块的位置突然堆了 10 万股的买单，但价格纹丝不动。这明显是有人在挂假单（Spoofing）。如果你只有 Level 1 数据，你根本察觉不到这种异常。

Level 3：逐笔委托数据

Level 3 数据，也叫逐笔委托（Order Book Increment）。它记录的是每一笔订单的完整生命周期。

说白了，Level 3 数据不是快照，而是事件流。每一笔订单的 新增、撤销、成交、修改 都会被记录下来。

举个例子，一条 Level 3 消息可能是这样的：

时间戳：09:30:01.123456
事件类型：新增订单
订单ID：12345678
方向：买入
价格：100.50
数量：1000股

为什么需要 Level 3？你想想看，Level 2 快照每 100 毫秒更新一次，但在这 100 毫秒内，可能发生了 50 笔订单的撤销和新增。这些信息在快照里是丢失的。

Order Book Snapshot 与 Order Book Increment

搞清楚了三个层级，接下来要理解两种数据格式：快照（Snapshot）和增量（Increment）。

快照（Snapshot）

快照就是某一时刻订单簿的完整状态。就像你给订单簿拍了一张照片。

优点很明显：简单、直观。你拿到一个快照，就知道当前所有价位的挂单情况。

缺点也很致命：数据量大。如果你每秒拍 10 张照片，每张照片包含 100 个价位，那数据量就爆炸了。

增量（Increment）

增量只记录变化的部分。比如「刚才有人在 100.50 挂了 500 股，现在撤单了」，增量消息只告诉你这个变化。

这样做的好处是数据量小、延迟低。高频交易系统几乎都采用增量模式。

但增量模式有个坑：你必须维护一个本地的订单簿副本。每次收到增量消息，你都要更新本地副本。如果中间漏掉一条消息，整个订单簿就乱了。

两者的对比

特性	快照（Snapshot）	增量（Increment）
数据量	大（每次全量）	小（只传变化）
延迟	高	低
实现复杂度	低	高（需维护本地副本）
容错性	高（每次都是完整状态）	低（漏一条就乱）
适用场景	低频分析、数据回放	高频交易、实时策略

核心逻辑流程图

下面这张图展示了从原始交易所数据到策略决策的完整链路：

这张图其实是我自己搭建交易系统时用的架构。你看，数据从交易所进来后，先解析成快照或增量，然后维护到本地订单簿。策略层从本地订单簿读取数据做决策。同时，定时校验链路会拉取快照来修正本地数据。

嗯，这里再补充一点。很多初学者会问：「我是不是直接上 Level 3 最好？」其实不一定。Level 3 数据量极大，处理起来对硬件要求很高。如果你的策略不需要那么细的粒度，Level 2 增量数据完全够用。

我个人习惯是：做市商策略必须用 Level 3，趋势跟踪策略用 Level 2 就够了。别盲目追求数据深度，适合你的策略才是最好的。