大數(shù)據(jù)技術(shù)介紹（Hadoop與MPP部分，包含與傳統(tǒng)技術(shù)的區(qū)別）版本號：1.0.0版本號：1.0.0TOC\o"1-5"\h\z概述 4大數(shù)據(jù)及大數(shù)據(jù)技術(shù) 4引入大數(shù)據(jù)的意義 4術(shù)語、定義和縮略語 4大數(shù)據(jù)技術(shù)的引入 5傳統(tǒng)數(shù)據(jù)倉庫數(shù)據(jù)特征 6大數(shù)據(jù)技術(shù)應(yīng)用場景 6Hadoop與MPP與傳統(tǒng)數(shù)據(jù)庫技術(shù)對比與適用場景 7\o"CurrentDocument"Hadoop實施扌指導(dǎo)意見 8應(yīng)用場景 8前期方案設(shè)計階段的建議 9\o"CurrentDocument"對Hadoop軟件選擇的建議 9所需硬件設(shè)備建議 12組網(wǎng)方式建議 13規(guī)劃節(jié)點(diǎn)規(guī)模時需要考慮的因素 17建設(shè)過程中的建議 18對壓縮的考慮 18\o"CurrentDocument"HBase設(shè)計 19參數(shù)設(shè)置建議 20\o"CurrentDocument"系統(tǒng)調(diào)優(yōu) 25上線前注意事項 30上線后效果評估 31運(yùn)維階段的建議 31\o"CurrentDocument"任務(wù)調(diào)度 32\o"CurrentDocument"監(jiān)控管理 32\o"CurrentDocument"告警管理 32\o"CurrentDocument"部署管理 33\o"CurrentDocument"配置管理 33\o"CurrentDocument"安全管理 33\o"CurrentDocument"日志管理 34\o"CurrentDocument"組織和培訓(xùn)建議 34人員安排建議 34培訓(xùn)建議 35MPP數(shù)據(jù)庫指導(dǎo)意見 35應(yīng)用場景 36\o"CurrentDocument"數(shù)據(jù)集市 36數(shù)據(jù)分級存儲（歷史庫或者明細(xì)庫） 36\o"CurrentDocument"ETL 37\o"CurrentDocument"小結(jié) 37前期方案設(shè)計階段的建議 38軟件平臺選型建議 38容量評估方法建議 39網(wǎng)絡(luò)評估方法建議 40建設(shè)過程中的建議 41\o"CurrentDocument"數(shù)據(jù)分布規(guī)劃 41故障與恢復(fù)策略規(guī)劃 43運(yùn)維階段的建議 44\o"CurrentDocument"系統(tǒng)監(jiān)控 44\o"CurrentDocument"告警管理 44\o"CurrentDocument"SQL監(jiān)控 44\o"CurrentDocument"4.4.4 備份恢復(fù) 45安全及權(quán)限控制 45擴(kuò)容及數(shù)據(jù)重分布 45\o"CurrentDocument"開發(fā)工具 45組織和培訓(xùn)建議 46系統(tǒng)集成建議 46數(shù)據(jù)互通的建議 46\o"CurrentDocument"方式分析 46\o"CurrentDocument"技術(shù)實現(xiàn) 47統(tǒng)一管理 48透明訪問 49附錄A-大數(shù)據(jù)技術(shù)介紹 49\o"CurrentDocument"Hadoop及生態(tài)圈 49\o"CurrentDocument"Hadoop簡介 49\o"CurrentDocument"6.1.2 Hadoop生態(tài)圈系統(tǒng) 57\o"CurrentDocument"Hadoop1.0特性 59\o"CurrentDocument"Hadoop2.0特性 60\o"CurrentDocument"Hadoop選型 62\o"CurrentDocument"6.1.6 HadoopHA方案對比 62\o"CurrentDocument"MPP數(shù)據(jù)庫 66數(shù)據(jù)庫架構(gòu)風(fēng)格 66\o"CurrentDocument"MPP數(shù)據(jù)庫基本架構(gòu) 67\o"CurrentDocument"MPP數(shù)據(jù)庫主要運(yùn)行機(jī)制 68MPP平臺技術(shù)規(guī)范和要點(diǎn) 69\o"CurrentDocument"X86服務(wù)器平臺 70網(wǎng)絡(luò) 71\o"CurrentDocument"InfiniBand 71\o"CurrentDocument"萬兆網(wǎng) 73\o"CurrentDocument"千兆網(wǎng) 74\o"CurrentDocument"適用場景 75硬盤 76硬盤類型介紹 76硬盤比較分析 76硬盤選購建議 77虛擬化 78\o"CurrentDocument"概念 78虛擬化技術(shù)介紹 78\o"CurrentDocument"適用場景 79

1概述1.1大數(shù)據(jù)及大數(shù)據(jù)技術(shù)大數(shù)據(jù)(BigData)的定義眾說紛紜，從技術(shù)講上它通常具備數(shù)據(jù)量大(volume)、數(shù)據(jù)類型多(variety)和數(shù)據(jù)處理和響應(yīng)速度快(velocity)的特征。麥肯錫定義大數(shù)據(jù)為超過了常規(guī)數(shù)據(jù)庫軟件所能搜集/存儲/管理和分析的規(guī)模的數(shù)據(jù)集。大數(shù)據(jù)處理技術(shù)可以認(rèn)為是處理大數(shù)據(jù)以便從中獲取價值的技術(shù)。大數(shù)據(jù)及其技術(shù)正在影響著IT產(chǎn)業(yè)，利用Hadoop和關(guān)系數(shù)據(jù)庫混搭來解決大數(shù)據(jù)難題是當(dāng)前通常采用的方法。1.2引入大數(shù)據(jù)的意義引入原則傳統(tǒng)數(shù)據(jù)倉庫系統(tǒng)已經(jīng)建設(shè)運(yùn)營十年，新技術(shù)的引入不能影響原有的使用感知，需要按照分階段逐步引入的方式?？梢詤⒖既缦碌膸讉€引入原則：1、 先增量后存量?，F(xiàn)有的數(shù)據(jù)處理系統(tǒng)引入大數(shù)據(jù)處理技術(shù)，面臨著模型改造、流程改造等一系列的問題，可以首先在新上線應(yīng)用引入大數(shù)據(jù)處理技術(shù)。2、 先邊緣后核心。對于原有功能的遷移，可以先遷移非關(guān)鍵的應(yīng)用。這些應(yīng)用不涉及到關(guān)鍵生產(chǎn)任務(wù)，可以忍受數(shù)據(jù)處理延遲和故障修復(fù)時間較高等可能出現(xiàn)的風(fēng)險。3、 先簡單后復(fù)雜。數(shù)據(jù)處理邏輯較簡單的應(yīng)用也可以首先嘗試引入大數(shù)據(jù)處理技術(shù)，降低實施的復(fù)雜度，積累運(yùn)維經(jīng)驗。通過在大數(shù)據(jù)處理技術(shù)的規(guī)劃、實施及運(yùn)維過程中積累經(jīng)驗及教訓(xùn)，不斷提升和完善大數(shù)據(jù)技術(shù)的應(yīng)用水平，逐步拓展大數(shù)據(jù)技術(shù)應(yīng)用領(lǐng)域。1.3術(shù)語、定義和縮略語名詞Hadoop名詞Hadoop一個開源的分布式系統(tǒng)基礎(chǔ)架構(gòu)，由Apache基金會開發(fā)?；贖adoop

框架，用戶可以方便的開發(fā)分布式程序，充分利用集群的威力高速運(yùn)算和存儲。MapReduceMapReduce是Hadoop一種并行計算框架，用于大規(guī)模數(shù)據(jù)集的并行運(yùn)算，其縮略語為MR。Hive是基于Hadoop的一個數(shù)據(jù)倉庫工具，可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為數(shù)據(jù)庫表，并提供常用的SQL支持。Hive查詢引擎將SQL語句轉(zhuǎn)換為Hadoop平臺的MapReduce任務(wù)運(yùn)行。Key-value鍵值對，其縮略語為K-V。K-VStoreKey-Value存儲引擎，業(yè)界使用廣泛的有GoogleBigTable和ApacheHBase、Cassandra、MangoDB等。KVStore系統(tǒng)是經(jīng)典的NoSQL實現(xiàn)，與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫相比，目前不支持SQL語言查詢、事物、回滾等復(fù)雜機(jī)制?；贙-VStore開發(fā)的應(yīng)用，其數(shù)據(jù)表設(shè)計模式也與基于關(guān)系型數(shù)據(jù)庫的開發(fā)有顯著區(qū)別。由于K-VStore模型簡單，可靠性高，易于擴(kuò)展，在互聯(lián)網(wǎng)、大數(shù)據(jù)領(lǐng)域有非常廣泛的應(yīng)用。JDBCJava數(shù)據(jù)庫連接MPP數(shù)據(jù)庫Massivelparallelprocessing大規(guī)模并行處理數(shù)據(jù)庫，相對于SymmetricMultiProcessing。DPI(DeepPacketInspection)深度包檢測技術(shù)是一種基于應(yīng)用層的流量檢測和控制技術(shù)，當(dāng)IP數(shù)據(jù)包、TCP或UDP數(shù)據(jù)流通過基于DPI技術(shù)的帶寬管理系統(tǒng)時，該系統(tǒng)通過深入讀取IP包載荷的內(nèi)容來對OSI七層協(xié)議中的應(yīng)用層信息進(jìn)行重組，從而得到整個應(yīng)用程序的內(nèi)容，然后按照系統(tǒng)定義的管理策略對流量進(jìn)行整形操作。2 大數(shù)據(jù)技術(shù)的引入在大數(shù)據(jù)時代，傳統(tǒng)數(shù)據(jù)倉庫基礎(chǔ)架構(gòu)難以滿足海量、多樣化數(shù)據(jù)以及高速響應(yīng)的需求。主要原因為：傳統(tǒng)IT系統(tǒng)采用Scale-up設(shè)計路線，擴(kuò)展性較弱，難以處理海量數(shù)據(jù)；小型機(jī)Unix系統(tǒng)的封閉性導(dǎo)致系統(tǒng)擴(kuò)容時難以利舊，且擁有成本高。為了解決上述問題，大數(shù)據(jù)時代涌現(xiàn)出了多種技術(shù)，典型技術(shù)如下：Hadoop:基于HDFS和Mapreduce，被互聯(lián)網(wǎng)廠商廣泛用于非結(jié)構(gòu)化數(shù)據(jù)處理和半結(jié)構(gòu)化日志處理。優(yōu)點(diǎn)是編程靈活、針對問題優(yōu)化、擴(kuò)展性好，且基于廉價的x86標(biāo)準(zhǔn)硬件。MPP數(shù)據(jù)庫：基于關(guān)系代數(shù)理論，面向結(jié)構(gòu)化數(shù)據(jù)處理設(shè)計的數(shù)據(jù)庫管理系統(tǒng)。近年演進(jìn)方向包括：提高擴(kuò)展性、支持快速復(fù)雜查詢、支持x86標(biāo)準(zhǔn)硬件、高壓縮、列存儲、打通與Hadoop交互。例如Vertica和GreenPlum等。NoSql:拋棄了關(guān)系數(shù)據(jù)庫復(fù)雜的關(guān)系操作、事務(wù)處理等功能，僅提供簡單的鍵值對(Key,Value)數(shù)據(jù)的存儲與查詢，換取高擴(kuò)展性和高性能。例如HBase和Cassendra等。流計算技術(shù)：在流數(shù)據(jù)不斷變化的運(yùn)動過程中實時地進(jìn)行分析，捕捉到可能對用戶有用的信息，并把結(jié)果發(fā)送出去。例如S4和Storm等。內(nèi)存數(shù)據(jù)庫：將數(shù)據(jù)存儲在內(nèi)存RAM中并進(jìn)行計算和查詢，充分發(fā)揮多核CPU的能力的數(shù)據(jù)庫管理系統(tǒng)。例如HANA、ExaAnalytic、TM1等。大數(shù)據(jù)技術(shù)與傳統(tǒng)技術(shù)有很大的差別，它們不是為了通用的需求去設(shè)計，多是某一些廠商按照自己的特定需求或細(xì)分市場設(shè)計的，所以在應(yīng)用的時候需要結(jié)合自身需求考慮到底引入哪些技術(shù)。2.1傳統(tǒng)數(shù)據(jù)倉庫數(shù)據(jù)特征傳統(tǒng)數(shù)據(jù)倉庫目前在數(shù)據(jù)量、數(shù)據(jù)類別、數(shù)據(jù)應(yīng)用需求方面具有典型的大數(shù)據(jù)特征，包括：1、 容量巨大；2、 類別多樣；3、 數(shù)據(jù)處理方式多樣；4、 訪問需求多樣。5、 數(shù)據(jù)價值不同。2.2大數(shù)據(jù)技術(shù)應(yīng)用場景大數(shù)據(jù)技術(shù)可以應(yīng)用在以下場景(包括但不限于)：1、 原數(shù)據(jù)倉庫底層結(jié)構(gòu)化數(shù)據(jù)處理（ETL或ELT）。底層結(jié)構(gòu)化數(shù)據(jù)處理計算任務(wù)重但復(fù)雜性不高，不涉及多表關(guān)聯(lián)，適合引入大數(shù)據(jù)技術(shù)實現(xiàn)高效低成本。2、 半結(jié)構(gòu)和非結(jié)構(gòu)數(shù)據(jù)處理與分析。3、 數(shù)據(jù)集市。數(shù)據(jù)集市應(yīng)用較為獨(dú)立，且對可靠性的要求并不是十分嚴(yán)格，適合作為引入大數(shù)據(jù)技術(shù)形成資源池，實現(xiàn)各地市、各部門數(shù)據(jù)集市的云化、池化和虛擬化，最終實現(xiàn)資源動態(tài)調(diào)配，達(dá)到高效低成本。4、 數(shù)據(jù)倉庫數(shù)據(jù)分級存儲。對低價值的細(xì)節(jié)數(shù)據(jù)以及長周期的歷史數(shù)據(jù)（冷數(shù)據(jù)）訪問頻率較低，也能容忍相對較長的響應(yīng)時間，可以存儲在成本更低的平臺上。5、 數(shù)據(jù)挖掘。某些數(shù)據(jù)挖掘設(shè)計長周期的數(shù)據(jù)，計算時間很長（數(shù)天），占用很多數(shù)據(jù)倉庫資源。還有一些數(shù)據(jù)挖掘算法超出了關(guān)系代數(shù)計算范疇，需要抽取數(shù)據(jù)到獨(dú)立的計算平臺（例如SAS）中進(jìn)行計算。這些數(shù)據(jù)挖掘任務(wù)可以遷移到大數(shù)據(jù)平臺之上進(jìn)行計算。例如交往圈的計算，因其僅涉及單一數(shù)據(jù)，但數(shù)據(jù)量非常大，且需要多次迭代計算。6、 對外查詢。數(shù)據(jù)中心中不僅僅是數(shù)據(jù)處理，也需要將數(shù)據(jù)處理的結(jié)果對外提供查詢,而這些查詢一部分是海量的OLAP性質(zhì)的查詢，另外還有一部分OLTP性質(zhì)的查詢，即數(shù)量眾多但每次查詢量較少的。針對這些應(yīng)用場景，可以看到，主要需要引入的是Hadoop和MPP技術(shù)，然后逐步考慮NoSQL、流計算和內(nèi)存計算等技術(shù)的引入。2.3Hadoop與MPP與傳統(tǒng)數(shù)據(jù)庫技術(shù)對比與適用場景Hadoop和MPP兩種技術(shù)的介紹請參見附錄A。雖然這兩種技術(shù)同屬于分布式計算，但由于依據(jù)的理論和采取的技術(shù)路線不同而有各自的優(yōu)缺點(diǎn)和適用范圍。兩種技術(shù)以及傳統(tǒng)數(shù)據(jù)倉庫技術(shù)的對比如下：HadoopMPP傳統(tǒng)數(shù)據(jù)倉庫平臺開放性高低低運(yùn)維復(fù)雜度高，與運(yùn)維人員能力相關(guān)中中擴(kuò)展能力高中低擁有成本低中高系統(tǒng)和數(shù)據(jù)管理成本高中中應(yīng)用開發(fā)維護(hù)成本高中中SQL支持低高高數(shù)據(jù)規(guī)模PB級別部分PBTB級別計算性能對非關(guān)系型操作效率高對關(guān)系型操作效率高對關(guān)系型操作效率中數(shù)據(jù)結(jié)構(gòu)結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)數(shù)據(jù)結(jié)構(gòu)化數(shù)據(jù)結(jié)構(gòu)化數(shù)據(jù)綜合而言Hadoop和MPP兩種技術(shù)的特點(diǎn)和適用場景為:Hadoop在處理非結(jié)構(gòu)數(shù)據(jù)和半結(jié)構(gòu)數(shù)據(jù)上具備優(yōu)勢，尤其適合海量數(shù)據(jù)批處理等應(yīng)用需求。當(dāng)然隨著Hadoop技術(shù)的成熟，基于Hadoop的即席查詢技術(shù)也逐漸嶄露頭角。比如仿照Dremel的開源項目ApacheDrill以及ClouderaImpala。MPP適合替代現(xiàn)有關(guān)系數(shù)據(jù)結(jié)構(gòu)下的大數(shù)據(jù)處理，具有較高的效率，但其在大規(guī)模集群（超過100個節(jié)點(diǎn)）下的可用性還有待試點(diǎn)證實。MPP適合多維度數(shù)據(jù)自助分析、數(shù)據(jù)集市等；Hadoop適合海量數(shù)據(jù)存儲查詢（詳單存儲和查詢）、批量數(shù)據(jù)ETL、非結(jié)構(gòu)化數(shù)據(jù)分析（日志分析、文本分析）等?？梢钥闯觯魏我环N單一技術(shù)都難以數(shù)據(jù)采集、存儲、處理和對外服務(wù)的需求，多種技術(shù)并存才是發(fā)展趨勢。3 Hadoop實施指導(dǎo)意見本章主要對Hadoop平臺在實施前的方案設(shè)計階段、實施過程中的建設(shè)階段和實施后的運(yùn)維階段中采取的步驟以及需要注意的問題提出指導(dǎo)意見。3.1應(yīng)用場景Hadoop技術(shù)和產(chǎn)品在數(shù)據(jù)中心中可以用于以下場景（包括但不限于）：場景為什么采用Hadoop采用的組件ETL1、 降低原始數(shù)據(jù)存儲壓力2、 降低數(shù)據(jù)倉庫處理壓力3、 降低存儲和處理成本Hive/MR/Pig清單查詢1、 快速響應(yīng)海量數(shù)據(jù)查詢2、 降低查詢成本HBase機(jī)器學(xué)習(xí)和數(shù)據(jù)挖掘1、 降低海量數(shù)據(jù)挖掘成本2、 縮短計算時間3、 實現(xiàn)更加靈活的算法mahout/R/MR冷數(shù)據(jù)存儲1、 降低冷數(shù)據(jù)存儲成本2、 降低冷數(shù)據(jù)查詢成本HiveOverHDFS3.2前期方案設(shè)計階段的建議本節(jié)主要對各公司搭建Hadoop平臺之前對軟硬件選型、組網(wǎng)以及容量規(guī)劃方面提出建議。對Hadoop軟件選擇的建議Hadoop版本選擇建議?Hadoop版本現(xiàn)狀目前ApacheHadoop開源社區(qū)非?；钴S，周期性發(fā)布升級Hadoop及其相關(guān)軟件（包括HBase、Hive、Zookeeper等）。此外，一些公司，如Cloudera、Hortonworks公司等也基于ApacheHadoop軟件進(jìn)行打包升級，開源發(fā)布其Hadoop版本。ApacheHadoop開源社區(qū)發(fā)布的軟件是當(dāng)前社區(qū)的最新進(jìn)展，但Hadoop各相關(guān)軟件分別獨(dú)立發(fā)布，可能存在兼容性的問題。而上述公司發(fā)布的軟件一般基于ApacheHadoop社區(qū)的某個版本進(jìn)行測試升級修訂，并將Hadoop各個系統(tǒng)整合測試，從而發(fā)布一個較為穩(wěn)定且各系統(tǒng)間兼容的軟件包。ApacheHadoop開源社區(qū)發(fā)布的各個版本以及與Cloudera發(fā)布的CDH軟件包的對應(yīng)關(guān)系如下圖所示：gwikecvnlGpmem|Hurc>tofewMailh祠其中，ApacheHadoop0.20版本分支經(jīng)過將0.20.append（為兼容HBase提供對HDFS文件追加寫功能）和0.20.security（提供基于Kerberos認(rèn)證的功能）整合后，于2011年底發(fā)布了Hadoop1.0版本，并在2012年和2013年持續(xù)對該版本進(jìn)行升級。ApacheHadoop0.23版本分支則對原有ApacheHadoop0.20版本做了較大的改動，這包括提供一種通用資源管理框架YARN以及對HDFS主節(jié)點(diǎn)擴(kuò)展方案NameNodeFederation。而ApacheHadoop2.0alpha版本又在0.23分支上又增加了HDFS主節(jié)點(diǎn)高可用方案。總體來看，目前ApacheHadoop開源社區(qū)主要在Hadoop1.0和2.0兩個版本上分別進(jìn)行持續(xù)更新優(yōu)化。而Cloudera公司的Hadoop版本CDH3和CDH4也分別基于Hadoop1.0和2.0版本進(jìn)行封裝。一般來講開源社區(qū)的版本更新非常頻繁，且有些組件之間并不兼容，而公司推出的版本一般都會基于某幾個大版本進(jìn)行推出。Cloudera版本的Hadoop用的比較廣泛，目前Cloudera的最新版為CDH4.3，各組件版本如下：產(chǎn)品包基線版本產(chǎn)品包基線版本Hadoop2.0.0HBase0.94.6Hive0.10.0ClouderaImpala1.0ZooKeeper3.4.3?操作系統(tǒng)建議操作系統(tǒng)一般使用CENTOS/redhat6.x,研究院主流為redhat6.4,內(nèi)核2.6.32以上。Hadoop組件及其用途Hadoop中主要包括如下組件:HDFSo是Hadoop的分布式文件系統(tǒng)，用于存儲分析和查詢所需的數(shù)據(jù)，可以是結(jié)構(gòu)化數(shù)據(jù)也可以是非結(jié)構(gòu)化數(shù)據(jù)。文件按照塊進(jìn)行劃分存儲在多臺機(jī)器上，并通過副本的方式保證高可用。MapReduce。是Hadoop的分布式計算框架，通過Map的方式將計算任務(wù)擴(kuò)展到多臺機(jī)器上，進(jìn)而通過Reduce的方式將多個節(jié)點(diǎn)上的結(jié)果進(jìn)行合并。在Hadoop2.0中，原有MapReduce框架被Yarn代替，但對用戶的接口不變。MapReduce可以簡稱為MR,是很多Hadoop組件的計算引擎，例如Hive、Pig、Mahout等。Hive。是Hadoop上的SQL解析和執(zhí)行引擎。其支持SQL的一個子集，名為HiveQL。Hive通過元數(shù)據(jù)保存表結(jié)構(gòu)信息，并將輸入的HiveQL轉(zhuǎn)換為MapReduce進(jìn)行執(zhí)行。HBase。是Hadoop上的一個鍵值對NoSQL數(shù)據(jù)庫，其主要特性是支持高并發(fā)文本數(shù)據(jù)寫入和讀取，舍棄了關(guān)系數(shù)據(jù)中的事務(wù)、關(guān)聯(lián)、復(fù)雜索引等HBase的典型場景可用于詳單存儲和查詢、互聯(lián)網(wǎng)內(nèi)容存儲、GiS數(shù)據(jù)存儲、半結(jié)構(gòu)化歷史數(shù)據(jù)存儲。Zookeeper。是Hadoop中的分布式可靠協(xié)調(diào)系統(tǒng)，被Hadoop的一些組件所用，例如HBase和Hive（可選）等。Mahout:是一組在MapReduce上的實現(xiàn)的數(shù)據(jù)挖掘算法庫，可被調(diào)用用于數(shù)據(jù)挖掘計算。Oozie：是一個Hadoop上的工作流組件。Pig。是另一個Hadoop上的腳本語言解析和執(zhí)行器，將面向過程的PigLatin語言解析為MapReduce任務(wù)執(zhí)行。Cascading。是一個架構(gòu)在Hadoop上的API，用來創(chuàng)建復(fù)雜和容錯數(shù)據(jù)處理工作流。它抽象了集群拓?fù)浣Y(jié)構(gòu)和配置來快速開發(fā)復(fù)雜分布式的應(yīng)用，而不用考慮背后的MapReduce。Impala。是另一個SQL解析引擎，但其繞過了MapReduce,利用自己的執(zhí)行引擎，充分利用內(nèi)存來直接訪問HDFS上的文件。數(shù)據(jù)處理方式建議從上節(jié)看，在Hadoop上進(jìn)行數(shù)據(jù)處理可以選擇多種方式。但目前較為流行的是采用MapReduce直接編程或者利用Hive。Pig由于要學(xué)習(xí)另外一種語言而用得較少，Impala由于其對內(nèi)存的渴求而難以用于大數(shù)據(jù)的加工。對于Hive和MapReduce用于數(shù)據(jù)處理，比較如下:HiveMapReduce查詢語言HQLJava或其他語言調(diào)優(yōu)方法中多性能略差略優(yōu)易用性簡單（類SQL）復(fù)雜（編程）數(shù)據(jù)格式結(jié)構(gòu)化結(jié)構(gòu)化和非結(jié)構(gòu)化均可可以看出Hive和MapReduce在很多方面基本都相同。在調(diào)優(yōu)方法、性能方面，Hive不如MapReduce，尤其是MapReduce可以針對性的對于某些應(yīng)用的算法優(yōu)化是Hive無法比擬的。但是Hive因為類SQL實現(xiàn)的機(jī)制極高地提升了開發(fā)人員的工作效率，減輕了工作量，而MapReduce的編程則相對復(fù)雜一些，普通水平的MR程序員，寫出來的程序很可能效率低于hive。3.2.2 所需硬件設(shè)備建議服務(wù)器配置建議Hadoop被設(shè)計運(yùn)行在大規(guī)模通用X86硬件平臺之上，使用本地存儲（DAS）來實現(xiàn)ScaleOut。所以其對硬件的要求較低，一般的PC服務(wù)器也可以運(yùn)行，只要滿足發(fā)行版所要求的操作系統(tǒng)和JDK需求即可。但是在實際使用中需要根據(jù)Hadoop的應(yīng)用環(huán)境來合理配置硬件，充分發(fā)揮每個部件的效率。在前期試點(diǎn)中，我們發(fā)現(xiàn)如果執(zhí)行MapReduce，特別是在壓縮文件上執(zhí)行，其對CPU的消耗較高，CPU成為了瓶頸；而在運(yùn)行Hbase的時候，更多的內(nèi)存會緩存更多的數(shù)據(jù)，提高查詢吞吐率并縮短響應(yīng)時間。所以建議這兩種情況下，可以考慮按照如下配比來配置硬件:項目主節(jié)點(diǎn)配置建議數(shù)據(jù)處理（MR/hive）的數(shù)據(jù)節(jié)點(diǎn)數(shù)據(jù)查詢（HBase）的數(shù)據(jù)節(jié)點(diǎn)，可以與數(shù)據(jù)處理的數(shù)據(jù)節(jié)點(diǎn)合設(shè)zk節(jié)點(diǎn)CPU個數(shù)及核心數(shù)2路8核以上2路8核以上，如果壓縮數(shù)據(jù)或者處理比較復(fù)雜，可以考慮更多路多核的2路6核以上2路8核以上硬盤數(shù)硬盤數(shù)可以不冋太多，4-6塊6、8或者12塊，數(shù)據(jù)處理時IO一般不是瓶頸，但更多的磁盤可以存儲更多的數(shù)據(jù)6、8或者12塊，取決于存儲量（主要靠緩存）硬盤數(shù)2-4塊內(nèi)存128G或更高48G或更高64G或更高，太高GC可能成為負(fù)擔(dān)48G或更高網(wǎng)絡(luò)雙口萬兆或千兆網(wǎng)卡雙口萬兆或千兆網(wǎng)卡，主要影響裝載速度和節(jié)點(diǎn)間數(shù)據(jù)交換效率雙口千兆網(wǎng)卡雙口萬兆或千兆網(wǎng)卡，對網(wǎng)絡(luò)延時有高要求，如果可以，建議單獨(dú)設(shè)立奇數(shù)個集群，3-5個? 內(nèi)存的選擇：通常情況下，Hadoop處理任務(wù)每個CPU邏輯核（指超線程下，一般一個核對應(yīng)兩個邏輯核）對應(yīng)2G內(nèi)存即可。CPU的選擇：實測表明：Hadoop處理性能與CPU性能密切相關(guān)，任務(wù)運(yùn)行時間與SPEC值基本成反比關(guān)系，因此應(yīng)該選擇性能較高的CPU。服務(wù)器類型：一般的Hadoop項目選擇2U的機(jī)架式服務(wù)器，試點(diǎn)中有公司選擇了多節(jié)點(diǎn)服務(wù)器（2U四節(jié)點(diǎn)），也應(yīng)用得比較好。硬盤掛載建議操作系統(tǒng)盤可以采用SAS或SATA盤，建議采用兩塊硬盤盤做RAID1后作為系統(tǒng)盤，磁盤支持熱插拔，方便運(yùn)維。對于數(shù)據(jù)節(jié)點(diǎn)存放數(shù)據(jù)的磁盤：可以采用SATA降低成本，提高存儲量。由于Hadoop在軟件層面已實現(xiàn)了數(shù)據(jù)的冗余備份，不必要在硬件層面通過RAID再做冗余。在效率提升方面，Hadoop自身的“優(yōu)化策略”推薦HDFS數(shù)據(jù)直接存儲到多塊物理盤，而不采用RAID（已經(jīng)在測試中驗證了這個結(jié)論）3.2.3組網(wǎng)方式建議一個完整的Hadoop集群中的節(jié)點(diǎn)，分為三個角色：Client、Master和Slave，如下:

Clients口扣tributedDataAnalytics口扣tributedDataAnalyticsMapR^duc^1DistributedDataStorageHDFSJahTrJtk^rNameNcdeNameMadernasters]i^ATrad^j-Ta4(Tractor□ataNadeJahTrJtk^rNameNcdeNameMadernasters]i^ATrad^j-Ta4(Tractor□ataNade&Ydskt^jcdc^rS函聲D^taPMd?MInkTrafkcrOntaNode-8.TiskTracfcrrDMaNMe&TuiilrTuclcrr其中Client:部署在用于跟Hadoop進(jìn)行交互的應(yīng)用節(jié)點(diǎn)中。Master節(jié)點(diǎn)用于集群管理，主要與Client進(jìn)行通訊，為Client分配可用的Slave節(jié)點(diǎn)，同時Master會維護(hù)Slaves節(jié)點(diǎn)上報的每個運(yùn)行參數(shù)。角色包括HDFS中的NameNode、SecondaryNameNode、MapRedcue的JobTracker等(MR2是ResourceManage)。Slave節(jié)點(diǎn)是Hadoop中的執(zhí)行者，主要模塊包括：DataNode用于存儲，TaskTracker(MR2為NodeManage)執(zhí)行并行計算。其他可單獨(dú)部署zookeeper節(jié)點(diǎn)集群奇數(shù)個(3-5)個，增加一個NTPserver節(jié)點(diǎn)，實現(xiàn)時間同步。綜合來說，在Hadoop集群中有大量文件讀寫或者M(jìn)apReduce計算任務(wù)提交時候，都會出現(xiàn)大量的網(wǎng)絡(luò)交互，尤其是MapReduce。所以一般建議給Hadoop提供專用的私有網(wǎng)絡(luò)，用于內(nèi)部數(shù)據(jù)的交互，網(wǎng)絡(luò)帶寬為萬兆網(wǎng)(指萬兆以太網(wǎng)或Infiniband網(wǎng)絡(luò)，下同)或千兆，萬兆網(wǎng)不僅僅10倍于千兆網(wǎng)的帶寬，在峰值流量下，其時延也大大低于千兆網(wǎng)。根據(jù)Hortonworks的建議，對于較小的集群至少保證所有節(jié)點(diǎn)點(diǎn)到點(diǎn)千兆網(wǎng)連接，對于更大的集群使用千兆網(wǎng)可能造成性能的下降，在超級的數(shù)據(jù)中心，Yah。。！的做法是同一個機(jī)架的20臺節(jié)點(diǎn)中每臺通過2個千兆網(wǎng)卡綁定的方式和其他節(jié)點(diǎn)通信，對于機(jī)架使用2條萬兆網(wǎng)連接。根據(jù)Hadoop集群數(shù)量不同，可以將集群分為小集群、中級集群和大規(guī)模集群三大類。一般來講，具體個數(shù)與組網(wǎng)與核心交換機(jī)支持的網(wǎng)絡(luò)口數(shù)量，具有較大關(guān)聯(lián)。以下對這三種規(guī)模的集群組網(wǎng)方式進(jìn)行分別描述。小集群節(jié)點(diǎn)規(guī)模：10個節(jié)點(diǎn)內(nèi)主要特征：計算和存儲能力有限，用于進(jìn)行Hadoop以及相關(guān)生態(tài)系統(tǒng)應(yīng)用功能驗證建議組網(wǎng)：T(35kTir(MkerTasitrFacucerDoioMaaeDotabode心饋餒心Da：aNcideualoHaaeMasterReek-i主要關(guān)注點(diǎn)：優(yōu)先考慮升級兼容性Master節(jié)點(diǎn)無需HA。千兆網(wǎng)絡(luò)，也可用萬兆，為后續(xù)擴(kuò)容準(zhǔn)備。預(yù)先考慮擴(kuò)容后的IP劃分。中級集群節(jié)點(diǎn)規(guī)模：10-100節(jié)點(diǎn)；主要特征：企業(yè)級典型集群規(guī)模，總數(shù)據(jù)量在百TB級別（冗余情況下），主要用于進(jìn)行中等規(guī)模數(shù)據(jù)量計算（單次10億級別或者10TB同等數(shù)量級數(shù)據(jù)計算），一般來講，具體節(jié)點(diǎn)個數(shù)受限于上層交換機(jī)口的數(shù)量。建議組網(wǎng)圖:

ROCk-2rcrackgmMe*rowfracfeer□EM皿skirackMMETAjckyrcikziracu?!『gTROCk-2rcrackgmMe*rowfracfeer□EM皿skirackMMETAjckyrcikziracu?!『gT「OCk頒potmooeroskirocite!由幃節(jié)點(diǎn)主要關(guān)注點(diǎn)：集群高可靠，機(jī)架之間通訊使用2條萬兆網(wǎng)卡連接；機(jī)架內(nèi)部通訊使用2條千兆網(wǎng)卡綁定足夠，但考慮后續(xù)擴(kuò)容和以及節(jié)點(diǎn)性能提升（如使用SSD硬盤）也可使用萬兆網(wǎng)卡。HadoopHA:HDFS-HAMapReduce-HA等。機(jī)柜單點(diǎn)，避免Master在同一機(jī)柜。HDFS機(jī)架感知開啟。交換機(jī)HA：使用雙換機(jī)放置不同機(jī)柜VLT方式的可靠性最高，但會帶來連接復(fù)雜性上升，具體可以根據(jù)能力進(jìn)行適當(dāng)調(diào)整。大規(guī)模集群節(jié)點(diǎn)規(guī)模：大于100節(jié)點(diǎn)；主要特性：PB級別以上存儲規(guī)模；MapReduce計算任務(wù)量大，且持續(xù)增加；多場景需求:MapReduce、HDFS、HBase、Hive、ETL、workflow等；多Rack，跨rack數(shù)據(jù)傳輸量頻繁；建議組網(wǎng)圖:主要關(guān)注點(diǎn)：節(jié)點(diǎn)與機(jī)架交換機(jī)使用L2連接。機(jī)架交換機(jī)與核心交換機(jī)使用L3連接。機(jī)架內(nèi)部通訊延遲低于跨機(jī)架時延（Hadoop默認(rèn)策略）。交換機(jī)oversubscription（入出率）比率建議2.5：1（不能高于交換機(jī)最高值）。核心交換機(jī)與Rack數(shù)相關(guān)，Rack數(shù)量與核心交換機(jī)數(shù)量和端口數(shù)成正比，但交換機(jī)不應(yīng)太多，會降低機(jī)架上傳帶寬。機(jī)架交換機(jī)方式的機(jī)柜交換機(jī)的上行鏈路會成為瓶頸，交換機(jī)數(shù)量多，設(shè)備管理復(fù)雜性增加。在核心交換機(jī)端口緊張情況下，可以從機(jī)架交換機(jī)接入外部網(wǎng)關(guān)，提供集群外部訪問能力。3.2.4規(guī)劃節(jié)點(diǎn)規(guī)模時需要考慮的因素1、 計算能力估算應(yīng)依據(jù)小規(guī)?；鶞?zhǔn)測試針對所需的業(yè)務(wù)類型進(jìn)行模擬測試，依據(jù)近似線性擴(kuò)展原理，根據(jù)業(yè)務(wù)需求可計算出計算能力節(jié)點(diǎn)個數(shù)?？紤]到擴(kuò)容及其他因素影響，建議預(yù)留30%的計算能力冗余。2、 存儲能力估算壓縮比、副本數(shù)、冗余量的考慮將影響存儲能力評估，需要預(yù)先確定?？梢詤⒖即斯竭M(jìn)行估算：（業(yè)務(wù)估算數(shù)據(jù)量*壓縮比*副本數(shù)）/冗余量當(dāng)HDFS剩余空間較小時會影響性能。建議冗余量設(shè)置為30%。進(jìn)行HBase存儲估算時，需要考慮數(shù)據(jù)膨脹率，一般來講可以為2。3、其余節(jié)點(diǎn)估算除了Master節(jié)點(diǎn)和Slave節(jié)點(diǎn)外，還應(yīng)對接口機(jī)、監(jiān)控運(yùn)維、調(diào)度預(yù)留機(jī)器。3.3建設(shè)過程中的建議本節(jié)主要對Hadoop平臺搭建和配置過程中遇到的問題提出建議。3.3.1 對壓縮的考慮在大數(shù)據(jù)平臺中，米用合理的壓縮算法不僅能節(jié)省存儲，而且還由于減少了IO的數(shù)據(jù)量而在大部分場景中可以縮短處理時間。因此在系統(tǒng)搭建過程中應(yīng)提前確定壓縮的策略。Hadoop的HDFS中可以米用的壓縮算法及其特點(diǎn)如下表：工具算法文件擴(kuò)展名多文件可分割性（支持MR并行處理）壓縮率（壓縮至）*snappysnappySnappy是是約37%gzipDEFLATE■gz不不約25%zipDEFLATE.zip是是,在文件范圍內(nèi)約22%bzip2bzip2.bz2不是約18%IzopLZO.lzo不是約35%*壓縮率是試點(diǎn)中測試結(jié)果，不同的數(shù)據(jù)壓縮率并不一樣。以上壓縮格式的壓縮率為bzip2〉gzip〉lzo〉snappy。但是壓縮率高通常代表壓縮和解壓時間長，綜合多個試點(diǎn)省對于各種壓縮格式性能比較的測試結(jié)果，大致得到以下結(jié)果：snappy〉lzo〉gzip〉nocompress〉bzip2。所以在不同的場景下，宜選擇不一樣的壓縮方式，主要可能有以下場景：1、 原始數(shù)據(jù)就是壓縮的，那么最好按照原始數(shù)據(jù)的壓縮格式直接上傳HDFS，在HDFS中并行處理過程中可以順帶解壓。這樣可以縮短裝載時間（壓縮數(shù)據(jù)量少）。2、 MapReduce或者Hive的中間結(jié)果的壓縮?？梢栽贛apReduce程序中設(shè)置Map后的中間結(jié)果用壓縮模式，然后交給Reduce，試點(diǎn)中我們發(fā)現(xiàn)可以節(jié)約處理時間，特別是對那種在Map和Reduce中有大量數(shù)據(jù)交換的操作，例如常規(guī)的Join。Hive中也是類似。這種情況下，適合采用snappy與lzo這種壓縮解壓性能快的壓縮算法。以下代碼顯示了啟用rnap輸出壓縮和設(shè)置壓縮格式的配置屬性。conf.setCompressMapOutput(true);conf.setMapOutputCompressorClass(GzipCodec.class);3、處理后數(shù)據(jù)或者冷數(shù)據(jù)的壓縮。這些數(shù)據(jù)可以采用壓縮率稍高的算法進(jìn)行壓縮以節(jié)約空間，比如Zip或Bzip2,特別是在冷數(shù)據(jù)歸檔的情況下。但如果數(shù)據(jù)可能會頻繁被即席查詢的話，還是應(yīng)該選擇解壓速度快一些的壓縮算法。壓縮的設(shè)置：如果要壓縮MapReduce作業(yè)的輸出，請在作業(yè)配置文件中將press屬性設(shè)置為true。將pression.codec屬性設(shè)置為自己打算使用的壓縮編碼/解碼器的類名。3.3.2HBase設(shè)計與傳統(tǒng)技術(shù)不一樣，Hadoop沒有走產(chǎn)品化的道路，其中的組件可定制程度非常高。這一方面提高了效率，另一方面也對使用人員提出了更高要求。HBase就是如此，合理的HBase設(shè)計可以極大提高查詢性能。可以考慮如下設(shè)計要素：Rowkey設(shè)計HBase表的rowkey設(shè)計，一般是將關(guān)系數(shù)據(jù)庫中的候選key拼接形成。但是要注意熱點(diǎn)問題，比如rowkey開始的幾位是時間排序，那么在插入的時候，最近幾天的數(shù)據(jù)很可能是熱點(diǎn)數(shù)據(jù)，這樣所有的查詢可能都指向了一個regionserver導(dǎo)致了HBase的性能瓶頸。盡量避免使用單調(diào)遞增的rowkey，因為在添加數(shù)據(jù)的時候，所有的新數(shù)據(jù)都添加到最后一個region，前面的region沒有或者很少有請求，也是熱點(diǎn)問題。熱點(diǎn)問題的處理方式一般是"加鹽”，即在rowkey前面添加hash數(shù)，來對數(shù)據(jù)進(jìn)行hash劃分。列簇設(shè)計HBase表的ColumnFamily最好少于4,一般少于3,對于一般數(shù)據(jù)放入一個列簇中即可。對于一些強(qiáng)關(guān)聯(lián)，頻繁訪問的數(shù)據(jù)可以放一列，這樣在取數(shù)據(jù)時，熱點(diǎn)訪問只用取這一列數(shù)據(jù)，可以節(jié)省IO。多個列簇有各自memstore，memstore開銷大，而且flush一個列簇，其他的類簇也會flush，會造成不必要的開銷。Region劃分HBase在導(dǎo)入大量數(shù)據(jù)前最好預(yù)先劃分region，這樣可以加快導(dǎo)入效率。同時也要避免使用HBase自動劃分region，在一種情況下，HBase面臨大量寫入或者scan請求，同時它的region中的數(shù)據(jù)又達(dá)到了閥值，那么它會啟動自動劃分region，有可能導(dǎo)致region劃分風(fēng)暴，大量的請求會使regionserver和namenode的壓力過大而導(dǎo)致regiondead或者namenodedead。?使用TTLTTL(timetolive)，它一般可以用來控制數(shù)據(jù)的生存時間。一些數(shù)據(jù)比如客戶幾年以前的數(shù)據(jù)，幾年以后已經(jīng)不關(guān)心這些數(shù)據(jù)，可以使用TTL刪除。如果數(shù)據(jù)沒有這些要求，可以不使用。3.3.3 參數(shù)設(shè)置建議本節(jié)主要討論重點(diǎn)參數(shù)的設(shè)置建議。副本個數(shù)副本數(shù)設(shè)置建議按照Hadoop默認(rèn)的3副本，這可以有效防止硬盤受損、機(jī)器或機(jī)架故障導(dǎo)致數(shù)據(jù)丟失或損壞。設(shè)置參數(shù)為hdfs-site.xml文件中的dfs.replication參數(shù)。但在實際的生產(chǎn)中，為了節(jié)省存儲或者提高處理效率，可以考慮采取動態(tài)的副本創(chuàng)建策略。比如對于非主營業(yè)務(wù)或者臨時需求，原始數(shù)據(jù)裝載到HDFS時可以選擇一副本或者兩副本從而提高裝載和出數(shù)效率，也可以節(jié)省存儲空間?？梢栽谏蟼鲿r設(shè)定副本個數(shù)為n：hadoopdfs-Ddfs.replication=n-put<src><dest>也可以之后修改副本個數(shù)bin/hadoopdfs[-setrep[-R][-w]<rep><path/file>...]也可以查看副本個數(shù)查看當(dāng)前hdfs的副本數(shù)hadoopfsck-locations塊大小HDFS塊大小，默認(rèn)是64M(某些發(fā)布版是128M,比如CDH)。但考慮到目前機(jī)器CPU的計算能力普遍很高，對于MapReduce在做Map的時候可以處理比較大的單個文件，目前一般建議Blocksize設(shè)置稍微大一點(diǎn)，比如256M或者512M。但跟實際應(yīng)用場景相關(guān)，需要根據(jù)不同的硬件環(huán)境以及應(yīng)用場景進(jìn)行相關(guān)測試，然后得出最佳設(shè)置。Slot數(shù)（Mapreduce1.x）Slot數(shù)主要是指以下兩個參數(shù)的的設(shè)置與搭配mapred.tasktracker.map.tasks.maximum每臺tasktracker允許啟動的最大map槽位數(shù)，官方建議為：（CPU數(shù)量〉2）?（CPU數(shù)量*0.75）:1mapred.tasktracker.reduce.tasks.maximum每臺tasktracker允許啟動的最大reduce槽位數(shù)，官方建議為：（CPU數(shù)量〉2）?（CPU數(shù)量*0.50）:1根據(jù)各個省試點(diǎn)的經(jīng)驗，無論是map槽數(shù)還是reduce槽數(shù)一般設(shè)置為CPU核數(shù)的1~2倍，map和reduce的槽數(shù)配比一般為2:1。但跟實際應(yīng)用場景相關(guān)，需要根據(jù)不同的硬件環(huán)境以及應(yīng)用場景進(jìn)行相關(guān)測試，然后得出最佳設(shè)置。其他配置參數(shù)（Hadoop1.x）Hdfs配置文件hdfs-site.xml參數(shù)名參數(shù)值說明dfs.datanode.data.dirDatanode的數(shù)據(jù)目錄：如果datanode對應(yīng)的機(jī)器上有多塊磁盤 ， 例 如/disk1-/disk3,dfs.data.dir可以 配 置為”/disk1/data,/disk2/data,/disk3/data”，datanode會在寫數(shù)據(jù)時，以輪詢的方式選擇一個目錄寫入數(shù)據(jù)，一般這些目錄是不同的塊設(shè)備，不存在的目錄會被忽略掉，參考配置屬性dfs.data.dir.datanode如果有多

個磁盤不建議做raid,因為做raid會有性能損失，還會導(dǎo)致一個磁盤壞了，整個硬盤也不能用了，而Hadoop可以規(guī)避這個問題。.dir兀數(shù)據(jù)保存目錄設(shè)置多個，保證數(shù)據(jù)可靠性dfs.datanode.balancer.bandwidthPerSec在帶寬和機(jī)器數(shù)允許的情況下，設(shè)置數(shù)據(jù)均衡傳輸量為10M/s或更大，加快均衡速度erval1440設(shè)置需要支持回撤周期（單位為分鐘）.回撤操作：在刪除文件的當(dāng)前目錄下（HDFS中）有.Trash目錄，講目錄中對應(yīng)文件移到當(dāng)前目錄即可。?MapReduce配置文件：core—site.xml參數(shù)名參數(shù)值說明Hadoop.tmp.dir/data2/tmphadoop文件系統(tǒng)依賴的基礎(chǔ)配置，默認(rèn)在/tmp里，默認(rèn)情況下master會將兀數(shù)據(jù)等存在這個目錄下，而slave會將所有上傳的文件放在這個目錄下，由于上傳到Hadoop的所有文件都會被存放在hadoop.tmp.dir所指定的目錄，所以要確保這個目錄是足夠大的，但是對掛載磁盤的10性能壓力比較大

文件：mapred-site.xml參數(shù)名參數(shù)值說明mapred.jobtracker.taskSchedulerOrg.Apache.Hadoop.mapred.FairScheduler公平調(diào)度，可以讓多個job并行，需要額外的jar包sdefault.tbequeue自定義公平調(diào)度名稱mapred.fairscheduler.allocation.公平調(diào)度的配置文件mapred.map.child.java.opts-Xmxl024設(shè)定每個map的jvm大小，使spill過程有足夠的內(nèi)存，減少磁盤IOmapred.reduce.child.java.opts-Xmx2048設(shè)定每個reduce的jvm大小，減少磁盤IOmapred.tasktracker.map.tasks.maximum8容忍的map作業(yè)最大并發(fā)個數(shù)按照前面的slot數(shù)量設(shè)置mapred.tasktracker.reduce.tasks.maximum8容忍的reduce作業(yè)最大并發(fā)個數(shù)同上pression.codec默認(rèn)Map結(jié)果輸出的默認(rèn)壓縮算法mapred.task.timeout默認(rèn)MapReduce任務(wù)默認(rèn)的超時設(shè)置mapred.min.split.sizesplit輸入最小尺寸，決定了Map任務(wù)數(shù)量mapred.reduce.tasks設(shè)定reduce任務(wù)數(shù)量Tasktracker的中間輸出目錄：mapred.local.dir。map和reduce任務(wù)MapReduce產(chǎn)生的中間數(shù)據(jù)會特別多，為了減少磁盤壓力，如果機(jī)器有多個磁盤，也可以像datanode的數(shù)據(jù)目 錄 設(shè)為”/diskl/local,/disk2

/local,/disk3/local^文件：Hadoop-env.sh參數(shù)名參數(shù)值說明HADOOP_HEAPSIZE4000Hadoop所有進(jìn)程的jvm配置參數(shù)，包括namenode/jobtracker/datanode/tasktracker所使用的最大內(nèi)存?HBase配置文件：HBase-env.sh參數(shù)名參數(shù)值說明HBASE_HEAPSIZE8192（根據(jù)實際情況考慮）HBase所使用的最大內(nèi)存HBASE_MANAGES_ZKFalse設(shè)置HBase不自行管理zk服務(wù)，需額外提供zk集群的服務(wù)文件：HBase-site.xml參數(shù)名參數(shù)值說明HBase.regionserver.handler.count20RegionServer的請求處理IO線程數(shù)，對于咼并發(fā)，適當(dāng)調(diào)咼以提升性能HBase.hregion.max.53687091200region分割的閥值，適當(dāng)設(shè)大以減少region分裂的次數(shù)HBase.hregion.majorcompaction0關(guān)閉自動major_compact,默認(rèn)是1天進(jìn)行1次對table的storefile記性合并清理，在保證集群性能的前提下，由運(yùn)維人員進(jìn)行該操作可以避免高峰期，會更靈活HBase.rpc.timeout600000節(jié)點(diǎn)間通信等待時間，主要是為了減少高并發(fā)時，延長節(jié)點(diǎn)間響應(yīng)等待時間HBase.client.pause3000客戶端在重試前的等待時間HBase.regionserver.global.memstore.upperLimit0.39memstore占heap的最大百分比，直接影響寫的性能h0.4storefile的讀緩存占用Heap的大小百分比，該值直接影響數(shù)據(jù)讀的性能HBase.hregion.memstore.flush.sizeRegion上MemStore的大小是64MBHBase.regionserver.handler.count一個RegionServer的最大并發(fā)handler數(shù)目HBase.regionserver.coprocessorhandler.count一個RegionServer的coprocessor最大并發(fā)handler數(shù)目3.3.4系統(tǒng)調(diào)優(yōu)Hive1、 少用count(distinct)例如：selectcount(distinctUSR_MOB_NBR)fromODS.TO_CDR性能差的原因：只會用一個reduce去處理。優(yōu)化的寫法：selectcount(1)from(selectUSR_MOB_NBRfromODS.TO_CDRgroupbyUSR_MOB_NBR)x;2、 表關(guān)聯(lián)時，過濾條件寫在合適的位置例如：selecta.USR_MOB_NBR,sum(a.MOB_FEE),sum(b.call_cnt)fromhive_test_to_cdraleftouterjoinhive_test_to_cdr2BonA.USR_MOB_NBR=b.USR_MOB_NBRandb.call_cnt>10whereA.DIR_TYP_CDIN('3','5','6')groupbyA.USR_MOB_NBR性能差的原因：這樣寫會導(dǎo)致先關(guān)聯(lián)，后過濾優(yōu)化的寫法：selecta.USR_MOB_NBR,sum(a.MOB_FEE),sum(b.call_cnt)from(select*fromhive_test_to_cdrwhereDIR_TYP_CDIN('3','5','6'))aleftouterjoinhive_test_to_cdr2BonA.USR_MOB_NBR=b.USR_MOB_NBRandb.call_cnt>10groupbyA.USR_MOB_NBR3、 MapjoinMAPJION會把小表全部讀入內(nèi)存中，在map階段直接拿另外一個表的數(shù)據(jù)和內(nèi)存中表數(shù)據(jù)做匹配，由于在map是進(jìn)行了join操作，省去了reduce運(yùn)行的效率也會高很多這樣就不會由于數(shù)據(jù)傾斜導(dǎo)致某個reduce上落數(shù)據(jù)太多而失敗。于是原來的sql可以通過使用hint的方式指定join時使用mapjoin。select/*+mapjoin(A)*/f.a,f.bfromAtjoinBfon(f.a=t.aandf.ftime=20110802)相關(guān)參數(shù)：hive.mapjoin.cache.numrows=25000hive.mapjoin.smalltable.4、 BucketedMapJoinBucketedmapjoin是一種特殊的mapsidejoin，其針對的是所有的表都使用待join的key作為bucket列，并且bucket數(shù)量彼此有倍數(shù)關(guān)系的場景。在這種場景下，由于不需要將整張表導(dǎo)入內(nèi)存，只需要將相應(yīng)的bucket導(dǎo)入內(nèi)存，因此，適宜一些數(shù)據(jù)量比較大的表。例如，Tablea使用key作為bucket列，共有8個bucket，Tableb也是用key作為bucket列，有16個bucket,則使用Mapsidejoin，a只需要將b對應(yīng)的2個bucket放入內(nèi)存即可，如下：SELECT/*+MAPJOIN(b)*/a.key,a.valueFROMajoinbona.key=b.key5、 合理使用Map端部分聚合并不是所有的聚合操作都要在Reduce端完成，很多聚合操作都可以先在Map端進(jìn)行部分聚合，最后在Reduce端得出最終結(jié)果。相關(guān)參數(shù)：hive.map.aggr=true是否在Map端進(jìn)行聚合，默認(rèn)為Truehive.groupby.mapaggr.checkinterval=100000在Map端進(jìn)行聚合操作的條目數(shù)目6、 防止數(shù)據(jù)傾斜當(dāng)出現(xiàn)數(shù)據(jù)傾斜的時候，我們可以采用Hive提供的通用的方法來進(jìn)行負(fù)載均衡，相關(guān)參數(shù):hive.groupby.skewindata=false當(dāng)選項設(shè)定為true，生成的查詢計劃會有兩個MRJob。第一個MRJob中，Map的輸出結(jié)果集合會隨機(jī)分布到Reduce中，每個Reduce做部分聚合操作，并輸出結(jié)果，這樣處理的結(jié)果是相同的GroupByKey有可能被分發(fā)到不同的Reduce中，從而達(dá)到負(fù)載均衡的目的；第二個MRJob再根據(jù)預(yù)處理的數(shù)據(jù)結(jié)果按照GroupByKey分布到Reduce中(這個過程可以保證相同的GroupByKey被分布到同一個Reduce中)，最后完成最終的聚合操作。7、 合理使用列裁剪(ColumnPruning)在讀數(shù)據(jù)的時候，只讀取查詢中需要用到的列，而忽略其他列。例如，對于查詢：SELECTa,bFROMTWHEREe<10;其中，T包含5個列(a,b,c,d,e),列c，d將會被忽略，只會讀取a,b,e列這個選項默認(rèn)為真：hive.optimize.cp=true8、 大表與小表關(guān)聯(lián)使用普通Join時候，將小表放在前面，大表放在后面，這樣會優(yōu)化最后一個MapReduce過程。9、合并小文件文件數(shù)目過多，會給HDFS帶來壓力，并且會影響處理效率，可以通過合并Map和Reduce的結(jié)果文件來消除這樣的影響：hive.merge.mapfiles=true//是否和并Map輸出文件，默認(rèn)為Truehive.merge.mapredfiles=false//是否合并Reduce輸出文件，默認(rèn)為Falsehive.merge.size.per.task=256*1000*1000//合并文件的大小10、 打散文件當(dāng)數(shù)據(jù)量比較大，我們需要更快的完成任務(wù)，多個map和reduce進(jìn)程是唯一的選擇。但是如果輸入文件是一個的話，map任務(wù)只能啟動一個。此時buckettable是個很好的選擇，通過指定CLUSTERED的字段，將文件通過hash打散成多個小文件。11、 合并輸入小文件表數(shù)據(jù)的小文件很多時，一個mapreducejob會啟動很多map任務(wù)(缺省每個文件一個map),造成大量不必要的系統(tǒng)調(diào)度開銷，這個問題可以通過使用Combine來解決，幾個map可輸入多個小文件，設(shè)置如下，hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat例如Text表src_mmsclog有200個比較小的文本文件，總共70M，查詢selectcount(1)fromsrc_mmsclog;未使用Combine前，會產(chǎn)生200個map任務(wù)，通過設(shè)置，hugetable〉 sethive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;hugetable>selectcount(1)fromsrc_mmsclog;就只產(chǎn)生一個map任務(wù)了。MapReduceMapReduce1、 選擇合適的壓縮格式輸入文件的壓縮格式大大影響MapReduce的執(zhí)行效率，具體請參考軟件參數(shù)建議的壓縮算法一節(jié)。2、 壓縮Map中間輸出在Map任務(wù)完成后對將要寫入磁盤的數(shù)據(jù)進(jìn)行壓縮是一種很好的優(yōu)化方法，它能夠使數(shù)據(jù)寫入磁盤的速度更快，節(jié)省磁盤空間，減少需要傳送到Reducer的數(shù)據(jù)量，以達(dá)到減少M(fèi)apReduce作業(yè)執(zhí)行時間的目的。相關(guān)參數(shù)：press=true，pression.codec=org.Apache.Hpress.SnappyCodec。3、 使用Combiner函數(shù)Combiner相當(dāng)于是本地的Reduce，它是用Reducer接口來定義的，只對本節(jié)點(diǎn)生成的數(shù)據(jù)進(jìn)行規(guī)約?？梢詼p少map與reduce階段之間Shuffle的數(shù)據(jù)量，較低的網(wǎng)絡(luò)流量縮短了執(zhí)行時間。4、 控制Map個數(shù)如果輸入文件是多個很小的文件，如果直接運(yùn)行MapReduce會導(dǎo)致map個數(shù)過多而影響整體性能，建議在裝載到HDFS之前對文件進(jìn)行合并，從而避免了maptask過多的現(xiàn)象，提高了處理性能。5、 選擇合適的join方式關(guān)聯(lián)時根據(jù)實際情況采用不同的處理方式，一般關(guān)聯(lián)大表采用reduce端關(guān)聯(lián)，關(guān)聯(lián)小表采用map端關(guān)聯(lián)，以提高處理性能。對大表關(guān)聯(lián)，一般先將父表的外鍵和子表的主鍵相同的記錄歸到同一組，然后進(jìn)行關(guān)聯(lián)。對小表關(guān)聯(lián)，一般使用哈希表保存子表（通常是維表），然后通過查詢哈希表進(jìn)行關(guān)聯(lián)。6、 代碼重構(gòu)與算法優(yōu)化在滿足業(yè)務(wù)功能的情況下，調(diào)整程序代碼，優(yōu)化算法，提升性能，提高M(jìn)apReduce代碼的擴(kuò)展性和維護(hù)性。HBaseScanCaching在對HBase表進(jìn)行掃描時，可以設(shè)置scancaching的大小，一般為1000左右，這樣可以避免默認(rèn)的一次一條記錄的scan導(dǎo)致的大量遠(yuǎn)程調(diào)用。配置項HBase.ipc.client.tcpnodelay設(shè)置為true，可以提升HBase性能HBase.master.loadbalance.bytable設(shè)置為trueHBase.regionserver.checksum.verify設(shè)置為true，可以避免hdfs層的驗證HBase.client.read.shortcircuit設(shè)置為true，這樣可以提高HBase的locality3.3.5 上線前注意事項Hadoop平臺上線前準(zhǔn)備與驗證主要從對數(shù)，正確率，數(shù)據(jù)入庫完整性，數(shù)據(jù)入庫邏輯失真，特殊字符失真，數(shù)據(jù)匯總邏輯等幾方面。以下提供評估參考格式:實施事件實施內(nèi)容上線前準(zhǔn)備提前對環(huán)境、空間、版本等檢查提前對環(huán)境、空間、版本等檢查提前部署應(yīng)用Hadoop平臺部署導(dǎo)出靜態(tài)數(shù)據(jù)和配置數(shù)據(jù)應(yīng)用規(guī)格數(shù)據(jù)提前進(jìn)行系統(tǒng)事務(wù)通告、申告通知各部門大數(shù)據(jù)系統(tǒng)上線上線及驗證導(dǎo)入靜態(tài)和配置數(shù)據(jù)導(dǎo)入準(zhǔn)備好的應(yīng)用規(guī)格數(shù)據(jù)啟動系統(tǒng)應(yīng)用執(zhí)行相關(guān)腳本啟動應(yīng)用系統(tǒng)數(shù)據(jù)入庫完整性通過對數(shù)，防止數(shù)據(jù)丟失，保證數(shù)據(jù)完整性數(shù)據(jù)入庫邏輯驗證如：原系統(tǒng)生成DW寬表時截取URL到60字節(jié)并進(jìn)行匯總，以適應(yīng)其處理能力，由此DW寬表已經(jīng)不能反映數(shù)據(jù)原貌需要恢復(fù)正常邏輯。特殊字符稽核如：原系統(tǒng)處理時對WAP記錄中的某些字符如"[”,“]”,“{”,“}"等存在限制，導(dǎo)致匯總結(jié)果失真，新的基于Hadoop的處理流程無此類限制匯總邏輯稽核原系統(tǒng)由于存儲與計算資源緊張，在匯總計算過程中采取了一些嚴(yán)格來說不準(zhǔn)確的做法來節(jié)約存儲和計算資源開銷；新的基于Hadoop平臺的匯總邏輯不存在此類問題。驗證系統(tǒng)功能驗證應(yīng)用系統(tǒng)其他相關(guān)功能。.6上線后效果評估Hadoop平臺搭建后應(yīng)及時評估建設(shè)效果，可以從功能、性能、高可用、系統(tǒng)資源占用、成本（軟硬件）等幾方面。以下提供評估參考格式：HADOOP平臺對比平臺計算能力CPU，內(nèi)存CPU，內(nèi)存存儲能力存儲存儲運(yùn)維成本占地機(jī)柜機(jī)柜電源功耗KWH/0KWH/日維護(hù)硬件成本計算能力x萬元x萬元存儲能力總計（元）x萬元x萬元軟件成本挖掘工具數(shù)據(jù)倉庫性能數(shù)據(jù)處理性能入庫性能咼可用橫向擴(kuò)展能力3.4運(yùn)維階段的建議Hadoop系統(tǒng)因為其分布式特性，可以容忍一定數(shù)量節(jié)點(diǎn)的異常，不影響其整體可用性。異常處理被定義為正常運(yùn)維操作，所以相應(yīng)的運(yùn)維管理有其特殊性，比如：對自動化程度要求比較高，關(guān)鍵節(jié)點(diǎn)可靠性要求高。對應(yīng)運(yùn)維管理中，應(yīng)該包括監(jiān)控、告警、部署、配置、日志、安全以及升級等功能。具體每個子模塊，應(yīng)該包括相應(yīng)基礎(chǔ)能力。開源社區(qū)中的Ambari是一個開源軟件，整合了多個工具以實現(xiàn)hadoop的自動部署、監(jiān)控和告警。運(yùn)維管理階段，應(yīng)提供統(tǒng)一的圖形化管理平臺，使得運(yùn)維人員可以在前臺進(jìn)行監(jiān)控、維護(hù)、部署等工作。而不需要在后臺命令行方式下進(jìn)行。目前開源Hadoop自帶UI中，監(jiān)控粒度比較大，只能查詢到節(jié)點(diǎn)運(yùn)行是否正常,MapReduce任務(wù)執(zhí)行進(jìn)度和結(jié)果，以及HBase數(shù)據(jù)訪問日志。無法對整個Hadoop平臺當(dāng)前運(yùn)行指標(biāo)進(jìn)行綜合評估與展示。建議使用開源軟件或者第三方廠商提供的運(yùn)維和管控平臺。運(yùn)維管理功能建議與現(xiàn)有數(shù)據(jù)中心的體系進(jìn)行結(jié)合，實現(xiàn)運(yùn)維層面的統(tǒng)一視圖。需要特別注意Hadoop的安全方面的管控。任務(wù)調(diào)度需要具備以下作業(yè)編排、調(diào)度、管理能力：1、 腳本的調(diào)度能力，包括JAVA、Python、tel、Hive等腳本。2、 支持按時間、事件、前置的觸發(fā)機(jī)制，可以按照任務(wù)類型、時間、區(qū)域等設(shè)置好的條件進(jìn)行任務(wù)的調(diào)度。3、 靈活的多依賴關(guān)系設(shè)定，通過依賴關(guān)系的設(shè)置，可以前置、后置觸發(fā)、支持多任務(wù)實例觸發(fā)、單任務(wù)多實例觸發(fā)的調(diào)度方式。4、 支持資源、并發(fā)控制，支持優(yōu)先級設(shè)置。實現(xiàn)調(diào)度平臺大、小任務(wù)的資源均衡分配,避免資源使用過載。5、 提供圖形化配置界面，提供作業(yè)的定義、編排管理。使得業(yè)務(wù)人員能夠簡單快速的完成作業(yè)編排與運(yùn)行。以上能力最好是擴(kuò)充數(shù)據(jù)中心現(xiàn)有調(diào)度平臺進(jìn)行實現(xiàn)，以便實現(xiàn)統(tǒng)一調(diào)度和高效運(yùn)維。監(jiān)控管理提供業(yè)務(wù)、應(yīng)用、平臺、設(shè)備層面全方位的監(jiān)控能力，提供故障的及時發(fā)現(xiàn)、及時告警能力及優(yōu)化診斷能力?；A(chǔ)指標(biāo)監(jiān)控包括：機(jī)器性能指標(biāo)：如磁盤10、CPU使用率、硬盤使用率、網(wǎng)絡(luò)帶寬占用率集群性能指標(biāo)：基礎(chǔ)機(jī)器指標(biāo)進(jìn)行計算后的相關(guān)指標(biāo)數(shù)據(jù)，如平均使用率、機(jī)器使用熱度分布、機(jī)器空閑率等、JVM使用率等業(yè)務(wù)指標(biāo)監(jiān)控，包含大數(shù)據(jù)平臺中的主要模塊關(guān)鍵業(yè)務(wù)參數(shù)值等以上監(jiān)控能力最好能與數(shù)據(jù)中心或這B0MC現(xiàn)有監(jiān)控能力進(jìn)行集成，實現(xiàn)統(tǒng)一的監(jiān)控。告警管理告警管理主要用于針對大數(shù)據(jù)平臺重要事件、主要監(jiān)控指標(biāo)發(fā)送告警信息，提醒運(yùn)維人員即使進(jìn)行后續(xù)處理操作。3.4.4部署管理部署管理主要用于Hadoop平臺部署、擴(kuò)容、升級等操作。通過自動化方式提供設(shè)備、平臺、服務(wù)的部署、配置、升級管理能力。為運(yùn)維人員提供快速上線、快速部署、維護(hù)的支撐平臺，降低大數(shù)據(jù)平臺的運(yùn)維復(fù)雜度。部署管理功能主要包括：集群主機(jī)統(tǒng)一管理，為運(yùn)維人員提供一個集中的操作維護(hù)平臺，實現(xiàn)服務(wù)更新、啟停集中維護(hù)操作功能。分布式集群節(jié)點(diǎn)管理，支持集群中在線添加、移除或者遷移計算節(jié)點(diǎn)、存儲節(jié)點(diǎn)。能夠在節(jié)點(diǎn)上自動部署監(jiān)控管理相關(guān)代理，實現(xiàn)后續(xù)節(jié)點(diǎn)的監(jiān)控、服務(wù)管理能力。分布式集群服務(wù)管理，支持在集群節(jié)點(diǎn)上安裝、移除服務(wù)，包括HDFS分布式文件服務(wù)、Map\Reduce分布式計算服務(wù)等。Hadoop的自有的部署管理都是在命令行方式下執(zhí)行的，這種操作方式對運(yùn)維人員要求非常高，在集群規(guī)模超過30臺以上時，異常問題的排查將會非常耗時間。可以采用開源部署工具如puppet降低部署管理復(fù)雜度，也可以使用其他發(fā)行版的工具。配置管理配置管理主要用于通過自動化方式實現(xiàn)大數(shù)據(jù)平臺配置信息快速同步，避免手動修改造成的人為錯誤，提高可靠性，尤其在系統(tǒng)調(diào)優(yōu)的情況下經(jīng)常使用。具體功能包括：配置文件修改同步配置文件修改歷史記錄安全管理在滿足業(yè)務(wù)的安全管理要求（例如4A、金庫模式等）的前提下，針對Hadoop平臺的特點(diǎn)，還應(yīng)加強(qiáng)以下三個方面的安全管理：網(wǎng)絡(luò)方面。Hadoop需要有獨(dú)立的子網(wǎng)，并隔離來自外網(wǎng)的所有訪問，只能通過網(wǎng)關(guān)或者指定的Client（例如內(nèi)部堡壘主機(jī)）訪問Hadoop集群。認(rèn)證方面。需要開啟Hadoop的Kerberos認(rèn)證機(jī)制，以便實現(xiàn)集群內(nèi)各個節(jié)點(diǎn)的互相認(rèn)證，防止有節(jié)點(diǎn)冒充的情況；并實現(xiàn)對信任客戶端的認(rèn)證，確保他們可以執(zhí)行相關(guān)作業(yè)，防止惡意冒充。敏感數(shù)據(jù)的去隱私化。需要利用加密算法對存儲在Hadoop平臺上的話單、上網(wǎng)日志等敏感信息中用戶號碼進(jìn)行加密，確保即使惡意用戶突破前述層層防線拿到數(shù)據(jù)后也無法窺探客戶隱私。3.4.7日志管理日志管理用于搜集Hadoop平臺的關(guān)鍵業(yè)務(wù)日志，便于運(yùn)維和上層研發(fā)人員定位系統(tǒng)問題，提高異常處理速度。主要功能包括：日志搜集日志查詢?nèi)罩炯墑e過濾模塊日志搜集開關(guān)在配置Hadoop時候，可以將日志目錄配置在統(tǒng)一目錄下，便于查詢。但仍由于是分布式系統(tǒng)，日志是分散在不同節(jié)點(diǎn)上，這導(dǎo)致日志查詢和管理上非常不方便。Hadoop中使用Log4j和sl4j作為日志輸出模塊，可以修改Hadoop安裝目錄下的perties配置文件，配置到指定目錄即可。同時由于節(jié)點(diǎn)多，日志量大，需要定時清理日志。建議采用如下措施：修改日志級別和適配器，將日志統(tǒng)一存儲在共享存儲介質(zhì)上。使用第三方產(chǎn)品提供的日志搜集和管理模塊。3.5組織和培訓(xùn)建議Hadoop平臺的引入不同于其他商業(yè)軟件，由于其開源性造成多個發(fā)行版并存，有的發(fā)行版修改了底層代碼，有的發(fā)行版是通過“外掛”的方式進(jìn)行增強(qiáng)，而且一些廠家根據(jù)自家的硬件進(jìn)行了特別的代碼優(yōu)化，所以必須增強(qiáng)自有人員掌控核心技術(shù)，否則有被廠商鎖定的風(fēng)險。除了配備專門人員外，還應(yīng)該加強(qiáng)對這些人員的培訓(xùn)。3.5.1 人員安排建議引入Hadoop平臺后，主要需要增加開發(fā)人員、運(yùn)維人員、監(jiān)控人員、專家組等角色，開發(fā)可以考慮外包。具體如下：1、 開發(fā)人員：職能：作業(yè)編排與業(yè)務(wù)邏輯的實現(xiàn)技術(shù)要求：要求熟悉ETL工具的使用，熟悉HQL語法，能夠熟練編寫HQL語句。2、 運(yùn)維人員：職能：Hadoop集群維護(hù)技術(shù)要求：除傳統(tǒng)的運(yùn)維技能要求外，需熟悉Hadoop、Hive原理及常見問題的處理方法。熟悉Hadoop相關(guān)參數(shù)的意義及配置方法。能夠借助運(yùn)維管理平臺，實現(xiàn)Hadoop、hive、HBase相關(guān)服務(wù)的安裝、啟停等。能夠借助于分析工具進(jìn)行常見問題的定位于解決。3、 監(jiān)控人員：職能：平臺、業(yè)務(wù)故障監(jiān)控技術(shù)要求：熟悉Hadoop基本概念及功能。能夠借助監(jiān)控平臺進(jìn)行告警分析及處理。4、 專家組職能：Hadoop平臺建設(shè)規(guī)劃及疑難問題處理，歸納總結(jié)監(jiān)控運(yùn)維過程中出現(xiàn)的問題，并形成知識庫。技術(shù)要求：熟悉Hadoop原理，有豐富的Hadoop實施經(jīng)驗，能夠快速定位Hadoop平臺出現(xiàn)的問題，并給出意見。3.5.2培訓(xùn)建議建議進(jìn)行如下方面的培訓(xùn)：Hadoop技術(shù)架構(gòu)、運(yùn)行機(jī)制Hadoop環(huán)境規(guī)劃及部署Hadoop集群管理及優(yōu)化Hadoop架構(gòu)原理及使用場景Hadoop運(yùn)維管理平臺的使用HQL語法及調(diào)優(yōu)4MPP數(shù)據(jù)庫指導(dǎo)意見MPP數(shù)據(jù)庫即大規(guī)模并行處理數(shù)據(jù)庫，其中每個節(jié)點(diǎn)內(nèi)的CPU不能直接訪問另一個節(jié)點(diǎn)的內(nèi)存，節(jié)點(diǎn)之間的信息交互通過節(jié)點(diǎn)互聯(lián)網(wǎng)絡(luò)實現(xiàn)，系統(tǒng)采用不共享資源（Share-Nothing）架構(gòu)，資源的水平擴(kuò)展比較容易實現(xiàn)。MPP數(shù)據(jù)庫詳細(xì)技術(shù)特點(diǎn)參考附錄5.1節(jié)MPP數(shù)據(jù)庫定義。本章主要對MPP數(shù)據(jù)庫在實施前、實施過程中和實施后的運(yùn)維過程中需要注意的問題提出指導(dǎo)意見。4.1應(yīng)用場景MPP數(shù)據(jù)庫適合結(jié)構(gòu)化數(shù)據(jù)的深度分析、復(fù)雜查詢以及多變的自助分析類應(yīng)用。它提供了統(tǒng)一的標(biāo)準(zhǔn)訪問接口（SQL）,而無需像Hadoop一樣需要定制開發(fā)。MPP數(shù)據(jù)庫一般構(gòu)建在X86平臺上，并使用本地盤而不用陣列，而且產(chǎn)品眾多，因為可以降低擁有成本。MPP數(shù)據(jù)庫產(chǎn)品在數(shù)據(jù)中心中可以用于以下場景（包括但不限于）。數(shù)據(jù)集市數(shù)據(jù)集市定位于以企業(yè)數(shù)據(jù)倉庫數(shù)據(jù)為基礎(chǔ)，結(jié)合其他相關(guān)數(shù)據(jù)，支撐特定業(yè)務(wù)場景或者業(yè)務(wù)部門需求的IT平臺?？梢栽跀?shù)據(jù)集市建設(shè)和擴(kuò)容時考慮引入MPP數(shù)據(jù)庫來降低成本，提高效率。數(shù)據(jù)分級存儲（歷史庫或者明細(xì)庫）系統(tǒng)中數(shù)據(jù)存儲周期分為在線數(shù)據(jù)、近線數(shù)據(jù)、歸檔數(shù)據(jù)。目前在線數(shù)據(jù)及近線數(shù)據(jù)存放在數(shù)據(jù)倉庫，歸檔數(shù)據(jù)使用磁帶庫存放。帶來的問題是在線數(shù)據(jù)中不常訪問的數(shù)據(jù)占據(jù)數(shù)據(jù)倉庫寶貴的資源，針對歸檔數(shù)據(jù)的數(shù)據(jù)分析需求增加，而數(shù)據(jù)從磁帶庫恢復(fù)的時間無法滿足需求。歷史庫定位于為數(shù)據(jù)中心數(shù)據(jù)倉庫的主要數(shù)據(jù)長期在線備份存儲，數(shù)據(jù)中心數(shù)據(jù)倉庫中的數(shù)據(jù)在完成近期數(shù)據(jù)支撐任務(wù)后，轉(zhuǎn)移到歷史庫中進(jìn)行長周期存儲，支持后續(xù)數(shù)據(jù)訪問和長周期數(shù)據(jù)分析需求，同時可作為核心數(shù)據(jù)倉庫的備份，提升整體架構(gòu)及數(shù)據(jù)的高可用性。MPP架構(gòu)基于x86平臺構(gòu)建，可高效低成本的實現(xiàn)歷史庫的建設(shè)需求。獲&系統(tǒng)訪何門戶結(jié)構(gòu)化歡據(jù)結(jié)構(gòu)化歡據(jù);生倉庫：基礎(chǔ)散據(jù)模型和一屋*KPI等關(guān)是LEiffl 歷史庫:重入網(wǎng).套饗會析等專題應(yīng)用和倉庫重要?dú)v史數(shù)據(jù)在線期存儲4.1.3ETL現(xiàn)有數(shù)據(jù)中心系統(tǒng)架構(gòu)中數(shù)據(jù)倉庫承擔(dān)了清單數(shù)據(jù)到輕度匯總、輕度匯總到高度匯總的數(shù)據(jù)關(guān)聯(lián)匯總?cè)蝿?wù)（指ELT模式，現(xiàn)在大部分省公司是ELT的模式），這部分的任務(wù)使用數(shù)據(jù)倉庫絕大部分的計算資源。通過將數(shù)據(jù)的關(guān)聯(lián)匯總卸載到MPP數(shù)據(jù)庫上，可降低數(shù)據(jù)倉庫的負(fù)載，提高數(shù)據(jù)關(guān)聯(lián)匯總的性能，同時可以滿足后續(xù)數(shù)據(jù)量增長情況下的平滑擴(kuò)容的需求。這部分的計算任務(wù)可以定位于數(shù)據(jù)倉庫外的復(fù)雜數(shù)據(jù)加工、數(shù)據(jù)匯總?cè)蝿?wù)，其源數(shù)據(jù)可以來自業(yè)務(wù)系統(tǒng)，也可以來自ETL（專業(yè)ETL工具或者Hadoop）清洗、轉(zhuǎn)換后的話單或者經(jīng)過ETL輕度匯總過的數(shù)據(jù)。其結(jié)果數(shù)據(jù)導(dǎo)入到基礎(chǔ)數(shù)據(jù)倉庫中供上層應(yīng)用訪問。如上一章所述，ETL的操作也可以由Hadoop完成。但是Hadoop平臺弱點(diǎn)在于對多個表的關(guān)聯(lián)的計算，以及易用性方面。MPP可以彌補(bǔ)這方面的不足，所以混合起來使用總體更優(yōu)。但是混合使用增加了數(shù)據(jù)同步和落地的環(huán)節(jié)，對于小規(guī)模的環(huán)境下不一定是最好的選擇。各公司應(yīng)該根據(jù)自己的情況進(jìn)行設(shè)計。4.1.4小結(jié)MPP數(shù)據(jù)庫的靈活查詢、復(fù)雜關(guān)聯(lián)匯總、深度分析等方面的性能相比Hadoop優(yōu)勢明顯,適合數(shù)據(jù)中心場景中數(shù)據(jù)挖掘、自助分析、數(shù)據(jù)關(guān)聯(lián)等復(fù)雜邏輯加工場景。而且MPP數(shù)據(jù)庫可以更快的響應(yīng)小規(guī)模的查詢，提供很高的吞吐率。但是MPP數(shù)據(jù)庫在大規(guī)模數(shù)據(jù)（超過100個節(jié)點(diǎn)或者超過PB級的數(shù)據(jù)）方面表現(xiàn)有待進(jìn)一步驗證。4.2前期方案設(shè)計階段的建議4.2.1 軟件平臺選型建議當(dāng)前構(gòu)建在X86平臺上的新型MPP數(shù)據(jù)庫產(chǎn)品眾多，Garnter每年會