hadoop叢集管理系統搭建規劃說明
Hadoop分布式叢集環境搭建是每個入門級新手都非常頭疼的事情，因為你可能花費了很久的時間在搭建運作環境，最終卻不知道什麼原因無法建立成功。但對新手來說，運作環境搭建不成功的機率還蠻高的。
在之前的分享文章中給hadoop新手入門推薦的大快搜尋DKHadoop發行版，在運作環境安裝方面的确要比其他的發行版hadoop要簡單的多，畢竟DKHadoop是對底層重新內建封裝的，對與研究hadoop尤其是入門級新手來說是非常友好的一個發行版！關于DKHadoop的安裝留在後面再給大家分享，本篇就跟大家聊一聊關于hadoop分布式叢集環境搭建規劃。
1、分布式機器架構圖：
其中機器1主節點，機器2從節點，機器3、機器4等都是計算節點。當主節點當機後從節點代替主節點工作，正常狀态是從節點和計算節點一樣工作。這種架構設計保證資料完整性。
首先我們保證每台計算節點上分别有一個DataNode節點和NodeManager節點。因為都是計算節點，真正幹活的。在數量上我們要保證。那麼NameNode和ResourceManager是兩個非常重要的管理者，我們用戶端的請求，第一時間與NameNode和ResourceManager打交道。NameNode負責管理HDFS檔案系統的中繼資料，用戶端不管是讀檔案還是寫檔案，都要首先找到NameNode擷取檔案的中繼資料，再進行檔案的操作。ResourceManager也是如此，它負責管理叢集中的資源和任務排程，你也可以把它視為“大資料作業系統”。用戶端能否送出應用并運作，就看你的ResourceManager是否正常。
2、達到多大規模的資料，才值得用大資料的方式來處理？
第一，從資料量角度，但是并無确定的答案，一般定性角度來說，你覺得這個資料量單機處理不了，比如記憶體限制，時間過久等，就用叢集，但是要降低時間，你的處理邏輯必須能分布式處理，定量就是一般資料或者未來的資料量會達到PB級别（可能GB）或以上就要用分布式，當然前提也是你的處理邏輯可以進行分布式。
第二，從算法角度，或者處理邏輯的時間複雜度來說，比如雖然你的資料記錄不是很多，但是你的算法或者處理邏輯的時間複雜度是n的平方，甚至更高，同時你的算法可以進行分布式設計，那麼就考慮用分布式，比如你的記錄雖然隻有1w, 但是時間複雜度确是n的平方，那麼你想想單機要多久，要是你的算法可以進行分布式處理，那麼就考慮用分布式。
3、制約大資料處理能力的幾個問題
a、網絡帶寬
網絡是聯接計算機的紐帶，這個紐帶當然越寬越好，這樣可以在計算機資源許可的情況下，在機關時間内傳輸更多的資料，讓計算機處理更多的資料。現在企業網絡中，普遍采用的多是百兆網絡，也有千兆，萬兆雖然有，但是用得不多。
b、磁盤
所有資料，不管它從哪裡來，最終都要存進不同的硬碟裡面，或者閃存盤。閃存盤的讀寫效率比硬碟高得多，但是缺點也明顯：價格貴、容量小。現在的存儲媒體主要還是硬碟，硬碟有順序讀寫和随機讀寫兩種模型。順序讀寫是磁頭沿着磁道，好象流水線一樣，有規律的向前滾動進行。随機讀寫是磁頭跳躍着，找到磁道上留白的地方，把資料寫進去。很明顯，順序讀寫比随機讀寫效率高，是以系統架構師在設計大資料存儲方案時，都是以順序讀寫為主要選擇。
c、計算機的數量
分布式的叢集環境下，計算機的規模當然越大越好。這樣在資料等量的情況下，計算機數量越多，配置設定給每台計算機的資料越少，處理效率自然就高了。但是計算機的數量也不是可以無限增加，叢集對計算機規模的容納有一個峰值，超過這個峰值，再提升就很困難，處理不好還會下降。原因主要來自木桶短闆效應、邊界效應、規模放大效應。根據多年前的一個測試，當時以Pentium 3和Pentium 4晶片為基礎平台，配合100M網絡，在上面運作LAXCUS大資料系統。當達到千台計算機的規模時，瓶頸開始顯露出來。如果現在用新的X86晶片，加上更高速的網絡，應該是能夠容納更多的計算機。
d、代碼品質
這不是關鍵問題，但是是企業必須關注的一個問題。這和程式員編寫的計算機代碼品質有關。實際上，每個大資料産品都是半成品，它們隻是提供了一個計算架構，要實際應用到企業生産中，裡面還有大量業務編碼需要程式員來實作。要使大資料應用達到高品質，技術負責人要做好前期設計，清楚和規範業務流程，程式員拿到方案後，用統一格式編寫代碼。這是雙方互相配合的過程。或者說，要做好協同和協調的事情。