亚马逊将自有服务数据的压缩从 Gzip 切换为 Zstd

作者 | Renato Losio

译者 | 平川

策划 | 丁晓昀

最近，亚马逊前副总裁 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 通信。

以下是用户 treffer 在 Hacker News 上的评论：

速度特别快的压缩算法（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/