论文一:Dropbox JPEG图片压缩系统

Jacky
Jacky
Aug 9, 2017 · 4 min read

论文链接:https://www.usenix.org/system/files/conference/nsdi17/nsdi17-horn-daniel.pdf NSDI17

文章很直接但是不简单,Dropbox发现在手机中的硬件图像编码的压缩率并不高,导致浪费了他们的存储,因此他们决定自己搞一个图像压缩格式。

结果就是他们省下了超过46PiB的存储,恩相当大的一个数字了。一张图片的大小在几个或者几十MB,中间差了正好3个1024。

这种努力肯定有很多人做过,也有很多的更高压缩率的方案,那么为什么他们要自己搞一个呢?他们在论文中进行了很好的解释,首先他们提出了一些要求:

1.对于用户的透明,作为一个云盘,有必要保持用户文件的完整性,用户上传和下载的文件必须是一致的,即使这个文件是损坏的。

2.要有很好的分布性,这样可以容错,也可以很好的兼容当前的分布式存储系统。他们的分布式存储是以4MB为单位的。

3.要有很小的延迟,并且可以以streaming的形式进行解压,因为如果不是这样的话用户体验太差了。

4.为了减小内存占用,需要按照行来读取文件,并不希望把整个文件放到内存里面再解压

那为啥当前的方式不好使呢?他们有以下分析:

1.现有的通用压缩方案,比如说rar格式,是基于熵编码的,对于JPEG这种已经编码了的格式并没有很好的压缩率,平均压缩效果小于1%(虽然我可以肯定就算是1%的压缩率也可以节省相当一部分的存储)

2.有损的压缩,这种就纯属于占篇幅、堵漏洞的假设,Dropbox又不是什么论坛、朋友圈,作为一个网络云盘是不敢修改用户文件的,否则他们就要修改自己的用户协议了。

3.有一些工具可以解压源JPEG并且进行重新编码,这样就可以保证照片的像素级一致。新编码后的文件与源文件显然是不符的,虽然可以解压再用原格式编码,但是这样需要两步,对于系统的开销太大。

4.现有的一些对于图像原格式保存的压缩方案,没有3的缺点,可以达到23%的压缩率,但是并行化之类的做的并不好(显然是因为没有这种需求……)

综上所述,他们需要自己做。

有一些很tricky的事情,他们需要一个实时解压的格式,但是并不需要实时压缩,因为前者会影响用户下载,但是后者并不会影响用户上传。

对于具体的格式文章并没有介绍很仔细(估计也没人会看)

性能测试:首先是压缩率和速度,图标都是用gnuplot画的bar graph,用了三种,bar+stddev,bar,bar+50/75/95/99 percentile。我觉得第三种还是很有意思的,很直观。接下来是内存占用

作者将大规模部署放到了evaluation后边,首先要解决的就是安全问题,作者表示要保证程序的确定性和安全性。C++经过了编译器的高度优化很难保证安全和确定性,Java和Rust这种更安全的语言效率又不够高。最终采用了linux下的secure computing mode。在这个模式下面只能进行读、写操作,退出和返回。不能新建文件,申请内存,开新的进程。因此需要预先分配内存,进程之间的管道。

可以看出Dropbox的流量还是很大的,已经处理了几千亿张图片,他们的测试也是在十亿量级的。

他们的服务器为了高并发优化过,因此不是很适合处理这种高CPU利用,低内存占用的任务。因此他们需要将计算任务交给别人,采用的是远程的方式,我觉得跟RPC的感觉差不多。同样还需要处理之前已经存储的照片,这时候就需要用到空闲的时间。

这种用计算换存储的方式相当于花电费省下磁盘钱,然而电费是相当便宜的。就算不考虑冗余等等操作,也可以省2/3的钱。另外,看起来丹麦的电费最贵,作者还吐槽了2333333。

接下来就是为了填满页数的种种了。

PS:发现这种方式能督促自己读论文读的很仔细,感觉还不错

    Jacky

    Written by

    Jacky