第二章：Level2行情解析
做量化交易的朋友都知道，行情数据就是我们的「眼睛」。但很多人用了很久的Level2，其实并不清楚它到底「深」在哪里。今天我就带你把这层窗户纸捅破。
2.1 逐笔成交与逐笔委托
先说说最核心的两个概念：逐笔成交和逐笔委托。
逐笔成交，说白了就是每一笔真实发生的交易。谁买了多少股，谁卖了多少股，什么价格成交的，全都记录在案。我刚开始做高频策略时，就靠这个数据来捕捉大单的动向。
逐笔委托呢？它是每一笔挂单的记录。有人挂了买单，有人挂了卖单，还没成交之前，这些信息都在逐笔委托里。
你可能会问：这两者有什么区别？
嗯，我举个例子你就明白了。假设你挂了一笔100手的买单，我挂了一笔100手的卖单，价格匹配上了，系统撮合成交。这时候：
- 逐笔委托里会记录：你挂单、我挂单这两条记录
- 逐笔成交里会记录：你我成交这一条记录
所以，逐笔委托是「因」，逐笔成交是「果」。我在项目中遇到过不少新手，把这两个搞混了，结果策略逻辑全乱套。
核心要点：
- 逐笔成交：已成交的订单记录
- 逐笔委托：未成交的挂单记录
- 两者共同构成完整的订单簿微观结构
2.2 快照与增量
接下来聊一个很实际的问题：行情数据怎么传输？
你想想看，如果每秒都把整个订单簿发一遍，那数据量得多大？交易所当然不会这么干。他们用了两个聪明的办法：快照和增量。
快照，就是某一时刻订单簿的完整状态。比如每天开盘时发一次，或者每3秒发一次。我习惯把快照理解为「基准点」。
增量，就是两次快照之间的变化。比如有人撤单了，有人新挂了单，这些变化都会通过增量数据告诉你。
为什么要这样设计？
我曾经在优化数据接收模块时做过测试：如果只用快照，每秒的数据量大约是500KB；如果配合增量，可以降到50KB以下。整整10倍的差距！
我的建议：
在实际开发中，建议用快照做初始化，用增量做实时更新。这样既保证了数据的完整性，又降低了带宽压力。
2.3 Tick级数据特征
Tick级数据，就是每一笔行情变动的最小单位。它的特征很明显：
- 高频：A股市场每秒能产生几百个Tick
- 不规则：Tick之间的时间间隔不固定，有时密集有时稀疏
- 带时间戳：精确到毫秒甚至微秒
我记得有一次做回测，发现策略在模拟环境里表现很好，一上实盘就亏钱。查了半天，原来是Tick数据的时间精度不够，导致信号延迟了十几毫秒。嗯，这个坑我踩过，你们别踩了。
避坑指南：
我曾经因为忽略了Tick数据的时间戳精度，导致策略在实盘中频繁出现「未来函数」。记住：一定要用交易所原始时间戳，不要用本地时间。
2.4 数据存储格式
最后聊聊存储。Level2数据量很大，怎么存才高效？
我个人比较推荐以下几种格式：
| 格式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| CSV | 通用、易读 | 体积大、查询慢 | 小规模分析 |
| Parquet | 压缩率高、查询快 | 需要特定库 | 大规模存储 |
| HDF5 | 支持多维数据 | 学习成本高 | 科研场景 |
| SQLite | 支持SQL查询 | 写入性能一般 | 中小规模 |
我自己的习惯是：实时数据用Parquet存，历史数据用HDF5。为什么？因为Parquet的列式存储对行情数据的聚合查询特别友好，而HDF5在处理多维时间序列时优势明显。
下面这张图展示了Level2行情数据的整体处理流程：
存储建议：
- 按日期分目录存储，方便管理
- 每个文件包含当天所有Tick数据
- 定期做数据校验，防止文件损坏
好了，Level2行情解析的核心内容就这些。记住：逐笔成交和逐笔委托是基础，快照和增量是传输方式，Tick特征是数据特性，存储格式是落地手段。把这四点吃透了，你就能真正看懂行情数据了。