Hadoop一出生就是存儲與計算在一起的，前幾年面試題中都問，Hadoop怎麼保證高性能呢？其中一個原因是存儲不動，計算(code)動，不同于傳統的集中式的存儲模式。那我們為什麼還要談存儲計算分離呢？衆觀曆史，分久必合、合久必分，在計算機曆史中也很類似，如今，也許到了計算與存儲分離的階段。後面我們以實際的case說明，分離的好處與劣勢。
為什麼呢？
先說一個筆者的，也應該是大家的經曆：筆者家裡的帶寬是100mpbs，現在從來不儲存電影，要看直接下載下傳，基本幾分鐘就好了。這在幾年前不可想象。
筆者也在
《雲上Hadoop之挑戰》中分析了其中的挑戰，其中有本地化的挑戰：
帶寬的速度，特别是機房内帶寬的速度，已經從1000mps、2000mps、10000mps，甚至100000mpbs。但是磁盤的速度基本沒有太大的變化。
因為硬體的變化，帶來了軟體架構的變化。
基本架構
架構其實比較簡單，OSS作為預設的存儲，Hadoop、Spark可以作為計算引擎直接分析OSS存儲的資料。
以上比較了計算與存儲分離的優缺點。
- 靈活性：在 《E-MapReduce(Hadoop)10大類問題之叢集規劃》 一文中分析了叢集規劃問題，關鍵是比對計算量與存儲量，如果把計算與存儲分離後，則 叢集規劃則變得簡單很多，基本不需要估算未來業務的規模了，真正做到按需使用。
- 成本：存儲與計算分離後。按照 1 master 8cpu32g 6 slave 8cpu32g 10T資料量 估算大緻為，成本下降一倍。在ecs自建的磁盤選擇 高效雲盤。
- 性能：大約下降10%以内，對于一般的應用是可以接受的。後續詳細說明。
場景測試及資料
- 測試的代碼為： https://github.com/fengshenwu/spark-terasort/tree/master/src/main/scala/com/github/ehiggs/spark/terasort
- 叢集規模：1 master 4cpu 16g 、8 Slave 4cpu 16g、每個slave節點250G*4 高效雲盤
- 測試spark腳本
/opt/apps/spark-1.6.1-bin-hadoop2.7/bin/spark-submit --master yarn --deploy-mode cluster --executor-memory 3G --num-executors 30 --conf spark.default.parallelism=800 --class com.github.ehiggs.spark.terasort.TeraSort spark-terasort-1.0-jar-with-dependencies.jar /data/teragen_100g /data/terasort_out_100g
- 測試的性能圖
E-MapReduce支援計算與存儲分離,成本下降1倍
- 時間對比
E-MapReduce支援計算與存儲分離,成本下降1倍
分析
我們可以看到，emr+oss後，成本節約了一半，但是性能下降基本可以忽略不計。從性能圖上看，emr+oss對比ecs自建hadoop對比：
- 整體的負載更低
- 記憶體使用率基本一樣
- cpu使用低一些，特别是iowait與sys低很多，這是因為ecs自建有datanode及磁盤操作，需要占一些資源，增加cpu的開銷。
- 從網絡看，因為sortbenchmark有兩次讀取資料，第一次是采樣、第二次是真正的讀取資料，開始網絡比較高，随後shuffle+輸出結果階段，網絡比ecs自建hadoop低一半左右，從網絡來看，整體使用量基本持平。
也就是整體來講，emr+oss比自建使用更少的資源，如果提高emr+oss的并發度，則時間上有可能超過ecs自建hadoop叢集的。
哪些場景不适合
并不是所有的場景都适合使用emapreduce+oss，對于以下場景目前不适合：
- 過多的 小的檔案，比如小于10m，請合并小檔案，當資料量在128m以上，使用emr+oss的性能最佳。
- 頻繁操作OSS中繼資料的操作，此塊emr+oss正在優化，目前并不太适合。
- 阿裡官方“HBase生态+Spark社群大群”點選加入：
https://dwz.cn/Fvqv066s