--Hadoop相關零散知識點

時間 2019-11-13

標籤 hadoop 相關零散知識欄目 Hadoop 简体版

原文原文鏈接

Hadoop學習筆記：
數據庫

1、Hadoop三種安裝模式

本地模式：本地模式是Hadoop默認的模式，只有Hadoop被配置成以非分佈式模式運行的一個獨立Java進程。默認模式下全部3個XML文件均爲空，此時，Hadoop會徹底運行在本地。它只負責存儲，沒有計算功能。服務器

僞分佈式模式：僞分佈式模式是在一臺機器上模擬分佈式部署，方便學習和調試。使用多個守護線程模擬分佈的僞分佈運行模式，此時每一個Hadoop守護進程都做爲一個獨立的Java進程運行。網絡

集羣模式：真正多臺機器來搭建分佈式集羣。數據結構

2、Hadoop集羣--圖解

Hadoop集羣是在同一地點用網絡互連的一組通用機器。數據存儲和處理都發生在這個機器「雲「中。不一樣的用戶能夠從獨立的客戶端提交計算「做業「到Hadoop，這些客戶端能夠是遠離Hadoop集羣的我的臺式機。架構

注：雖非絕對必要，但一般在一個Hadoop集羣中的機器都是相對同構的X86 Linux服務器。並且它們幾乎老是位於同一個數據中心，並一般在同一組機架裏。app

3、機架結構圖—圖解

節點: H1、H2、H3、H4 … …分佈式

節點H1、H4、H7的機架名對應爲：/D1/R1、/D1/R2、/D2/R3 … …函數

機架：R1、R2、R3 … …oop

數據中心：D1、D2性能

4、Hadoop集羣架構——兩級網絡拓撲 P261

5、Hadoop集羣節點的拓撲結構圖解

這些拓撲結構的特色是：

在主節點上運行NameNode和JobTracker的守護進程，並使用獨立的節點運行SecondaryNameNode以防主節點失效。在小型集羣中，SecondaryNameNode（SNN）也能夠駐留在某一個從節點上，而在大型集羣中，連NameNode和JobTracker都會分別駐留在兩臺機器上。每一個從節點均駐留一個DataNode和TaskTracker，從而在存儲數據的同一個節點上執行任務。

6、MapReduce數據傳輸

7、jobtracker及一系列tasktracker。

首先定義一些術語：

MapReduce做業（job）是客戶端須要執行的一個工做單元。它包括輸入數據、MapReduce程序和配置信息。Hadoop將做業分紅若干個小任務（task）來執行，其中包括兩類任務：map任務和reduce任務。

有兩類節點控制着做業執行過程：

Jobtracker經過調度tasktracker上運行的任務，來協調全部運行在系統上的做業。

Tasktracker在運行任務的同時將運行進度報告發送給jobtracker，jobtracker由此記錄每項做業任務的總體進度狀況，若是其中一個任務失敗，jobtracker能夠在另一個tasktracker節點上從新調度該任務。

8、輸入分片

Hadoop將MapReduce的輸入數據劃分紅等長的小數據塊，成爲輸入分片（input spit）或簡稱分片，Hadoop爲每一個分片構建一個map任務，並由該任務來運行用戶自定義的map函數從而處理分片中的每條記錄。

擁有許多分片，意味着處理每一個分片所須要的時間少於處理整個輸入數據所花的時間。所以，若是咱們並行處理每一個分片，且每一個分片數據比較小，那麼整個處理過程將得到更好的負載平衡。由於一臺較快的計算機可以處理的數據分片比一臺較慢的計算機更多，且成必定的比例。即便使用相同的機器，處理失敗的做業或其餘同時運行的做業也可以實現負載平衡，而且若是分片被切分得更細，負載平衡的質量會更好。

另外一方面，若是分片切分得過小，那麼管理分片的總時間和構建map任務的總時間將決定着做業的整個執行時間。對於大多數做業來講，一個合理的分片大小趨向於HDFS的一個塊的大小，默認是64MB，不過能夠針對集羣調整這個默認值，在新建全部文件或新建每一個文件時具體指定便可。

9、爲何最佳分片的大小應該與塊大小相同

由於它是確保能夠存儲在單個節點上的最大輸入塊的大小。若是分片跨越兩個數據塊，那麼對於任何一個HDFS節點，基本上都不可能同時存儲這兩個數據塊，所以分片中的部分數據須要經過網絡傳輸到map任務節點。與使用本地數據運行整個map任務相比，這種方法顯然效率更低。

10、數據本地優化

Hadoop在存儲有輸入數據（HDFS中的數據）的節點上運行map任務，能夠得到最佳性能。這就是所謂的數據本地化優化（data locality optimization）。

11、剖析MapReduce程序—圖解

MapReduce程序經過操做鍵/值對來處理數據，通常形式爲

map: (k1, v1) -> list(k2, v2)

reduce:(k2, list(v2)) -> lsit(k3, v3)

12 咱們爲何不能使用數據庫來對大量磁盤上的大規模數據進行批量分析呢？咱們爲何須要MapReduce？

這些問題的答案來自磁盤的另外一個發展趨勢：

尋址時間的提升遠遠慢於傳輸速率的提升。尋址是將磁頭移動到特定磁盤位置進行讀寫操做的過程。它是致使磁盤操做延遲的主要緣由，而傳輸速率取決於磁盤的帶寬。

若是數據的訪問模式中包含大量的磁盤尋址，那麼讀取大量數據集所花的時間勢必會更長（相較於流式數據讀取模式），流式讀取主要取決於傳輸速率。另外一方面，若是數據庫系統只更新一小部分記錄，那麼傳統的B樹更有優點（關係型數據庫中使用的一種數據結構，受限於尋址的比例）。但數據庫更新大部分數據時，B樹的效率比MapReduce低得多，由於須要使用「排序/合併」來重建數據庫。

在許多狀況下，能夠將MapReduce視爲關係型數據庫管理系統的補充。兩個系統之間的差別以下圖所示。

MapReduce比較適合以批處理的方式處理須要分析整個數據集的問題。RDBMS適用於「點查詢」和更新，數據集被索引後，數據庫系統可以提供低延遲的數據檢索和快速的少許數據更新。MapReduce適合一次寫入、屢次讀取數據的應用，而關係型數據庫更適合持續更新的數據集。

12、Map任務輸出結果存放在哪兒

Map任務將其輸出寫入本地硬盤，而非HDFS。

由於map的輸出是中間結果：該中間結果由reduce任務處理後才產生最終輸出結果，並且一旦做業完成，map的輸出結果能夠被刪除。所以，若是把它存儲在HDFS中並實現備份，不免有些小題大作。若是該節點上運行的map任務在將map中間結果傳送給reduce任務以前失敗，Hadoop將在另外一個節點上從新運行這個map任務以再次構建map中間結果。

13、Reduce任務不具有數據本地化的優點

在僅有一個reduce任務的狀況下，輸入一般來自於全部mapper的輸出。所以，排過序的map輸出需經過網絡傳輸發送到運行reduce任務的節點。數據在reduce端合併，而後由用戶定義的reduce函數處理。

若是是多個reduce任務的狀況，mapper的輸出也要通過一系列的分區操做，將一部分mapper合併，而後分別輸入到不一樣的reducer中。

14、reducer經過什麼方式獲得輸出文件的分區

Reducer經過HTTP方式獲得輸出文件的分區。由於Map的輸出結果是存放在本地的。

15、reduce的輸出一般存放在哪兒

Reduce的輸出一般存儲在HDFS中以實現可靠存儲。

16、reduce輸出的HDFS塊，複本存儲在哪兒

對於每一個reduce輸出的HDFS塊，第一個複本存儲在本地節點上，其餘複本存儲在其餘機架節點中。

所以，reduce的輸出寫入HDFS確實須要佔用網絡帶寬，但這與正常的HDFS流水線寫入的消耗同樣。

HDFS流水線寫入：

client把數據Block只傳給一個DataNode，這個DataNode收到Block以後，傳給下一個DataNode，依次類推，...，最後一個DataNode就不須要下傳數據Block了。

17、Map的做用

Map的做用是過濾一些原始數據

18、Reduce的做用

Reduce則是處理這些數據，獲得咱們想要的結果

19、分佈式文件系統

HDFS、NDFS、GFS

20、map任務的數量由誰決定

Map任務的數量由輸入分片的的個數決定。

Hadoop將MapReduce的輸入數據劃分爲等長的小數據塊，稱爲輸入分片(input split)或簡稱分片。

Hadoop爲每一個分片構建一個map任務，並由該任務來運行用戶自定義的map函數從而處理分片中的每條數據。

21、reduce任務的數量由誰決定

Reduce任務的數量不禁輸入數據的大小決定，而是特別指定的。

22、reduce任務最優個數怎麼計算

真實應用中，做業都把它設置成一個較大的數字，不然因爲全部的中間數據都會放到一個reducer任務中，從而致使做業效率較低。

注意：在本地做業運行器上運行時，只支持0個或1個reducer。

Reduce最優個數與集羣中可用的reducer任務槽數相關。總槽數由集羣中節點數與每一個節點的任務槽數相乘獲得。該值由mapred.tasktracker.reduce.task.maximum屬性的值決定。

23、map任務對其輸出進行分區

若有多個reduce任務，則每一個map任務都會對其輸出進行分區（partition），即爲每一個reduce任務建一個分區。每一個分區有許多鍵（及其對應值），但每一個鍵對應的鍵/值對記錄都在同一個分區中。分區由用戶定義的分區函數控制，但一般用默認的分區器（partitioner，有時也稱「分區函數「）經過哈希函數來分區，這種方法和高效。

24、一個reduce任務的完整數據流—圖解

虛線框表示節點，虛線箭頭表示節點內部的數據傳輸，而實線箭頭表示節點之間的數據傳輸。

25、多個reduce任務的MapReduce數據流--圖解

26、無reduce任務的數據流--圖解

27、一個TaskTracker可同時運行多個map和reduce任務

每一個TaskTracker能夠生成多個JVM（JAVA虛擬機）來進行並行地處理許多map或reduce任務。

28、一個tasktracker可以同時運行最多多少個map和reduce任務

一個tasktracker可以同時運行最多多少個map任務：由mapred.tasktracker.map.tasks.maximum屬性控制，默認值是2個任務。相應的，一個tasktracker可以同時運行的最多reduce任務數由mapred.tasktracker.reduce.task.maximum屬性控制，默認也是2。詳見《Hadoop權威指南》第二版P269頁。

在一個tasktracker上可以同時運行的任務數取決於一臺機器有多少個處理器。因爲MapReduce做業一般是I/O-bound，所以將任務數設定爲超出處理器數也有必定道理，可以得到更好的利用率。

至於到底須要運行多少個任務，則依賴於相關做業的CPU使用狀況。

但經驗法則是任務數（包括map和reduce任務）與處理器數的比值最好在1和2之間。

29、TaskTracker職責

1、其中一個職責是持續不斷地與JobTracker通訊。

30、計算的守護進程遵循主/從架構--圖解

JobTracker做爲主節點，監測MapReduce做業的整個執行過程，同時，TaskTracker管理各個任務在每一個從節點上的執行狀況。每一個TaskTracker負責執行由JobTracker分配的單項任務。雖然每一個從節點上僅有一個TaskTracker，但每一個TaskTracker能夠生成多個JVM（JAVA虛擬機）來進行並行地處理許多map或reduce任務。

TakTracker的一個職責是持續不斷地與JobTracker通訊。若是JobTracker在指定時間內沒有收到來自TaskTracker的「心跳「，它會假定TaskTracker已經崩潰，進而從新提交相應的任務到集羣中的其餘任務節點。

31、節點間通訊的惟一時間是在哪一個階段

節點間通訊的惟一時間是在「洗牌「(shuffle)階段。這個通訊約束對可擴展性有很大的幫助。

集羣上的可用帶寬限制了MapReduce做業的數量，所以最重要的一點是儘可能避免map任務和reduce任務之間的數據傳輸。Hadoop容許用戶針對map任務的輸出指定一個合併函數（combiner，就像mapper和reducer同樣），合併函數的輸出做爲reduce函數的輸入。因爲合併函數是一個優化方案，因此Hadoop沒法肯定針對map任務輸出中任一條記錄須要調用多少次合併函數。換言之，無論調用多少次合併函數，reducer的輸出結果都應一致。