最近,亚马逊前副总裁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/
相关阅读:
评论