1. 介绍

相信很多使用alluxio的同学,都是冲着其memory speed的加速效果而来。我也一样,认为只要用上了alluxio,整合了spark和hadoop就可以轻松把以前的JOB提升数倍的性能。然而,事实并不是这么顺利的。

今天主要就来总结下alluxio在提升MR job和Spark job性能上存在的问题和挑战。

2. 实验说明

2.1 实验环境

后面在说明问题的时候会贴一些实验结果。为了排除网络IO的影响,我这边的实验将hadoop、spark还有alluxio都部署在一台机器上。这台机器内存120G,40核。

2.2 实验方法

主要是做对比实验,一个使用alluxio,一个不使用alluxio,查看效果。

2.3 实验负载

为了让对比实验的结果差异尽量明显,在设计实验负载的时候,我们选取了能最大化发挥alluxio内存存储优势的实验负载。

我们运行一个只进行读取文本文件的job,来作为实验负载。这样的job主要性能瓶颈都是在IO上,可以保证内存存储带来最大效果。

3. MapReduce on alluxio

3.1 读取10G文件(1G split)

3.2 读取20G文件(1G split)

3.3 读取60G文件(1G split)

3.4 读取60G文件(512MB split)

4. Spark on Alluxio

这个可以拿Spark shell来测试,实验结果也是:alluxio没法带来成倍的性能提升。实际用alluxio和不用alluxio效果差不多。

5. 关于使用alluxio来提升性能的注意点

5.1 alluxio是否以memory speed来进行读写?

alluxio是否以内存的速度来进行读写?答案肯定是:YES。 当然前提是没有其他干扰(比如和hadoop这样的分布式计算引擎集成在一起,影响性能的因素是非常多的)。这里主要是单纯利用文件操作API读写和以MR JOB或者SPARK JOB形式读写的差别。这里给下结论:

  1. 纯文件系统下的测试和以JOB形式进行测试的区别
    a. 纯文件系统的API去读取文本文件,可以有预期的性能提升(8倍左右)。这时候是比较纯粹的测试,没干扰。
    b. job形式进行测试。生产使用的MR JOB修改后进行测试,都是基本差不多的(无论文本文件还是seq file)。因此需要分析其原因。

  2. JOB形式测试依赖 配置、JOB任务负载(不同的JOB,产生性能瓶颈的地方不同。要确保是IO密集型的JOB)

PS: 还有个坑,就是alluxio利用文件系统API来操作的时候,如果是sequence file格式的话,也是不会以memory speed来进行读写的。我怀疑开销可能是在解压缩上。因为我实验的sequence file data是有压缩的。欢迎大家反馈。

5.2 如何使用alluxio提升MR job性能?

要使用alluxio来提升性能也是可以,确保如下要求:

  1. 任务是IO密集型的JOB
  2. 参数配置符合要求
  3. split size要大(也就是说map个数要少),最起码split size 大于1G的纯IO密集型才可能体会到有性能提升

以上结论可以看我第三节的实验结果。但是实际操作中你会发现有很多问题,比如控制split size特别大,在调整配置的时候会引发各种问题。而且即使split size变大了,提升了单个map任务的读取速度了,但是却会在集群角度降低map的并发性能。

而且即使在完美情况下,恐怕也无法有成倍的性能提升(第三节的实验是纯粹的IO类JOB,也尽量采用了比较大的split size,也仍然只有50%左右性能提升)。至于为什么我没有采用更大的split size,是因为这样配置会引发其他的一些问题,导致集群不能正常工作。

5.3 如何使用alluxio提升Spark job性能?

实验跑了下line count job,统计数G文件的行数。不过测试出来也是性能差不多。耗时应该都在任务分片上了。所以使用spark on alluxio来提升性能也有如下要求:

  1. spark job是IO密集型的
  2. 最好是有很多spark job,并且不同job之间有RDD共享(alluxio提供的内存数据管理可以很好的管理热数据,从而增加内存命中率来改进性能)
  3. spark sql这种大表关联查询的场景貌似比较适合。因为查询的时候经常有一些中间结果集的共享。因此这种spark的大表的关联查询job估计使用alluxio能有效果~

6. 综上

想用alluxio来提升单个job的性能,基本上是比较难的,不建议。如果你们的使用场景,job比较多,内存资源比较有限的情况下,通过alluxio合理管理热数据,能有效改进性能。还有spark或者hive之类的大表关联查询,估计也有效果。其他场景应该比较难看到什么性能提升。

关于alluxio的应用场景,alluxio的作者其实也给出了总结:专访范斌,谈开源三年后的Alluxio

范斌: Alluxio作为一个内存级的虚拟分布式存储系统有几个常见的使用场景:

  1. 计算层需要反复访问远程(比如在云端,或跨机房)的数据;
  2. 计算层需要同时访问多个独立的持久化数据源(比如同时访问S3和HDFS中的数据);
  3. 多个独立的大数据应用(比如不同的Spark Job)需要高速有效的共享数据;
  4. 当计算层有着较为严重的内存资源、以及JVM GC压力,或者较高的任务失败率时,Alluxio作为输入输出数据的Off heap存储可以极大缓解这一压力,并使计算消耗的时间和资源更可控可预测。

实际例子:
Alluxio的目的就是想要让计算层和存储层可以再次轻装上阵,让它们独立的优化和发展自己,而不用担心破坏两者之间的依赖。具体说来,Alluxio提供一层文件系统的抽象给计算层。这层抽象之上的计算只需要和Alluxio交互来访问数据;而这层抽象之下可以同时对接多个不同的持久化存储(比如一个S3加上一个HDFS部署),而这层抽象本身又是由部署在靠近计算的内存级Alluxio存储系统来实现。一个典型的场景比如在百度,Spark不在需要关心数据是否是在本机房还是远程的数据中心,它只需要通过Alluxio中读写数据,而Alluxio可以聪明的帮助应用在需要时把数据同步到远端。

百度应用alluxio提升性能的主要原因:经过更深层次的发掘,我们发现了问题所在。由于数据分散分布在多个数据中心,有很大的可能是:数据的查询需要到达远程数据中心以提取数据——这应该是在用户运行查询时遇到延迟的最大原因。

这个可以参考文章:为了应对数据大爆炸 百度投向了这个开源新项目

我想alluxio之所以作为acceleration layer来说不够称职,其原因可能就是并没有去为MapReduce和Spark去实现自己的alluxio native acceleration layer. 说到希望给计算JOB做这种即插即用的内存加速,可以考虑使用ignite。 我也写了相关文章比较了ignite和alluxio,可以关注下。

再做个友情提醒: 使用alluxio需要仔细看看上述场景是否符合你们的使用场景。想和MR和Spark集成,利用内存来加速job处理的,不妨考虑下Apache ignite,我最近会玩玩试试效果