Hadoop教程：Hadoop擴(kuò)展過(guò)程中的潛在危機(jī)

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

容量規(guī)劃是基于IaaS的Hadoop實(shí)施中相當(dāng)重要的一步，不僅僅是為了管理容量也為了管理成本。但好的容量規(guī)劃只是一個(gè)開(kāi)始，如果你想要擴(kuò)展基于Iaas的Hadoop實(shí)施，最好要像Netflix那樣大力投資系統(tǒng)來(lái)追蹤并優(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)用場(chǎng)景;不要讓創(chuàng)新成為后期問(wèn)題，給予數(shù)據(jù)科學(xué)家足夠的支持;擴(kuò)容不是解決問(wèn)題的唯一辦法，管理使用情況也同樣重要;讓用戶(hù)(及業(yè)務(wù)所有者)做足夠的作業(yè)優(yōu)化，一點(diǎn)點(diǎn)的優(yōu)化都可以降低現(xiàn)有成本。

來(lái)源：CSDN