Making Sense of Performance in Data Analytics Frameworks

Posted by CodingCat on March 17, 2015

花了半个下午的时间读了一下这篇论文[1]。这是一篇测量性的文章,写的很浅显易懂,所以实属快餐式的论文,但是揭示的道理,却让以后做大数据框架的人们多了一些思考的空间,而不是疯狂引用过去的结论。

在很长一段时间,学术界都有一个定论,数据处理框架的瓶颈主要来源于磁盘操作、网络传输和异常任务(Straggler),也产生了很多很多针对这三个问题做优化的paper。这篇来自于伯克利的paper对这三个瓶颈在spark上做了再一次的验证,并且证明,这三个瓶颈并不是主要的性能瓶颈。

具体的实验环境可以去参看原文的表1,本文的测量方法主要是去测量每个task block在不同资源(disk, network, straggler)上所花的时间。总结论文的结论

###Disk###

  1. 假如磁盘瓶颈完全不存在,Job的响应时间提升中值大约是19%,与之前的paper 所揭示的十几和几十倍的提升有较大的差距

  2. 相对磁盘的低负载,CPU是主要负载

  3. CPU高负荷磁盘低负载的原因有 1) 本文得出上述实验时存储的是压缩格式的数据,所以引入了CPU利用率换IO利用率的tradeoff; 2) 因为spark基于JVM,所以序列化反序列化带来的CPU开销不容忽视

  4. 过去的paper 哪里错了: 1) 在某paper[2]中,因为研究数据(Facebook cluster trace)的原因,作者假设computational job不需要任何复杂计算,而仅仅是排序或者类似word count这样的逻辑,2) 同一篇paper的测量有些问题,没有考虑在proposed的方法中因为避免了反序列化操作而减小的CPU负载

###Network###

  1. 假如网络瓶颈不存在,Job的响应时间提升中值大约是2%

  2. 相对网络的低负载,CPU仍然是主要负载

  3. 网络低负载的原因主要是: 在大多数情况下,通过网络传输的数据量都要比从文件系统读入的作为输入的数据量要小多了

  4. 过去的paper哪里错了: 1) 选用的workload非典型,都是多少数据读进来多少数据送出去 2) 之前的工作测量错了, 之前的工作把shuffle结束到任务结束的时间全部算成了用来网络传输输出数据的时间 [5] 3) 之前的测量没有考虑框架本身带来的负载,比如hadoop框架本身用于找shuffle数据的时间开销没有剔除出整体的”网络传输开销”[4]

###Straggler###

  1. 假如Straggler完全不存在,Job的响应时间大概能有5% - 10%

  2. 为什么与过去的paper结果不同: 1)一些经典的straggler工作,例如Mantri[3], 得到的性能提升除了straggler的消除外,其实有部分来来源于对重复计算的避免; 2) 不同的cluster size和trace带来的影响 3) 不同的框架带来的不同的并行粒度还有任务运行的开销,例如spark的任务启动开销比hadoop低得多并且任务数据通常也更多

  3. Straggler的原因: 1) 调度器延时; 2)HDFS磁盘拥塞; 3) shuffle写; 4) GC; 5) 输出偏移,某些任务输出得比较慢; 6)JIT优化启动延时,某一个stage的前一部分任务没享受到JIT的动态优化

  4. Straggler的原因是workload-dependent的

作者有一段话很好, there is much more work to be done before our community can claim to understand the performance of data analytics frameworks.

[1] http://www.eecs.berkeley.edu/~keo/publications/nsdi15-final147.pdf

[2] https://www.cs.berkeley.edu/~alig/papers/pacman.pdf

[3] http://research.microsoft.com/en-us/um/people/srikanth/data/mantri_osdi10.pdf

[4] http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p98.pdf

[5] http://research.microsoft.com/en-us/um/people/srikanth/data/sinbad_sigcomm13.pdf