還記得剛接觸Hadoop的時候,還是1.x版本,硬是在自己的4GB內存上面弄了3個虛擬機
學習,條件有些艱苦,Hadoop測試集群搭建不需要太多考慮,隨著畢業開始進入企業,在企業中實踐Hadoop,特別是一定規模的集群,逐漸涉及到硬件資源,網絡規劃,操作系統,軟件棧等一系列問題！對于一個沒有經驗的小白來說,還是比較復雜的,還好公司有linux大牛配合上我從各種技術網站博客吸收的微薄知識，從0開始搭建集群穩定運行2年多,接近年關,今晚我把這些問題簡單梳理一下,希望對出建集群的同學有些許幫助！

什么決定集群規模？
Hadoop資源包括：存儲和計算,對于計算資源其實初建集群很難評估,所以可以先忽略計算資源評估，單從存儲指標來規劃.首先找準這個方向，接下來就是和數據團隊溝通收集數據量,每天數據增長率,數據存儲周期,盡量多了解信息,存儲周期是1個月,3個月,半年來確認數據量,從而計算存儲,從存儲出發規劃集群是前期最合理的方向。
比如：每天增長數據量為4T, 3倍冗余,存儲3個月為周期,大概存儲=4T390天=1080T,這個基礎上面需要乘一個系數,考慮給用戶,磁盤計算,臨時空間留一部分存儲,未來數據增長趨勢,分析結果存儲周期占用空間,這些都是HDFS相關！在HDFS存儲的基礎上面,還需要考慮LinuxOS(Linux分區規劃).評估完成之后，最重要的還是考慮企業的投入意愿和財力現狀.這個系數需要綜合考量.如何合理規劃分區,使用目錄規范,存儲初步確定集群規模.規劃非常合理而被用戶不合理利用資源,那合理的規劃就變得不合理了,有關合理存儲規劃請參考《Hadoop平臺架構—存儲篇》

工作負載 && 軟件棧?
幾乎在很多場景,MapRdeuce或者說分布式架構,都會在IO受限,硬盤或者網絡讀取數據
遇到瓶頸.處理數據瓶頸CPU受限.大量的硬盤讀寫數據是海量數據分析常見情況！
IO受限例子：

• 索引
• 分組
• 數據倒入導出
• 數據移動和轉換

CPU受限例子：

• 聚類/分類
• 復雜的文本挖掘
• 特征提取
• 用戶畫像
• 自然語言處理

目前Hadoop發展為一個無所不包的數據平臺,所以不僅僅是MapReudce使用,多種計算模型可插拔和Hadoop無縫結合,Hadoop2.x版本Yarn資源管理器,可以兼容多種技術模型；如：內存計算代表的saprk,impala,tez,drill,presto.磁盤計算代表的hive,mapreduce,pig. 對于一個異構集群,會同時存在多種計算模型！在硬件配置上面就需要高內存,大磁盤; Impala推薦最低配置128G內存,才能發揮優勢；spark典型的CPU密集型,需要更多CPU和內存。Hive,MR磁盤計算,多磁盤讀寫比較頻繁！當你在為集群硬件選型的時候，需要考慮的軟件組件包括Apache HBase、Cloudera Impala、Presto Or Drill、Apache Phoenix和Apache spark。
1、Hbase是一個可靠的列數據存儲系統，它提供一致性、低延遲和隨機讀寫。region的一些坑,在Hbase1.0+版本提供新的API，訪問集群類似JDBC形式,增加了異步寫入API，一主多從region, 解決region offline問題；Hbase-Region-split-policy！
2、Impala項目為Hadoop帶來了可擴展的并行數據庫技技術,使得用戶可以向HDFS和HBase中存儲的數據發起低延遲的SQL查詢，而且不需要數據移動或轉換。Cloudera開源;內存使用評估不合理,數據量太大,join性能低下！hive都跑完了,還沒結束！
3、PrestoDb或者Drill,Presto讓我們方便的查詢Hive,Nosql(hbase,cassandra,redis),RDBMS(mysql,postgresql)；Facebook開源;有商業公司在支持;功能是把Hadoop和多種數據源聯系起來,讓Hadoop兼容更多數據源,實現無所不包的數據平臺！一切看上去都是那么美好誰用誰知道…小聲說一句木有寫磁盤功能,內存不夠直接報錯,一部分節點失去聯系，短時間使用不鳥了.
4、Drill和Presto非常類似可以支持SQL直接查詢很多數據源：Hive,HDFS,Hbase,MongoDB,S3,RDBMS(Mysql,Oracle,postgresql,SQLServer)；MapR主推;把Hadoop和多種數據源聯系起來,讓Hdoop兼容更多數據源,實現無所不包的數據平臺！
5、Hive提供穩定和可靠的SQL分析海量數據,也是最早的SQL on Hadoop解決方案！
6、Tez,HDP主推,可以替代Hive底層執行引擎MR,讓hive擁有內存計算相當的性能！生產有使用過,可靠穩定,join有些時候不如Hive！
7、spark,對于這個框架,讓人又愛又恨,主要用在機器學習和圖計算吧！
SparkSQL做過一些性能測試,性能并沒有外界宣稱的那么牛X,生產環境也用過,
說多了都是淚啊,SQL模塊投入力度比較小,也是最易用的吧,很多SQL on Hadoop方案都比它做的好,所以呵呵..！spark 1.6 新版Dataset API更好的內存管理,鎢絲計劃等提升性能！Spark宣傳做的非常好；我們使用下來SQL性能不如其他方案,穩定性不夠好！executor假死,甚至退出無法恢復,穩定性還不如Tez吧！當然也可能
是我們技術能力不夠吧！用來做機器學習,圖計算,通過API開發數據清洗入庫Hbase
提供查詢！替代MR做開發是一種選擇吧！SQL模塊Join性能低下,單表查詢性能ok！
8、Phoenix,SQL-on-Hbase解決方案！這是除了Hive/Impala on Hbase比較好的方案,Phoenix底層是調用Hbase API實現查詢,所以能用到Hbase的優化器,社區跟進Hbase也很快,是一個不錯的方案！
SQL on Hadoop我個人花費了大量精力做性能測試,可能個人技術能力有限無法做到全面
，目前對于億級表,足夠大內存，全方位比較 Imapla > PrestoDb > SparkSQL > Tez > Drill > Hive。當然比如20-30億單表查詢檢索PrestoDb,SparkSql,Hive能很快完成,而Impala寫了磁盤,或某些節點壓力太大崩潰了,性能急劇下降！針對這些SQL,NOSQL產品我們技術選型的時候做過tpch,tpcds,ycbs,業務場景等性能測試！目前
市面上開源的SQL-on-Hadoop基本沒一個能跑全的！使用也很多坑,誰用誰知道…
有關集群存儲格式如何選擇請參考《Hadoop平臺架構—存儲篇》


硬件配置如何選擇？
硬件的選擇,要高配還是低配？
確定節點規模,cpu、內存、磁盤配比？

• 1、節點規模按照,數據增長率+浮動系數確定！彈性擴展節點,容災,HA高可靠方面！
• 單個節點故障，對于20節點集群,計算能力失去20%,對于100節點的集群計算能力失去
• 1%。如果沒有自動化,監控管理也是一大成本！
• 2、初建立集群建議考慮主流配置,平衡集群資源,存儲不夠,調整搞壓縮比例算法,拿
• CPU換存儲；當CPU不足，以網絡寬帶換CPU。集群擁有多個機架，考慮Hdoop的機架感知
• 功能的配置！
• 3、軟件層面的資源管理，比如所以計算框架都在Yarn申請資源,需要分配資源池等.有關各種軟件層面的優化請參考相關yarn資源調優內容！
• 4、硬件配置參考

• 異構集群

• 小集群,次多增加硬件,規格不一致,需要考慮資源利用率問題？

注意：1塊盤3T 理論大小應為 3*1024G =3096G 實際大小3000G， 而我們實際計算時使用的是1024.

Hadoop版本如何選擇？
在Hadoop的發行版包括：Apache hadoop、Cloudera cdh，Hortonworks HDP 。后兩者是商業團隊在原生apache hadoop之上做一些優化和調整,目前我們
主要選擇Cloudera Hadoop發行版,如果公司有研發能力能夠同時跟進幾條Hdoop
家族軟件發展，并且能fix bug，使用更多新功能新特性，可以考慮Apache Hdoop版本。
Cloudera CDH版本,基于Cloudrea強大的研發能力,能很快修復bug,更加可靠穩定，一套
好用ClouderaManager監控方案！如果你選擇HDP版本，其實也和選擇Apache版本比較接近了,HDP版本有商業公司支持,但是基本就是把開源的Hadoop家族做了一個安裝包,號稱是基于完全開源的軟件棧構建，而權限控制模塊是不開源的,和自己的基于完全開源
口號有些背道而馳；選擇商業發行版,在搭建基礎環境上面少浪費一些時間,可以多把時
間花在應用層面，你說你搭建個基礎集群環境都弄幾天，使用一個安裝包,幾個小時
就完成就專注于應用層面！甚至可以做出一鍵批量安裝,從硬件上架通電之后,linux系統安裝完成之后,集群就可以使用了！完全的自動化！配合好用的監控圖標
降低運維成本！
當然,選擇商業發行版,可定制性就低一些,重大bug需要等待新版本的發布.而且
某些Hadoop軟件棧由于競爭或者某些利益關系,而在發行版中被砍掉,比如在CDH
版本中SparkSQL是被砍掉的,雖然兩家公司在合作,也有hive on spark項目,但是
相對來說是有點搶Impala生意的！我們的做法是自己編譯spark版本在CDH集群中
獨立模式部署一套Spark集群,但是比如on Yarn模式是無法使用的！SparkSQL獨立
模式和CDH其他組件配置使用時沒有任何問題。比如資源管理就不能都統一在Yarn
管理！對于維護和使用都造成一定的麻煩！

節點該如何分配？
Hadoop包括兩類節點：

Yarn資源分配性能調優

結論
購買合適的硬件，對于一個Hapdoop群集而言，需要性能測試和細心的計劃，從而全面理解工作負荷。然而，Hadoop群集通常是一個形態變化的系統， 而Cloudera建議，在開始的時候，使用負載均衡的技術文檔來部署啟動的硬件。重要的是，記住，當使用多種體系組件的時候，資源的使用將會是多樣的, 而專注與資源管理將會是你成功的關鍵。
參考：http://www.itweet.cn

本文轉自：whoami的博客