2、数据压缩必要性：存储成本分析、带宽限制、高频场景下的IO瓶颈
好，咱们接着聊。上一章我们把订单簿的数据结构拆了个底朝天，你可能会想：「数据量再大，硬盘现在也不贵啊，有必要折腾压缩吗？」
嗯，这个问题我当年也问过自己。直到我在一个高频回测项目里，亲眼看着磁盘阵列的灯狂闪，CPU 却闲着等数据——那一刻我才意识到，压缩不是省硬盘，是救性能。
2.1 存储成本：你以为的便宜，其实很贵
先算一笔账。一个典型的 Level 2 订单簿，每秒快照大约 50KB。一天交易 6.5 小时，就是：
50KB × 3600秒 × 6.5小时 ≈ 1.14 GB/天一年下来就是 400 多 GB。如果你同时跑 10 个品种、3 年历史数据——嗯，12TB 就这么没了。
我个人习惯用 NVMe SSD 做回测，1TB 的盘大概 1000 块。12TB 就是一万二。这还只是存储，还没算备份、传输、运维的成本。
关键点： 订单簿数据是「高频快照」+「低频变动」的组合。原始数据里大量重复信息——比如买卖盘口不变的价格档位，每次快照都重复写入。压缩率通常能做到 5:1 到 10:1。
说白了，你花一万二买的盘，压缩后只需要一千二的盘。剩下的钱干点啥不好？
2.2 带宽限制：网络才是真正的瓶颈
存储成本还算小事，带宽才是真正的痛点。
我做过一个跨机房的数据同步项目。两个机房之间带宽只有 1Gbps，但需要实时同步 20 个品种的订单簿数据。你算算：
50KB × 20 品种 × 每秒 10 次快照 = 10 MB/s ≈ 80 Mbps看起来 1Gbps 够用对吧？但别忘了，还有行情数据、成交数据、风控数据……实际跑起来，带宽占用经常飙到 700-800 Mbps。一旦网络抖动，数据就开始堆积。
我曾经踩过的坑： 有一次带宽被打满，导致订单簿数据延迟了 200 毫秒。策略以为价格没变，实际上已经跳了 3 个 tick。那一单亏了 6 位数。从那以后，我强制所有跨机房传输的数据必须压缩。
压缩后，50KB 的快照能压到 5-8KB。带宽占用直接降到 10-15 Mbps。你想想看，同样的带宽，能多传 5 倍的品种——这性价比，不香吗？
2.3 高频场景下的 IO 瓶颈：CPU 在等数据吃饭
这是最容易被忽视的问题。很多人觉得「我 CPU 够快，内存够大，IO 不是问题」。但高频场景下，IO 往往是第一瓶颈。
举个例子。一个典型的回测流程：
- 从磁盘读取订单簿快照
- 解析成内存结构
- 喂给策略引擎
- 策略计算并下单
你猜哪一步最慢？
磁盘 IO。尤其是随机读取。机械硬盘的随机 IOPS 只有 100-200，SSD 好一点，也就 10 万左右。但订单簿数据是时间序列，需要按时间顺序读取——这其实是顺序读，性能还行。
真正的坑在于解析开销。
原始数据是二进制或者 JSON 格式。每次读取都要反序列化。我测过一个 JSON 格式的订单簿，解析 1MB 数据需要 50 毫秒。而压缩后的二进制格式，解析只需要 5 毫秒。
我的经验： 压缩不只是减少存储，更重要的是减少 IO 次数和解析时间。压缩后的数据体积小，读取快，解析也快。整体回测速度能提升 3-5 倍。
2.4 一张图看懂数据压缩的必要性
下面这张图，是我自己画的一个对比流程。左边是不压缩的路径，右边是压缩后的路径。你看看差距有多大。
2.5 总结一下
数据压缩的必要性，说白了就三点：
- 省存储：一年 12TB 变 1.2TB，省下的钱够买台新服务器
- 省带宽：80Mbps 变 15Mbps，同样的网络能跑更多品种
- 省时间：解析速度提升 10 倍，回测效率翻几番
嗯，这一章就聊到这。下一章我们具体看看，有哪些压缩算法适合订单簿数据，以及怎么选型。
公众号:蓝海数据掘金营，微信deep3321