开源压缩工具 bzip3 把自己定位成 BZip2 的"精神继承者"——不是官方续作,也不是格式兼容的升级版,而是用一套新算法组合去补BZip2压缩率上的短板。项目作者拿CPAN上能下载到的每一个Perl5历史版本源码打包测试,结果显示bzip3的压缩后体积能小于xz、bzip2和Zstandard,但换来的代价是最快配置下要吃掉12GB到18GB内存。这组数字定义了bzip3现在的真实位置:压缩率数据好看,迁移门槛也不小。
bzip3在GitHub上以LGPLv3发布,部分底层组件另用Apache 2.0和BSD许可。核心是三段式流水线:Burrows-Wheeler变换重排数据,结合LZ77字符串匹配与PPM上下文建模的LZP做预处理,最后用0阶上下文混合熵编码器压缩。作者称这套组合尤其擅长处理文本和代码——这恰好是BZip2当年最被诟病的地方:压缩率不算高,胜在简单可靠。
压缩率赢了,内存账单也涨了
作者的测试方法很直接:把历代Perl5源码全部解压,打包成一个tar文件,再分别用不同工具压缩。结果按体积从大到小排:bzip2压缩后是3.44GB,Zstandard是3.08GB,xz是2.06GB,bzip3用256KB块、12线程压到1.00GB,换成511MB块、4线程后进一步压到546MB——是bzip2的六分之一,比xz小接近四倍。
体积小的代价写在同一份日志里:bzip3用511MB块压缩时占用12GB内存,256KB块、12线程时占用18GB;相比之下,bzip2全程只用8MB,zstd用687MB,xz用16线程也要吃到14.7GB。bzip3把内存开销拉到了新量级,这在压缩率对比表里通常不会单独标出来,却决定了它能不能上普通生产机器。
解压速度上bzip3没有掉队:并行解压耗时4分06秒,比xz的4分40秒略快,只比zstd的3分51秒慢一点,比bzip2的9分22秒快了一倍多。压缩速度这次没有直接对比价值——不同工具用的线程数和块大小差异很大,作者自己也承认参数选择直接决定最终结果。
压缩率是账面数字,内存账单才是落地门槛
谁该看这组数字,谁不该照搬
先说清楚这组基准的边界。测试语料是历代Perl5源码合集,不同版本之间大量代码是重复的,这种高重复率的语料本来就是压缩算法的理想考场。作者自己还补了一组对照:先用lrzip对原始tar文件做长程去重,再用bzip3压缩去重后的结果,最终体积压到60.67MB,比lrzip+xz的64.77MB和lrzip+bzip2的75.69MB都小——但这是"去重+bzip3"组合的成绩,不是bzip3单独压缩的数字,两者不能混着引用。
日常代码仓库、日志文件、生产数据库转储的重复模式和这份Perl归档不一样,直接把这组数字套到别的场景,大概率拿不到同样的压缩比。项目文档里还有一条容易被忽略的免责声明:bzip3算法复杂度和特殊情况处理,使得极低概率的数据不可恢复风险无法完全排除,作者明确要求用户压缩关键数据前接受这个可能性。
- 风险.关键归档不要只留bzip3压缩后的单一副本,至少保留原始数据或另一份独立备份。
对维护代码仓库、日志和冷数据归档的团队来说,现实的做法是先用自己的真实语料跑一遍bzip3,再决定要不要换。追求低内存占用、追求和现有工具链的成熟兼容性,或者追求高吞吐量的场景,压缩率这一项指标不足以构成迁移bzip2、xz或Zstandard的理由——bzip3目前更像一个高压缩率的可选项,不是全面替代品。