最近一直在研究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的應用場景，使得性能大幅度提高。