|
還記得剛接觸Hadoop的時(shí)候,還是1.x版本,硬是在自己的4GB內(nèi)存上面弄了3個(gè)虛擬機(jī)
學(xué)習(xí),條件有些艱苦,Hadoop測(cè)試集群搭建不需要太多考慮,隨著畢業(yè)開始進(jìn)入企業(yè),在企業(yè)中實(shí)踐Hadoop,特別是一定規(guī)模的集群,逐漸涉及到硬件資源,網(wǎng)絡(luò)規(guī)劃,操作系統(tǒng),軟件棧等一系列問題！對(duì)于一個(gè)沒有經(jīng)驗(yàn)的小白來說,還是比較復(fù)雜的,還好公司有l(wèi)inux大牛配合上我從各種技術(shù)網(wǎng)站博客吸收的微薄知識(shí)，從0開始搭建集群穩(wěn)定運(yùn)行2年多,接近年關(guān),今晚我把這些問題簡單梳理一下,希望對(duì)出建集群的同學(xué)有些許幫助！ 什么決定集群規(guī)模？ Hadoop資源包括：存儲(chǔ)和計(jì)算,對(duì)于計(jì)算資源其實(shí)初建集群很難評(píng)估,所以可以先忽略計(jì)算資源評(píng)估，單從存儲(chǔ)指標(biāo)來規(guī)劃.首先找準(zhǔn)這個(gè)方向，接下來就是和數(shù)據(jù)團(tuán)隊(duì)溝通收集數(shù)據(jù)量,每天數(shù)據(jù)增長率,數(shù)據(jù)存儲(chǔ)周期,盡量多了解信息,存儲(chǔ)周期是1個(gè)月,3個(gè)月,半年來確認(rèn)數(shù)據(jù)量,從而計(jì)算存儲(chǔ),從存儲(chǔ)出發(fā)規(guī)劃集群是前期最合理的方向。 比如：每天增長數(shù)據(jù)量為4T, 3倍冗余,存儲(chǔ)3個(gè)月為周期,大概存儲(chǔ)=4T390天=1080T,這個(gè)基礎(chǔ)上面需要乘一個(gè)系數(shù),考慮給用戶,磁盤計(jì)算,臨時(shí)空間留一部分存儲(chǔ),未來數(shù)據(jù)增長趨勢(shì),分析結(jié)果存儲(chǔ)周期占用空間,這些都是HDFS相關(guān)！在HDFS存儲(chǔ)的基礎(chǔ)上面,還需要考慮LinuxOS(Linux分區(qū)規(guī)劃).評(píng)估完成之后，最重要的還是考慮企業(yè)的投入意愿和財(cái)力現(xiàn)狀.這個(gè)系數(shù)需要綜合考量.如何合理規(guī)劃分區(qū),使用目錄規(guī)范,存儲(chǔ)初步確定集群規(guī)模.規(guī)劃非常合理而被用戶不合理利用資源,那合理的規(guī)劃就變得不合理了,有關(guān)合理存儲(chǔ)規(guī)劃請(qǐng)參考《Hadoop平臺(tái)架構(gòu)—存儲(chǔ)篇》 工作負(fù)載 && 軟件棧? 幾乎在很多場(chǎng)景,MapRdeuce或者說分布式架構(gòu),都會(huì)在IO受限,硬盤或者網(wǎng)絡(luò)讀取數(shù)據(jù) 遇到瓶頸.處理數(shù)據(jù)瓶頸CPU受限.大量的硬盤讀寫數(shù)據(jù)是海量數(shù)據(jù)分析常見情況！ IO受限例子：
CPU受限例子：
目前Hadoop發(fā)展為一個(gè)無所不包的數(shù)據(jù)平臺(tái),所以不僅僅是MapReudce使用,多種計(jì)算模型可插拔和Hadoop無縫結(jié)合,Hadoop2.x版本Yarn資源管理器,可以兼容多種技術(shù)模型；如：內(nèi)存計(jì)算代表的saprk,impala,tez,drill,presto.磁盤計(jì)算代表的hive,mapreduce,pig. 對(duì)于一個(gè)異構(gòu)集群,會(huì)同時(shí)存在多種計(jì)算模型！在硬件配置上面就需要高內(nèi)存,大磁盤; Impala推薦最低配置128G內(nèi)存,才能發(fā)揮優(yōu)勢(shì)；spark典型的CPU密集型,需要更多CPU和內(nèi)存。Hive,MR磁盤計(jì)算,多磁盤讀寫比較頻繁！當(dāng)你在為集群硬件選型的時(shí)候，需要考慮的軟件組件包括Apache HBase、Cloudera Impala、Presto Or Drill、Apache Phoenix和Apache spark。 1、Hbase是一個(gè)可靠的列數(shù)據(jù)存儲(chǔ)系統(tǒng)，它提供一致性、低延遲和隨機(jī)讀寫。region的一些坑,在Hbase1.0+版本提供新的API，訪問集群類似JDBC形式,增加了異步寫入API，一主多從region, 解決region offline問題；Hbase-Region-split-policy！ 2、Impala項(xiàng)目為Hadoop帶來了可擴(kuò)展的并行數(shù)據(jù)庫技技術(shù),使得用戶可以向HDFS和HBase中存儲(chǔ)的數(shù)據(jù)發(fā)起低延遲的SQL查詢，而且不需要數(shù)據(jù)移動(dòng)或轉(zhuǎn)換。Cloudera開源;內(nèi)存使用評(píng)估不合理,數(shù)據(jù)量太大,join性能低下！hive都跑完了,還沒結(jié)束！ 3、PrestoDb或者Drill,Presto讓我們方便的查詢Hive,Nosql(hbase,cassandra,redis),RDBMS(mysql,postgresql)；Facebook開源;有商業(yè)公司在支持;功能是把Hadoop和多種數(shù)據(jù)源聯(lián)系起來,讓Hadoop兼容更多數(shù)據(jù)源,實(shí)現(xiàn)無所不包的數(shù)據(jù)平臺(tái)！一切看上去都是那么美好誰用誰知道…小聲說一句木有寫磁盤功能,內(nèi)存不夠直接報(bào)錯(cuò),一部分節(jié)點(diǎn)失去聯(lián)系，短時(shí)間使用不鳥了. 4、Drill和Presto非常類似可以支持SQL直接查詢很多數(shù)據(jù)源：Hive,HDFS,Hbase,MongoDB,S3,RDBMS(Mysql,Oracle,postgresql,SQLServer)；MapR主推;把Hadoop和多種數(shù)據(jù)源聯(lián)系起來,讓Hdoop兼容更多數(shù)據(jù)源,實(shí)現(xiàn)無所不包的數(shù)據(jù)平臺(tái)！ 5、Hive提供穩(wěn)定和可靠的SQL分析海量數(shù)據(jù),也是最早的SQL on Hadoop解決方案！ 6、Tez,HDP主推,可以替代Hive底層執(zhí)行引擎MR,讓hive擁有內(nèi)存計(jì)算相當(dāng)?shù)男阅?！生產(chǎn)有使用過,可靠穩(wěn)定,join有些時(shí)候不如Hive！ 7、spark,對(duì)于這個(gè)框架,讓人又愛又恨,主要用在機(jī)器學(xué)習(xí)和圖計(jì)算吧！ SparkSQL做過一些性能測(cè)試,性能并沒有外界宣稱的那么牛X,生產(chǎn)環(huán)境也用過, 說多了都是淚啊,SQL模塊投入力度比較小,也是最易用的吧,很多SQL on Hadoop方案都比它做的好,所以呵呵..！spark 1.6 新版Dataset API更好的內(nèi)存管理,鎢絲計(jì)劃等提升性能！Spark宣傳做的非常好；我們使用下來SQL性能不如其他方案,穩(wěn)定性不夠好！executor假死,甚至退出無法恢復(fù),穩(wěn)定性還不如Tez吧！當(dāng)然也可能 是我們技術(shù)能力不夠吧！用來做機(jī)器學(xué)習(xí),圖計(jì)算,通過API開發(fā)數(shù)據(jù)清洗入庫Hbase 提供查詢！替代MR做開發(fā)是一種選擇吧！SQL模塊Join性能低下,單表查詢性能ok！ 8、Phoenix,SQL-on-Hbase解決方案！這是除了Hive/Impala on Hbase比較好的方案,Phoenix底層是調(diào)用Hbase API實(shí)現(xiàn)查詢,所以能用到Hbase的優(yōu)化器,社區(qū)跟進(jìn)Hbase也很快,是一個(gè)不錯(cuò)的方案！ SQL on Hadoop我個(gè)人花費(fèi)了大量精力做性能測(cè)試,可能個(gè)人技術(shù)能力有限無法做到全面 ，目前對(duì)于億級(jí)表,足夠大內(nèi)存，全方位比較 Imapla > PrestoDb > SparkSQL > Tez > Drill > Hive。當(dāng)然比如20-30億單表查詢檢索PrestoDb,SparkSql,Hive能很快完成,而Impala寫了磁盤,或某些節(jié)點(diǎn)壓力太大崩潰了,性能急劇下降！針對(duì)這些SQL,NOSQL產(chǎn)品我們技術(shù)選型的時(shí)候做過tpch,tpcds,ycbs,業(yè)務(wù)場(chǎng)景等性能測(cè)試！目前 市面上開源的SQL-on-Hadoop基本沒一個(gè)能跑全的！使用也很多坑,誰用誰知道… 有關(guān)集群存儲(chǔ)格式如何選擇請(qǐng)參考《Hadoop平臺(tái)架構(gòu)—存儲(chǔ)篇》 引用 我們下面說的硬件選型都是基于異構(gòu)集群！
硬件配置如何選擇？ 硬件的選擇,要高配還是低配？ 確定節(jié)點(diǎn)規(guī)模,cpu、內(nèi)存、磁盤配比？
注意：1塊盤3T 理論大小應(yīng)為 3*1024G =3096G 實(shí)際大小3000G， 而我們實(shí)際計(jì)算時(shí)使用的是1024. Hadoop版本如何選擇？ 在Hadoop的發(fā)行版包括：Apache hadoop、Cloudera cdh，Hortonworks HDP 。后兩者是商業(yè)團(tuán)隊(duì)在原生apache hadoop之上做一些優(yōu)化和調(diào)整,目前我們 主要選擇Cloudera Hadoop發(fā)行版,如果公司有研發(fā)能力能夠同時(shí)跟進(jìn)幾條Hdoop 家族軟件發(fā)展，并且能fix bug，使用更多新功能新特性，可以考慮Apache Hdoop版本。 Cloudera CDH版本,基于Cloudrea強(qiáng)大的研發(fā)能力,能很快修復(fù)bug,更加可靠穩(wěn)定，一套 好用ClouderaManager監(jiān)控方案！如果你選擇HDP版本，其實(shí)也和選擇Apache版本比較接近了,HDP版本有商業(yè)公司支持,但是基本就是把開源的Hadoop家族做了一個(gè)安裝包,號(hào)稱是基于完全開源的軟件棧構(gòu)建，而權(quán)限控制模塊是不開源的,和自己的基于完全開源 口號(hào)有些背道而馳；選擇商業(yè)發(fā)行版,在搭建基礎(chǔ)環(huán)境上面少浪費(fèi)一些時(shí)間,可以多把時(shí) 間花在應(yīng)用層面，你說你搭建個(gè)基礎(chǔ)集群環(huán)境都弄幾天，使用一個(gè)安裝包,幾個(gè)小時(shí) 就完成就專注于應(yīng)用層面！甚至可以做出一鍵批量安裝,從硬件上架通電之后,linux系統(tǒng)安裝完成之后,集群就可以使用了！完全的自動(dòng)化！配合好用的監(jiān)控圖標(biāo) 降低運(yùn)維成本！ 當(dāng)然,選擇商業(yè)發(fā)行版,可定制性就低一些,重大bug需要等待新版本的發(fā)布.而且 某些Hadoop軟件棧由于競(jìng)爭(zhēng)或者某些利益關(guān)系,而在發(fā)行版中被砍掉,比如在CDH 版本中SparkSQL是被砍掉的,雖然兩家公司在合作,也有hive on spark項(xiàng)目,但是 相對(duì)來說是有點(diǎn)搶Impala生意的！我們的做法是自己編譯spark版本在CDH集群中 獨(dú)立模式部署一套Spark集群,但是比如on Yarn模式是無法使用的！SparkSQL獨(dú)立 模式和CDH其他組件配置使用時(shí)沒有任何問題。比如資源管理就不能都統(tǒng)一在Yarn 管理！對(duì)于維護(hù)和使用都造成一定的麻煩！ 節(jié)點(diǎn)該如何分配？ Hadoop包括兩類節(jié)點(diǎn)： 引用 Master： CPU：16CPU*4核 ;內(nèi)存：128G-512G; HA 需要兩臺(tái)Namenode,配置一致！ Slave: CPU：8CPU*4核-16CPU*4核;內(nèi)存：16G-24G128G-256G;配置最好一致,如果不一致,資源分配需要著重考慮！ LinuxOS: redhat 6.3 or CentOS 6.6,NameNode節(jié)點(diǎn)存儲(chǔ)區(qū)做RAID1！Datanode節(jié)點(diǎn)磁盤JBOD安裝，無RAID。Linux系統(tǒng)盤做RAID1 硬件配置如果存在一定的差異需要考慮資源利用率問題！特別注意有單點(diǎn)的問題的統(tǒng)一放到一臺(tái)主機(jī)！ 集中式Master，將SPOF單點(diǎn)集中到一起:Namenode HA,HMaster HA,Spark Master, JobTracker/ResourceManager HA ,Hive Metastore,HiveServer2,Impala StateStore, Catalog Server,impala-LLAMA HA,Oozie,Sentry,Hue Slave,例如：Impalad,TaskTracker/Nodemanager,RegionServer,spark worker 計(jì)算資源統(tǒng)一交給yarn分配,所有的作業(yè)分組，按部門，不同的作業(yè)類型,劃分不同 的資源池，每個(gè)部門和作業(yè)類型分組，放入不同的資源池處理.有關(guān)資源分配內(nèi)容, 請(qǐng)參考《Yarn資源分配性能調(diào)優(yōu)》，Map slot,Reduce slot這些值怎么來的,Yarn的資源池 ,Hadoop-2.6新功能,Hadoop YARN新特性—label based scheduling,基于標(biāo)簽的調(diào)度策略！ 怎么優(yōu)化來提升性能，怎么合理利用資源！請(qǐng)參考更多相關(guān)文章！ 如果你對(duì)初建Hadoop集群前期硬件配置,版本選擇等還有疑問歡迎討論！ Yarn資源分配性能調(diào)優(yōu) 結(jié)論 購買合適的硬件，對(duì)于一個(gè)Hapdoop群集而言，需要性能測(cè)試和細(xì)心的計(jì)劃，從而全面理解工作負(fù)荷。然而，Hadoop群集通常是一個(gè)形態(tài)變化的系統(tǒng)， 而Cloudera建議，在開始的時(shí)候，使用負(fù)載均衡的技術(shù)文檔來部署啟動(dòng)的硬件。重要的是，記住，當(dāng)使用多種體系組件的時(shí)候，資源的使用將會(huì)是多樣的, 而專注與資源管理將會(huì)是你成功的關(guān)鍵。 參考：http://www. 本文轉(zhuǎn)自：whoami的博客 |
|
|
