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形式读写的差别。这里给下结论：
纯文件系统下的测试和以JOB形式进行测试的区别
a. 纯文件系统的API去读取文本文件，可以有预期的性能提升（8倍左右）。这时候是比较纯粹的测试，没干扰。
b. job形式进行测试。生产使用的MR JOB修改后进行测试，都是基本差不多的（无论文本文件还是seq file）。因此需要分析其原因。JOB形式测试依赖 配置、JOB任务负载（不同的JOB，产生性能瓶颈的地方不同。要确保是IO密集型的JOB）
PS： 还有个坑，就是alluxio利用文件系统API来操作的时候，如果是sequence file格式的话，也是不会以memory speed来进行读写的。我怀疑开销可能是在解压缩上。因为我实验的sequence file data是有压缩的。欢迎大家反馈。
5.2 如何使用alluxio提升MR job性能?
要使用alluxio来提升性能也是可以，确保如下要求：
- 任务是IO密集型的JOB
- 参数配置符合要求
- 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来提升性能也有如下要求：
- spark job是IO密集型的
- 最好是有很多spark job，并且不同job之间有RDD共享（alluxio提供的内存数据管理可以很好的管理热数据，从而增加内存命中率来改进性能）
- spark sql这种大表关联查询的场景貌似比较适合。因为查询的时候经常有一些中间结果集的共享。因此这种spark的大表的关联查询job估计使用alluxio能有效果~
6. 综上
想用alluxio来提升单个job的性能，基本上是比较难的，不建议。如果你们的使用场景，job比较多，内存资源比较有限的情况下，通过alluxio合理管理热数据，能有效改进性能。还有spark或者hive之类的大表关联查询，估计也有效果。其他场景应该比较难看到什么性能提升。
关于alluxio的应用场景，alluxio的作者其实也给出了总结：专访范斌，谈开源三年后的Alluxio
范斌： Alluxio作为一个内存级的虚拟分布式存储系统有几个常见的使用场景：
- 计算层需要反复访问远程（比如在云端，或跨机房）的数据；
- 计算层需要同时访问多个独立的持久化数据源（比如同时访问S3和HDFS中的数据）；
- 多个独立的大数据应用（比如不同的Spark Job）需要高速有效的共享数据；
- 当计算层有着较为严重的内存资源、以及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，可以关注下。