一、高频做市数据概述
做高频交易的人都知道，数据是命根子。我做了这么多年量化架构，见过太多团队在数据上栽跟头。今天咱们就来聊聊高频做市数据的那些事儿。
1.1 高频交易数据的特点
高频交易数据，说白了就是三个词：海量、高维、时序。这三个特点，每一个都够你喝一壶的。
海量
你想想看，一个中等活跃度的股票，一天就能产生几百万条Tick数据。要是做全市场、多品种，一天的数据量轻松上TB。我在项目中遇到过最夸张的情况——某家交易所的行情网关，每秒推送超过10万笔订单簿更新。嗯，这数据量，传统的关系型数据库根本扛不住。
高维
高频数据不只是价格和成交量。每一条Tick都包含：
- 时间戳（精确到纳秒）
- 买卖方向
- 价格（买一至买N、卖一至卖N）
- 数量（每个档位的挂单量）
- 订单类型（限价单、市价单、撤单等）
- 交易所标识、交易品种、交易日期等
维度一多，存储和查询的复杂度就上来了。我见过有人把几十个字段全塞进一张宽表里，结果查询慢得像蜗牛爬。
时序
高频数据天然是时间序列。每一笔数据都有精确的时间戳，而且时间顺序极其重要。你想想看，如果数据乱序了，回测出来的策略结果可能完全不对。我曾经因为一个时间戳精度问题，排查了整整三天——最后发现是不同交易所的时钟不同步导致的。
核心要点：高频数据的三大特点决定了我们不能用传统数据库来存。你需要专门为时序数据设计的存储引擎，比如ClickHouse、InfluxDB，或者自己撸一个内存数据库。
1.2 Tick级数据与Order Book数据
做高频做市，你每天打交道最多的就是这两类数据。我建议你先把它们搞清楚。
Tick级数据
Tick数据就是每一笔成交的原始记录。它包含：
- 成交时间（精确到微秒甚至纳秒）
- 成交价格
- 成交量
- 成交方向（买方主动还是卖方主动）
- 成交编号（交易所给的唯一标识）
为什么Tick数据重要？因为它反映了最真实的交易行为。我记得有一次做策略回测，发现用1秒K线算出来的信号和用Tick数据算出来的信号完全相反。后来一查，原来是K线聚合时把关键信息给抹掉了。
Order Book数据
Order Book就是订单簿，也叫深度行情。它展示的是当前市场上所有未成交的限价单。结构大概是这样的：
买盘（Bid） 卖盘（Ask）
价格 数量 价格 数量
10.01 1000 10.02 800
10.00 2000 10.03 1500
9.99 3000 10.04 2000
...做市商最关心的就是Order Book的变化。每一笔订单的进入、撤单、成交，都会改变订单簿的形状。我习惯把Order Book的快照和增量更新分开存储——快照用于恢复状态，增量用于分析市场微观结构。
我的经验：存储Order Book数据时，别傻傻地存全量快照。每毫秒存一次全量，一天下来数据量爆炸。正确的做法是：每隔一段时间（比如1秒）存一次快照，中间只存增量更新。这样既能恢复完整状态，又能节省大量存储空间。
1.3 数据源与数据格式
数据从哪来？怎么传？这是架构设计的第一步。我见过太多人在这上面踩坑了。
数据源
高频做市的数据源主要有这么几个：
- 交易所直连：延迟最低，但需要自己处理协议和网络问题
- 行情数据商：比如Bloomberg、Reuters，数据质量高，但贵
- 券商/经纪商：方便，但延迟和精度可能打折扣
- 开源数据源：比如Binance的WebSocket API，适合测试
我个人建议，做生产环境一定要用交易所直连。延迟差个几毫秒，做市策略的盈亏可能就差一个数量级。
FIX协议
FIX（Financial Information eXchange）协议是金融领域最常用的消息协议。它长这样：
8=FIX.4.2|9=178|35=D|49=CLIENT1|56=BROKER1|34=1|52=20240101-12:00:00.000|
11=ORDER001|21=1|55=IBM|54=1|60=20240101-12:00:00.000|38=1000|40=2|
44=150.00|59=0|10=128|FIX协议的好处是标准化程度高，几乎所有交易所都支持。但坏处也很明显——它是文本协议，解析起来慢。在高频场景下，每微秒都很宝贵，所以很多人会选择更高效的二进制格式。
避坑指南：我曾经在项目中直接用开源的FIX解析库，结果发现解析延迟高达几十微秒。后来我们手写了一个精简版的FIX解析器，只解析我们需要的字段，延迟降到了2微秒以内。记住：在高频交易里，通用库往往不是最优解。
Binary格式
为了追求极致性能，很多交易所和做市商都转向了二进制协议。比如：
- Binary FIX：FIX协议的二进制版本，保留字段定义但用二进制编码
- Protobuf：Google的序列化协议，压缩率高，解析快
- FlatBuffers：Facebook开源的，零拷贝解析，延迟极低
- 自定义二进制：很多交易所自己定义的，比如CME的MDP 3.0
二进制格式的解析速度比文本格式快一个数量级。我做过测试，同样一条行情消息，FIX文本解析需要5微秒，Protobuf只需要0.5微秒，FlatBuffers甚至能做到0.1微秒以下。
下面这张图展示了不同数据格式的解析延迟对比：
看到这个对比，你应该明白为什么做高频的都在用二进制格式了。延迟就是金钱，每节省一微秒，你的策略就能跑得更快。
我的建议：如果你刚开始搭建高频数据系统，先用Protobuf。它生态好、工具链成熟，性能也够用。等你的延迟要求到了亚微秒级别，再考虑FlatBuffers或者自定义二进制协议。别一上来就追求极致，先把系统跑通再说。
好了，关于高频做市数据的基本概念就聊到这儿。记住：数据是高频交易的基石，把数据搞清楚了，后面的架构设计才能站得住脚。