最近，亚马逊前副总裁Adrian Cockcroft在推文中特别指出了从 gzip 切换到 Zstandard 压缩所带来的好处，这在社区中引发了关于压缩算法的讨论。其他大公司，包括 Twitter 和 Honeycomb，也分享了使用 zstd 获得的收益。
最近，Dan Luu分析了推特存储节省的情况，并在推特上发起了一场对话：
我想知道 Yann Collect 创建 zstd 到底消除了多少浪费。我估算了下 Twitter 的数值（与大型科技公司相比微不足道），从 HDFS 切换到 zstd 每年节省的数量大约为 8 位数的中值。在世界范围内（非年化），这个数值应该不低于 9 位数？
Cockcroft 回复说：
亚马逊从 gzip 切换到 zstd，压缩 S3 存储量减少了大约 30%，达艾字节的规模。
Zstandard（其 C 语言实现 zstd 更为知名）是由 Facebook 公司的Yann Collet开发的无损数据压缩算法，在多种数据集上提供了很高的压缩比和非常好的性能。该参考实现库是一个遵循 BSD 许可的开源软件，它提供了一个速度极快的解码器，允许我们在速度和压缩比之间做大范围权衡。
起初，Cockcroft 的表述在社区中引发了质疑，一些开发人员询问亚马逊如何在 S3 上压缩客户数据。亚马逊一名内部员工澄清道：
Adrian 说错了，或许是所有人都误解了他的意思。他的意思并不是说 S3 改变了存储压缩客户数据的方式。他的意思是亚马逊改变了在 S3 中存储自有服务数据（主要是日志）的方式——从 gzip 日志切换到 ztsd 日志，我们（作为 S3 的一个客户）能够将 S3 存储成本降低 30%。
Honeycomb 首席开发者大使Liz Fong-Jones赞同切换到 zstd：
我们不把它用于列文件，因为那太慢了，但我们把它用于 Kafka（…），在生产环境中从 snappy 切换到 zstd 后，Honeycomb 节省了 25%的带宽。（…）不仅仅是存储和计算，对我们来说，是网络。亚马逊跨 AZ 的数据传输非常昂贵。
在Reddit一个热门的帖子中，noirknight 是众多提供正反馈的用户之一：
我的公司几年前也做过类似的事情，也看到了类似的好处。只要可能，我们都使用 zstandard，不仅仅是存储，还有其他东西，比如内部 HTTP 通信。
速度特别快的压缩算法（zstd、lz4、snappy、lzo……）是值得我们付出 CPU 成本的，而且几乎没有什么缺点。问题在于找到最佳契合点，在不产生 CPU 瓶颈的情况下减少当前的瓶颈，不过在这方面，zstd 也提供了最大的灵活性。
亚马逊在一些托管服务的 API 中公开了 Zstandard 和对其他压缩算法的支持。例如，在Amazon Redshift中引入Zstandard支持后，这家云提供商针对云数据仓库开发了自己的算法AZ64。按照他们的说法，其专有压缩算法比 zstd 编码节省 5-10%的存储空间，并且速度快 70%。
亚马逊官方没有就其内部数据使用的压缩技术或相关的 S3 存储节省发表任何评论。
原文链接：
https://www.infoq.com/news/2022/09/amazon-gzip-zstd/
相关阅读：
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论