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

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

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

危機信號1：無法投入生產環境

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

在投入生產環境之前，需要進行規模及壓力測試，通過這類測試的應用程序具備可擴展性及容錯能力，也可協助開發自身容量規劃模型。

危機信號2：開始延期

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

千萬不要等到危機爆發后再采取行動。在容量遭到挑戰之前，可適當的擴展容量或優化程序。調整預期容量模型，尤其注意要在最糟糕的性能環境下進行容量檢測，使其具備更加貼近現實的性能。

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

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

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

危機信號4：數據科學家們失去地位

過度使用Hadoop集群會扼殺創新，會導致數據科學家沒有足夠的資源去運行大型作業，沒有足夠的空間為科學家們存儲大量運算結果。

容量規劃經常容易被忽視，數據科學家的作用也經常被忽視。被忽視加上生產環境負載規劃不足，意味著數據科學家經常被邊緣化。請確定你的需求里包括對數據科學家的需求，并能在容量問題出現早期發揮作用。

危機信號5：數據科學家通過Stack Overflow解決問題

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

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

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

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

危機信號7：開支失控

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

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

平緩Hadoop擴展

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

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

來源：CSDN