中國IDC圈6月15日報道，在云上運行Hadoop，很多人擔(dān)心性能。因為一提到虛擬化就會有人想到有成本，往往得出有偏見的結(jié)論-在云上運行肯定比物理機器上運行性能差。確實，在云上運行Hadoop對平臺方還是面臨一些挑戰(zhàn)的，下面主要講述這些挑戰(zhàn)及平臺方怎么解決的。
前言
在云上運行Hadoop，很多人擔(dān)心性能。因為一提到虛擬化就會有人想到有成本，往往得出有偏見的結(jié)論-在云上運行肯定比物理機器上運行性能差。如果單獨把10臺物理機虛擬化跑Hadoop，這肯定是有部分性能的開銷的。但是如果在公共云上，情況就不是這樣了。因為公共云虛擬化的開銷最終是由平臺方來承擔(dān)的，其一是平臺方采購機器有規(guī)模優(yōu)勢，其二平臺方可以在保證虛擬機性能的情況超賣部分資源。
平臺賣給用戶8core32g的虛擬機就保證有這個規(guī)格的能力的。結(jié)合云上的彈性優(yōu)勢，企業(yè)的總體成本是會下降的。
在云上運行Hadoop對平臺方還是面臨一些挑戰(zhàn)的，下面主要講述這些挑戰(zhàn)及平臺方怎么解決的。
云上Hadoop的挑戰(zhàn)-Shuffle
Shuffle分為Push模式，Pull模式。Push模式就是直接通過網(wǎng)絡(luò)發(fā)送到下一個節(jié)點，比如：storm、flink。Pull模式就是數(shù)據(jù)先存儲在本地，再啟動下一個節(jié)點拉取數(shù)據(jù)，比如：Hadoop MR、Spark。
在push模式下，主要瓶頸點是網(wǎng)絡(luò)。在一般的云環(huán)境中，網(wǎng)絡(luò)跟線下沒有太多的區(qū)別，可以滿足需求。
在pull模式下，主要瓶頸點是磁盤。在云環(huán)境中，會提供本地磁盤或者用SDD加速的方案。如下：
另外：
根據(jù)spark社區(qū)的報告，在機器學(xué)習(xí)等很多場景下，瓶頸點現(xiàn)在是CPU了
云上Hadoop的挑戰(zhàn)-數(shù)據(jù)本地化
數(shù)據(jù)本地化含義是分析時，把計算移動到數(shù)據(jù)節(jié)點的。如果計算存儲分離，則存在數(shù)據(jù)放在OSS中，需要從OSS遠程拉取數(shù)據(jù)。一般情況下，認為這樣會有性能問題。
當(dāng)前，網(wǎng)絡(luò)的帶寬發(fā)展非常快：
從09年到16年對比，大約帶寬提升100倍左右，讓大家影響深刻的是家庭帶寬從4Mbps到了100Mbps了，4G也流行起來了，筆者現(xiàn)在基本不在電腦上存放電影，直接在線看的?，F(xiàn)在很多機房在做100Gbps點到點的帶寬。磁盤本身并沒有太大的吞吐量的提升。還可以采取壓縮算法把存儲量減少。在 ETL場景下，往往只需要晚上運行數(shù)個小時，對性能本身不是太敏感;機器學(xué)習(xí)場景需要內(nèi)存緩存數(shù)據(jù);流式計算本身數(shù)據(jù)在移動的。
整體來講，會隨著帶寬的增加、業(yè)務(wù)場景的實時化、多元化，數(shù)據(jù)本地化不是必須的。
云上Hadoop的挑戰(zhàn)-自動化運維
作業(yè)的管理、任務(wù)編排、監(jiān)控、報警這些基本功能都還好。Hadoop本身非常復(fù)雜，如果Hadoop本身出現(xiàn)點什么問題，則會影響作業(yè)的運行。
這些問題包括但是不僅限于：
Master掛 各種日志清理等 節(jié)點掛掉，自動補回 Datanode掉線處理 NodeManager掉線處理 Job運行監(jiān)控報警 負載過高監(jiān)控報警 節(jié)點數(shù)據(jù)均衡 單節(jié)點擴容 版本自動升級 重要數(shù)據(jù)備份 Hbase等指標監(jiān)控報警 Storm等指標監(jiān)控報警
我們需要自動化診斷這些問題并在用戶、平臺的共同參與下把這些問題解決。
云上Hadoop的挑戰(zhàn)-專家建議
是否需要擴容
Hive SQL，可以給SQL評分，給出最優(yōu)寫法
分析存儲，比如：指明是否需要壓縮;小文件是否過多，是否需要合并;訪問記錄分析，是否可以把冷數(shù)據(jù)歸檔處理
分析運行時各種JOB統(tǒng)計信息，如：Job的map時間是否過小，運行時reduce是否數(shù)據(jù)傾斜，單個job是否有一些參數(shù)調(diào)整
這個主要是針對存儲、作業(yè)調(diào)優(yōu)的，優(yōu)化性能之類的。在一般企業(yè)內(nèi)部是沒有這套系統(tǒng)的。云上可以做成一套這樣的系統(tǒng)，幫助廣大的中小企業(yè)