1. 高频交易数据概述
大家好，我是你们这门课的老朋友。今天咱们聊聊高频交易的数据——说白了，就是那些在极短时间内产生的、海量的市场数据。
我刚开始接触这个领域时，第一反应是：这不就是普通行情数据吗？后来才发现，自己太天真了。高频交易的数据，从定义到特征，再到量级，跟传统金融数据完全是两码事。
1.1 高频交易的定义
高频交易，英文叫 High-Frequency Trading，简称 HFT。它不是什么神秘的黑科技，本质上就是利用计算机程序，在极短时间内完成大量订单的买卖。
那多快算「高频」？嗯，这里有个模糊地带。我个人习惯把响应时间在毫秒级甚至微秒级的交易策略，才叫高频交易。你想想看，普通散户下单可能要几秒钟，而高频交易系统呢？从接收到行情数据，到做出买卖决策，再到发送订单，整个过程可能不到 10 微秒。
为什么会这么快？因为高频交易赚的就是速度的钱。比如，同一只股票在不同交易所存在微小价差，谁能最先发现并执行套利，谁就能赚钱。这中间的差距，可能就是几微秒的事。
核心要点：高频交易不是一种策略，而是一种技术驱动的交易方式。它的核心是速度，数据是它的燃料。
1.2 数据特征：纳秒级时间戳
说到数据特征，第一个要提的就是时间戳。普通行情数据的时间戳，精确到秒就不错了。但高频交易呢？纳秒级。
1 纳秒 = 10-9 秒。什么概念？光在 1 纳秒内只能走大约 30 厘米。也就是说，如果你的交易服务器和交易所的物理距离超过 30 厘米，信号传输的时间就已经超过 1 纳秒了。
我在项目中遇到过这样的坑：一开始用的时间戳精度是微秒级，结果发现同一个微秒内居然有几十笔订单。后来换成纳秒级时间戳，才真正看清了订单的先后顺序。嗯，这里要注意：纳秒级时间戳不是随便找个系统时间就能用的，必须用硬件时间戳，比如 PTP（精确时间协议）或者专用的 FPGA 时间戳卡。
避坑指南：我曾经因为软件时间戳的精度不够，导致回测结果和实盘表现天差地别。后来花了整整一周排查，才发现是时间戳精度问题。所以，从一开始就上硬件时间戳，别走弯路。
1.3 数据特征：订单簿快照
第二个关键数据是订单簿快照。说白了，就是某个时刻，市场上所有买单和卖单的排队情况。
订单簿通常包含以下几个层级：
- 买一、买二、买三...：从高到低排列的买单价格和数量
- 卖一、卖二、卖三...：从低到高排列的卖单价格和数量
- 最新成交价：最后一笔交易的价格
- 成交量：累计成交的股数或合约数
但高频交易的订单簿快照，跟普通行情软件上看到的完全不同。普通行情可能每 3 秒更新一次，而高频交易需要的是每次订单簿发生变化时的快照——也就是事件驱动的快照。
举个例子：
# 一个简化的订单簿快照结构
order_book_snapshot = {
'timestamp': 1623456789.123456789, # 纳秒级时间戳
'bids': [ # 买单，按价格从高到低
{'price': 100.05, 'size': 1000},
{'price': 100.04, 'size': 2000},
{'price': 100.03, 'size': 1500},
],
'asks': [ # 卖单，按价格从低到高
{'price': 100.06, 'size': 800},
{'price': 100.07, 'size': 1200},
{'price': 100.08, 'size': 900},
]
}你想想看，在交易活跃时段，订单簿可能每秒变化几百次甚至上千次。每次变化都要记录一个完整的快照？那数据量就太恐怖了。所以实际中，我们通常只记录增量变化——也就是「事件」数据。
关键点：高频交易的数据存储，通常分为两种模式：快照模式和增量模式。快照模式记录完整状态，增量模式只记录变化。两者各有优劣，后面章节我会详细讲。
1.4 数据量级估算：每日 TB 级
好了，现在咱们来算一笔账。看看高频交易的数据量到底有多大。
假设我们跟踪的是 A 股市场，大约 4000 只股票。每只股票每天的交易时间是 4 小时（240 分钟）。在交易活跃时段，每只股票每秒可能产生 10-50 次订单簿变化。
咱们取个中间值：每只股票每秒 20 次变化。那么：
| 项目 | 数值 |
|---|---|
| 股票数量 | 4,000 只 |
| 交易时长 | 4 小时 = 14,400 秒 |
| 每秒变化次数 | 20 次 |
| 每次变化数据量 | 约 200 字节（含时间戳、价格、数量等） |
| 每日总数据量 | 约 230 GB |
这只是订单簿数据。如果再加上逐笔成交数据、行情快照数据、以及各种衍生数据（比如指数计算、波动率等），每天的数据量轻松超过 1 TB。
我记得有一次，公司要搭建一个全市场的高频数据仓库。一开始估算每天 500 GB，结果上线后第一个月，日均数据量就飙到了 1.2 TB。嗯，这里要提醒大家：数据量估算时，一定要留出 2-3 倍的余量。因为市场活跃度会波动，而且数据源可能会增加新的字段。
警告：千万别小看数据量。我曾经见过一个团队，因为低估了数据量，导致存储系统在行情火爆时直接崩溃。那天的损失，够买好几年的存储设备了。
1.5 数据压缩的必要性
既然数据量这么大，那怎么处理呢？答案就是压缩。
但高频交易数据的压缩，跟普通文件的压缩不一样。普通压缩工具（比如 gzip、zip）虽然能压缩，但解压速度太慢。在高频交易中，数据需要实时处理，压缩和解压的速度必须跟得上数据产生的速度。
所以，我们需要专门针对金融时序数据的压缩算法。比如：
- 增量编码：只存储相邻数据之间的差值，而不是完整数值
- 字典编码：对重复出现的价格、代码等进行编码
- 位打包：用最少的位数存储整数数据
- 列式存储：按字段而不是按行存储，提高压缩率
这些技术，咱们后面几章会一个一个地拆开来讲。今天先有个概念：高频交易的数据压缩，核心目标是在不损失信息的前提下，把数据量压缩到原来的 1/5 甚至 1/10，同时保证压缩和解压的速度在微秒级别。
个人经验：我建议初学者先从增量编码入手。这个技术最简单，但效果往往出奇地好。我在一个项目中，仅用增量编码就把订单簿数据压缩了 70%。
小结
今天咱们聊了高频交易数据的三个核心点：
- 定义：高频交易是速度驱动的交易方式，数据是它的命脉
- 特征：纳秒级时间戳和事件驱动的订单簿快照
- 量级：全市场每日 TB 级的数据量，压缩是必须的
下一章，我会带大家深入分析几种常见的高频数据格式，看看它们各自的优缺点。咱们到时候见。
公众号:蓝海资料掘金营，微信deep3321