4. 压缩算法基础：无损压缩 vs 有损压缩
聊压缩之前，我先问大家一个问题：你愿意为了省一半的存储空间，丢掉千分之一的精度吗？
这个问题，在Tick数据领域其实没有标准答案。我见过不少团队，一上来就上zstd，觉得压缩比高就是王道。结果呢？解压速度跟不上行情推送，交易系统直接卡死。嗯，这里面的门道，咱们今天好好捋一捋。
4.1 无损压缩 vs 有损压缩：选哪个？
说白了，区别就一句话：解压后能不能100%还原原始数据。
- 无损压缩：解压后和原始数据一模一样。Tick数据里的价格、成交量、时间戳，一个bit都不能错。我个人的习惯是，所有交易数据、行情快照、订单簿数据，必须用无损压缩。为什么？因为监管审计的时候，你拿不出原始数据，那麻烦就大了。
- 有损压缩：丢掉一些不重要的信息，换来更高的压缩比。比如高频交易中的某些噪声数据、历史回测中的毫秒级精度。我曾经在回测系统里试过有损压缩，结果策略收益曲线变得平滑了——但那是假象，真实交易中根本跑不出那个效果。
核心原则：Tick数据中，价格、成交量、时间戳必须无损。某些衍生指标（如波动率、买卖价差）可以适当有损。
4.2 通用压缩算法对比：gzip、snappy、zstd
这三个家伙，是压缩界的「三剑客」。但各有各的脾气，用错了地方，性能会很难看。
| 算法 | 压缩比 | 压缩速度 | 解压速度 | 内存占用 | 适合场景 |
|---|---|---|---|---|---|
| gzip | 中等（2-4x） | 慢 | 中等 | 低 | 冷数据归档、日志 |
| snappy | 低（1.5-2x） | 极快 | 极快 | 极低 | 实时流、内存缓存 |
| zstd | 高（3-8x） | 快（可调） | 快 | 中等 | 热数据、冷热混合 |
你想想看，如果每秒要处理10万笔Tick，用gzip压缩，CPU直接飙到100%，行情都来不及入库。我建议：实时写入用snappy，历史归档用zstd。snappy虽然压缩比低，但解压速度是gzip的5倍以上，这在Tick回放时特别重要。
避坑指南：我曾经在某个项目中，用zstd的默认级别（level=3）压缩Tick数据，结果发现压缩比只有2.5x。后来调到了level=19，压缩比到了6x，但压缩时间增加了20倍。嗯，zstd的level参数一定要根据数据特征调优，别直接用默认值。
4.3 时序数据专用压缩思路
通用压缩算法有个致命问题：它们不懂时序数据的结构。Tick数据是高度有序的，相邻两条记录的时间戳、价格、成交量往往变化很小。你想想看，如果直接用gzip压缩原始二进制，压缩比可能只有2-3x。但如果我们先做预处理，压缩比能轻松到10x以上。
我总结了一套「三板斧」思路：
- 差分编码：不存原始值，存差值。比如时间戳，第一条存完整值，后面只存与上一条的差值。价格也是，只存变动量。这样数据分布会非常集中，压缩算法更容易处理。
- 字典编码：对于重复出现的值（比如交易所代码、证券代码），建立字典映射。一个32位的ID，映射成1个字节的索引，存储空间直接省75%。
- 列式存储：把同一字段的数据放在一起。比如所有时间戳放一列，所有价格放一列。这样同一列的数据类型一致，压缩算法可以针对性地优化。
实战经验：我做过一个测试，原始Tick数据（包含时间戳、价格、成交量、买卖盘口）约100GB。直接用gzip压缩，得到35GB。用了差分+字典+列式预处理后，再用zstd压缩，最终只有8GB。压缩比从3x提升到了12x。
4.4 核心知识体系
下面这张图，是我梳理的本章知识脉络。你可以把它当作一个「压缩算法选型地图」：
重要提醒：不要盲目追求最高压缩比。我曾经见过一个团队，为了把100TB的Tick数据压缩到10TB，用了zstd level=22，结果压缩花了3天，解压花了2天。数据是省了，但业务根本等不起。压缩算法的选择，永远是速度、压缩比、内存三者的平衡。
好了，这一章的内容就到这里。记住一个核心原则：Tick数据压缩，先做时序预处理，再选合适的通用算法。下一章，我会带大家手写一个差分编码器，看看实际效果到底有多猛。