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，可以關注下。