Hadoop擴展是一個非常復雜的過程，這里羅列了7種常見問題和解決方案。

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

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

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

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

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

危機信號2：開始延期

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

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

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

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

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

危機信號4：數(shù)據(jù)科學家們失去地位

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

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

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

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

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

危機信號6：服務器溫度升高

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

危機信號7：開支失控

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

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

平緩Hadoop擴展

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

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

來源：CSDN