目目 二、HDFS介 三、HDFS架 四、 十、HDFS十一、HDFS數(shù)據(jù)策 十二、Colocation同分 二、Yarn簡 三、Yarn架 四、MapReduce在Yarn中的任務(wù)調(diào) 五、Yarn通信協(xié) 七、Yarn的資源分 Spark的應(yīng)用運行流 五、SparkStructuredStreaming技術(shù)原 SparkStructuredStreaming概 Sparkstructuredstreaming計算模 六、SparkStreaming技術(shù)原 一、HBase定 五、Hive數(shù)據(jù)模 三、Streaming系統(tǒng)特 Kafkain KafkaCluster 我們不能單純的認(rèn)為大數(shù)據(jù)就是一個巨大的數(shù)據(jù)集，在百科中，大數(shù)據(jù)不1知道數(shù)據(jù)實際存放在那個位置上。4V百科的解釋一樣，數(shù)據(jù)的體量是超過我們所能的限度的。到非結(jié)構(gòu)化數(shù)據(jù)，大數(shù)據(jù)可以說基本囊括了當(dāng)前所有的類型的數(shù)據(jù)。1Value：價值密度，大數(shù)據(jù)其實整體來說價值密度是很低的，例如視息。就像我們說的，一潭終會干涸，大數(shù)據(jù)也是一樣。大數(shù)據(jù)不適合對小型隨機文件或者說是OLTP型業(yè)務(wù)進行分析，由于大數(shù)據(jù)中的hadoop架構(gòu)的元數(shù)據(jù)是由內(nèi)存進行的，所以一旦的部都是讀進程，并且該寫進程還位于所有進程的最后。那么針對于大量注：OLTP，業(yè)務(wù)類型名稱，OLTP型業(yè)務(wù)主要是以隨機用戶的大量寫入操作為特點，并且寫入的文件小。WORM（writeoncereadmany，意為寫入一次之后基FusionInsight解決方案由4個子產(chǎn)品FusionInsightHD、FusionInsightLibrA、FusionInsightMiner、FusionInsightFarmer和1個操作運維系統(tǒng)FusionInsightManager構(gòu)成。具體內(nèi)容請參考下圖FusionInsightHD：企業(yè)級的大數(shù)據(jù)處理環(huán)境，是一個分布式數(shù)據(jù)處理系FusionInsightLibrA：企業(yè)級的大規(guī)模并行處理關(guān)系型數(shù)據(jù)庫。FusionInsightLibrA采用MPP(MassiveParallelProcessing)架構(gòu)，支持行和列，提供PB(Petabyte，2的50次方字節(jié))級別數(shù)據(jù)HD的分布式和并行計算技術(shù)，提供從海量數(shù)據(jù)中挖掘出價值信息的FusionInsightManager：企業(yè)級大數(shù)據(jù)的操作運維系統(tǒng)，提供高可靠、編者注：目前的FusionInsight分為如上的幾大平臺，簡潔來說，Miner數(shù)據(jù)分析，搭建在HD之上。HD是底層平臺，集成了hadoop生態(tài)圈的各大組件，提供了和分布式計算的功能。LibrA提供的是并行分布式關(guān)系型數(shù)據(jù)庫，做到了數(shù)據(jù)倉庫的功能。Farmer提供的是軟件開發(fā)平臺。Manager提他們涵蓋了單位的大部分日常操作，如購物、庫存、制造、銀行、工資、、數(shù)據(jù)內(nèi)容：OLTP系統(tǒng)管理當(dāng)前數(shù)據(jù)。通常這種數(shù)據(jù)太瑣碎，很難用于決庫設(shè)計。OLAP系統(tǒng)通常采用星形或雪花模型和面向的數(shù)據(jù)庫設(shè)計。視圖：OLTP在系統(tǒng)主要關(guān)注的是一個企業(yè)或部門內(nèi)部的當(dāng)前數(shù)據(jù)，而不常常數(shù)據(jù)庫模式的多個版本。OLAP還處理來自不同單位的信息，以及由多個數(shù)據(jù)庫集成的信息。由于數(shù)據(jù)量巨大，OLAP數(shù)據(jù)也存放在多個模式：OLTP系統(tǒng)的主要由短的原子事務(wù)構(gòu)成，這種系統(tǒng)需要并大部分?jǐn)?shù)據(jù)倉庫存放歷史數(shù)據(jù)，而不是數(shù)據(jù)，盡管許多可能是復(fù)雜辦事員、表示這些符號或名稱。例如對于頭發(fā)的顏色，我們可以標(biāo)記0為黑色，1為棕色……，雖然標(biāo)稱屬性在這種情況下?lián)碛辛藬?shù)值，但是對這些數(shù)值進行計算是true和false。重。即0和1沒有什么偏好，例如男和女的屬性。檢測，為了方便計，我們就用1表示重要的結(jié)果。是有用的。因此序數(shù)屬性經(jīng)常用于等級評定。例如顧客的滿意度1-滿意，2-一般，3-不滿意，4-很不滿意。序數(shù)屬性的中心趨勢可以用眾數(shù)和中位數(shù)來進行注意：標(biāo)稱、二元和序數(shù)屬性都是定性的，也就是說他們描述對象的特征，而了某個含義，對其進行數(shù)算是沒有任何意義的?；?。因此我們可以針對這些值進行比較和定量評估值之間的差。名字，在一個數(shù)據(jù)中可能表示成name，但是另一個數(shù)據(jù)庫就可能是⑥使用最可能的值填充缺失值：可以用回歸，使用形式化方法的創(chuàng)建一棵決策樹，來預(yù)測屬性的缺失值。用離群點檢測技術(shù)將其檢測出來，或者是使用回歸技術(shù)將噪聲數(shù)據(jù)擬合到數(shù)據(jù)就被視為離群點。數(shù)據(jù)挖掘經(jīng)常需要數(shù)據(jù)集成，合并來自多個數(shù)據(jù)的數(shù)據(jù)。集成有助問題。例如機器如何才能正確識別一個數(shù)據(jù)庫中的name和另一個數(shù)據(jù)庫中的customer是一個屬性。我們一般通過元數(shù)據(jù)進行數(shù)據(jù)的集成， 致結(jié)果數(shù)據(jù)集中的冗余。數(shù)據(jù)值數(shù)據(jù)集成還涉及數(shù)據(jù)值的檢測和處理，例如對某一些數(shù)據(jù)來說單位①維歸約是減小所考慮的隨量或?qū)傩缘膫€數(shù)。維歸約方法包括小波N個最能代表數(shù)據(jù)的正交向量，這樣原有的數(shù)據(jù)就會被投影到一個小得：對數(shù)據(jù)進行匯總或。例如可以日銷售額，去計算月和離散化：數(shù)值屬性的原始值用區(qū)間（例如1-10，0-1）或概念標(biāo)相反，他們首先將所有的連續(xù)值看做可能的點，通過合并鄰域的值形成區(qū)于多個抽象層上的挖掘，概念分層也是有效的。Hadoop以塊形式是目前最常用的一種數(shù)據(jù)方式，我們在進行數(shù)據(jù)時，使用的是元數(shù)據(jù)加數(shù)據(jù)的形式，元數(shù)據(jù)相當(dāng)于是數(shù)據(jù)的一個信息，保存著文于索引，數(shù)據(jù)相當(dāng)于是正文，我們查字典就和查找數(shù)據(jù)一樣，首先需要二、HDFSHDFS（HadoopDistributionFileSystem）是運行在通用硬件（所謂通用硬對于HDFS文件系統(tǒng)包括整體的Hadoop組件來說，這樣做就可以達到完美的拓的方式進行性能的拓展，直到滿足大數(shù)據(jù)處理系統(tǒng)的需求，這樣做可以減小在BUG，那么就會在一批設(shè)備上出現(xiàn)相同的問題，造成整體性能的下降或者系統(tǒng)的安全性）上的分布式文件系統(tǒng)，它具有高容錯性，高吞吐量并且支持大文件。注：由于HDFS的文件系統(tǒng)是需要將元數(shù)據(jù)加載在內(nèi)存中進行的，我們又將該進程稱之為Namenode，系統(tǒng)需要為每一個數(shù)據(jù)文件約150字節(jié)的相同的文件數(shù)目下，大文件和小文件的開銷相同，那么大文件就更加合理。并且作為大數(shù)據(jù)主要使用的文件系統(tǒng)，HDFS保護數(shù)據(jù)的一致性和讀寫的性能，就提出了WORM模型作為HDFS整體的系統(tǒng)設(shè)計目標(biāo)，WORM-writeoncereadmany，WORM的最開始是使用在系統(tǒng)中，用于對關(guān)鍵數(shù)據(jù)進行保護的，比如，的文件等，這些文件可以允許進行，但是由于需要保護其不受篡改所以就需要WORM來進行保證，當(dāng)一個任何寫都不能執(zhí)行。當(dāng)文件大小為0取，所以我們并沒有將WORM設(shè)計的很嚴(yán)格。我們寫入的文件是不再允許修改三、HDFS在大數(shù)據(jù)的組件架構(gòu)中，HDFS提供的是整個結(jié)構(gòu)最底層的文件功能，他組織了文件形式，將數(shù)據(jù)切分為數(shù)據(jù)塊起來，并且記載和元數(shù)據(jù)。HDFS入到內(nèi)存中運行的。NameNode作為元數(shù)據(jù)的進程，為了能夠提升整體的效率，所以元數(shù)據(jù)的進程搭載在內(nèi)存中進行運行的。當(dāng)系統(tǒng)啟動之后，服務(wù)器會拉起HDFS進程，然后將NameNodeNameNodeDatanode：用于實際的數(shù)據(jù)，每個Datanode會將自己的數(shù)據(jù)塊信息上報到Namenode，運行多個實例。HDFS默認(rèn)最小的空間為block，每個block默認(rèn)的大小為128MB。DataNode除了需要數(shù)據(jù)之外，還需要留有一部分的空間用于元數(shù)據(jù)鏡像文件Fsimage。如果NameNode和DataNode是部署在一起的，那么Fsimage就在DataNode上，其實相當(dāng)于是在服務(wù)器的介質(zhì)上。如果NameNode和DataNode是分開部署的，那么就相當(dāng)于Fsimage是在部署NameNode的服務(wù)器上的。如下圖所示：：支持業(yè)務(wù)HDFS，并從Namenode和Datanode中獲取數(shù)據(jù)，返回給用戶，多個業(yè)務(wù)和實例一起運行。這里所說的并可以HDFS，相當(dāng)于HDFS是一間房，為我們提供了進入的門，提供的接口主要有JDBC和ODBC接口。HDFS為了達成高可用性進群，設(shè)計了以下幾個組件來保證可靠性。由于HDFSzookeeper：分布式協(xié)調(diào)進程，用來HA下的狀態(tài)文件，主備信息，zk建議為三個或三個以上的奇數(shù)個。Zookeeper進程主要提供的是對NameNode進程的保護，這里所謂的保護其實是用于裁決NameNode備狀態(tài)，并且NameNode的狀態(tài)信息。Namenode主備：在主備模式中，主節(jié)點提供服務(wù)，備節(jié)點合并元數(shù)據(jù)并作為主節(jié)點的熱備。NameNode為了能夠保護自身的可靠性，元數(shù)據(jù)提供業(yè)務(wù)，另一個進程作為備進程，但是備進程并不是冷備，而是處于熱備狀態(tài)，一旦進程出現(xiàn)故障，那么備進程可以立即受到消息，然后切換狀態(tài)，由于備進程本身在進行元數(shù)據(jù)持久化的過程中了FsimageEditlogFsimage，Editlog戶對于元數(shù)據(jù)的修改操作，F(xiàn)simage是元數(shù)據(jù)的鏡像。ZKFC（zookeeperFailoverControllerNamenodeNameNode現(xiàn)故障的時候可以及時的進行故障切換，將業(yè)務(wù)切換到備NameNode中進行運行，保障業(yè)務(wù)的連續(xù)性，所以ZKFC需要及時檢測主備NameNode的狀態(tài)，并且將心跳信息及時上報給Zookeeper，所以ZKFC進程和NameNodeNameNodeZKFC要的兩個工作就是獲取NameNode上報的心跳，并且進行故障切換這兩ZKFC進程和NameNode進程強耦合，所以兩個進程需要部署在一起，NameNodeZookeeperZKFC所以我們可以理解ZKFC是一個通道或者是一個發(fā)送的接口進程。當(dāng)Zookeeper沒有收到心跳時，就會下發(fā)對應(yīng)的failover操作給ZKFC，那么這個時候ZKFC就負(fù)責(zé)控NameNode接管業(yè)務(wù)。J（JournalNode文件是我們對HDFS的操作的日志文件，這些信息并未寫入到FSimageHDFS 性保證，HA提供的是進程的可靠性保證，那么數(shù)據(jù)的可靠性保證就可以通過兩RAID中出現(xiàn)降級重構(gòu)或者預(yù)拷貝而導(dǎo)致的性能影響問題。我們默認(rèn)會三份2AB4.所以的距離副本1：Distance=00，第二份數(shù)據(jù)隨機進行，在除源數(shù)據(jù)服務(wù)器以外的任意一個位置，第三份副本通FsimageFsimage件就是上一次開機時加載的文件，從時效性上來說，就會很。當(dāng)下一次開機并且同時為了保證數(shù)據(jù)的安全性（比如在突然斷電的情況下，Editlog和Fsimage就可以出現(xiàn)數(shù)據(jù)丟失的情況，我們也需要元數(shù)據(jù)持久化，主要是為了達成這個目的，我們就需要通過元數(shù)據(jù)持久化這個操作來保證主備之間關(guān)于Namenode1Editlog64M時，啟動一次元數(shù)據(jù)持久化操作。來記錄臨時操作，將原先的Editlog文件發(fā)送到備端進行合并和。EditlogJNNameNodeNameNodeEditlog備節(jié)點會對Editlog和Fsimage兩個文件做合并，生成一個名為EditlogEditlogID。生成的文件我們稱之為.ckptcheckpoint，就是指我們認(rèn)為在該時間點之前的數(shù)據(jù)都是正常并且正確的文件可以被持久化到硬件Fsimage，F(xiàn)simage.ckptEditlogEditlogEditlog前我們也提過，HDFS作為大數(shù)據(jù)文件系統(tǒng)，有一個特點就是它認(rèn)為硬件總是不HDFSHAHDFS的進程可靠性，通過元數(shù)據(jù)持久化保障了元數(shù)據(jù)的可靠性，數(shù)據(jù)的可靠性Datanode和Namenode之間需要通過心跳機制來保證數(shù)據(jù)狀態(tài)，由Namenode來決定Datanode是否需要上報完整性，如果Datanode由于損壞無法進行完NamenodeDatanode照心跳信息的形式去發(fā)送。雖然我們說NameNode和DataNode之間是通過心NameNode沒有收到周期性發(fā)送的數(shù)據(jù)完整性報文，也就相當(dāng)于DataNode出現(xiàn)NamenodeDatanode由于NameNode本身需要周期性的獲取DataNode的數(shù)據(jù)完整性信息，那么NameNode本身就可以根據(jù)自身的機制從DataNode上獲取數(shù)據(jù)的分布情況，所以本身就存在著獲取數(shù)據(jù)分布的能力，然后NameNode作為元數(shù)據(jù)節(jié)點，自身還可以進行該信息的匯總收集和，一方面NameNode從DataNode上獲取了數(shù)據(jù)的分布情況，另一方面NameNode也根據(jù)該信息可以更新元數(shù)據(jù)，DataNodeNameNode數(shù)據(jù)的完整性。所以在這里RebalancingServer可以直接向NameNode獲取Namenode均衡服務(wù)會根據(jù)NameNode上報的數(shù)據(jù)分布匯總的情況，決定哪一些節(jié)點需要進行數(shù)據(jù)的均衡操作。然后在根據(jù)分析的情況再向NameNode請求詳細(xì)的數(shù)據(jù)分布情況，之后根據(jù)NameNodeRebalancingServer在遷移的過，由于遷移相當(dāng)于是剪切的操作也可以理解為移動move操作，所以在遷移的過，為了保證數(shù)據(jù)的安全性，我們的RebalancingServer就RebalancingServer相當(dāng)于除了遷移操作之外，RebalancingServer還會對每一個遷移的數(shù)據(jù)做一RebalancingServer中刪除。在均衡的過，我們需要考慮一個問題，就是遷移對網(wǎng)絡(luò)的影響，由于遷移法的，所以我們需要在業(yè)務(wù)空窗期進行數(shù)據(jù)的遷移是最合適的，那么業(yè)務(wù)的Namenode為了保障Datanode中的數(shù)據(jù)讀出都是有效的，HDFS設(shè)計了一個機制，針對每如果校驗值不匹配，Namenode就會認(rèn)為數(shù)據(jù)已經(jīng)失效，將會從其他節(jié)點上的副值是通過哈希值算法得到的，跟隨數(shù)據(jù)一起寫入到DataNode中。當(dāng)節(jié)點硬盤故障時，進入安全模式，HDFS只支持元數(shù)據(jù)，此時HDFS上首先，客戶端請求寫入一個文件，通過自身的DistributedFileSystemNamenodeRPC請求。提供了對外的接口，和對內(nèi)其他組件之間的交互接口。RPC過程調(diào)用，的數(shù)據(jù)寫入操作，這個時候我們使用的就是流式數(shù)據(jù)導(dǎo)入進程。那么FsDataOutputStream提供的還是一個接口，但是數(shù)據(jù)這次在進行寫入的時業(yè)務(wù)會在本地調(diào)用writeAPI接口，將數(shù)據(jù)寫入到進收到數(shù)據(jù)之后，會將數(shù)據(jù)通過FSDataOutputStreamDFSOutputStream，DataNodeDataNode建空間寫入數(shù)據(jù)到DataNode1，再由DataNode1到DataNode2,DataNode3所有數(shù)據(jù)確認(rèn)完成后，文件寫入成功，業(yè)務(wù)調(diào)用HDFS關(guān)閉文件的寫完成，NameNode更新元數(shù)據(jù)首先，客戶端請求一個文件，通過自身的DistributedFileSystemNamenodeRPC請求HDFS聯(lián)系NameNode，獲取到文件信息（數(shù)據(jù)塊、DataNode位置信業(yè)務(wù)應(yīng)用調(diào)用readAPI文件。DistributedFileSystem通過對NameNode發(fā)出RPC請求，確定要文件的block的位置，F(xiàn)SDataInputStream中數(shù)據(jù)HDFS根據(jù)從NameNode獲取到的信息，(采用就近原則流式，也體現(xiàn)了HDFS的高吞吐量的特點，第二個就是關(guān)于數(shù)據(jù)副本機制的NameNodeSideMountTable對命名空間劃分和管理。NameSpace（NS：命名空間。HDFS名空間包含、文件和塊。Pool：blockpool.FederationHDFS（Namespace（blockpool個物理概念，而blockpool是一個重新將block劃分的邏輯概念。同一個NameNodeDataNodeNameNode的服務(wù)。十一、HDFS數(shù)據(jù)策DataNode上存在的不同的設(shè)備，數(shù)據(jù)需要選擇一個合適的設(shè)備分級存DataNode不同 適的DataNode節(jié)點保存。DataNode數(shù)據(jù)策略可以廣泛的應(yīng)用于各種業(yè)務(wù)，就像中使用的分級一樣，在HDFS中，我們一樣可以提供很高的一個的策略，用于做不同業(yè)務(wù)的數(shù)據(jù)保時候就可以將數(shù)據(jù)放在內(nèi)存虛擬硬盤或者是SSD中，電視劇結(jié)局之后，量就 量很小的時候就可以將數(shù)據(jù)放在SATA硬盤或者進行歸檔。HDFS的策略和以上 的策略比較類似，但是HDFS存放數(shù)據(jù)涉及的根據(jù)量（1） 略為指定下的文件選擇DataNode節(jié)點進行存放時，根據(jù)文件的表達式這里詳細(xì)解釋可以理解為，我們是給元數(shù)據(jù)進行的打的操作，由NameNode發(fā)現(xiàn)，不管是什么寫操作，在寫入之前第一步都必須要對元數(shù)據(jù)做，那么這個時候，我們給元數(shù)據(jù)上就打了，也就相當(dāng)于是在元數(shù)據(jù)分配寫空間的時候配置DataNode使用節(jié)點組：關(guān)鍵數(shù)據(jù)根據(jù)實際業(yè)務(wù)需要保存在具有高度可靠性的節(jié)點中，此時DataNode組成了異構(gòu)集群。通過修改DataNode的策節(jié)點組和①節(jié)點組是由DataNode執(zhí)行的，是由NameNode來做的②節(jié)點組的作用對象是副本數(shù)據(jù)?？刂频脑词堑谝环輸?shù)據(jù)。作用對象是第一份數(shù)據(jù)的寫入，控制的源是元數(shù)據(jù)中的。安全性和可用性，所以的控制范圍要比節(jié)點組的范圍要大。虛擬硬盤、DISK（機械硬盤、ARCHIVE（高密度低成本介質(zhì)、SSD（固態(tài) 綜上所述，所以Block放置位置策略指定的是在正常的情況下，數(shù)據(jù)的 NONE值，那么一旦主策略無法寫入那么就會直接返回寫入失敗。要保證數(shù)據(jù)的一致性，比如Oracle中不同的LUN的需要保證實時性，并高速，就可以只從一個節(jié)點獲取到全部的數(shù)據(jù)，減少了節(jié)點間的交源的浪費，在同一位置還更利于數(shù)據(jù)的，并且大數(shù)據(jù)平臺本身就提供了我們只需要按需拓展我們的節(jié)點，通過Scale-out來進行性能線性拓展，而本身（luteInrstucueHadoopMapReduce（trFawrk譯，比如其在Python中就作為了一個語句固件被編程者使用。MapReduce（ProgrammingModel&Methodology。MapReduce行相關(guān)的操作。這樣的話，MapReduce資源進行操作，那么設(shè)備越多我們?yōu)榱嗽O(shè)備所需要從MapReduce中提供作為一個離線這里主要想要表達的是MapReduce對于計算引擎之間的低效問題。由于MapReduce不支持進行數(shù)據(jù)共享就導(dǎo)致了其對于資源的利用率過低的問題。數(shù)據(jù)共享，或者中間結(jié)果共享，那么就會出現(xiàn)問題，MapReduce須將自己的計算結(jié)果先存入到底層的組件中，才能被其他組件調(diào)用到，那么數(shù)據(jù)下盤第一個會造成的問題在于，這里的數(shù)據(jù)作為一個臨時結(jié)果對于HDFS等二、YarnApacheHadoopYARN（YetAnotherResourceNegotiator，另一種資源協(xié)調(diào)YarnMapReducev1MapReduce了一體，那么Yarn主要帶來了以下的幾個好處：增大拓展性：前面說到拓展性的受限主要是由于計算引擎需要自身去節(jié)點，那么Yarn第一步就將節(jié)點的作業(yè)從引擎身上卸載到Y(jié)arn來做，以往每個引擎都需要自身去，可能一個節(jié)點安裝了5個計算引擎，那么5個計算引擎就會有5個節(jié)點進程，現(xiàn)在交由Yarn做之后，就會將這些進程單點故障：Yarn的第二個作用就是解決了單點故障的問題，yarn將計算管理不再交由計算引擎來進行，而是交由Yarn來進行。如果傳統(tǒng)的計算引反而消耗的資源會。當(dāng)Yarn將整體任務(wù)規(guī)劃執(zhí)行卸載到自身之后，一計算框架之間的共享：Yarn的出現(xiàn)了計算引擎之間的差異，主要是從現(xiàn)在傳統(tǒng)的計算引擎中，每個計算引擎都會自身的資源，這個時候如果某一Yarnyarn管理的資源上，這個時候，我們的臨時數(shù)據(jù)就不需要在執(zhí)行寫入操作，直接在內(nèi)存中進行資源分配，將包含數(shù)據(jù)的那一部分內(nèi)存直接調(diào)用給其他引擎進三、YarnRM是內(nèi)存和CPU資源。所有的應(yīng)用在被提交之后首先第一步都是需要做資源的申請的。業(yè)務(wù)提交之后會根據(jù)自身的資源消耗情況向RM做申請，RM需要做資源的分配，以及資源的回收。包括與ResourceManger保持通信，監(jiān)督Container的生命周期管理，每和不同應(yīng)用程序用到的附屬服務(wù)（auxiliaryservice。這里我們說RM本身是資源的管控者，資源是在NM上的，相當(dāng)于NM實際擁RM是自己的。NM需要上報自己的資源擁有狀況給RM，RM在根據(jù)相關(guān)任務(wù)情ApplicationMaster(AM)：負(fù)責(zé)一個Application生命周期內(nèi)的所有工作。包Container：Yarn中的資源抽象，它封裝了某個節(jié)點上的度資源，如內(nèi)存MapReduce中執(zhí)行任務(wù)的工作單位，其是一個資源的集合體，它是一CPURMNMNM一個CPU和內(nèi)存的集合體，這個集合體就是Container。NodeManager主要工作是節(jié)點資源管理和容器管理，RM是系統(tǒng)中將資源分四、MapReduceYarnYARNApplicationMaster動ApplicationMaster令、用戶程序等。這里還是一個進程，并非是用戶的程序，用于提交執(zhí)行應(yīng)用，然后提交對應(yīng)的應(yīng)用，然后將應(yīng)用轉(zhuǎn)發(fā)到RM上進行進一步的操作，應(yīng)AmasterResourceManager為該應(yīng)用程序分配第一個Container，并與對應(yīng)的NodeManager通信，要求它在這個ContainerRMAppManager，ResourceScheduler，AppManager主要是對提交到引擎上的多個應(yīng)用進行一個統(tǒng)一集中的管理，保證RMAppMasterCPU的資源，然后通告對應(yīng)NM節(jié)點，在其身上拉起一個Container，由于個Container中運行AppMaster。ApplicationMaster首先向ResourceManager，這樣用戶可以直接通并它的運行狀態(tài)，直到運行結(jié)束，即重復(fù)步驟4~7。AppMaster啟動之后，首先第一步需要向AppManager去進行相關(guān)的操作，否則Appmaster將會是一個的程序。行的階段，最終切分為執(zhí)行的一個個計算工作，我們稱之為task，之后它會計算當(dāng)前的task所需要消耗資源，然后向ResourceScheduler進行資源的申請操作，ResourceScheduler同意之后將和NM進行通信，通知NM分配相關(guān)的資源使用權(quán)給AppMaster。以及當(dāng)前計算的開銷NM，將其資源分配給 各個任務(wù)通過某個RPCApplicationMasterApplicationMaster應(yīng)用程序運行完成后，ApplicationMaster五、YarnApplicationProtocol：Job通過該RPC協(xié)議提交應(yīng)用程序、ResourceManagerAdministrationProtocol：AdminRPCApplicationMasterProtocol：AM通過該RPC協(xié)議向RM和撤銷自己，ContainerManagementProtocol：AM通過該RPC要求NMContainer，ContainerResourceTracker：NM通過該RPC協(xié)議向RM，并定時發(fā)送心跳信息匯報當(dāng)前節(jié)點的資源使用情況和Container運行情況。MapReduceHDFS個唯一的JobID進行區(qū)分。JobID將分片與MapTask進行一一對應(yīng)。MapReducetaskMapTask些NMContainertaskMap區(qū)寫滿，最前端的數(shù)據(jù)就會溢出寫入到本地磁盤中，觸發(fā)Reduce進程在進行Reduce（可選③組合：根據(jù)用戶的要求，可選將結(jié)果進行組合，最終產(chǎn)生一個總結(jié)果（可選并為MOF文件進行輸出，MOF（MapOutputFile）MOF文件在進行輸出的時候首先是放置在內(nèi)存（這里所說的內(nèi)存并不是之MOFMOFMOFAppMaster在啟動之后，首先會向AppManager執(zhí)行操作。之后會根據(jù)為單位向RS去申請。會要求該NM啟動容器，并且將task進行發(fā)送。Appmaster11.AppMasterkeyMOFeryarn.nodemanager.resource.memory-yarn.nodemanager.vmem-pmem-yarn.nodemanager.resource.cpu-調(diào)度器一群隊列的信息。用戶可以向一個或者多個隊列提交應(yīng)用。每次NMFIFOQ110，Q212，則會優(yōu)先將資源分配給Q1；行過可能產(chǎn)生多個Container。被終止。NM總內(nèi)存閾值的計算方法是：namic.memory.usage.threshold、單位GBNM.MEM=分配給容器運行任務(wù)的內(nèi)存*1024*1024*nodemanagerContainers的總內(nèi)存利用率并沒有超過設(shè)置的集群內(nèi)存閾值，那么那些內(nèi)存使用過多的Containers仍可以繼續(xù)運行。十、Yarn 運行在普通性能的機器上。Labelbasedscheduling是一種調(diào)度策略。該策略的基本思想是：用戶可以為每個nodemanager標(biāo)注一個，比如high-memory，high-IOnodemanager列中的作業(yè)，只會使用標(biāo)注有對應(yīng)的節(jié)點上的資源，即任務(wù)實際運行在打有對應(yīng)的節(jié)點上。將耗內(nèi)存消耗型的任務(wù)提交到綁定了high-memry的標(biāo)在YARNApplicationMaster(AM)ContainerNodeManager上（忽略未管理的AM。AM可能會由于多種原因、退出或關(guān)AMResourceManager(RMApplicationMaster理的所有Container，包括當(dāng)前任務(wù)在NodeManager(NM)上正在運行的所有RM會在另一計算節(jié)點上啟動新的ApplicationMaster。不同類型的應(yīng)用希望以AM。MapReduce由于 AM的故障而導(dǎo)致整個服務(wù)停止運行。YARN支持在新的ApplicationMaster啟動時，保留之前Container的狀態(tài)，因此運行中的作業(yè)性能提升的并不明顯，基本和Hadoop持平。Spark是基于內(nèi)存的分布式批處理引擎，它最大的特點是延遲小，具有很高HadoopSparkHadoop100Spark的計算速度沒有hadoop快，但是當(dāng)反復(fù)的重復(fù)和迭代層數(shù)多以后，本身從原理上來說，SparkCoreStandaloneYARN、SparkSQL：SparkSQL是一個用于處理結(jié)構(gòu)化數(shù)據(jù)的Spark組件，作為ApacheSparkCore來進行計算。SparkStreaming：微批處理的流處理引擎，將流數(shù)據(jù)分片以后用StructuredStreaming為2.0版本之后的spark獨有。它是構(gòu)建在Driver：負(fù)責(zé)應(yīng)用的業(yè)務(wù)邏輯和運行規(guī)劃Driver前，Driver就需要對任務(wù)做相關(guān)的劃分和處理的順序的控制，將任務(wù)的執(zhí)行規(guī)DAG（DAG：DAG如果是Spark，則由Driver執(zhí)行。的RM，沒有在自身引擎內(nèi)創(chuàng)建和RM。Executor：ExecutorExecutor是一個更小化的概念，我們的AppMaster在申請的時候，申請的是App會啟動一個SparkContext，也就是Application的Driver，驅(qū)動整個Application的運行。Job；actioncollect，countDriverApplication炒菜的一步步的job來進行執(zhí)行。候整體的計算流程就已經(jīng)劃分為了Application—Job—Stage—taskTasktask保證全局應(yīng)用的唯一并且拆解，最終成為DAG的形式提交，按照如上的基本概念RMNMNM其中打開AppMaster。創(chuàng)建完成之后在內(nèi)部繼續(xù)創(chuàng)建Executor。結(jié)束之后，Executor就會關(guān)閉自身進程，然后NM將資源做回收操作。任務(wù)計算完成之后，DriverRM并且向返回對應(yīng)的執(zhí)行結(jié)果。如果在執(zhí)行的過，我們有相關(guān)的查詢操作，這個時候，請求會通過由于DriverDAG規(guī)劃。那么在實際進行計算的時候，一個大的數(shù)據(jù)也就會按照這種DAG性計算產(chǎn)生的小的數(shù)據(jù)集就被稱為RDD彈性分布式數(shù)據(jù)集。RDD的生成：從Hadoop文件系統(tǒng)（或與Hadoop兼容的其它系統(tǒng)）輸入創(chuàng)建（如HDFS?；蛘邚母窻DD轉(zhuǎn)換得到新的RDD。后，我們首先在Duiver中會進行Application到task的DAG切分，這個候是按照DAG的執(zhí)行反向順序進行的創(chuàng)建，由一個大的文件，也就是量級比較大的父RDD，逐步的切分為多個子RDD，直到最終子RDD的對應(yīng)關(guān)系可以和taskRDD的和分區(qū)：用戶可以選擇不同的級別RDD以便重用（11種。當(dāng)前RDD默認(rèn)于內(nèi)存，但當(dāng)內(nèi)存不足時，RDD會溢出到磁盤中。RDD在需要進行分區(qū)時會根據(jù)每條記錄Key進行分區(qū)，以此保證兩個數(shù)據(jù)集能高效進行Join操作。我們在執(zhí)行相關(guān)的計算時，主要有兩種大類的操作，為transfermation和action，transfermation執(zhí)行的操作結(jié)果還是一個RDD，相當(dāng)于在執(zhí)行計算的過，transfermation產(chǎn)生的是臨時的數(shù)據(jù)集，對數(shù)據(jù)做一些基本的操作和處理。如map、filter、join等。Transformation都是Lazy的，TransformationActionactioncount，collect，saveAction或者將結(jié)果寫入的操作。ActionSpark應(yīng)用真正執(zhí)行的觸發(fā)動作。RDD的11 來提高能。RDD都是可序列化的，在內(nèi)存不足時自動降級為磁盤。HadoopMapReduce(SpeculativeExecution)(SpeculativeExecution)：為了避免這種情況發(fā)生，Hadooptaskspeculative提高整Job的執(zhí)行時間。RDDRDDRDD（計算或者轉(zhuǎn)換等）得到一個新的RDD，那么這個RDD在執(zhí)行Application類操作的時候是會產(chǎn)生對原RDD的依賴關(guān)系，那么此時，原RDD成為父RDD，新的RDD為子RDD。窄依賴（Narrow）RDDRDD寬依賴（Wide）指子RDD的分區(qū)依賴于父RDD的所有分區(qū)，是Stage窄依賴對優(yōu)化很有利。邏輯上，每個RDD的算子都是一個（joinjoin算子，而是指同步多個并行任務(wù)的barrier；把計算fork到每個分區(qū)，算完后join，然后下一個fork/join。如果直接轉(zhuǎn)換到物中，費時費空間；二是join作為全局的barrier，是很昂貴的，會被最慢的那個節(jié)點拖死。如果子RDD的分區(qū)到父RDD的分區(qū)是窄依賴，就可以把兩個fork/join合為一個；如果連續(xù)的變換算子序列都是窄依賴，就可以把很多個fork/join并為一個，不但減少了大量的全局barrier，而且無需物化很多中間結(jié)果RDD，這將極大地提升性能。Spark把這個叫做pipeline優(yōu)化。RDD的序列化，我們在進行計算時，由于RDD之間包括我們執(zhí)行的計算之間都存的容量不足時，我們就需要將一部分的RDD在硬盤中，這個時候，由于RDD存在序列化編號，這樣我們就可以根據(jù)編號繼續(xù)按順序進行計算操作，而不會導(dǎo)致由于RDD沒有編號產(chǎn)生的計算的問題。窄依賴的優(yōu)勢：首先，narrowdependencies可以支持在同一個cluster因為它只需要重新計算丟失的parentpartition即可，而且可以并行地在不Stage劃分：stage的劃分是Spark作業(yè)調(diào)度的關(guān)鍵一步，它基于DAG確定依賴關(guān)系，借此來劃分stage，將依賴鏈斷開，每個stage內(nèi)部可以并行stageJob。實際應(yīng)用提交JobRDD依賴關(guān)系是十分復(fù)雜的，依據(jù)這些依賴關(guān)系來劃分stage自然Spark此時就利用了前文提到的依賴關(guān)系，調(diào)度器從DAG圖末端出發(fā)，逆向遍ShuffleDepndenc遇到NarrowDependency就將其加入到當(dāng)前stage。stage中task數(shù)目由stage末端的RDD分區(qū)個數(shù)來決定，RDD轉(zhuǎn)換是基于分區(qū)的一種粗粒度計算，一個stage執(zhí)行的結(jié)果就是這幾個分區(qū)構(gòu)成的RDD。計算結(jié)果相互進行迭代和調(diào)用，這也就導(dǎo)致了在轉(zhuǎn)化為DAG的過，我們的的話，某一些計算的RDD算子，就會依賴于其之前計算的RDD，產(chǎn)生了相關(guān)的依賴關(guān)系，如果某個RDD只依賴于一個RDD的運算就可以執(zhí)行自身的計算，RDDRDD滿足執(zhí)行下一步執(zhí)行的條件，這個時候我們就稱之為RDD之間的關(guān)系叫做寬依賴。在具體的實際執(zhí)行過窄依賴要遠(yuǎn)遠(yuǎn)優(yōu)秀于寬依賴，所以我們需要將寬依賴拆分為窄依賴，這樣就可以提升整體的執(zhí)行效率，那么每遇到一個寬依賴之后，可以出現(xiàn)這種情況，當(dāng)寬依賴出現(xiàn)的時候，由于寬依賴的子RDD需要依賴的父才能執(zhí)行下一階段，如上圖中，須要等待Stage1執(zhí)行完畢，所有的分區(qū)Stage2，Stagestage的次的調(diào)度器，DAGScheduler把DAG拆分成很多的tasks，每組的如數(shù)據(jù)本地性等；DAGScheduler還要監(jiān)視因為shuffle輸出導(dǎo)致；服務(wù)，TaskScheduler接受來自DAGScheduler發(fā)送過來的分組的任務(wù)，行，如果某個task運行失敗，TaskScheduler要負(fù)責(zé)重試；另外如果Task，哪個任務(wù)先運行完就用哪個任務(wù)的結(jié)果。DAGRDD的依賴關(guān)系并且根據(jù)該RDD的依賴關(guān)系做任務(wù)的切分，也就相當(dāng)于是將stagestage一個RDD對應(yīng)的就是一個task。的個數(shù)產(chǎn)生對應(yīng)多個的task。taskcontainerexecutor來執(zhí)行的。task調(diào)度器會實時的對計算的進度進行，當(dāng)一個計算產(chǎn)生延遲并且長時據(jù)資源叫做DataSet和DataFrame。具體的解釋下文中將會詳細(xì)闡述。DataSet并行轉(zhuǎn)換其中的對象。DatasetDatasetRDD似，性能比較好。DataSetCatalyst二進制形式，不需要反序列化就可以執(zhí)行sort、filter、shuffle等操作。Dataset與RDD相似,然而,并不是使用Java序列化或者Kryo編碼器來序列化用于處理或者通過網(wǎng)絡(luò)進行傳輸?shù)膶ο蟆ｋm然編和標(biāo)準(zhǔn)的序列Sparkfiltering,sortinghashing使用中是使用哪種方式，則需要視情況而定。例如如果是需要最終到磁盤本質(zhì)上來說，RDDDataSet是對數(shù)據(jù)的操作和計算方法。進制表示來進行，這樣做的好處就是節(jié)省內(nèi)存，而SparkCore可以將源數(shù)RDD操作。DatasetSparkSQL集中包含哪些列，每列的名稱和類型各是什么。DataFrameschema。這里主要對比DatasetDataFrame，Dataset和DataFramecaseclass出，DataFrame列信息明確，行信息不明確。SparkSQLSQL指令的下發(fā)執(zhí)行的，所以我們在看RowclassDataFrameDataFrameRDD：優(yōu)點：類型安全，面向?qū)ο?。缺點：RDD的性能開銷大；GCGC。off-heapoff-heapSparkschema,SparkStructuredStreamingRDD數(shù)據(jù)那樣編寫流式計算過程。當(dāng)流數(shù)據(jù)連續(xù)不斷的產(chǎn)生里、騰訊等企業(yè)的是使用后者。兩種流式數(shù)據(jù)使用哪一種的本質(zhì)區(qū)別就在身數(shù)據(jù)量產(chǎn)生較小，所以的是依托于后者，也就是底層用戶產(chǎn)生數(shù)據(jù)，互StructuredStreaming的是將流式的數(shù)據(jù)看成一張數(shù)據(jù)不斷增加的數(shù)在這種流，已經(jīng)計算完成的數(shù)據(jù)被不斷地丟棄，新的數(shù)據(jù)持續(xù)的被加入到數(shù)據(jù)集的末尾。對于這個數(shù)據(jù)集來說，是一個無頭的數(shù)據(jù)集。但是這SparkstructuredstreamingStructuredStreamingResultTable。每一個觸發(fā)間隔，當(dāng)新的數(shù)ResultTable。無論何時結(jié)果集發(fā)生了更新，都能將變化的結(jié)果寫入一個外部的系統(tǒng)。下3種：CompleteMode：整個更新的結(jié)果集都會寫入外部。整張表的寫入操AppendMode：ResultTable據(jù)行會被寫入外部。這種方式只適用于結(jié)果集中已經(jīng)存在的內(nèi)容不UpdateMode：ResultTable據(jù)才會被寫入外部系統(tǒng)。注意，和CompleteMode方式的不同之處是不更新的結(jié)果集不會寫入外部。以通過RDD的血統(tǒng)機制重新恢復(fù)丟失的RDD。量上比Storm要優(yōu)秀。1、建議在那種需要純實時，1融系統(tǒng)，要求純實時進行金融和分析。處理完全精準(zhǔn)，一條也不能多，一條也不能少，也可以考慮使用Storm。4SQL對于SparkStreaming來說：SparkStreaming。中無縫進行延遲批處理、交互式查詢等操作。這個特點大大增強了SparkStreaming的優(yōu)勢和功能。Spark起來，作為一個RDD再處理低高一、HBaseHBase是一個高可靠性、高性能、面向列、可伸縮的分布式系統(tǒng)。適合HDF（Hadoop為其文件系統(tǒng)，提供實時讀寫的分布式數(shù)據(jù)庫系統(tǒng)；利用ZooKeeper作為大數(shù)據(jù)系統(tǒng)中，我們需要保證整體數(shù)據(jù)的安全性和可靠性，所以Hbase也提供HbaseHDFSHDFS了其數(shù)據(jù)的可靠性，并且主備集群之間的容災(zāi)能力可以增強HBase數(shù)據(jù)的高可用性，主集群提供數(shù)據(jù)服務(wù)，備用集群提供數(shù)據(jù)備份，當(dāng)主集群出現(xiàn)故障時，備集群可以提供數(shù)據(jù)服務(wù)。這里Hbase通過主備的形式來進行數(shù)據(jù)的安全實現(xiàn)應(yīng)用級別的容災(zāi)保護，也可以通過HBase自己的進程來實現(xiàn)相關(guān)的容災(zāi)性能。HBase集群容災(zāi)作為提高HBase集群系統(tǒng)高可用性的一個關(guān)鍵特性，為容災(zāi)，可以把本HBase集群中的數(shù)據(jù)備份到另一個集群。如上所說的是我們針對于應(yīng)用和數(shù)據(jù)的保護，那么進程的保護和HDFS很類似，組價內(nèi)的進程底層次組件依賴于次組件來進行容災(zāi)保護，比如Region失效之后，需要HMaster來進行相關(guān)的遷移等操作，那么次的組件依賴于Zookeeper來用場景，所以如何實現(xiàn)高效率的操作就是Hbase所需要做的很重要的一個工作。那么Hbase首先通過了分布式的集群保證了整體性能能夠滿足需求，其次還根據(jù)了key-value的形式保障了整體的高效性，另外Hbase還支持HBase是一個Key-Value類型的分布 RowKey的字典順序排序的，因此，如果按照某個指定的RowKey或者指定某一個RowKey范圍去掃描數(shù)據(jù)時，HBase可以快速定位到需要在實際應(yīng)用中，很多場景是查詢某一個列值為XXX的數(shù)據(jù)。HBase提供了Filter特性去支持這樣的查詢，它的原理是：按照RowKey的順序，去遍歷所查詢請求非常頻繁并且對查詢性能要求較高，使用Filter這個需求。我們傳統(tǒng)的時候，進行數(shù)據(jù)索引都是通過key值來進行的，那么我們可以根據(jù)就可以直接根據(jù)二級索引表來查找匹配的數(shù)據(jù)，而不是根據(jù)Rowkey的值遍歷數(shù)理。那么在Hbase中，我們采用了面向于列的，那么這樣的話，底層添加信息都是按照行的思維來進行的，添加一行信息。面向于列的存于分析結(jié)果的影響，比如，對于電子產(chǎn)品的一個相關(guān)關(guān)聯(lián)性，這個時候我們的關(guān)注點就是屬性和是否會的結(jié)果，而對于其他的屬性就不會 HBase海量數(shù)據(jù)（TB、海量數(shù)據(jù)的適應(yīng)性主要取決于兩個角度，首先第一個就是Hbase借力于HDFS組件，可以借助到HDFS的無限拓展能力。雖然HDFS可以無限拓展，但是Hbase本身能否承載這么多數(shù)據(jù)的表格加載也是一個需要考量的問題，所以的基于key-value形式的索引，并且自身還做了對應(yīng)特性的增強，添加了高吞吐量主要體現(xiàn)在數(shù)據(jù)的流式導(dǎo)入和導(dǎo)出等機制，HDFS雖然給Hbase提供了海量數(shù)據(jù)的基礎(chǔ)，但是Hbase（4）實現(xiàn)方式為key-value和二級索引機制ACID以分成兩個步驟:1劃卡,2出錢.不可能劃了卡,而錢卻沒出來.這兩步必一致性(Consistency)：指事務(wù)的運行并不改變數(shù)據(jù)庫中數(shù)據(jù)的一致性.例如,完整性約束了a+b=10,一個事務(wù)改變了a,那么b也應(yīng)該隨之改持久性(Durability：事務(wù)的持久性是指事務(wù)執(zhí)行成功以后,該對ID、Name、Phone、AddressHTML化數(shù)據(jù)的類似。按行數(shù)據(jù)按行在底層文件系統(tǒng)中。通常，每一行會被分配固定的空間。優(yōu)點：有利于增加/修改整行記錄等操作；有利于整行數(shù)據(jù)的操作。缺點：單列查詢按列類型多次I/O操作。Master：HBaseRegionServer的管理，包括表的增刪改查；分配；RegionServer失效后的Region遷移等。供服務(wù)。故障恢復(fù)后，原主用Master降為備用。HbaseHmasterHMaster作為最的管理進程，除了負(fù)責(zé)regionServer的管理以外，還對底將對應(yīng)的讀寫權(quán)限交給其他的RegionServer，這種情況只限進程出現(xiàn)故障的情么同樣Region也是會故障的。時就沒有設(shè)計管理的權(quán)限，所以對于RegionServer來說，雖然稱之為于每次用戶提交了關(guān)于數(shù)據(jù)庫的讀寫請求之后，RegionServer體進程的運行安全，這方面上Zookeeper主要做兩件事，第一件事就是在Hbase外一個進程進入到熱備狀態(tài)。第二件事就是做HBASE的MetaRegion進程的同步工作。由于整體Hbase的時候都是 元數(shù)據(jù)被整體，而不是切分。所以我們選擇將元數(shù)據(jù)存放在Zookeeper這個問題就涉及到了一個整個Hadoop設(shè)計時的問題，就是如何保證進程的安全性？面的文檔中，我們也已經(jīng)解釋過，對于Hadoop來說，它本身是認(rèn)為硬件不可靠，所以Hadoop保證自身安全性和穩(wěn)定性是不會使用到任何的要使用的方法就是分層保護，一個組件內(nèi)，底層的進程由進程來保護，進行，主備進程本身其實可以有保護數(shù)據(jù)的條件，但是實際上由于備進程是程是存在副本機制的。所以我們會把數(shù)據(jù)寫入到Zookeeper中而不是HMaster將一個數(shù)據(jù)表按Key值范圍橫向劃分為一個個的子表，實現(xiàn)分布式。這個子表，在HBase中被稱作“Region”。Region都關(guān)聯(lián)一個KeyStartKey和EndKey述的區(qū)間。事實上，每一個Region僅僅記錄StartKey就可以了，因為它的EndKey就是下一個Region的StartKey。數(shù)據(jù)庫中實際記錄的就是一個個的表格，在實際進行的時候，因為表的規(guī)模比較大，那么在進行的時候，如果整表進行那么對于數(shù)據(jù)的快速查找就會產(chǎn)生對應(yīng)的問題。但是如果要是一條一條對數(shù)據(jù)進行，相應(yīng)的開銷又會很大，所以我們選擇將一個完整的表劃分為多個分區(qū)進行，按照幾行幾行的形式，那么每一個分區(qū)我們就稱之為是一個Region，Region進行分區(qū)我們可以保證對數(shù)據(jù)一個較好的。RegionHBaseRegionRegionRegionMetaRegion個UserRegion的路由信息。讀寫Region數(shù)據(jù)的路由，包括如下幾步：MetaRegion再由MetaUserRegionRegion們會將對數(shù)據(jù)的操作引擎和元數(shù)據(jù)放在一起，但是在Hbase中，我們沒有這么，Region一個用戶如果想要對Region進行讀寫，那么首先需要做的就是向Zookeeper性信息，由于ZookeeperMetaRegion，所以元數(shù)據(jù)在整合起來之后，如何根據(jù)元數(shù)據(jù)的信息查找到數(shù)據(jù)的位置就需要詳細(xì)的區(qū)分，這時候MetaRegion中記錄的地址信息就被稱之為是路由信息，通過MetaRegion中的路由信息進號，節(jié)點號，具體的邏輯位置三個大的部分。RegionServer是HBase的數(shù)據(jù)服務(wù)進程。負(fù)責(zé)處理用戶數(shù)據(jù)的讀寫請求。RegionRegionServerRegionServer上的Region進行交互。RegionRegionServer作是不交由RegionServer來進行的，這個思想就很類似于MapReduce中的負(fù)責(zé)了執(zhí)行和任務(wù)的操作，其他的都不負(fù)責(zé)。RegionServer一般都是和具單進程。所以一旦RegionServer出現(xiàn)問題就會導(dǎo)致整體數(shù)據(jù)元數(shù)據(jù)丟失。元數(shù)據(jù)的整體安全，而且在實際上RegionServer出現(xiàn)故障之后，我們就可HMasterRegionServer新RegionServer的RegionServerFailover就像之前所說的，底層進程的安全性是交由上層進程實現(xiàn)的，所以在這里也算不上保證 RegionServer的安全，HMaster主要是創(chuàng)建和注冊RegionServer的信息，保證RegionServer的 ，并且需要RegionServerHMasterRegionServer出現(xiàn)了故障和問題，這個時候就需要進行故障的遷移，由于如上所說的，RegionServer只涉及對Region的操作，對于實際的數(shù)據(jù)等操作都不運行，所以在RegionServer進程出現(xiàn)故障之后HMaster在做Failover故障切換時無需對數(shù)據(jù)進行遷移的操作，只需要將Zookeeper中的元數(shù)據(jù)路由信息做一個更改即HMasterRegionRegionRegionServerFailoverRegionHMaster進程有主備角色。集群可以配置兩個HMasterHMasterHMaster角色。主HMaster只能有一個，備HMaster進程在集群運行期間處于休眠狀態(tài)，不任何集群事務(wù)。主備HMaster的裁決交由Zookeeper決定。HMaster除了我們上面所說的對RegionServer的管理之外，對于Region的數(shù)據(jù)操作和也是由HMaster來做的，所以整體來講，Region的元數(shù)據(jù)是由Zookeeper和管理，Region的數(shù)據(jù)和操作是由HMaster來管理，作為RegionServer，只負(fù)責(zé)了讀寫等動作的執(zhí)行。就像之前所說的，HMasterRegionServer在故障情況下的Region遷移操作，那么HMaster首先就需要擁有對于Region的管理權(quán)，這里HMaster做的工作主要就是對于Region的創(chuàng)建、分配。包括節(jié)點在Region的時候，為了保證不會出現(xiàn)某些節(jié)點的壓力過大的問題，HMaster衡，這個時候就需要對Region做對應(yīng)的工作分配，將RegionServer的ColumnFamily是Region的一個物理單元。同一個Region下面的多同一個ColumnFamily配置信息相同。傳統(tǒng)的行相比，列更適合用于數(shù)據(jù)分析，而且在大數(shù)據(jù)的環(huán)境下，我們統(tǒng)的行形式來進行相關(guān)的結(jié)構(gòu)設(shè)計就會出現(xiàn)無法拓展的情況，因為行的一RegionColumnFamilyRegion中會包含多個ColumnFamily，同樣，多個Region也會擁有相同的ColumeFamily。通過字段的形式一起以數(shù)據(jù)的類型到實際的空間中，key-value分為了的具體字段（行鍵值長度，行鍵值，列族長度，列族值，時間戳，keyvaluekey們事先數(shù)據(jù)查詢的三個重要字段，我們又稱之為三維有序。hbase所謂的三，columnrowkey，rowkey1:aaa222,rowkey2:bbb111rowkey1rowkey23231-，endKey為:3231,那么你查到的就是用戶為3231在要按排序，那我們就可以把這設(shè)置為我們的columnkey，即設(shè)計為RegionMaster是為了Region作的。并且服務(wù)是在DataNodeHBase這個表會按照鍵值的范圍橫向劃分成一個個的子表，就成為Region。根據(jù)鍵值用戶region兩種HMaster主要做的工作就是創(chuàng)建和RegionServer，并且給這些Regionregioncolumnfamilykeyregion，keyvalue，我們在底層時，數(shù)據(jù)都是按照keyvalue進行的組織和，用戶可以通過key值進行快捷的和查找。Region，CloumnFamily和key-value的關(guān)系如下所示：個ColumnFamily。rmSeRegionServerMemStore時，RegionServerMemStore中的數(shù)據(jù)“flush”HDFS中。置的最大值時，RegionServer會將多個StoreFile合并為一個大的HfieFi系統(tǒng)中StoreFile的具體實現(xiàn)。丟失，RegionServer的多個Region共個相同的Hlog?？蛻舳税l(fā)起請求通過ZooKeeper尋找到meta表所在RegionServermeta表中記載著各個UserRegion信息（rowkeyRegionServer，通過meta表尋找所要寫入的Region所在RegionServer請求按RegionServerRegionRegionRegionServer，由該RegionServer具體處理數(shù)據(jù)寫入。Region首先，RegionServerRegion獲取到了讀寫鎖之后，RegionServer行鎖獲取成功之后，RegionServer行鎖釋放后，數(shù)據(jù)操作將會寫入日志中（writeaheadlog預(yù)寫日志全部修改完成之后，RegionServerRegion的讀寫鎖?？诘倪M程，受理客戶的請求，將讀寫請求轉(zhuǎn)發(fā)給zookeeper，然后進行我們需要向zookeeper申請寫空間，創(chuàng)建一個元數(shù)據(jù)，如果是讀改寫，那么就ZookeeperRegionServer請求，通過RegionServer進行具體相關(guān)的操作。RegionServer會再轉(zhuǎn)發(fā)請求之前首先獲取對應(yīng)位置的權(quán)限，權(quán)限主要分為讀寫鎖，在進行寫操作的時候，由于Hbase屬于數(shù)據(jù)庫，所以要獲取到對應(yīng)的讀鎖ACID特性不被破壞。在獲取到讀寫鎖之后，針對當(dāng)前寫操作需要做的更改，進Region鎖也就是對應(yīng)的讀寫鎖。先寫內(nèi)存的原因：HBaseMVCC（多版本并發(fā)控制）機制，來保障寫回滾。寫內(nèi)存可以避免多Region情形下帶來的過多的分散IO操作。MemStoreHLogFlush刷新操作會觸發(fā)數(shù)據(jù)從內(nèi)存中寫入到對應(yīng)的HFile一個Region的Flush操作：該RegionMemStoreFlushSizeSize閾值過多的話，也可能會引起一小段時間的堵塞。RegionServer的總內(nèi)存大小超出了預(yù)設(shè)的閾值大小。這種場景下，在總高、低水位設(shè)置不合理，會影響Cache的讀寫性能。臟數(shù)據(jù)（DirtyRead）是指在數(shù)據(jù)，并且對數(shù)據(jù)進行了修改，而這種修改還沒有提交到數(shù)據(jù)庫中，這時，另外一個事務(wù)也這個數(shù)據(jù)，然后使用了這個數(shù)據(jù)。因為這個數(shù)據(jù)是還沒有提可能是不正確的。在中，對于臟數(shù)據(jù)的理解其實說成是駐留在Cache中的數(shù)TCQNCQ，CacheCacheIOCacheIOCacheIO況進行調(diào)整，重點關(guān)注調(diào)整后的性能變化狀況和Cache狀況，針對隨機寫業(yè)務(wù)建議設(shè)置在80左右。刷盤線程每隔1s啟動一次Compaction壓縮操作：的小文件數(shù)目，從而提升的性能。Minor:Compaction。有最少和最大文件數(shù)目限制。通常會選擇一些連Compaction過，會清理被刪除的數(shù)據(jù)。了預(yù)設(shè)的閾值，則需要將該Region自動成為兩個子Region。數(shù)據(jù)文件并不會真正的并重寫到兩個子Region中，而是僅僅通過在新Region中創(chuàng)建文件的方式，來實現(xiàn)快速的。因此，Region暫停服務(wù)的RegionRegion沒有數(shù)據(jù)，的只是原有數(shù)據(jù)的映射，將舊的Region數(shù)據(jù)添加了一個映射到自身，數(shù)據(jù)本身還是在原先的Region中。當(dāng)新的寫請求下達的時候，數(shù)據(jù)就會寫到新的Region中。RegionServer過rowkey查找meta表，獲取所要的Region所在RegionServer數(shù)據(jù)返回到客戶端據(jù)Hfiles，那么在openscanner的時候就需要分別這兩塊數(shù)據(jù)，打開對應(yīng)不同的scanner做查詢操作。MemStore對應(yīng)的Scanner為MemStoreScannerHFile對應(yīng)的ScannerStoreFileScanner據(jù)XXXX不存在”的判斷結(jié)果是可信的。對比，如果為1表示存在，如果不為1表示不存在。為value。其實就是查詢了2次。在實際應(yīng)用中，很多場景是查詢某一個列值為XXX的數(shù)據(jù)。HBase提供了樣的查詢請求非常頻繁并且對查詢性能要求較高，使用Filter這個需由于HBase接口以及內(nèi)部機制的原因，一些較大的文件也不適合直接保存到HBase中。上層應(yīng)用提供文件的、、刪除等功能。下，同時又需要存放一些比較大的文件（10MB以上。compactionsplit，占用很多CPU，磁盤IO頻率很高，性能嚴(yán)重下降。用地址以及數(shù)據(jù)偏移量。數(shù)據(jù)時，mobstore會用自己的scanner，先從文件系統(tǒng)中真正的數(shù)據(jù)。數(shù)據(jù)倉庫通常排除對于決策無用的數(shù)據(jù)，提供特定的簡明視圖。他只需要兩種數(shù)據(jù)操作：數(shù)據(jù)的初始化裝入和數(shù)據(jù)。Hadoop理論，他們都認(rèn)為硬件是不可靠的HiveHadoopSQL理大規(guī)模數(shù)據(jù)集合。Hive非常簡單，功能非常強大，所以非常流行。通常來說，Hive只支持?jǐn)?shù)據(jù)查詢和加載，但后面的版本也支持了插入，更新和刪除以及流式api。Ｈive具有目前Hadoop上最豐富最全的SQL語法，也擁有最慢最穩(wěn)定的執(zhí)行。是目前Hadoop上幾乎標(biāo)準(zhǔn)的ETL和數(shù)據(jù)倉庫工具。Hive這個特點與其它AdHoc查詢工具如Impala，SparkSQL或者Presto有ETLImpalaHiveHiveHadoopHiveSQLMapReduce，TezGroupByJOINMapReduceHiveMapReduce原理。一臺機器分到了鍵nk1和nk3，第二臺機器分到了鍵nk2Reducers（count，輸出就是nk1出現(xiàn)了2次，nk3出現(xiàn)了1次，nk2出現(xiàn)了3次。從全局上來看，MapReduce就是一個分布式的GroupBy的過程。從上圖可以看到，GlobalShuffle左邊，兩臺機器執(zhí)行的是Map。GlobalShuffle右邊，兩臺機器執(zhí)行的是Reduce。所以Hive，實際上就是一個編譯器，一個翻譯機。把SQL翻譯成MapReduce之類的作業(yè)。靈活方便的整體的影響。關(guān)于這些問題，我們已經(jīng)在Hbase給業(yè)務(wù)人員用的，是給分析師使用的。作為分析師，我們更關(guān)注的是數(shù)據(jù)的完整度和全面性，另外關(guān)注的就是這個數(shù)據(jù)是否是干凈的，所謂干凈就是指這個數(shù)據(jù)是不是存在一些干擾或者是問題的。就好比我們?nèi)ベI菜，回家之后也肯定據(jù)倉庫中的數(shù)據(jù)是直接供給做數(shù)據(jù)分析使用的，所以數(shù)據(jù)倉庫需要將數(shù)據(jù)收集集成到本地，并且對數(shù)據(jù)進行預(yù)處理操作，排除掉數(shù)據(jù)中的一些分析無關(guān)的數(shù)據(jù)以及一些會分析準(zhǔn)確度產(chǎn)生影響的數(shù)據(jù)。那么為了實現(xiàn)數(shù)據(jù)的集成，我們就需要從各個位置收集并且數(shù)據(jù)，并且對原始數(shù)據(jù)進行預(yù)處理。關(guān)于數(shù)據(jù)的預(yù)處理操作的步驟詳見第一章大數(shù)據(jù)基本概念導(dǎo)入壓力，另外一個就是外部程序?qū)崿F(xiàn)，比如GDS等。支持相關(guān)的元數(shù)據(jù)，對各種類型的數(shù)據(jù)都能夠支持。直接HDFS文件以及HIVEHadoop所以Hive支持直接HDFS和Hbase中的文件，降低整體數(shù)據(jù)集成延遲。MapReduce，Tez，Spark們對于不同類型的數(shù)據(jù)也有對應(yīng)類型的計算引擎去做相關(guān)的分析操作，所以Hive對于計算引擎的支持度也應(yīng)該足夠大，才能滿足業(yè)務(wù)的需求。通過類SQL語法，易于由于Hive默認(rèn)使用MapReduce當(dāng)前版本還不能支持過程，只能通過UDF來實現(xiàn)一些邏輯處HiveHiveServer、MetaStore、WebHcatHiveServerHQLYarn務(wù)、SparkHDFSMetaStoreWebHcat對外提供基于https協(xié)議的元數(shù)據(jù)、DDL查詢等服務(wù)Hive的編譯、解析、優(yōu)化轉(zhuǎn)化為MapReduce任務(wù)提交給Hadoop1中的JobTracker或者是Hadoop2中的SourceManager來進行實際的執(zhí)行相應(yīng)MetaStore組件：著hive的元數(shù)據(jù)信息，將自己的元數(shù)據(jù)到了關(guān)系型數(shù)據(jù)庫當(dāng)中，支持的數(shù)據(jù)庫主要有：Mysql、Derby、支持把metastore獨立出來放在的集群上面，使得hive更加健壯。元數(shù)據(jù)主要包括了表在的。用戶接口：CLI（CommandLineInterface)(常用的接口：命令行模式:Hive的客戶端用戶