Hadoop 學習筆記 生態

概論

Hadoop是Apache下的開源項目

 

 

數據存儲：

HDFS 分佈式文件系統，負責存儲數據，數據分散存儲

NameNode

管理節點，存儲元數據（文件對應的數據塊位置、文件大小、文件權限等信息）

同時負責讀寫調度和存儲分配

DataNode

數據存儲節點，每一個數據塊會根據設置的副本數進行分級複製，保證同一個文件的每一個數據塊副本都在不一樣機器上

 

 

 

數據分析：MapReduce計算引擎

離線計算（非實時計算）

 

 

MapRedue（一代）

分佈式計算（多臺運算加速）

Map階段

多臺機器同時讀取這個文件內容的一個部分

Reducer階段

將Map階段輸出結果整合輸出

 

Tez、Spark（二代）

 

 

Yarn（分佈式資源管理器）

解決Hadoop擴展性

支持CPU和內存兩種資源管理

資源管理由ResourceManager（RM）、ApplicationMaster（AM）和NodeManager（NM）完成

RM負責對各個NM上的資源進行統一管理和調度

NM負責對資源供給和隔離

當用戶提交一個應用程序時，會建立一個用以跟蹤和管理這個程序的AM，它負責向RM申請資源，並要求NM啓動指定資源的任務。這就是YARN的基本運行機制。

 

Yarn 做爲一個通用的分佈式資源管理器，它能夠管理多種計算模型，如 Spark、Storm、MapReduce 、Flink 等均可以放到 Yarn 下進行統一管理。

 

Spark（內存計算）

 

Spark 提供了內存中的分佈式計算能力，相比傳統的MapReduce 大數據分析效率更高、運行速度更快。總結一句話：之內存換效率。

 

傳統的MapReduce 計算過程的每個操做步驟發生在內存中，但產生的中間結果會儲存在磁盤裏，下一步操做時又會將這個中間結果調用到內存中，如此循環，直到分析任務最終完成。這就會產生讀取成本，形成效率低下。

 

而Spark 在執行分析任務中，每一個步驟也是發生在內存之中，但中間結果會直接進入下一個步驟，直到全部步驟完成以後纔會將最終結果寫入磁盤。也就是說Spark 任務在執行過程當中，中間結果不會「落地」，這就節省了大量的時間。

少許數據看不出來效率差異

 

HBase（分佈式列存儲數據庫）

基於面向列存儲（又叫非關係型數據庫、NoSQL）基於HDFS

實現了數據便是索引。所以，它的最大優勢是查詢速度快，這對數據完整性要求不高的大數據處理領域，好比互聯網

 

Hbase繼承了列存儲的特性，它很是適合需對數據進行隨機讀、寫操做、好比每秒對PB級數據進行幾千次讀、寫訪問是很是簡單的操做。其次，Hbase構建在HDFS之上，其內部管理的文件所有存儲在HDFS中。這使它具備高度容錯性和可擴展性，並支持Hadoop mapreduce程序設計模型。

 

大數據適用於列存儲

 

 Hive（數據倉庫）

Hive 定義了一種相似SQL 的查詢語言（HQL），它能夠將SQL 轉化爲MapReduce 任務在Hadoop 上執行。這樣，小李就能夠用更簡單、更直觀的語言去寫程序了。

 

Oozie（工做流調度器）

針對多個工做查詢腳本任務調度

 

Oozie 是一個基於工做流引擎的調度器，它其實就是一個運行在Java Servlet 容器（如Tomcat）中的Javas Web 應用，你能夠在它上面運行Hadoop 的Map Reduce 和Pig 等任務。

 

對於Oozie 來講，工做流就是一系列的操做（如Hadoop 的MR，Pig 的任務、Shell 任務等），經過Oozie 能夠實現多個任務的依賴性。也就是說，一個操做的輸入依賴於前一個任務的輸出，只有前一個操做徹底完成後，才能開始第二個。

 

Oozie 工做流經過hPDL 定義（hPDL 是一種XML 的流程定義語言），工做流操做經過遠程系統啓動任務。當任務完成後，遠程系統會進行回調來通知任務已經結束，而後再開始下一個操做。

 

Sqoop 與Pig

把原來存儲在MySQL 中的數據導入Hadoop 的HDFS 上，是否能實現呢？這固然能夠，經過Sqoop（SQL-to-Hadoop）就能實現，它主要用於傳統數據庫和Hadoop 之間傳輸數據。數據的導入和導出本質上是MapreDuce 程序，充分利用了MR 的並行化和容錯性。

 

 

經過Hive 能夠把腳本和SQL 語言翻譯成MapReduce 程序，扔給計算引擎去計算。Pig 與Hive 相似，它定義了一種數據流語言，即Pig Latin，它是MapReduce 編程的複雜性的抽象，Pig Latin 能夠完成排序、過濾、求和、關聯等操做，支持自定義函數。Pig 自動把Pig Latin 映射爲MapReduce 做業，上傳到集羣運行，減小用戶編寫Java 程序的苦惱。

 

Flume（日誌收集工具）

 

• Flume 數據流提供對日誌數據進行簡單處理的能力，如過濾、格式轉換等。
• Flume 還具備可以將日誌寫往各類數據目標（文件、HDFS、網絡）的能力。

 

在Hadoop 平臺，咱們主要使用的是經過Flume 將數據從源服務器寫入Hadoop 的HDFS 上。

 

 Kafka（分佈式消息隊列）

相似生產者、消費者問題

能夠實時的處理大量數據以知足各類需求場景：好比基於 Hadoop 平臺的數據分析、低時延的實時系統、Storm/Spark 流式處理引擎等。

 

ZooKeeper（分佈式協做服務）

雙機熱備架構來講，雙機熱備主要用來解決單點故障問題，傳統的方式是採用一個備用節點，這個備用節點按期向主節點發送ping 包，主節點收到ping 包之後向備用節點發送回覆信息，當備用節點收到回覆的時候就會認爲當前主節點運行正常，讓它繼續提供服務。而當主節點故障時，備用節點就沒法收到回覆信息了，此時，備用節點就認爲主節點宕機，而後接替它成爲新的主節點繼續提供服務。

 

這種傳統解決單點故障的方法，雖然在必定程度上解決了問題，可是有一個隱患，就是網絡問題，可能會存在這樣一種狀況：主節點並無出現故障，只是在回覆響應的時候網絡發生了故障，這樣備用節點就沒法收到回覆，那麼它就會認爲主節點出現了故障；接着，備用節點將接管主節點的服務，併成爲新的主節點，此時，集羣系統中就出現了兩個主節點（雙Master 節點）的狀況，雙Master 節點的出現，會致使集羣系統的服務發生混亂。這樣的話，整個集羣系統將變得不可用，爲了防止出現這種狀況，就須要引入ZooKeeper 來解決這種問題。

 

ZooKeeper 是如何來解決這個問題的呢，這裏以配置兩個節點爲例，假定它們是「節點A」和「節點B」，當兩個節點都啓動後，它們都會向ZooKeeper 中註冊節點信息。咱們假設「節點A」鎖註冊的節點信息是「master00001」，「節點B」註冊的節點信息是「master00002」，註冊完之後會進行選舉，選舉有多種算法，這裏以編號最小做爲選舉算法，那麼編號最小的節點將在選舉中獲勝並得到鎖成爲主節點，也就是「節點A」將會得到鎖成爲主節點，而後「節點B」將被阻塞成爲一個備用節點。這樣，經過這種方式ZooKeeper 就完成了對兩個Master 進程的調度。完成了主、備節點的分配和協做。

 

若是「節點A」發生了故障，這時候它在ZooKeeper 所註冊的節點信息會被自動刪除，而ZooKeeper 會自動感知節點的變化，發現「節點A」故障後，會再次發出選舉，這時候「節點B」將在選舉中獲勝，替代「節點A」成爲新的主節點，這樣就完成了主、被節點的從新選舉。

 

若是「節點A」恢復了，它會再次向ZooKeeper 註冊自身的節點信息，只不過這時候它註冊的節點信息將會變成「master00003」，而不是原來的信息。ZooKeeper 會感知節點的變化再次發動選舉，這時候「節點B」在選舉中會再次獲勝繼續擔任「主節點」，「節點A」會擔任備用節點。

 

通俗的講，ZooKeeper至關於一個和事佬的角色，若是兩人之間發生了一些矛盾或者衝突，沒法自行解決的話，這個時候就須要ZooKeeper 這個和事佬從中進行調解，而和事佬調解的方式是站在第三方客觀的角度，根據一些規則（如道德規則、法律規則），客觀的對衝突雙方作出合理、合規的判決。

 

Ambari（大數據運維工具）

Ambari 是一個大數據基礎運維平臺，它實現了Hadoop 生態圈各類組件的自動化部署、服務管理和監控告警，Ambari 經過puppet 實現自動化安裝和配置，經過Ganglia 收集監控度量指標，用Nagios 實現故障報警。目前Ambari 已支持大多數Hadoop 組件，包括HDFS、MapReduce、Oozie、Hive、Pig、Hbase、ZooKeeper、Sqoop、Kafka、Spark、Druid、Storm 等幾十個經常使用的Hadoop 組件。

 

做爲大數據運維人員，經過Ambari 能夠實現統一部署、統一管理、統一監控，可極大提升運維工做效率。