Hadoop、MPP技術(shù)介紹、對(duì)比與應(yīng)用

大數(shù)據(jù)技術(shù)介紹（Hadoop與MPP部分,包含與傳統(tǒng)技術(shù)的區(qū)別）大數(shù)據(jù)技術(shù)介紹（Hadoop與MPP部分,包含與傳統(tǒng)技術(shù)的區(qū)別）版本號(hào)：版本號(hào)：1.0.0PAGE1目 錄概述大數(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ù)庫(kù)軟件所能搜集/存儲(chǔ)/管理和分析的規(guī)模的數(shù)據(jù)集。大數(shù)據(jù)處理技術(shù)可以認(rèn)為是處理大數(shù)據(jù)以便從中獲取價(jià)值的技術(shù)。大數(shù)據(jù)及其技術(shù)正在影響著IT產(chǎn)業(yè)，利用Hadoop和關(guān)系數(shù)據(jù)庫(kù)混搭來解決大數(shù)據(jù)難題是當(dāng)前通常采用的方法。引入大數(shù)據(jù)的意義 引入原則 傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)已經(jīng)建設(shè)運(yùn)營(yíng)十年，新技術(shù)的引入不能影響原有的使用感知，需要按照分階段逐步引入的方式?？梢詤⒖既缦碌膸讉€(gè)引入原則：1、先增量后存量?，F(xiàn)有的數(shù)據(jù)處理系統(tǒng)引入大數(shù)據(jù)處理技術(shù)，面臨著模型改造、流程改造等一系列的問題，可以首先在新上線應(yīng)用引入大數(shù)據(jù)處理技術(shù)。2、先邊緣后核心。對(duì)于原有功能的遷移，可以先遷移非關(guān)鍵的應(yīng)用。這些應(yīng)用不涉及到關(guān)鍵生產(chǎn)任務(wù)，可以忍受數(shù)據(jù)處理延遲和故障修復(fù)時(shí)間較高等可能出現(xiàn)的風(fēng)險(xiǎn)。3、先簡(jiǎn)單后復(fù)雜。數(shù)據(jù)處理邏輯較簡(jiǎn)單的應(yīng)用也可以首先嘗試引入大數(shù)據(jù)處理技術(shù)，降低實(shí)施的復(fù)雜度，積累運(yùn)維經(jīng)驗(yàn)。通過在大數(shù)據(jù)處理技術(shù)的規(guī)劃、實(shí)施及運(yùn)維過程中積累經(jīng)驗(yàn)及教訓(xùn)，不斷提升和完善大數(shù)據(jù)技術(shù)的應(yīng)用水平，逐步拓展大數(shù)據(jù)技術(shù)應(yīng)用領(lǐng)域。術(shù)語、定義和縮略語名詞解釋Hadoop一個(gè)開源的分布式系統(tǒng)基礎(chǔ)架構(gòu)，由Apache基金會(huì)開發(fā)?；贖adoop框架，用戶可以方便的開發(fā)分布式程序，充分利用集群的威力高速運(yùn)算和存儲(chǔ)。MapReduceMapReduce是Hadoop一種并行計(jì)算框架，用于大規(guī)模數(shù)據(jù)集的并行運(yùn)算,其縮略語為MR。Hive是基于Hadoop的一個(gè)數(shù)據(jù)倉(cāng)庫(kù)工具，可以將結(jié)構(gòu)化的數(shù)據(jù)文件映射為數(shù)據(jù)庫(kù)表，并提供常用的SQL支持。Hive查詢引擎將SQL語句轉(zhuǎn)換為Hadoop平臺(tái)的MapReduce任務(wù)運(yùn)行。Key-value鍵值對(duì)，其縮略語為K-V。K-VStoreKey-Value存儲(chǔ)引擎，業(yè)界使用廣泛的有GoogleBigTable和ApacheHBase、Cassandra、MangoDB等。K-VStore系統(tǒng)是經(jīng)典的NoSQL實(shí)現(xiàn)，與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)相比，目前不支持SQL語言查詢、事物、回滾等復(fù)雜機(jī)制?；贙-VStore開發(fā)的應(yīng)用，其數(shù)據(jù)表設(shè)計(jì)模式也與基于關(guān)系型數(shù)據(jù)庫(kù)的開發(fā)有顯著區(qū)別。由于K-VStore模型簡(jiǎn)單，可靠性高，易于擴(kuò)展，在互聯(lián)網(wǎng)、大數(shù)據(jù)領(lǐng)域有非常廣泛的應(yīng)用。JDBCJava數(shù)據(jù)庫(kù)連接MPP數(shù)據(jù)庫(kù)Massivelparallelprocessing大規(guī)模并行處理數(shù)據(jù)庫(kù)，相對(duì)于SymmetricMultiProcessing。DPI(DeepPacketInspection)深度包檢測(cè)技術(shù)是一種基于應(yīng)用層的流量檢測(cè)和控制技術(shù)，當(dāng)IP數(shù)據(jù)包、TCP或UDP數(shù)據(jù)流通過基于DPI技術(shù)的帶寬管理系統(tǒng)時(shí)，該系統(tǒng)通過深入讀取IP包載荷的內(nèi)容來對(duì)OSI七層協(xié)議中的應(yīng)用層信息進(jìn)行重組，從而得到整個(gè)應(yīng)用程序的內(nèi)容，然后按照系統(tǒng)定義的管理策略對(duì)流量進(jìn)行整形操作。大數(shù)據(jù)技術(shù)的引入在大數(shù)據(jù)時(shí)代，傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)基礎(chǔ)架構(gòu)難以滿足海量、多樣化數(shù)據(jù)以及高速響應(yīng)的需求。主要原因?yàn)椋簜鹘y(tǒng)IT系統(tǒng)采用Scale-up設(shè)計(jì)路線，擴(kuò)展性較弱，難以處理海量數(shù)據(jù)；小型機(jī)Unix系統(tǒng)的封閉性導(dǎo)致系統(tǒng)擴(kuò)容時(shí)難以利舊，且擁有成本高。為了解決上述問題，大數(shù)據(jù)時(shí)代涌現(xiàn)出了多種技術(shù)，典型技術(shù)如下：Hadoop：基于HDFS和Mapreduce，被互聯(lián)網(wǎng)廠商廣泛用于非結(jié)構(gòu)化數(shù)據(jù)處理和半結(jié)構(gòu)化日志處理。優(yōu)點(diǎn)是編程靈活、針對(duì)問題優(yōu)化、擴(kuò)展性好，且基于廉價(jià)的x86標(biāo)準(zhǔn)硬件。MPP數(shù)據(jù)庫(kù)：基于關(guān)系代數(shù)理論，面向結(jié)構(gòu)化數(shù)據(jù)處理設(shè)計(jì)的數(shù)據(jù)庫(kù)管理系統(tǒng)。近年演進(jìn)方向包括：提高擴(kuò)展性、支持快速?gòu)?fù)雜查詢、支持x86標(biāo)準(zhǔn)硬件、高壓縮、列存儲(chǔ)、打通與Hadoop交互。例如Vertica和GreenPlum等。NoSql：拋棄了關(guān)系數(shù)據(jù)庫(kù)復(fù)雜的關(guān)系操作、事務(wù)處理等功能，僅提供簡(jiǎn)單的鍵值對(duì)(Key,Value)數(shù)據(jù)的存儲(chǔ)與查詢，換取高擴(kuò)展性和高性能。例如HBase和Cassendra等。流計(jì)算技術(shù)：在流數(shù)據(jù)不斷變化的運(yùn)動(dòng)過程中實(shí)時(shí)地進(jìn)行分析，捕捉到可能對(duì)用戶有用的信息，并把結(jié)果發(fā)送出去。例如S4和Storm等。內(nèi)存數(shù)據(jù)庫(kù)：將數(shù)據(jù)存儲(chǔ)在內(nèi)存RAM中并進(jìn)行計(jì)算和查詢，充分發(fā)揮多核CPU的能力的數(shù)據(jù)庫(kù)管理系統(tǒng)。例如HANA、ExaAnalytic、TM1等。大數(shù)據(jù)技術(shù)與傳統(tǒng)技術(shù)有很大的差別，它們不是為了通用的需求去設(shè)計(jì)，多是某一些廠商按照自己的特定需求或細(xì)分市場(chǎng)設(shè)計(jì)的，所以在應(yīng)用的時(shí)候需要結(jié)合自身需求考慮到底引入哪些技術(shù)。傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)特征傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)目前在數(shù)據(jù)量、數(shù)據(jù)類別、數(shù)據(jù)應(yīng)用需求方面具有典型的大數(shù)據(jù)特征，包括：容量巨大；類別多樣；數(shù)據(jù)處理方式多樣；訪問需求多樣。數(shù)據(jù)價(jià)值不同。大數(shù)據(jù)技術(shù)應(yīng)用場(chǎng)景大數(shù)據(jù)技術(shù)可以應(yīng)用在以下場(chǎng)景（包括但不限于）：1、原數(shù)據(jù)倉(cāng)庫(kù)底層結(jié)構(gòu)化數(shù)據(jù)處理（ETL或ELT）。底層結(jié)構(gòu)化數(shù)據(jù)處理計(jì)算任務(wù)重但復(fù)雜性不高，不涉及多表關(guān)聯(lián)，適合引入大數(shù)據(jù)技術(shù)實(shí)現(xiàn)高效低成本。2、半結(jié)構(gòu)和非結(jié)構(gòu)數(shù)據(jù)處理與分析。3、數(shù)據(jù)集市。數(shù)據(jù)集市應(yīng)用較為獨(dú)立，且對(duì)可靠性的要求并不是十分嚴(yán)格，適合作為引入大數(shù)據(jù)技術(shù)形成資源池，實(shí)現(xiàn)各地市、各部門數(shù)據(jù)集市的云化、池化和虛擬化，最終實(shí)現(xiàn)資源動(dòng)態(tài)調(diào)配，達(dá)到高效低成本。4、數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)分級(jí)存儲(chǔ)。對(duì)低價(jià)值的細(xì)節(jié)數(shù)據(jù)以及長(zhǎng)周期的歷史數(shù)據(jù)（冷數(shù)據(jù)）訪問頻率較低，也能容忍相對(duì)較長(zhǎng)的響應(yīng)時(shí)間，可以存儲(chǔ)在成本更低的平臺(tái)上。5、數(shù)據(jù)挖掘。某些數(shù)據(jù)挖掘設(shè)計(jì)長(zhǎng)周期的數(shù)據(jù)，計(jì)算時(shí)間很長(zhǎng)（數(shù)天），占用很多數(shù)據(jù)倉(cāng)庫(kù)資源。還有一些數(shù)據(jù)挖掘算法超出了關(guān)系代數(shù)計(jì)算范疇，需要抽取數(shù)據(jù)到獨(dú)立的計(jì)算平臺(tái)（例如SAS）中進(jìn)行計(jì)算。這些數(shù)據(jù)挖掘任務(wù)可以遷移到大數(shù)據(jù)平臺(tái)之上進(jìn)行計(jì)算。例如交往圈的計(jì)算，因其僅涉及單一數(shù)據(jù)，但數(shù)據(jù)量非常大，且需要多次迭代計(jì)算。6、對(duì)外查詢。數(shù)據(jù)中心中不僅僅是數(shù)據(jù)處理，也需要將數(shù)據(jù)處理的結(jié)果對(duì)外提供查詢，而這些查詢一部分是海量的OLAP性質(zhì)的查詢，另外還有一部分OLTP性質(zhì)的查詢，即數(shù)量眾多但每次查詢量較少的。針對(duì)這些應(yīng)用場(chǎng)景，可以看到，主要需要引入的是Hadoop和MPP技術(shù)，然后逐步考慮NoSQL、流計(jì)算和內(nèi)存計(jì)算等技術(shù)的引入。Hadoop與MPP與傳統(tǒng)數(shù)據(jù)庫(kù)技術(shù)對(duì)比與適用場(chǎng)景Hadoop和MPP兩種技術(shù)的介紹請(qǐng)參見附錄A。雖然這兩種技術(shù)同屬于分布式計(jì)算，但由于依據(jù)的理論和采取的技術(shù)路線不同而有各自的優(yōu)缺點(diǎn)和適用范圍。兩種技術(shù)以及傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)技術(shù)的對(duì)比如下：HadoopMPP傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)平臺(tái)開放性高低低運(yùn)維復(fù)雜度高，與運(yùn)維人員能力相關(guān)中中擴(kuò)展能力高中低擁有成本低中高系統(tǒng)和數(shù)據(jù)管理成本高中中應(yīng)用開發(fā)維護(hù)成本高中中SQL支持低高高數(shù)據(jù)規(guī)模PB級(jí)別部分PBTB級(jí)別計(jì)算性能對(duì)非關(guān)系型操作效率高對(duì)關(guān)系型操作效率高對(duì)關(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)和適用場(chǎng)景為：Hadoop在處理非結(jié)構(gòu)數(shù)據(jù)和半結(jié)構(gòu)數(shù)據(jù)上具備優(yōu)勢(shì)，尤其適合海量數(shù)據(jù)批處理等應(yīng)用需求。當(dāng)然隨著Hadoop技術(shù)的成熟，基于Hadoop的即席查詢技術(shù)也逐漸嶄露頭角。比如仿照Dremel的開源項(xiàng)目ApacheDrill以及ClouderaImpala。MPP適合替代現(xiàn)有關(guān)系數(shù)據(jù)結(jié)構(gòu)下的大數(shù)據(jù)處理，具有較高的效率，但其在大規(guī)模集群（超過100個(gè)節(jié)點(diǎn)）下的可用性還有待試點(diǎn)證實(shí)。MPP適合多維度數(shù)據(jù)自助分析、數(shù)據(jù)集市等；Hadoop適合海量數(shù)據(jù)存儲(chǔ)查詢（詳單存儲(chǔ)和查詢）、批量數(shù)據(jù)ETL、非結(jié)構(gòu)化數(shù)據(jù)分析（日志分析、文本分析）等?？梢钥闯?，任何一種單一技術(shù)都難以數(shù)據(jù)采集、存儲(chǔ)、處理和對(duì)外服務(wù)的需求，多種技術(shù)并存才是發(fā)展趨勢(shì)。Hadoop實(shí)施指導(dǎo)意見本章主要對(duì)Hadoop平臺(tái)在實(shí)施前的方案設(shè)計(jì)階段、實(shí)施過程中的建設(shè)階段和實(shí)施后的運(yùn)維階段中采取的步驟以及需要注意的問題提出指導(dǎo)意見。應(yīng)用場(chǎng)景Hadoop技術(shù)和產(chǎn)品在數(shù)據(jù)中心中可以用于以下場(chǎng)景（包括但不限于）：場(chǎng)景為什么采用Hadoop采用的組件ETL1、降低原始數(shù)據(jù)存儲(chǔ)壓力

2、降低數(shù)據(jù)倉(cāng)庫(kù)處理壓力

3、降低存儲(chǔ)和處理成本Hive/MR/Pig清單查詢1、快速響應(yīng)海量數(shù)據(jù)查詢

2、降低查詢成本HBase機(jī)器學(xué)習(xí)和數(shù)據(jù)挖掘1、降低海量數(shù)據(jù)挖掘成本

2、縮短計(jì)算時(shí)間

3、實(shí)現(xiàn)更加靈活的算法mahout/R/MR冷數(shù)據(jù)存儲(chǔ)降低冷數(shù)據(jù)存儲(chǔ)成本降低冷數(shù)據(jù)查詢成本HiveOverHDFS前期方案設(shè)計(jì)階段的建議本節(jié)主要對(duì)各公司搭建Hadoop平臺(tái)之前對(duì)軟硬件選型、組網(wǎng)以及容量規(guī)劃方面提出建議。對(duì)Hadoop軟件選擇的建議Hadoop版本選擇建議Hadoop版本現(xiàn)狀目前ApacheHadoop開源社區(qū)非?；钴S，周期性發(fā)布升級(jí)Hadoop及其相關(guān)軟件（包括HBase、Hive、Zookeeper等）。此外，一些公司，如Cloudera、Hortonworks公司等也基于ApacheHadoop軟件進(jìn)行打包升級(jí)，開源發(fā)布其Hadoop版本。ApacheHadoop開源社區(qū)發(fā)布的軟件是當(dāng)前社區(qū)的最新進(jìn)展，但Hadoop各相關(guān)軟件分別獨(dú)立發(fā)布，可能存在兼容性的問題。而上述公司發(fā)布的軟件一般基于ApacheHadoop社區(qū)的某個(gè)版本進(jìn)行測(cè)試升級(jí)修訂，并將Hadoop各個(gè)系統(tǒng)整合測(cè)試，從而發(fā)布一個(gè)較為穩(wěn)定且各系統(tǒng)間兼容的軟件包。ApacheHadoop開源社區(qū)發(fā)布的各個(gè)版本以及與Cloudera發(fā)布的CDH軟件包的對(duì)應(yīng)關(guān)系如下圖所示：其中，ApacheHadoop0.20版本分支經(jīng)過將0.20.append(為兼容HBase提供對(duì)HDFS文件追加寫功能)和0.20.security(提供基于Kerberos認(rèn)證的功能)整合后，于2011年底發(fā)布了Hadoop1.0版本，并在2012年和2013年持續(xù)對(duì)該版本進(jìn)行升級(jí)。ApacheHadoop0.23版本分支則對(duì)原有ApacheHadoop0.20版本做了較大的改動(dòng)，這包括提供一種通用資源管理框架YARN以及對(duì)HDFS主節(jié)點(diǎn)擴(kuò)展方案NameNodeFederation。而ApacheHadoop2.0alpha版本又在0.23分支上又增加了HDFS主節(jié)點(diǎn)高可用方案。總體來看，目前ApacheHadoop開源社區(qū)主要在Hadoop1.0和2.0兩個(gè)版本上分別進(jìn)行持續(xù)更新優(yōu)化。而Cloudera公司的Hadoop版本CDH3和CDH4也分別基于Hadoop1.0和2.0版本進(jìn)行封裝。一般來講開源社區(qū)的版本更新非常頻繁，且有些組件之間并不兼容，而公司推出的版本一般都會(huì)基于某幾個(gè)大版本進(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中主要包括如下組件：HDFS。是Hadoop的分布式文件系統(tǒng)，用于存儲(chǔ)分析和查詢所需的數(shù)據(jù)，可以是結(jié)構(gòu)化數(shù)據(jù)也可以是非結(jié)構(gòu)化數(shù)據(jù)。文件按照塊進(jìn)行劃分存儲(chǔ)在多臺(tái)機(jī)器上，并通過副本的方式保證高可用。MapReduce。是Hadoop的分布式計(jì)算框架，通過Map的方式將計(jì)算任務(wù)擴(kuò)展到多臺(tái)機(jī)器上，進(jìn)而通過Reduce的方式將多個(gè)節(jié)點(diǎn)上的結(jié)果進(jìn)行合并。在Hadoop2.0中，原有MapReduce框架被Yarn代替，但對(duì)用戶的接口不變。MapReduce可以簡(jiǎn)稱為MR，是很多Hadoop組件的計(jì)算引擎，例如Hive、Pig、Mahout等。Hive。是Hadoop上的SQL解析和執(zhí)行引擎。其支持SQL的一個(gè)子集，名為HiveQL。Hive通過元數(shù)據(jù)保存表結(jié)構(gòu)信息，并將輸入的HiveQL轉(zhuǎn)換為MapReduce進(jìn)行執(zhí)行。HBase。是Hadoop上的一個(gè)鍵值對(duì)NoSQL數(shù)據(jù)庫(kù)，其主要特性是支持高并發(fā)文本數(shù)據(jù)寫入和讀取，舍棄了關(guān)系數(shù)據(jù)中的事務(wù)、關(guān)聯(lián)、復(fù)雜索引等HBase的典型場(chǎng)景可用于詳單存儲(chǔ)和查詢、互聯(lián)網(wǎng)內(nèi)容存儲(chǔ)、GiS數(shù)據(jù)存儲(chǔ)、半結(jié)構(gòu)化歷史數(shù)據(jù)存儲(chǔ)。Zookeeper。是Hadoop中的分布式可靠協(xié)調(diào)系統(tǒng)，被Hadoop的一些組件所用，例如HBase和Hive（可選）等。Mahout：是一組在MapReduce上的實(shí)現(xiàn)的數(shù)據(jù)挖掘算法庫(kù)，可被調(diào)用用于數(shù)據(jù)挖掘計(jì)算。Oozie：是一個(gè)Hadoop上的工作流組件。Pig。是另一個(gè)Hadoop上的腳本語言解析和執(zhí)行器，將面向過程的PigLatin語言解析為MapReduce任務(wù)執(zhí)行。Cascading。是一個(gè)架構(gòu)在Hadoop上的API，用來創(chuàng)建復(fù)雜和容錯(cuò)數(shù)據(jù)處理工作流。它抽象了集群拓?fù)浣Y(jié)構(gòu)和配置來快速開發(fā)復(fù)雜分布式的應(yīng)用，而不用考慮背后的MapReduce。Impala。是另一個(gè)SQL解析引擎，但其繞過了MapReduce，利用自己的執(zhí)行引擎，充分利用內(nèi)存來直接訪問HDFS上的文件。數(shù)據(jù)處理方式建議從上節(jié)看，在Hadoop上進(jìn)行數(shù)據(jù)處理可以選擇多種方式。但目前較為流行的是采用MapReduce直接編程或者利用Hive。Pig由于要學(xué)習(xí)另外一種語言而用得較少，Impala由于其對(duì)內(nèi)存的渴求而難以用于大數(shù)據(jù)的加工。對(duì)于Hive和MapReduce用于數(shù)據(jù)處理，比較如下：HiveMapReduce查詢語言HQLJava或其他語言調(diào)優(yōu)方法中多性能略差略優(yōu)易用性簡(jiǎn)單（類SQL）復(fù)雜（編程）數(shù)據(jù)格式結(jié)構(gòu)化結(jié)構(gòu)化和非結(jié)構(gòu)化均可可以看出Hive和MapReduce在很多方面基本都相同。在調(diào)優(yōu)方法、性能方面，Hive不如MapReduce，尤其是MapReduce可以針對(duì)性的對(duì)于某些應(yīng)用的算法優(yōu)化是Hive無法比擬的。但是Hive因?yàn)轭怱QL實(shí)現(xiàn)的機(jī)制極高地提升了開發(fā)人員的工作效率，減輕了工作量，而MapReduce的編程則相對(duì)復(fù)雜一些，普通水平的MR程序員，寫出來的程序很可能效率低于hive。所需硬件設(shè)備建議服務(wù)器配置建議Hadoop被設(shè)計(jì)運(yùn)行在大規(guī)模通用X86硬件平臺(tái)之上，使用本地存儲(chǔ)（DAS）來實(shí)現(xiàn)ScaleOut。所以其對(duì)硬件的要求較低，一般的PC服務(wù)器也可以運(yùn)行，只要滿足發(fā)行版所要求的操作系統(tǒng)和JDK需求即可。但是在實(shí)際使用中需要根據(jù)Hadoop的應(yīng)用環(huán)境來合理配置硬件，充分發(fā)揮每個(gè)部件的效率。在前期試點(diǎn)中，我們發(fā)現(xiàn)如果執(zhí)行MapReduce，特別是在壓縮文件上執(zhí)行，其對(duì)CPU的消耗較高，CPU成為了瓶頸；而在運(yùn)行Hbase的時(shí)候，更多的內(nèi)存會(huì)緩存更多的數(shù)據(jù)，提高查詢吞吐率并縮短響應(yīng)時(shí)間。所以建議這兩種情況下，可以考慮按照如下配比來配置硬件：項(xià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個(gè)數(shù)及核心數(shù)2路8核以上2路8核以上，如果壓縮數(shù)據(jù)或者處理比較復(fù)雜，可以考慮更多路多核的2路6核以上2路8核以上硬盤數(shù)硬盤數(shù)可以不同太多，4-6塊6、8或者12塊，數(shù)據(jù)處理時(shí)IO一般不是瓶頸，但更多的磁盤可以存儲(chǔ)更多的數(shù)據(jù)6、8或者12塊，取決于存儲(chǔ)量（主要靠緩存）硬盤數(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)卡，對(duì)網(wǎng)絡(luò)延時(shí)有高要求，如果可以，建議單獨(dú)設(shè)立奇數(shù)個(gè)集群，3-5個(gè)內(nèi)存的選擇：通常情況下，Hadoop處理任務(wù)每個(gè)CPU邏輯核（指超線程下，一般一個(gè)核對(duì)應(yīng)兩個(gè)邏輯核）對(duì)應(yīng)2G內(nèi)存即可。CPU的選擇：實(shí)測(cè)表明：Hadoop處理性能與CPU性能密切相關(guān)，任務(wù)運(yùn)行時(shí)間與SPEC值基本成反比關(guān)系，因此應(yīng)該選擇性能較高的CPU。服務(wù)器類型：一般的Hadoop項(xiàng)目選擇2U的機(jī)架式服務(wù)器，試點(diǎn)中有公司選擇了多節(jié)點(diǎn)服務(wù)器（2U四節(jié)點(diǎn)），也應(yīng)用得比較好。硬盤掛載建議操作系統(tǒng)盤可以采用SAS或SATA盤，建議采用兩塊硬盤盤做RAID1后作為系統(tǒng)盤，磁盤支持熱插拔，方便運(yùn)維。對(duì)于數(shù)據(jù)節(jié)點(diǎn)存放數(shù)據(jù)的磁盤：可以采用SATA降低成本，提高存儲(chǔ)量。由于Hadoop在軟件層面已實(shí)現(xiàn)了數(shù)據(jù)的冗余備份，不必要在硬件層面通過RAID再做冗余。在效率提升方面，Hadoop自身的“優(yōu)化策略”推薦HDFS數(shù)據(jù)直接存儲(chǔ)到多塊物理盤，而不采用RAID（已經(jīng)在測(cè)試中驗(yàn)證了這個(gè)結(jié)論）組網(wǎng)方式建議一個(gè)完整的Hadoop集群中的節(jié)點(diǎn)，分為三個(gè)角色：Client、Master和Slave，如下：其中Client：部署在用于跟Hadoop進(jìn)行交互的應(yīng)用節(jié)點(diǎn)中。Master節(jié)點(diǎn)用于集群管理，主要與Client進(jìn)行通訊，為Client分配可用的Slave節(jié)點(diǎn)，同時(shí)Master會(huì)維護(hù)Slaves節(jié)點(diǎn)上報(bào)的每個(gè)運(yùn)行參數(shù)。角色包括HDFS中的NameNode、SecondaryNameNode、MapRedcue的JobTracker等(MR2是ResourceManage)。Slave節(jié)點(diǎn)是Hadoop中的執(zhí)行者，主要模塊包括：DataNode用于存儲(chǔ)，TaskTracker(MR2為NodeManage)執(zhí)行并行計(jì)算。其他可單獨(dú)部署zookeeper節(jié)點(diǎn)集群奇數(shù)個(gè)（3-5）個(gè)，增加一個(gè)NTPserver節(jié)點(diǎn)，實(shí)現(xiàn)時(shí)間同步。綜合來說，在Hadoop集群中有大量文件讀寫或者M(jìn)apReduce計(jì)算任務(wù)提交時(shí)候，都會(huì)出現(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)的帶寬，在峰值流量下，其時(shí)延也大大低于千兆網(wǎng)。根據(jù)Hortonworks的建議，對(duì)于較小的集群至少保證所有節(jié)點(diǎn)點(diǎn)到點(diǎn)千兆網(wǎng)連接，對(duì)于更大的集群使用千兆網(wǎng)可能造成性能的下降，在超級(jí)的數(shù)據(jù)中心，Yahoo！的做法是同一個(gè)機(jī)架的20臺(tái)節(jié)點(diǎn)中每臺(tái)通過2個(gè)千兆網(wǎng)卡綁定的方式和其他節(jié)點(diǎn)通信，對(duì)于機(jī)架使用2條萬兆網(wǎng)連接。根據(jù)Hadoop集群數(shù)量不同，可以將集群分為小集群、中級(jí)集群和大規(guī)模集群三大類。一般來講，具體個(gè)數(shù)與組網(wǎng)與核心交換機(jī)支持的網(wǎng)絡(luò)口數(shù)量，具有較大關(guān)聯(lián)。以下對(duì)這三種規(guī)模的集群組網(wǎng)方式進(jìn)行分別描述。小集群節(jié)點(diǎn)規(guī)模：10個(gè)節(jié)點(diǎn)內(nèi)主要特征：計(jì)算和存儲(chǔ)能力有限，用于進(jìn)行Hadoop以及相關(guān)生態(tài)系統(tǒng)應(yīng)用功能驗(yàn)證建議組網(wǎng)：主要關(guān)注點(diǎn)：優(yōu)先考慮升級(jí)兼容性Master節(jié)點(diǎn)無需HA。千兆網(wǎng)絡(luò)，也可用萬兆，為后續(xù)擴(kuò)容準(zhǔn)備。預(yù)先考慮擴(kuò)容后的IP劃分。中級(jí)集群節(jié)點(diǎn)規(guī)模：10-100節(jié)點(diǎn)；主要特征：企業(yè)級(jí)典型集群規(guī)模，總數(shù)據(jù)量在百TB級(jí)別（冗余情況下），主要用于進(jìn)行中等規(guī)模數(shù)據(jù)量計(jì)算（單次10億級(jí)別或者10TB同等數(shù)量級(jí)數(shù)據(jù)計(jì)算），一般來講，具體節(jié)點(diǎn)個(gè)數(shù)受限于上層交換機(jī)口的數(shù)量。建議組網(wǎng)圖：主要關(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方式的可靠性最高，但會(huì)帶來連接復(fù)雜性上升，具體可以根據(jù)能力進(jìn)行適當(dāng)調(diào)整。大規(guī)模集群節(jié)點(diǎn)規(guī)模：大于100節(jié)點(diǎn)；主要特性：PB級(jí)別以上存儲(chǔ)規(guī)模；MapReduce計(jì)算任務(wù)量大，且持續(xù)增加；多場(chǎng)景需求：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ī)架時(shí)延（Hadoop默認(rèn)策略）。交換機(jī)oversubscription（入出率）比率建議2.5：1（不能高于交換機(jī)最高值）。核心交換機(jī)與Rack數(shù)相關(guān)，Rack數(shù)量與核心交換機(jī)數(shù)量和端口數(shù)成正比，但交換機(jī)不應(yīng)太多，會(huì)降低機(jī)架上傳帶寬。機(jī)架交換機(jī)方式的機(jī)柜交換機(jī)的上行鏈路會(huì)成為瓶頸，交換機(jī)數(shù)量多，設(shè)備管理復(fù)雜性增加。在核心交換機(jī)端口緊張情況下，可以從機(jī)架交換機(jī)接入外部網(wǎng)關(guān)，提供集群外部訪問能力。規(guī)劃節(jié)點(diǎn)規(guī)模時(shí)需要考慮的因素1、計(jì)算能力估算應(yīng)依據(jù)小規(guī)模基準(zhǔn)測(cè)試針對(duì)所需的業(yè)務(wù)類型進(jìn)行模擬測(cè)試，依據(jù)近似線性擴(kuò)展原理，根據(jù)業(yè)務(wù)需求可計(jì)算出計(jì)算能力節(jié)點(diǎn)個(gè)數(shù)?？紤]到擴(kuò)容及其他因素影響，建議預(yù)留30%的計(jì)算能力冗余。2、存儲(chǔ)能力估算壓縮比、副本數(shù)、冗余量的考慮將影響存儲(chǔ)能力評(píng)估，需要預(yù)先確定?？梢詤⒖即斯竭M(jìn)行估算：（業(yè)務(wù)估算數(shù)據(jù)量*壓縮比*副本數(shù)）/冗余量當(dāng)HDFS剩余空間較小時(shí)會(huì)影響性能。建議冗余量設(shè)置為30%。進(jìn)行HBase存儲(chǔ)估算時(shí)，需要考慮數(shù)據(jù)膨脹率，一般來講可以為2。3、其余節(jié)點(diǎn)估算除了Master節(jié)點(diǎn)和Slave節(jié)點(diǎn)外，還應(yīng)對(duì)接口機(jī)、監(jiān)控運(yùn)維、調(diào)度預(yù)留機(jī)器。建設(shè)過程中的建議本節(jié)主要對(duì)Hadoop平臺(tái)搭建和配置過程中遇到的問題提出建議。對(duì)壓縮的考慮在大數(shù)據(jù)平臺(tái)中，采用合理的壓縮算法不僅能節(jié)省存儲(chǔ)，而且還由于減少了IO的數(shù)據(jù)量而在大部分場(chǎng)景中可以縮短處理時(shí)間。因此在系統(tǒng)搭建過程中應(yīng)提前確定壓縮的策略。Hadoop的HDFS中可以采用的壓縮算法及其特點(diǎn)如下表：

工具

算法文件擴(kuò)展名多文件

可分割性（支持MR并行處理）壓縮率（壓縮至）*

snappy

snappy

Snappy是

是約37%

gzip

DEFLATE

.gz不

不約25%

zip

DEFLATE

.zip是

是，在文件范圍內(nèi)約22%

bzip2

bzip2

.bz2不

是約18%

lzop

LZO

.lzo不

是約35%*壓縮率是試點(diǎn)中測(cè)試結(jié)果，不同的數(shù)據(jù)壓縮率并不一樣。以上壓縮格式的壓縮率為bzip2>gzip>lzo>snappy。但是壓縮率高通常代表壓縮和解壓時(shí)間長(zhǎng)，綜合多個(gè)試點(diǎn)省對(duì)于各種壓縮格式性能比較的測(cè)試結(jié)果，大致得到以下結(jié)果：snappy>lzo>gzip>nocompress>bzip2。所以在不同的場(chǎng)景下，宜選擇不一樣的壓縮方式，主要可能有以下場(chǎng)景：原始數(shù)據(jù)就是壓縮的，那么最好按照原始數(shù)據(jù)的壓縮格式直接上傳HDFS，在HDFS中并行處理過程中可以順帶解壓。這樣可以縮短裝載時(shí)間（壓縮數(shù)據(jù)量少）。MapReduce或者Hive的中間結(jié)果的壓縮?？梢栽贛apReduce程序中設(shè)置Map后的中間結(jié)果用壓縮模式，然后交給Reduce，試點(diǎn)中我們發(fā)現(xiàn)可以節(jié)約處理時(shí)間，特別是對(duì)那種在Map和Reduce中有大量數(shù)據(jù)交換的操作，例如常規(guī)的Join。Hive中也是類似。這種情況下，適合采用snappy與lzo這種壓縮解壓性能快的壓縮算法。以下代碼顯示了啟用rnap輸出壓縮和設(shè)置壓縮格式的配置屬性。conf.setCompressMapOutput(true);

conf.setMapOutputCompressorClass(GzipCodec.class);

處理后數(shù)據(jù)或者冷數(shù)據(jù)的壓縮。這些數(shù)據(jù)可以采用壓縮率稍高的算法進(jìn)行壓縮以節(jié)約空間，比如Zip或Bzip2，特別是在冷數(shù)據(jù)歸檔的情況下。但如果數(shù)據(jù)可能會(huì)頻繁被即席查詢的話，還是應(yīng)該選擇解壓速度快一些的壓縮算法。壓縮的設(shè)置：如果要壓縮MapReduce作業(yè)的輸出，請(qǐng)?jiān)谧鳂I(yè)配置文件中將press屬性設(shè)置為true。將pression.codec屬性設(shè)置為自己打算使用的壓縮編碼/解碼器的類名。HBase設(shè)計(jì)與傳統(tǒng)技術(shù)不一樣，Hadoop沒有走產(chǎn)品化的道路，其中的組件可定制程度非常高。這一方面提高了效率，另一方面也對(duì)使用人員提出了更高要求。HBase就是如此，合理的HBase設(shè)計(jì)可以極大提高查詢性能?？梢钥紤]如下設(shè)計(jì)要素：Rowkey設(shè)計(jì)HBase表的rowkey設(shè)計(jì)，一般是將關(guān)系數(shù)據(jù)庫(kù)中的候選key拼接形成。但是要注意熱點(diǎn)問題，比如rowkey開始的幾位是時(shí)間排序，那么在插入的時(shí)候，最近幾天的數(shù)據(jù)很可能是熱點(diǎn)數(shù)據(jù)，這樣所有的查詢可能都指向了一個(gè)regionserver導(dǎo)致了HBase的性能瓶頸。盡量避免使用單調(diào)遞增的rowkey，因?yàn)樵谔砑訑?shù)據(jù)的時(shí)候，所有的新數(shù)據(jù)都添加到最后一個(gè)region，前面的region沒有或者很少有請(qǐng)求，也是熱點(diǎn)問題。熱點(diǎn)問題的處理方式一般是"加鹽"，即在rowkey前面添加hash數(shù)，來對(duì)數(shù)據(jù)進(jìn)行hash劃分。列簇設(shè)計(jì)HBase表的ColumnFamily最好少于4，一般少于3，對(duì)于一般數(shù)據(jù)放入一個(gè)列簇中即可。對(duì)于一些強(qiáng)關(guān)聯(lián)，頻繁訪問的數(shù)據(jù)可以放一列，這樣在取數(shù)據(jù)時(shí)，熱點(diǎn)訪問只用取這一列數(shù)據(jù)，可以節(jié)省IO。多個(gè)列簇有各自memstore，memstore開銷大，而且flush一個(gè)列簇，其他的類簇也會(huì)flush，會(huì)造成不必要的開銷。Region劃分HBase在導(dǎo)入大量數(shù)據(jù)前最好預(yù)先劃分region，這樣可以加快導(dǎo)入效率。同時(shí)也要避免使用HBase自動(dòng)劃分region，在一種情況下，HBase面臨大量寫入或者scan請(qǐng)求，同時(shí)它的region中的數(shù)據(jù)又達(dá)到了閥值，那么它會(huì)啟動(dòng)自動(dòng)劃分region，有可能導(dǎo)致region劃分風(fēng)暴，大量的請(qǐng)求會(huì)使regionserver和namenode的壓力過大而導(dǎo)致regiondead或者namenodedead。使用TTLTTL（timetolive），它一般可以用來控制數(shù)據(jù)的生存時(shí)間。一些數(shù)據(jù)比如客戶幾年以前的數(shù)據(jù)，幾年以后已經(jīng)不關(guān)心這些數(shù)據(jù)，可以使用TTL刪除。如果數(shù)據(jù)沒有這些要求，可以不使用。參數(shù)設(shè)置建議本節(jié)主要討論重點(diǎn)參數(shù)的設(shè)置建議。副本個(gè)數(shù)副本數(shù)設(shè)置建議按照Hadoop默認(rèn)的3副本，這可以有效防止硬盤受損、機(jī)器或機(jī)架故障導(dǎo)致數(shù)據(jù)丟失或損壞。設(shè)置參數(shù)為hdfs-site.xml文件中的dfs.replication參數(shù)。但在實(shí)際的生產(chǎn)中，為了節(jié)省存儲(chǔ)或者提高處理效率，可以考慮采取動(dòng)態(tài)的副本創(chuàng)建策略。比如對(duì)于非主營(yíng)業(yè)務(wù)或者臨時(shí)需求，原始數(shù)據(jù)裝載到HDFS時(shí)可以選擇一副本或者兩副本從而提高裝載和出數(shù)效率，也可以節(jié)省存儲(chǔ)空間?？梢栽谏蟼鲿r(shí)設(shè)定副本個(gè)數(shù)為n：hadoopdfs-Ddfs.replication=n-put<src><dest>也可以之后修改副本個(gè)數(shù)bin/hadoopdfs[-setrep[-R][-w]<rep><path/file>...]也可以查看副本個(gè)數(shù)查看當(dāng)前hdfs的副本數(shù)

hadoopfsck-locations塊大小HDFS塊大小，默認(rèn)是64M（某些發(fā)布版是128M，比如CDH）。但考慮到目前機(jī)器CPU的計(jì)算能力普遍很高，對(duì)于MapReduce在做Map的時(shí)候可以處理比較大的單個(gè)文件，目前一般建議Blocksize設(shè)置稍微大一點(diǎn)，比如256M或者512M。但跟實(shí)際應(yīng)用場(chǎng)景相關(guān)，需要根據(jù)不同的硬件環(huán)境以及應(yīng)用場(chǎng)景進(jìn)行相關(guān)測(cè)試，然后得出最佳設(shè)置。Slot數(shù)（Mapreduce1.x）Slot數(shù)主要是指以下兩個(gè)參數(shù)的的設(shè)置與搭配mapred.tasktracker.map.tasks.maximum每臺(tái)tasktracker允許啟動(dòng)的最大map槽位數(shù)，官方建議為：(CPU數(shù)量>2)?(CPU數(shù)量*0.75):1mapred.tasktracker.reduce.tasks.maximum每臺(tái)tasktracker允許啟動(dòng)的最大reduce槽位數(shù)，官方建議為：(CPU數(shù)量>2)?(CPU數(shù)量*0.50):1根據(jù)各個(gè)省試點(diǎn)的經(jīng)驗(yàn)，無論是map槽數(shù)還是reduce槽數(shù)一般設(shè)置為CPU核數(shù)的1~2倍，map和reduce的槽數(shù)配比一般為2:1。但跟實(shí)際應(yīng)用場(chǎng)景相關(guān)，需要根據(jù)不同的硬件環(huán)境以及應(yīng)用場(chǎng)景進(jìn)行相關(guān)測(cè)試，然后得出最佳設(shè)置。其他配置參數(shù)(Hadoop1.x)Hdfs配置文件hdfs-site.xml參數(shù)名參數(shù)值說明dfs.datanode.data.dirfile:///data0,file:///data1,file:///data2Datanode的數(shù)據(jù)目錄:如果datanode對(duì)應(yīng)的機(jī)器上有多塊磁盤，例如/disk1-/disk3,dfs.data.dir可以配置為”/disk1/data,/disk2/data,/disk3/data”,datanode會(huì)在寫數(shù)據(jù)時(shí),以輪詢的方式選擇一個(gè)目錄寫入數(shù)據(jù)，一般這些目錄是不同的塊設(shè)備，不存在的目錄會(huì)被忽略掉,參考配置屬性dfs.data.dir.datanode如果有多個(gè)磁盤不建議做raid,因?yàn)樽鰎aid會(huì)有性能損失,還會(huì)導(dǎo)致一個(gè)磁盤壞了,整個(gè)硬盤也不能用了，而Hadoop可以規(guī)避這個(gè)問題。.dirfile:///dir1,file://dir2,file:///dir3元數(shù)據(jù)保存目錄設(shè)置多個(gè)，保證數(shù)據(jù)可靠性dfs.datanode.balancer.bandwidthPerSec20485760在帶寬和機(jī)器數(shù)允許的情況下，設(shè)置數(shù)據(jù)均衡傳輸量為10M/s或更大，加快均衡速度erval1440設(shè)置需要支持回撤周期（單位為分鐘）.回撤操作：在刪除文件的當(dāng)前目錄下（HDFS中）有.Trash目錄，講目錄中對(duì)應(yīng)文件移到當(dāng)前目錄即可。MapReduce配置文件：core-site.xml參數(shù)名參數(shù)值說明Hadoop.tmp.dir/data2/tmphadoop文件系統(tǒng)依賴的基礎(chǔ)配置，默認(rèn)在/tmp里，默認(rèn)情況下master會(huì)將元數(shù)據(jù)等存在這個(gè)目錄下，而slave會(huì)將所有上傳的文件放在這個(gè)目錄下，由于上傳到Hadoop的所有文件都會(huì)被存放在hadoop.tmp.dir所指定的目錄，所以要確保這個(gè)目錄是足夠大的，但是對(duì)掛載磁盤的IO性能壓力比較大文件：mapred-site.xml參數(shù)名參數(shù)值說明mapred.jobtracker.taskSchedulerOrg.Apache.Hadoop.mapred.FairScheduler公平調(diào)度,可以讓多個(gè)job并行，需要額外的jar包sdefault.tbequeue自定義公平調(diào)度名稱mapred.fairscheduler.allocation.file/home/bigdata/apps/Hadoop-mr-talkyun/cont/pools.xml公平調(diào)度的配置文件mapred.map.child.java.opts-Xmx1024設(shè)定每個(gè)map的jvm大小，使spill過程有足夠的內(nèi)存，減少磁盤IOmapred.reduce.child.java.opts-Xmx2048設(shè)定每個(gè)reduce的jvm大小，減少磁盤IOmapred.tasktracker.map.tasks.maximum8容忍的map作業(yè)最大并發(fā)個(gè)數(shù)按照前面的slot數(shù)量設(shè)置mapred.tasktracker.reduce.tasks.maximum8容忍的reduce作業(yè)最大并發(fā)個(gè)數(shù)同上pression.codec默認(rèn)Map結(jié)果輸出的默認(rèn)壓縮算法mapred.task.timeout默認(rèn)MapReduce任務(wù)默認(rèn)的超時(shí)設(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ù)會(huì)特別多，為了減少磁盤壓力，如果機(jī)器有多個(gè)磁盤，也可以像datanode的數(shù)據(jù)目錄設(shè)為”/disk1/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ù)實(shí)際情況考慮）HBase所使用的最大內(nèi)存HBASE_MANAGES_ZKFalse設(shè)置HBase不自行管理zk服務(wù)，需額外提供zk集群的服務(wù)文件：HBase-site.xml參數(shù)名參數(shù)值說明HBase.regionserver.handler.count20RegionServer的請(qǐng)求處理IO線程數(shù)，對(duì)于高并發(fā)，適當(dāng)調(diào)高以提升性能HBase.hregion.max.filesize53687091200region分割的閥值，適當(dāng)設(shè)大以減少region分裂的次數(shù)HBase.hregion.majorcompaction0關(guān)閉自動(dòng)major_compact，默認(rèn)是1天進(jìn)行1次對(duì)table的storefile記性合并清理，在保證集群性能的前提下，由運(yùn)維人員進(jìn)行該操作可以避免高峰期，會(huì)更靈活HBase.rpc.timeout600000節(jié)點(diǎn)間通信等待時(shí)間，主要是為了減少高并發(fā)時(shí)，延長(zhǎng)節(jié)點(diǎn)間響應(yīng)等待時(shí)間HBase.client.pause3000客戶端在重試前的等待時(shí)間HBase.regionserver.global.memstore.upperLimit0.39memstore占heap的最大百分比，直接影響寫的性能hfile.block.chche.size0.4storefile的讀緩存占用Heap的大小百分比，該值直接影響數(shù)據(jù)讀的性能HBase.hregion.memstore.flush.size

Region上MemStore的大小是64MBHBase.regionserver.handler.count一個(gè)RegionServer的最大并發(fā)handler數(shù)目HBase.regionserver.coprocessorhandler.count一個(gè)RegionServer的coprocessor最大并發(fā)handler數(shù)目系統(tǒng)調(diào)優(yōu)Hive1、少用count(distinct)例如：selectcount(distinctUSR_MOB_NBR)fromODS.TO_CDR性能差的原因：只會(huì)用一個(gè)reduce去處理。優(yōu)化的寫法：selectcount(1)from(selectUSR_MOB_NBRfromODS.TO_CDRgroupbyUSR_MOB_NBR)x;2、表關(guān)聯(lián)時(shí)，過濾條件寫在合適的位置例如：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性能差的原因：這樣寫會(huì)導(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會(huì)把小表全部讀入內(nèi)存中，在map階段直接拿另外一個(gè)表的數(shù)據(jù)和內(nèi)存中表數(shù)據(jù)做匹配，由于在map是進(jìn)行了join操作，省去了reduce運(yùn)行的效率也會(huì)高很多

這樣就不會(huì)由于數(shù)據(jù)傾斜導(dǎo)致某個(gè)reduce上落數(shù)據(jù)太多而失敗。于是原來的sql可以通過使用hint的方式指定join時(shí)使用mapjoin。select/*+mapjoin(A)*/f.a,f.bfromAtjoinBf

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

-無主控節(jié)點(diǎn)??*?無共享MPP架構(gòu)

-有主控節(jié)點(diǎn)??支持行存儲(chǔ)???支持列存儲(chǔ)???（10.5版本發(fā)布后）?前期測(cè)試發(fā)現(xiàn)，不同架構(gòu)的數(shù)據(jù)倉(cāng)庫(kù)各有優(yōu)缺點(diǎn)。比如帶主控節(jié)點(diǎn)（Master）的數(shù)據(jù)庫(kù)會(huì)存在單點(diǎn)故障，但各節(jié)點(diǎn)分工明確；無主控節(jié)點(diǎn)的數(shù)據(jù)庫(kù)不存在單點(diǎn)故障，但可能某各節(jié)點(diǎn)承擔(dān)的任務(wù)不平均。行存儲(chǔ)裝載數(shù)據(jù)快、壓縮率低、查詢速度稍慢；列存儲(chǔ)裝載數(shù)據(jù)滿、壓縮率高、查詢速度快，但部分產(chǎn)品的列存儲(chǔ)方式無法支持更新、刪除數(shù)據(jù)。所以建議在引入MPP數(shù)據(jù)庫(kù)前各公司應(yīng)該根據(jù)預(yù)期的應(yīng)用場(chǎng)景編寫測(cè)試案例，用去隱私的實(shí)際數(shù)據(jù)作為測(cè)試數(shù)據(jù)，對(duì)可選的MPP產(chǎn)品進(jìn)行評(píng)估，然后確定最適合自身場(chǎng)景的產(chǎn)品。硬件平臺(tái)選型建議MPP數(shù)據(jù)庫(kù)場(chǎng)景下經(jīng)常需要掃描大量的數(shù)據(jù)，所以對(duì)磁盤存儲(chǔ)系統(tǒng)的I/O性能要求非常高，在測(cè)試和日常運(yùn)行中，I/O多大情況下是瓶頸，這點(diǎn)與Hadoop平臺(tái)可以明顯區(qū)分開來。MPP數(shù)據(jù)庫(kù)大多架構(gòu)在X86平臺(tái)上，使用本地盤作為存儲(chǔ)，大部分的機(jī)架式服務(wù)器（少數(shù)也使用刀片服務(wù)器+磁盤陣列，但非主流）都可以勝任。為了充分發(fā)揮硬件的效率，需要實(shí)現(xiàn)磁盤I/O，內(nèi)存、處理器、網(wǎng)絡(luò)帶寬之間的平衡配置，使數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)提供最佳的性能。雖然每款MPP數(shù)據(jù)庫(kù)產(chǎn)品的典型均衡配置不一樣，且不同的場(chǎng)景也有不同的均衡配置原則，但是仍有一些規(guī)律可以參考。其數(shù)據(jù)節(jié)點(diǎn)一般按照如下要求來配置：CPU核數(shù)、內(nèi)存（G）和磁盤個(gè)數(shù)的配比：一般情況下為1：8：1或1：8：2。同等情況下磁盤個(gè)數(shù)越多性能越高，但磁盤總個(gè)數(shù)受機(jī)架式服務(wù)器的空間限制，一般為12（3.5寸）到16個(gè)（2.5寸），少部分非集采服務(wù)器更多。磁盤：為了獲得高可靠、高讀寫帶寬和高IOPS，應(yīng)選用SAS接口的企業(yè)級(jí)硬盤，轉(zhuǎn)數(shù)一萬及以上。RAID卡：雖然MPP數(shù)據(jù)庫(kù)大多通過副本的機(jī)制來保證某個(gè)節(jié)點(diǎn)故障情況下的高可用，但是代價(jià)高：大部分?jǐn)?shù)據(jù)庫(kù)故障情況下當(dāng)前應(yīng)用需要中斷，少部分?jǐn)?shù)據(jù)庫(kù)還需要重啟來應(yīng)對(duì)故障；且故障情況下理論的效率要下降50%而不是按故障節(jié)點(diǎn)比例下降。所以在選擇硬件平臺(tái)的時(shí)候要有限選擇高可靠的硬件，比如電源，更比如RAID卡。一般將通過RAID卡的PCI-E接口連接到主機(jī)上，通過RAID10或RAID5來保證單個(gè)磁盤出錯(cuò)不會(huì)觸發(fā)節(jié)點(diǎn)故障。這點(diǎn)也與Hadoop明顯區(qū)分出來。如果選擇刀片加磁盤陣列部署，應(yīng)該保證刀片的HBA卡至少8Gb以上，也即提供2GB/s的理論讀寫雙向帶寬。這樣在使用12塊磁盤的時(shí)候，磁盤總的吞吐為12*100MB=1.2GB/s的讀寫帶寬，HBA不會(huì)成為帶寬的瓶頸。另外SAN交換機(jī)側(cè)和磁陣的總的帶寬需要滿足所有刀片通過訪問存儲(chǔ)的需求，可以考慮使用多個(gè)低端磁盤陣列的方式來降低成本，同時(shí)滿足帶寬需求。除了數(shù)據(jù)節(jié)點(diǎn)外，組成MPP數(shù)據(jù)庫(kù)系統(tǒng)的可能還有主節(jié)點(diǎn)，一般來說，主節(jié)點(diǎn)由于可能成為瓶頸和單點(diǎn)故障，應(yīng)配置更好、更可靠的設(shè)備。每種數(shù)據(jù)庫(kù)主節(jié)點(diǎn)配置都有所差異，應(yīng)充分了解。接口和裝載服務(wù)器一般通過萬兆網(wǎng)絡(luò)連接到系統(tǒng)中，而接口機(jī)的IO可能成為瓶頸，要么多配置內(nèi)置盤，要么將其連接在高性能磁盤陣列上獲得高讀寫帶寬。容量評(píng)估方法建議影響容量評(píng)估的因素包括:RAID損失空間R操作系統(tǒng)與應(yīng)用軟件使用空間O格式化系統(tǒng)損失空間F數(shù)據(jù)庫(kù)壓縮比C數(shù)據(jù)庫(kù)系統(tǒng)空間S數(shù)據(jù)庫(kù)最優(yōu)工作空間容量比U實(shí)際處理數(shù)據(jù)的大小K實(shí)際數(shù)據(jù)轉(zhuǎn)換為數(shù)據(jù)庫(kù)空間的比率KR裸磁盤空間L可以按照如下步驟進(jìn)行估算：每個(gè)數(shù)據(jù)節(jié)點(diǎn)硬盤格式化后提供的文件系統(tǒng)空間FD=L（裸磁盤空間）-R（鏡像損失空間）-F（格式化損失空間）每個(gè)數(shù)據(jù)節(jié)點(diǎn)去除操作系統(tǒng)和應(yīng)用軟件的使用空間DD=FD-O（操作系統(tǒng)空間和應(yīng)用軟件空間）考慮文件系統(tǒng)轉(zhuǎn)化為數(shù)據(jù)庫(kù)空間的比率（T），一般來說兩副本就是50%，最終數(shù)據(jù)庫(kù)空間G=DD*T綜合公式G=（L-R-F-O）*T*U=K*KR/C一般情況下不考慮壓縮，MPP數(shù)據(jù)庫(kù)裸磁盤空間和可用的數(shù)據(jù)空間的比例為3.4：1，這是在兩副本的情況下。相比在Hadoop三副本的情況下約為5.2：1。當(dāng)然，考慮壓縮的情況下，可以裝入更多的原始數(shù)據(jù)，但壓縮率的計(jì)算因數(shù)據(jù)庫(kù)產(chǎn)品和所存數(shù)據(jù)的不同有很大的差別，需要實(shí)際測(cè)算。網(wǎng)絡(luò)評(píng)估方法建議 MPP數(shù)據(jù)庫(kù)中運(yùn)算的特點(diǎn)是多節(jié)點(diǎn)并發(fā)計(jì)算，其間可能會(huì)出現(xiàn)節(jié)點(diǎn)間的裝載、數(shù)據(jù)重分布、復(fù)制或數(shù)據(jù)廣播（如非分區(qū)鍵關(guān)聯(lián)等操作），最后各節(jié)點(diǎn)運(yùn)算結(jié)果數(shù)據(jù)匯總，所以節(jié)點(diǎn)間互連網(wǎng)絡(luò)的速度（包括帶寬和時(shí)延）會(huì)直接影響到計(jì)算效率的高低，這就使得MPP數(shù)據(jù)庫(kù)的架構(gòu)會(huì)對(duì)內(nèi)部互連網(wǎng)絡(luò)有較高的要求。因此MPP數(shù)據(jù)庫(kù)內(nèi)部交換網(wǎng)絡(luò)需要保證點(diǎn)到點(diǎn)的萬兆以太網(wǎng)帶寬，MPP數(shù)據(jù)庫(kù)對(duì)網(wǎng)絡(luò)的要求也與Hadoop有較大差別。因此每臺(tái)機(jī)器至少需要配置兩個(gè)網(wǎng)口（當(dāng)然配備兩個(gè)的大多數(shù)原因是為了保證高可用，而不是綁定在一起負(fù)荷分擔(dān)），推薦使用IB網(wǎng)卡（但是這種情況下，要注意PCI-E的版本應(yīng)3.0以上才能和網(wǎng)卡速度匹配）或萬兆網(wǎng)卡和交換機(jī)以保證內(nèi)部數(shù)據(jù)高速傳輸。用于數(shù)據(jù)加載的ETL服務(wù)器也應(yīng)處于內(nèi)部網(wǎng)絡(luò)內(nèi)以保證大數(shù)據(jù)量的加載性能。為了實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)的萬兆速度保障，在超過一個(gè)機(jī)柜的情況下，一般還需要通過核心交換機(jī)來實(shí)現(xiàn)FLATTREE方式的一比一收斂，參見之前Hadoop的組網(wǎng)章節(jié)。建設(shè)過程中的建議由于MPP數(shù)據(jù)庫(kù)皆為商業(yè)產(chǎn)品，故在前期選擇好了合作伙伴后，建設(shè)過程中可以獲得專業(yè)的服務(wù)，難度較小。但也應(yīng)該注意數(shù)據(jù)分布規(guī)劃、故障與恢復(fù)策略規(guī)劃的的問題。數(shù)據(jù)分布規(guī)劃得益于Share－Nothing的架構(gòu)，MPP數(shù)據(jù)庫(kù)的所有表都是分布式存儲(chǔ)的，所以在創(chuàng)建表時(shí)都需要指定分布鍵，分布鍵可以是單一字段，也可以是復(fù)合字段，然后通過Hash方式去分布。合理的分布鍵設(shè)計(jì)可以使得大部分的表關(guān)聯(lián)操作在一個(gè)節(jié)點(diǎn)內(nèi)完成，不需要跨節(jié)點(diǎn)進(jìn)行數(shù)據(jù)交互，這是MPP數(shù)據(jù)庫(kù)產(chǎn)品（按行Hash分布）與Hadoop（選擇按照塊隨機(jī)分布）的根本差別。數(shù)據(jù)Hash分布的示意圖如下：如上圖所示，通過分布鍵的選擇，數(shù)據(jù)將均勻分布在每個(gè)節(jié)點(diǎn)、每塊磁盤上，發(fā)揮每個(gè)節(jié)點(diǎn)、每塊磁盤的性能，從根本上解決IO瓶頸。所以分布鍵選擇的是否合理，將直接影響MPP數(shù)據(jù)庫(kù)的性能表現(xiàn)，在選擇表的分布策略時(shí)，需要重點(diǎn)考慮以下問題（問題由重要程度由高到低列出）均勻的數(shù)據(jù)分布--為了盡可能達(dá)到最好的性能，所有的數(shù)據(jù)節(jié)點(diǎn)應(yīng)該盡量存儲(chǔ)等量的數(shù)據(jù)。若數(shù)據(jù)的分布不平衡或傾斜，那些存儲(chǔ)了較多數(shù)據(jù)的節(jié)點(diǎn)在處理自己那部分?jǐn)?shù)據(jù)時(shí)將需要耗費(fèi)更多的工作量。為了實(shí)現(xiàn)數(shù)據(jù)的均勻分布，盡量選取具有唯一性的分布鍵，如主鍵。但往往有很多表沒有唯一鍵，那么盡量選擇數(shù)據(jù)分布規(guī)律性強(qiáng)且取值范圍非常大的字段作為分布鍵。本地操作與分布式操作--在處理查詢時(shí)，很多處理如關(guān)聯(lián)、排序、聚合等，若能夠在節(jié)點(diǎn)本地完成，其效率將遠(yuǎn)高于跨節(jié)點(diǎn)（需要在各節(jié)點(diǎn)間交叉?zhèn)鬏敂?shù)據(jù)）的操作。當(dāng)不同的表使用相同的分布鍵時(shí)，在分布鍵上的關(guān)聯(lián)或排序操作將會(huì)以最高效的方式在本地完成。本地操作大約比分布操作快5倍。如果采用隨機(jī)分布策略，將大大限制本地操作的可能。所以在實(shí)際的使用中，如果一個(gè)字段被大量的Join使用的話，建議以該字段作為分布鍵。平坦的查詢處理--在查詢正被處理時(shí)，我們希望所有的節(jié)點(diǎn)都能處理等量的工作負(fù)載，從而盡可能達(dá)到最好的性能。有時(shí)候查詢場(chǎng)景與數(shù)據(jù)分布策略很不吻合，這就會(huì)導(dǎo)致工作負(fù)載的傾斜。例如，有一張銷售交易表，該表的分布鍵為公司名稱，那么數(shù)據(jù)分布的Hash算法將基于公司名稱的值來計(jì)算，假如有一個(gè)查詢以某個(gè)特定的公司名稱作為查詢條件，該查詢?nèi)蝿?wù)將僅在一個(gè)節(jié)點(diǎn)上執(zhí)行，其他節(jié)點(diǎn)處于閑置狀態(tài)。工作負(fù)載傾斜就是如此發(fā)生的。除此之外，還有一種數(shù)據(jù)傾斜的原因是由于數(shù)據(jù)本身分布不均衡導(dǎo)致的，比如按照號(hào)碼的哈希做分布，如果某些號(hào)段的數(shù)據(jù)記錄數(shù)本身就比較多，就回產(chǎn)生數(shù)據(jù)的傾斜，相應(yīng)的計(jì)算也會(huì)產(chǎn)生傾斜。 在具體模型設(shè)計(jì)階段，建議按照如下的原則選擇分布鍵：選擇某數(shù)據(jù)列隨機(jī)性很大的字段，如phone_no,subs_id,account_id等，一般不建議將statis_date,area_code等作為分布鍵建議經(jīng)常用于表關(guān)聯(lián)的字段作為分布鍵，將經(jīng)常關(guān)聯(lián)的表的分布鍵設(shè)計(jì)為一致。以減少數(shù)據(jù)關(guān)聯(lián)時(shí)分布鍵不一致導(dǎo)致的某張表數(shù)據(jù)的重分布。分布鍵一致要求字段類型、長(zhǎng)度都要保持一致?？蛇x擇多個(gè)字段作為組合分布鍵，過多的字段組合會(huì)增加數(shù)據(jù)分布的消耗，建議最多不超過三個(gè)。某些MPP數(shù)據(jù)庫(kù)在建表時(shí)如果不指定分布鍵，默認(rèn)將表中的第一個(gè)字段作為分布鍵。如果第一個(gè)字段的列值較少，很容易導(dǎo)致數(shù)據(jù)分布不均衡。所以建表時(shí)一定要指定分布鍵。有些MPP數(shù)據(jù)庫(kù)支持分區(qū)組的概念，也即某些表雖然是HASH分布但是可以選擇存儲(chǔ)到一部分節(jié)點(diǎn)而不是整個(gè)集群的所有節(jié)點(diǎn)，數(shù)據(jù)量小的維度表適合采用這種方式。故障與恢復(fù)策略規(guī)劃MPP數(shù)據(jù)庫(kù)采用Share-Nothing的架構(gòu)，通過數(shù)據(jù)分布策略使得每個(gè)數(shù)據(jù)節(jié)點(diǎn)承擔(dān)相當(dāng)?shù)臄?shù)據(jù)任務(wù)。根據(jù)木桶理論，其中能力最差的節(jié)點(diǎn)將成為短板，因而影響MPP數(shù)據(jù)庫(kù)的整體性能。因此在配置的硬件的時(shí)候需要為數(shù)據(jù)節(jié)點(diǎn)選擇一致的配置（磁盤需要通過DD進(jìn)行測(cè)試確保一致，同一型號(hào)不一定一致）。另外在擴(kuò)容中，應(yīng)該優(yōu)先考慮一致的硬件，或者為新的高性能硬件分配更多的任務(wù)