前言

在云上運行Hadoop，很多人擔心性能。因為一提到虛擬化就會有人想到有成本，往往得出有偏見的結論-在云上運行肯定比物理機器上運行性能差。如果單獨把10臺物理機虛擬化跑Hadoop，這肯定是有部分性能的開銷的。但是如果在公共云上，情況就不是這樣了。因為公共云虛擬化的開銷最終是由平臺方來承擔的，其一是平臺方采購機器有規(guī)模優(yōu)勢，其二平臺方可以在保證虛擬機性能的情況超賣部分資源。

平臺賣給用戶8core32g的虛擬機就保證有這個規(guī)格的能力的。結合云上的彈性優(yōu)勢，企業(yè)的總體成本是會下降的。

在云上運行Hadoop對平臺方還是面臨一些挑戰(zhàn)的，下面主要講述這些挑戰(zhàn)及平臺方怎么解決的。

[[167090]]

云上Hadoop的挑戰(zhàn)-Shuffle

Shuffle分為Push模式，Pull模式。Push模式就是直接通過網(wǎng)絡發(fā)送到下一個節(jié)點，比如：storm、flink。Pull模式就是數(shù)據(jù)先存儲在本地，再啟動下一個節(jié)點拉取數(shù)據(jù)，比如：Hadoop MR、Spark。

在push模式下，主要瓶頸點是網(wǎng)絡。在一般的云環(huán)境中，網(wǎng)絡跟線下沒有太多的區(qū)別，可以滿足需求。

在pull模式下，主要瓶頸點是磁盤。在云環(huán)境中，會提供本地磁盤或者用SDD加速的方案。如下：

另外：

根據(jù)spark社區(qū)的報告，在機器學習等很多場景下，瓶頸點現(xiàn)在是CPU了

云上Hadoop的挑戰(zhàn)-數(shù)據(jù)本地化

數(shù)據(jù)本地化含義是分析時，把計算移動到數(shù)據(jù)節(jié)點的。如果計算存儲分離，則存在數(shù)據(jù)放在OSS中，需要從OSS遠程拉取數(shù)據(jù)。一般情況下，認為這樣會有性能問題。

當前，網(wǎng)絡的帶寬發(fā)展非?？欤?/p>

從09年到16年對比，大約帶寬提升100倍左右，讓大家影響深刻的是家庭帶寬從4Mbps到了100Mbps了，4G也流行起來了，筆者現(xiàn)在基本不在電腦上存放電影，直接在線看的?，F(xiàn)在很多機房在做100Gbps點到點的帶寬。磁盤本身并沒有太大的吞吐量的提升。還可以采取壓縮算法把存儲量減少。在 ETL場景下，往往只需要晚上運行數(shù)個小時，對性能本身不是太敏感;機器學習場景需要內存緩存數(shù)據(jù);流式計算本身數(shù)據(jù)在移動的。

整體來講，會隨著帶寬的增加、業(yè)務場景的實時化、多元化，數(shù)據(jù)本地化不是必須的。

云上Hadoop的挑戰(zhàn)-自動化運維

作業(yè)的管理、任務編排、監(jiān)控、報警這些基本功能都還好。Hadoop本身非常復雜，如果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評分，給出***寫法

分析存儲，比如：指明是否需要壓縮;小文件是否過多，是否需要合并;訪問記錄分析，是否可以把冷數(shù)據(jù)歸檔處理

分析運行時各種JOB統(tǒng)計信息，如：Job的map時間是否過小，運行時reduce是否數(shù)據(jù)傾斜，單個job是否有一些參數(shù)調整

這個主要是針對存儲、作業(yè)調優(yōu)的，優(yōu)化性能之類的。在一般企業(yè)內部是沒有這套系統(tǒng)的。云上可以做成一套這樣的系統(tǒng)，幫助廣大的中小企業(yè)