2. 压缩存储格式评价指标体系构建

逐笔数据压缩格式的选型，不能只看“压缩率有多高”。一笔逐笔成交或委托记录通常包含证券代码、时间戳、价格、数量、买卖方向、序号等字段，单条记录只有几十字节，但每天动辄数千万到上亿条。压缩率、解压速度、随机读取性能、写入吞吐、格式兼容性和生态工具支持这六个维度，彼此之间存在明显的此消彼长关系：列式编码往往压缩率高但随机读取需要额外索引，通用压缩算法兼容性好但解压速度未必满足回放要求。因此本节要做的，是把这些维度转化为可量化、可复现的比较框架，并明确在逐笔数据场景下各指标的权重与测试方法。

六个维度的量化定义

先明确每个指标的计算口径，避免不同格式之间“各说各话”。

• 压缩率：以原始未压缩字节数为分母，压缩后字节数为分子，取比值 R = 原始大小 / 压缩后大小，或等价地报告压缩后占原始大小的百分比。必须注明是否包含索引、元数据和文件头开销，否则列式格式容易因忽略索引而虚高。
• 解压速度：单位时间内解压出的原始字节数或记录数，单位 MB/s 或 万条/s。测试时应区分“全量顺序解压”和“按块解压”两种口径。
• 随机读取性能：给定任意一条记录序号或时间区间，定位并取出目标记录所需的平均延迟（μs 或 ms），以及每秒可完成的随机读取次数（IOPS）。这是逐笔回放和按时间段抽查的关键指标。
• 写入吞吐：单位时间内完成压缩并落盘的原始数据量，单位 MB/s 或 万条/s，需注明是单线程还是多线程、是否含 fsync。
• 格式兼容性：格式能否被主流语言和计算引擎直接读取，是否需要专用库，跨版本、跨平台的稳定程度。可用“可直接读取的目标系统数量”做半定量打分。
• 生态工具支持：命令行工具、Python/Java/C++ 客户端、与 Spark、DuckDB、ClickHouse 等分析引擎的集成成熟度，以及社区活跃度和文档完备度。

逐笔数据场景下的权重分配

权重不能拍脑袋，要回到逐笔数据的真实使用模式。逐笔数据主要有三类负载：一是历史回放与策略回测，需要按时间顺序高速顺序解压，解压速度权重最高；二是按时间段或按证券抽查，需要快速定位，随机读取性能权重上升；三是每日入库归档，写入吞吐和压缩率共同决定存储成本与落盘窗口。兼容性和生态工具支持则影响接入成本与长期维护。

据此给出一个可调整的参考权重（合计 100%）：解压速度 25%、压缩率 20%、随机读取性能 20%、写入吞吐 15%、格式兼容性 10%、生态工具支持 10%。若团队以回测为主，可把解压速度上调至 30%、压缩率下调至 15%；若以长期归档为主，则压缩率上调至 30%、解压速度下调至 15%。权重必须在测试前确定并记录，避免看到结果后反向调权。

测试方法与可复现的示例参数

为了让不同格式可比，测试必须固定数据集、硬件和测量口径。以下参数为教学示例，用于说明测试设计，并非真实实测结果。

数据集：某A股逐笔成交 1 个交易日
  记录数：约 3200 万条
  单条原始大小：约 48 字节（代码6 + 时间4 + 价格4 + 数量4 + 方向1 + 序号4 + 预留）
  原始总大小：约 1.5 GB
硬件：单机 8 核 / 32 GB 内存 / NVMe SSD
测量：每项指标预热 1 次，正式测 5 次取中位数

压缩率测试：分别记录压缩后文件总大小（含索引文件、元数据 JSON），计算 1.5 GB / 压缩后大小。若某格式把索引单独存放，必须一并计入，否则比较失真。

解压速度测试：从磁盘读取压缩文件，完整解压为内存中的记录流，记录耗时，换算为 MB/s 和 万条/s。为排除磁盘缓存干扰，每次测试前清空页缓存或使用不同文件副本。

随机读取测试：随机生成 1 万个记录序号，逐个定位并读取目标记录，统计平均延迟和 P99 延迟。对不支持单条定位的格式，退化为“按最小可读块读取”，并在报告中注明块大小，这是公平比较的前提。

写入吞吐测试：从原始记录流读入，经压缩编码写入新文件，统计端到端耗时。单线程与多线程分别报告，并注明是否调用 fsync。

兼容性与生态：采用半定量打分。能直接被 Python、Java、C++ 及至少一种分析引擎（如 DuckDB、Spark）读取的，每满足一项计 1 分，满分 5 分；需要专用库或额外转换步骤的相应扣分。生态工具支持按“官方 CLI + 至少两种语言客户端 + 文档完整”打分，满分 5 分。

综合评分与结果判读

各指标量纲不同，需先归一化再加权。对“越大越好”的指标（压缩率、解压速度、写入吞吐、兼容性、生态）采用 得分 = 100 × 实测值 / 候选最大值；对“越小越好”的随机读取延迟，采用 得分 = 100 × 最小延迟 / 实测延迟。最后按权重求和得到 0–100 的综合分。

把上述框架固化为一张可填写的比较表，就能在引入新格式时快速复用：固定数据集与硬件，按六维口径采集原始值，归一化后加权，得到可解释、可复核的选型结论。权重随业务负载调整，但调整必须发生在测试之前，并随报告一同归档。