2. Tick数据特征分析：高频特性、数据量级估算与时间戳对齐
做Tick数据存储，第一件事不是选压缩算法，也不是搭集群。
而是搞清楚——你面对的数据，到底长什么样？
我见过不少团队，一上来就搞列式存储、搞字典编码，结果发现数据特征完全不适合，最后性能还不如直接存CSV。说白了，Tick数据有它自己的脾气，你得顺着它来。
2.1 高频特性：Tick数据到底有多“高频”？
A股市场的Tick数据，指的是每一笔逐笔成交数据。不是分钟线，不是5秒快照，是真正的“每一笔”。
我举个例子你就明白了：
- 普通股票：每天大约产生 1万～5万笔 Tick
- 热门股票（比如茅台、宁德时代）：每天 10万～30万笔
- 全市场（约5000只股票）：每天总Tick数在 1亿～3亿笔
嗯，你没看错。一天3亿笔。这还只是成交数据，还没算订单簿的逐笔委托。
为什么会这么高？
因为A股的交易机制是“连续竞价+集合竞价”，而且现在程序化交易占比越来越高。我做过一个统计：
| 时间段 | 每秒Tick数（热门股） | 每秒Tick数（全市场） |
|---|---|---|
| 开盘集合竞价（9:15-9:25） | 200～500 | 5万～10万 |
| 连续竞价（9:30-11:30） | 50～200 | 2万～5万 |
| 尾盘集合竞价（14:57-15:00） | 300～800 | 8万～15万 |
你看，开盘和尾盘是Tick数据的“洪峰”。我当年做实时存储系统时，就因为这个洪峰特性，差点把Kafka集群搞崩了。后来加了背压控制和预分桶策略，才算稳住。
核心结论：Tick数据不是均匀流，而是“脉冲式”的。存储系统必须能扛住瞬间10倍以上的写入压力。
2.2 数据量级估算：一天到底存多少？
咱们来算一笔账。以A股全市场为例：
一条Tick记录，通常包含这些字段：
- 股票代码（6字节，如"600519"）
- 时间戳（8字节，纳秒级）
- 成交价格（4字节，int32）
- 成交数量（4字节，int32）
- 成交金额（8字节，int64）
- 买卖方向（1字节）
- 成交编号（8字节）
一条原始记录大约 40～50 字节。我们按50字节算：
每日Tick数：2亿笔（取中间值）
单笔大小：50字节
每日原始数据量：2亿 × 50B = 10GB
每月（22个交易日）：220GB
每年：约2.6TB这还只是成交数据。如果加上逐笔委托（Order Book），数据量至少翻3倍。我做过一个项目，客户要求同时存储Level-2的十档行情，最终年数据量接近10TB。
注意：以上估算没有考虑压缩。实际存储时，好的压缩算法可以把体积压缩到原始数据的 10%～20%。但压缩的前提是——你得先理解数据特征，才能选对算法。
2.3 时间戳精度与对齐问题
这是Tick数据里最坑的地方，没有之一。
A股交易所提供的时间戳精度是 微秒级（μs），但不同数据源给的精度不一样：
- 上交所：逐笔成交时间戳精度为微秒，但实际有效位只有毫秒级
- 深交所：同样微秒精度，但部分字段存在“时间戳跳跃”现象
- 第三方数据商：有的给纳秒，有的给微秒，有的干脆只给毫秒
我遇到过最离谱的一次：同一只股票，同一笔成交，从两个数据商拿到的Tick时间戳差了整整3毫秒。3毫秒在Tick数据里是什么概念？足够发生好几笔新的成交了。
时间戳对齐，说白了就是解决两个问题：
- 精度统一：把所有时间戳转成同一个精度（我建议统一用微秒）
- 排序去重：同一时间戳下可能有多个Tick，需要按交易所原始顺序排列
我个人的习惯是：
// 伪代码：时间戳对齐策略
if (timestamp_precision == "nanosecond") {
timestamp = timestamp / 1000; // 转微秒
} else if (timestamp_precision == "millisecond") {
timestamp = timestamp * 1000; // 转微秒
}
// 注意：不要直接截断，要四舍五入
// 我曾经因为直接截断，导致回测时出现了“未来数据”避坑指南：我曾经在回测系统里直接用纳秒时间戳做排序，结果发现同一微秒内的Tick顺序是乱的。后来加了“交易所序号”作为二级排序键，才彻底解决。
2.4 知识体系总览
下面这张图，是我自己总结的Tick数据特征分析框架。每次做新项目，我都会先过一遍这张图：
这张图的核心逻辑很简单：先理解数据特征，再选压缩算法，最后设计存储架构。顺序不能乱。我见过太多人跳过第一步，直接去调压缩参数，结果折腾一个月发现方向错了。
好了，这一章我们搞清楚了Tick数据长什么样。下一章，我会带你看看针对这些特征，有哪些压缩算法是真正能打的。