背景
在傳統Hadoop的使用中,儲存與計算密不可分,而隨著業務的發展,叢集的規模常常不能滿足業務的需求。例如,數據規模超過了叢集儲存能力,業務上對數據產出的周期提出新的要求導致計算能力跟不上。這就要求我們能隨時應對叢集儲存空間不足或者計算能力不足的挑戰。
如果將計算和儲存混合部署,常常會因為為了擴儲存而帶來額外的計算擴容,這其實就是一種浪費;同理,只為了提升計算能力,也會帶來一段時期的儲存浪費。
將離線計算的計算和儲存分離,可以更好地應對單方面的不足。把數據全部放在OSS中,再通過無狀態的E-MapReduce分析。E-MapReduce只需進行純粹的計算,不存在儲存跟計算搭配來適應業務了,這樣最為靈活。
架構
離線計算的儲存和計算分離架構簡單,如下圖所示。OSS作為預設的儲存,Hadoop/Spark作為計算引擎直接分析OSS儲存的數據。
優勢
因素 | 計算和儲存不分離 | 計算和儲存分離 |
---|---|---|
靈活性 | 不靈活 | 計算與儲存分離後,叢集規劃簡單靈活,基本不需要估算未來業務的規模,做到按需使用。 |
成本 | 高 | 在ECS自建的磁碟選擇高效雲盤,以1 master 8 cpu32g/6 slave 8 cpu32g/10T數據量為例進行估算,儲存與計算分離後,成本下降一倍。 |
性能 | 較高 | 至多下降10%。 |
案例測試
- 測試條件
詳細的測試代碼請參見GitHub。
叢集規模: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
- 測試結果
- 性能
- 成本
- 時間
- 性能
- 結果分析
從性能圖上看,EMR+OSS相較於ECS自建Hadoop,有如下優勢:
-
整體的負載更低。
-
記憶體利用率基本一樣。
-
CPU使用低,其中iowait與sys低很多。因為ECS自建有datanode及磁碟操作,需要佔一些資源,增加CPU的開銷。
-
從網路看,因為sortbenchmark有兩次讀取數據,第一次是採樣,第二次是真正的讀取數據,開始網路比較高,隨後shuffle+輸出結果階段,網路比ECS自建Hadoop低一半左右。因此從網路來看,整體使用量基本持平。
綜上所述,EMR+OSS比自建ECS使用更少的資源,成本節約了一半,但是性能下降基本可以忽略不計。並且,如果提高EMR+OSS的並發度,則時間上有可能比ECS自建Hadoop叢集更有優勢。
-
不適用的場景
以下場景不建議使用EMR+OSS:
-
小檔案過多的場景。
如果檔案小於10M時,請合并小檔案。當數據量在128M以上時,使用EMR+OSS的性能最佳。
-
頻繁操作OSS元數據的場景。