大數據組件原理總結-Hadoop、Hbase、Kafka、Zookeeper、Spark

Hadoop原理

分爲HDFS與Yarn兩個部分。HDFS有Namenode和Datanode兩個部分。每一個節點佔用一個電腦。Datanode定時向Namenode發送心跳包，心跳包中包含Datanode的校驗等信息，用來監控Datanode。HDFS將數據分爲塊，默認爲64M每一個塊信息按照配置的參數分別備份在不一樣的Datanode，而數據塊在哪一個節點上，這些信息都存儲到Namenode上面。Yarn是MapReduce2，能夠集成更多的組件，如spark、mpi等。MapReduce包括Jobtraker與Tasktraker兩個部分。其中JobTraker是在主節點上，負責總體的調度。Tasktraker在slave節點上，當提交任務後，將其交給Jobtraker進行調度，調度到該任務以後就會將jar包發送到響應的Tasktraker，以實現分佈式中移動計算資源而非移動數據。由於這些任務都是併發執行的，因此每一個任務須要調用哪一個節點的數據必須很是的明確，一般這一部分是經過Jobtraker進行指揮。

在MapReduce的開始，每一個block做爲一個Map輸入，Map輸入後就進入shuffle階段。Shuffle階段主要分爲Map和Reduce兩個階段。在Map Shuffle階段，Map輸入按用戶的程序進行處理，生成的結果按key排序，而後進入內存，溢出後造成一個spill寫入磁盤，這樣多個spill在這個節點中進行多路歸併排序（勝者樹）造成一個排序文件寫入磁盤，這期間那些Map文件交給那些節點處理由Jobtraker進行調度，最後生成一個大排序的文件，而且刪除spill。以後，再將多個節點上已經排序的文件進行行多路歸併排序（一個大文件N分到n個節點，每一個節點分爲k個spill，一個spill長度s，時間複雜度是N(logn（n個節點多路歸併排序） + logk（每一個節點內k個spill排序） + logs（每一個spill內部進行排序）)，N=nks,因此最後的複雜度仍是NlogN）。

完成Map Shuffle階段後通知Jobtraker進入Reduce Shuffle階段。在這個階段，由於已經排序，很容易將用戶的程序直接做用到相同key的數據上，這些數據做爲Reduce的輸入進行處理，最終將輸出的結果數據寫入到HDFS上，並刪除磁盤數據。Map通常多，Reduce少，因此經過Hash的方法將Map文件映射到Reduce上，進行處理，這個階段叫作Patition。爲了不譬如全部數據相加這種操做使得數據負載移動的數量少的Reduce階段，形成效率低下的結果，咱們能夠在在Map Shuffle階段加一個Combine階段，這個Combine是在每一臺節點上將已經排序好的文件進行一次Reduce並將結果做爲Reduce Shuffle階段的輸入，這樣能夠大大減小數據的輸入量。一般Reduce的個數經過用戶來指定，一般和CPU個數相適應才能使其效率達到最大。

HBase原理

Hbase是列存儲數據庫。其存儲的組織結構就是將相同的列族存儲在一塊兒，所以得名的。Hbase存儲有行鍵，做爲惟一標識，列表示爲 <列族> : <列> 存儲信息，如address：city，address：provice，而後是時間戳。

Hbase物理模型中，有一個總結點HMaster，經過其自帶的zookeeper與客戶端相鏈接。Hbse做爲分佈式每個節點做爲一個RegionServer，維護Region的狀態和管理。Region是數據管理的基本單位。最初只有一個，經過擴充後達到閾值而後分裂，經過Server控制其規模。在RegionServer中，每個store做爲一個列族。當數據插入進來，新數據成爲Memstore，寫入內存，當Memstore達到閾值後，經過Flashcache進程將數據寫入storeFile，也就是當內存數據增多後溢出成一個StoreFile寫入磁盤，這裏和Hadoop的spill相似，這個過程是在HDFS上進行的操做。因此數據的插入並非追加的過程，而是積累成大塊數據後一併寫入。當StoreFile數量過多時，進行合併，將造成一個大的StoreFile而且刪除掉原來的StoreFile。再當StoreFile大小超過必定閾值後，分裂成Region。

HBase有一個ROOT表和META表。META表記錄用戶Region的信息，可是隨着數據增多，META也會增大，進而分裂成多個Region ，那咱們用ROOT表記錄下META的信息，是一個二級表，而zookeeper中記錄ROOT表的location。當咱們需找找到一條信息時，先去zookeeper查找ROOT，從ROOT中查找META找到META位置，在進入META表中尋找該數據所在Region，再讀取該Region的信息。HBase適合大量插入又同時讀的狀況，其瓶頸是硬盤的傳輸速度而再也不是像Oracle同樣瓶頸在硬盤的尋道速度。

Zookeeper原理

Zookeeper是一個資源管理庫，對節點進行協調、通訊、失敗處理、節點損壞的處理等，是一個無中心設計，主節點經過選舉產生。Zookeeper的節點是Znode。每個節點能夠存放1M的數據，client訪問服務器時建立一個Znode，能夠是短暫的Znode，其上能夠放上觀察Watcher對node進行監控。Zookeeper有高可用性，每一個機器複製一份數據，只要有通常以上的機器能夠正常的運行，整個集羣就能夠工做。好比6臺的集羣容忍2臺斷開，超過兩臺達到通常的數量就不能夠，所以集羣一般都是奇數來節約資源。

Zookeeper使用zab協議，是一個無中心協議，經過選舉的方式產生leader，經過每臺機器的信息擴散選舉最閒的資源利用較少的節點做爲主控。同時當配置數據有更改更新時，在每一個節點上有配置watcher並觸發讀取更改，。所以可以保證一致性。每一個節點經過leader廣播的方式，使全部follower同步。

Zookeeper能夠實現分佈式鎖機制。經過watcher監控，對每一個Znode的鎖都有一個獨一的編號，按照序號的大小比較，來分配鎖。當一個暫時Znode完結後刪除本節點，通知leader完結，以後下一個Znode獲取鎖進行操做。

Kafka原理
Kafka是分佈式發佈-訂閱消息系統。它最初由LinkedIn公司開發，以後成爲Apache項目的一部分。Kafka是一種快速、可擴展的、設計內在就是分佈式的，分區的和可複製的提交日誌服務。它被設計爲一個分佈式系統，易於向外擴展；它同時爲發佈和訂閱提供高吞吐量；它支持多訂閱者，當失敗時能自動平衡消費者；它將消息持久化到磁盤，所以可用於批量消費，例如ETL，以及實時應用程序。broker和生產者、消費者各自都是集羣，集羣中的各個實例他們之間是對等的，集羣擴充節點很方便。

Kafka的基本概念包括話題、生產者、消費者、代理或者kafka集羣。話題是特定類型的消息流。消息是字節的有效負載，話題是消息的分類名或種子名。生產者是可以發佈消息到話題的任何對象。已發佈的消息保存在一組服務器中，它們被稱爲代理或Kafka集羣。消費者能夠訂閱一個或多個話題，並從Broker拉數據，從而消費這些已發佈的消息。

Kafka的存儲佈局很是簡單。話題的每一個分區對應一個邏輯日誌。物理上，一個日誌爲相同大小的一組分段文件。每次生產者發佈消息到一個分區，代理就將消息追加到最後一個段文件中。當發佈的消息數量達到設定值或者通過必定的時間後，段文件真正寫入磁盤中。寫入完成後，消息公開給消費者。段文件機制和Hadoop中spill相似。消費者始終從特定分區順序地獲取消息，若是消費者知道特定消息的偏移量，也就說明消費者已經消費了以前的全部消息。消費者向代理髮出異步拉請求，準備字節緩衝區用於消費。每一個異步拉請求都包含要消費的消息偏移量與其它消息系統不一樣，Kafka代理是無狀態的。這意味着消費者必須維護已消費的狀態信息。這些信息由消費者本身維護，代理徹底無論。消費者能夠故意倒回到老的偏移量再次消費數據。這違反了隊列的常見約定，但被證實是許多消費者的基本特徵。

kafka的broker在配置文件中能夠配置最多保存多少小時的數據和分區最大的空間佔用，過時的和超量的數據會被broker自動清除掉。

Kafka會記錄offset到zk，同時又在內存中維護offset，容許快速的checkpoint，若是consumer比partition可能是浪費，由於kafka不容許partition上並行consumer讀取。同時，consumer比partition少，一個consumer會對應多個partition，有可能致使partition中數據的讀取不均勻，也不能保證數據間的順序性，kafka只有在一個partition讀取的時候才能保證時間上是有順序的。增長partition或者consumer或者broker會致使rebalance，因此rebalance後consumer對應的partition會發生變化。

Spark原理

spark 能夠很容易和yarn結合，直接調用HDFS、Hbase上面的數據，和hadoop結合。配置很容易。spark發展迅猛，框架比hadoop更加靈活實用。減小了延時處理，提升性能效率實用靈活性。也能夠與hadoop切實相互結合。

spark核心部分分爲RDD。Spark SQL、Spark Streaming、MLlib、GraphX、Spark R等核心組件解決了不少的大數據問題，其完美的框架日受歡迎。其相應的生態環境包括zepplin等可視化方面，正日益壯大。大型公司爭相實用spark來代替原有hadoop上相應的功能模塊。Spark讀寫過程不像hadoop溢出寫入磁盤，都是基於內存，所以速度很快。另外DAG做業調度系統的寬窄依賴讓Spark速度提升。

RDD是彈性分佈式數據也是spark的核心，徹底彈性的，若是數據丟失一部分還能夠重建。有自動容錯、位置感知調度和可伸縮性，經過數據檢查點和記錄數據更新金象容錯性檢查。經過SparkContext.textFile()加載文件變成RDD，而後經過transformation構建新的RDD，經過action將RDD存儲到外部系統。

RDD使用延遲加載，也就是懶加載，只有當用到的時候才加載數據。若是加載存儲全部的中間過程會浪費空間。所以要延遲加載。一旦spark看到整個變換鏈，他能夠計算僅需的結果數據，若是下面的函數不須要數據那麼數據也不會再加載。轉換RDD是惰性的，只有在動做中才可使用它們。

Spark分爲driver和executor，driver提交做業，executor是application早worknode上的進程，運行task，driver對應爲sparkcontext。Spark的RDD操做有transformation、action。Transformation對RDD進行依賴包裝，RDD所對應的依賴都進行DAG的構建並保存，在worknode掛掉以後除了經過備份恢復還能夠經過元數據對其保存的依賴再計算一次獲得。看成業提交也就是調用runJob時，spark會根據RDD構建DAG圖，提交給DAGScheduler，這個DAGScheduler是在SparkContext建立時一同初始化的，他會對做業進行調度處理。當依賴圖構建好之後，從action開始進行解析，每個操做做爲一個task，每遇到shuffle就切割成爲一個taskSet，並把數據輸出到磁盤，若是不是shuffle數據還在內存中存儲。就這樣再往前推動，直到沒有算子，而後運行從前面開始，若是沒有action的算子在這裏不會執行，直到遇到action爲止纔開始運行，這就造成了spark的懶加載，taskset提交給TaskSheduler生成TaskSetManager而且提交給Executor運行，運行結束後反饋給DAGScheduler完成一個taskSet，以後再提交下一個，當TaskSet運行失敗時就返回DAGScheduler並從新再次建立。一個job裏面可能有多個TaskSet，一個application可能包含多個job。

引用自：http://www.javashuo.com/article/p-hzgwbcll-dz.html 若有侵權，請聯繫我刪除