大大都企業(yè)大數(shù)據(jù)應用案例尚處于嘗試和試點階段，對付少數(shù)首次在出產(chǎn)情況陳設Hadoop系統(tǒng)的用戶來說，最常碰著的就是擴展問題，此類問題往往導致企業(yè)因噎廢食，終止大數(shù)據(jù)應用項目。

陳設和擴展Hadoop系統(tǒng)是一件高度巨大的工作，假如用戶能提前對Hadoop擴展大概會碰著的各類問題和危險信號有所相識，就能制止許多“救火”局勢。

以下是Hadoop大數(shù)據(jù)系統(tǒng)呈現(xiàn)擴展問題的七大危險信號：

危險信號一: 永遠進入不了出產(chǎn)階段

大數(shù)據(jù)應用從觀念驗證到出產(chǎn)情況是一個龐大的奔騰，Hadoop系統(tǒng)的可擴展性將面對龐大的挑戰(zhàn)。出產(chǎn)情況的數(shù)據(jù)局限發(fā)生的一些問題嘗試情況很難遇到。別的數(shù)據(jù)自己也存在差別，觀念驗證階段利用的測試數(shù)據(jù)集往往是不真實的，可能范例單一。

在進入出產(chǎn)情況前，大數(shù)據(jù)團隊需要對Hadoop系統(tǒng)舉辦模仿真實數(shù)據(jù)局限的壓力測試，此類測試可以或許檢討大數(shù)據(jù)應用的可擴展性和容錯機能，還能幫你做出越發(fā)精確的機能(資源需求)籌劃模子。

危險信號二: 闡明計較任務不絕超時

當Hadoop集群中運行的大數(shù)據(jù)應用很少可能只有一個時，一切都行云流水，按部就班，，可是跟著Hadoop集群的增長，數(shù)據(jù)闡明任務的運行時間變得難以預測起來。一開始，只是有零散的超時現(xiàn)象，問題容易被忽視，但跟著時間增長，超時問題會越來越嚴重，最后導致危機。

在危機發(fā)作前，你必需提前采納動作，按照任務峰值調(diào)解計較機能籌劃模子。

危險信號三: 你開始匯報人們不要保存所有數(shù)據(jù)

危機呈現(xiàn)的另一個征兆是數(shù)據(jù)保存時間窗口不絕縮水。一開始你想保存13個月的數(shù)據(jù)舉辦年度闡明。可是由于空間限制，你開始淘汰保存數(shù)據(jù)的月份數(shù)。到最后，你的Hadoop系統(tǒng)因為沒有足夠多的數(shù)據(jù)而不再是“大數(shù)據(jù)”系統(tǒng)。

數(shù)據(jù)保存窗口的縮水是因為存儲的擴展性碰著問題，這與前面的計較機能問題雷同。當你的容量預測模子呈現(xiàn)問題時，需要盡快調(diào)解。

危險信號四: 數(shù)據(jù)科學家被“餓死”

任務負荷過重的Hadoop集群會抹殺創(chuàng)新，因為數(shù)據(jù)科學家們將沒有足夠的計較資源來開展大型任務，也沒有足夠的空間來存儲中間功效。

機能和容量籌劃凡是會忽略可能低估數(shù)據(jù)科學家的需求，在加之前面提到的對出產(chǎn)情況任務的預計不敷，會嚴重限制數(shù)據(jù)科學家的開辟性和創(chuàng)新性事情。

危險信號五：數(shù)據(jù)科學家們開始查察Stack Overflow

在Hadoop系統(tǒng)陳設的早期，你的運營團隊與科學家細密協(xié)作。運營團隊隨時為數(shù)據(jù)科學家提供支持。(編者按：雷同串聯(lián)的協(xié)作模式)可是當Hadoop 系統(tǒng)樂成上線后，系統(tǒng)的運維和擴展任務就會讓運營團隊疲于奔命，這時候數(shù)據(jù)科學家碰著Hadoop問題就只好本身辦理，譬喻常常去技能問答網(wǎng)站Stack Overflow查察問題帖子。

危險信號六：數(shù)據(jù)中心越來越熱

數(shù)據(jù)中心處事器的電力都不是按處事器的功率峰值設置的，可是一個Hadoop集群運行任務的時候常常會持續(xù)“拷機”數(shù)小時，會燒壞功率不匹配的供電線路，同樣的問題也存在于制冷系統(tǒng)中。陳設Hadoop系統(tǒng)時請確保數(shù)據(jù)中心支持其長時間全速運行。

危險信號七：用度超支

基于IaaS的Hadoop陳設，譬喻AWS，在支出上是失控的。一個月的用度很有大概是上個月的三倍，遠遠超出你的預算。

機能籌劃對付基于IaaS的Hadoop陳設來說也長短常重要的，可是好的機能籌劃只是開始，假如你需要擴展IaaS上的Hadoop系統(tǒng)，那么你需要進修Netflix在本錢監(jiān)控和優(yōu)化系統(tǒng)上投入大量資金。