Hadoop擴(kuò)展是一個(gè)非常復(fù)雜的過程，這里羅列了7種常見問題和解決方案。

所有Hadoop實(shí)施都存在著潛在的危機(jī)，包括一些非常棘手的Hadoop運(yùn)行問題。這類問題出現(xiàn)在投入生產(chǎn)環(huán)境前會(huì)導(dǎo)致Hadoop被棄用，但是如果發(fā)生在投入生產(chǎn)環(huán)境后，則意味著一場“成功的災(zāi)難”(其實(shí)更有可能是一場純粹的災(zāi)難)。

Hadoop的擴(kuò)展和實(shí)施是非常復(fù)雜的。但是如果你能確切的認(rèn)識(shí)到問題根源所在，還是可以避免“災(zāi)難”的發(fā)生，以下是根據(jù)經(jīng)驗(yàn)總結(jié)出的一些危機(jī)信號(hào)。

危機(jī)信號(hào)1：無法投入生產(chǎn)環(huán)境

從概念驗(yàn)證到生產(chǎn)環(huán)境使用是大數(shù)據(jù)工作流程的重要一步。Hadoop擴(kuò)展工作充滿了挑戰(zhàn)，較大的工作量往往不能被及時(shí)完成，測試環(huán)境不能完全覆蓋真實(shí)運(yùn)行環(huán)境，例如數(shù)據(jù)測試中常見的一種問題是：概念驗(yàn)證經(jīng)常使用不切實(shí)際的小型或單一的數(shù)據(jù)集。

在投入生產(chǎn)環(huán)境之前，需要進(jìn)行規(guī)模及壓力測試，通過這類測試的應(yīng)用程序具備可擴(kuò)展性及容錯(cuò)能力，也可協(xié)助開發(fā)自身容量規(guī)劃模型。

危機(jī)信號(hào)2：開始延期

第一個(gè)應(yīng)用程序投入生產(chǎn)環(huán)境標(biāo)志著你能夠輕松實(shí)現(xiàn)SLA，但隨著Hadoop集群數(shù)量增加，其運(yùn)行時(shí)間變得不可預(yù)知，首次延期問題很容易被忽略，而隨著時(shí)間的推移，這種情況變得越來越糟，最終導(dǎo)致危機(jī)出現(xiàn)。

千萬不要等到危機(jī)爆發(fā)后再采取行動(dòng)。在容量遭到挑戰(zhàn)之前，可適當(dāng)?shù)臄U(kuò)展容量或優(yōu)化程序。調(diào)整預(yù)期容量模型，尤其注意要在最糟糕的性能環(huán)境下進(jìn)行容量檢測，使其具備更加貼近現(xiàn)實(shí)的性能。

危機(jī)信號(hào)3：開始告訴客戶不可能保存所有數(shù)據(jù)

危機(jī)爆發(fā)的另一征兆是減少數(shù)據(jù)保留需求。起初你希望為每年的數(shù)據(jù)分析保留13個(gè)月的數(shù)據(jù)，但由于空間限制，你開始縮減保留數(shù)據(jù)的時(shí)間，這在某種程度上等價(jià)于丟失了Hadoop大數(shù)據(jù)分析能力的優(yōu)勢。

縮減數(shù)據(jù)保留時(shí)間并不能解決問題，要避免這種問題必須要及早行動(dòng)，重新審視容量模型，尋找預(yù)測失敗原因，然后調(diào)整模型以便更好的追蹤問題根源所在。

危機(jī)信號(hào)4：數(shù)據(jù)科學(xué)家們失去地位

過度使用Hadoop集群會(huì)扼殺創(chuàng)新，會(huì)導(dǎo)致數(shù)據(jù)科學(xué)家沒有足夠的資源去運(yùn)行大型作業(yè)，沒有足夠的空間為科學(xué)家們存儲(chǔ)大量運(yùn)算結(jié)果。

容量規(guī)劃經(jīng)常容易被忽視，數(shù)據(jù)科學(xué)家的作用也經(jīng)常被忽視。被忽視加上生產(chǎn)環(huán)境負(fù)載規(guī)劃不足，意味著數(shù)據(jù)科學(xué)家經(jīng)常被邊緣化。請確定你的需求里包括對數(shù)據(jù)科學(xué)家的需求，并能在容量問題出現(xiàn)早期發(fā)揮作用。

危機(jī)信號(hào)5：數(shù)據(jù)科學(xué)家通過Stack Overflow解決問題

在Hadoop實(shí)施初期，運(yùn)維團(tuán)隊(duì)和數(shù)據(jù)科學(xué)家協(xié)同工作。隨著Hadoop實(shí)施的成功，運(yùn)維團(tuán)隊(duì)的維護(hù)壓力隨之增加，科學(xué)家們必須自己解決Hadoop的問題，通常會(huì)通過Stock Overflow尋找處理方法。

隨著Hadoop擴(kuò)展及關(guān)鍵任務(wù)的增加，維護(hù)的工作量開始增加，如果想要保證數(shù)據(jù)專家們集中在數(shù)據(jù)研究上，則需要重新調(diào)整運(yùn)維團(tuán)隊(duì)的大小。

危機(jī)信號(hào)6：服務(wù)器溫度升高

分配服務(wù)器電力供應(yīng)時(shí)，我們常常假設(shè)它們不會(huì)滿負(fù)荷運(yùn)行，但是大型的Hadoop作業(yè)很可能讓服務(wù)器滿載數(shù)個(gè)小時(shí)，嚴(yán)重威脅到你的電網(wǎng)(冷卻方面也有類似的問題)。所以請確保你的Hadoop集群可長時(shí)間在全功率環(huán)境下運(yùn)行。

危機(jī)信號(hào)7：開支失控

在基于IaaS部署的Hadoop環(huán)境中，排名第一的“成功災(zāi)難”是開支失控。你會(huì)突然發(fā)現(xiàn)賬單費(fèi)用是上個(gè)月的三倍，嚴(yán)重超出預(yù)算。

容量規(guī)劃是基于IaaS的Hadoop實(shí)施中相當(dāng)重要的一步，不僅僅是為了管理容量也為了管理成本。但好的容量規(guī)劃只是一個(gè)開始，如果你想要擴(kuò)展基于Iaas的Hadoop實(shí)施，最好要像Netflix那樣大力投資系統(tǒng)來追蹤并優(yōu)化成本。

平緩Hadoop擴(kuò)展

Hadoop計(jì)劃通常低估了保持Hadoop集群穩(wěn)定運(yùn)行所需的工作量，這種誤判是可以理解的。傳統(tǒng)企業(yè)應(yīng)用程序的初始優(yōu)化實(shí)施成本比后續(xù)的維護(hù)與支持高出許多個(gè)數(shù)量級(jí)，人們通常誤認(rèn)為Hadoop遵循同樣的模式，實(shí)際上Hadoop的維護(hù)非常困難，需要大量的運(yùn)維工作。

優(yōu)質(zhì)的容量規(guī)劃是必不可少的;擁有良好容量模型的同時(shí)，還需要及時(shí)的更新以避免其偏離實(shí)際應(yīng)用場景;不要讓創(chuàng)新成為后期問題，給予數(shù)據(jù)科學(xué)家足夠的支持;擴(kuò)容不是解決問題的唯一辦法，管理使用情況也同樣重要;讓用戶(及業(yè)務(wù)所有者)做足夠的作業(yè)優(yōu)化，一點(diǎn)點(diǎn)的優(yōu)化都可以降低現(xiàn)有成本。

來源：CSDN