最近一直在研究alluxio,希望其能够和hive,spark，hbase集成在一起，达到更快的运行速度，提高性能；但从目前情况来看，想用alluxio提升某个具体应用的性能，不大现实。从网上查找的资料分析，应用比较广泛的几家大公司比如：百度，去哪儿--都是建立在多个数据中心提取远程数据的前提下才大幅度提升的性能。
在此，把相关涉及的资料mark下，免得忘记，也给朋友们分享下，少走点弯路。
alluxio的应用场景--(参考文章：专访范斌，谈开源三年后的Alluxio) 范斌(alluxio公司的工程师)
Alluxio作为一个内存级的虚拟分布式存储系统有几个常见的使用场景：
- 计算层需要反复访问远程（比如在云端，或跨机房）的数据；
- 计算层需要同时访问多个独立的持久化数据源（比如同时访问S3和HDFS中的数据）；
- 多个独立的大数据应用（比如不同的Spark Job）需要高速有效的共享数据；
- 当计算层有着较为严重的内存资源、以及JVM GC压力，或者较高的任务失败率时，Alluxio作为输入输出数据的Off heap存储可以极大缓解这一压力，并使计算消耗的时间和资源更可控可预测。
架构设计目标以及案例：
Alluxio的目的就是想要让计算层和存储层可以再次轻装上阵，让它们独立的优化和发展自己，而不用担心破坏两者之间的依赖。具体说来，Alluxio提供一层文件系统的抽象给计算层。这层抽象之上的计算只需要和Alluxio交互来访问数据；而这层抽象之下可以同时对接多个不同的持久化存储（比如一个S3加上一个HDFS部署），而这层抽象本身又是由部署在靠近计算的内存级Alluxio存储系统来实现。一个典型的场景比如在百度，Spark不在需要关心数据是否是在本机房还是远程的数据中心，它只需要通过Alluxio中读写数据，而Alluxio可以聪明的帮助应用在需要时把数据同步到远端。
百度应用--（参考文章：为了应对数据大爆炸
百度投向了这个开源新项目）
个人感觉百度应用alluxio提升性能的主要原因：经过更深层次的发掘，我们发现了问题所在。由于数据分散分布在多个数据中心，有很大的可能是：数据的查询需要到达远程数据中心以提取数据——这应该是在用户运行查询时遇到延迟的最大原因。该场景正好符合了alluxio的应用场景，使得性能大幅度提高。