Hadoop 概述和結構

1. Hadoop 構成

　　Hadoop 是有兩部分構成一個是分布式計算框架MapReduce另一個是分布式存儲框架HDFS.

2.HDSF

　　HDFS 是一個Master-Slave結構,其有一個NameNode和多個DataNode,組成,NameNode主要記錄HDSF上文件的所在的位置和數據塊控制著整個文件系統,並通過NN尋址找到DataNode上的文件,因為NN是一個結果,所以如果HDSF上文件數據量達到一定量之後,會使NN節點崩潰,所以Hadop上存儲的文件推薦是大文件,因為如果存儲的都是很多小文件很可能將NN內存占滿,導致無法向HDFS上寫入數據.Client如果向HDFS讀取文件會首先訪問NN,在NN中找到文件元數據信息(比如:所在節點,每個節點的第幾塊),之後根據元訪問各個DN得到數據.

　　Secondary NameNode

　　是輔助名稱節點,可以理解成對NN的備份,但又不僅僅是做備份工作,SNN會定期和NN之間做通訊,保存元數據快照.當NN掛掉之後可以啟動SNN作為一個臨時NN,但是這個過程是管理員手動完成Hadoop並不會自動切換.NN將fsimage讀取到內存中,當Hadoop操作文件之後fsimage會更新,未防止數據丟失這些更新會記錄到本地一個名位edits的日誌文件中,fsimage並不存儲數據塊的位置,這些數據塊其實是DN啟動時向NN進行匯報之後存儲在內存中.edits用來記錄hadoop在運行過程中HDFS上文件的變化情況,當Hadoop重啟後edits會和fsimage進行合並,可想而知當hadoop啟動時候進行fsimage和edits數據合並這會嚴重拖慢系統運行,所有這個合並操作就是通過SNN來完成.SNN的任務就是周期性的對NN中的fsimage和edits進行合並,具體合並步驟如下:

　　1. SNN通知NN要合並鏡像文件,此時讓NN結果對edits的修改,如果有修改請放到一個新文件中edits.new

　　2. SNN向NN請求fsimage和edits文件

　　3. SNN合並fsimage和edits生成新的fsimage

　　4. NN接受SNN新生成的fsimage後替換當前的fsimage並將之前的新的edits.new 內容替換到edtis中

　　5. 更新fsimage記錄(檢查點)

　　在SNN上重要文件如下:

　　1. fsimage 鏡像文件:記錄了文件系統元數據信息

　　2. edits 修改日誌:記錄對fsimage元數據修改信息

　　3. fstime : 最近一次檢查點信息

　　DataNode

　　數據節點,主要負責對HDFS上文件的讀寫操作,NN\SNN\DN一同構成了HDFS系統. Hadoop結構圖如下:

3. MapReduce

　　MR是一種編程範式,主要由兩個任務構成Map操作和Reduce操作

　　 Map階段:Map階段由一系列的MapTask構成,主要流程如下:

　　 1. InputFormat :將數據數據源解析成Key-Value對形式,具體解析方式可以自己定義,Hadoop預定義了幾種常見方式

　　 2. Mapper:輸入數據處理,對每一對Key-Value進行處理(需要自己編程實現,業務相關)形成新的Key-Value

3. Partitioner:數據分組,將Mapper結果進行分組,確定每一個Key-Value對需要被那個Reduce處理.該步驟可以自定義也可以使用Hadoop內置的Partitioner(Hash 分桶)

　　4. 將每個節點計算完成的數據輸出,如果Map後沒有Reduce階段則直接輸出到HDFS,如果有Reduce階段則輸出到NN本地節點以供Reduce階段讀取

Reduce 階段:Reduce階段由一系列的ReductTask組成,過程如下:

　　1. Shuffle:數據遠程拷貝,將本節點需要處理的數據通過網絡從Map節點拷貝到本地

　　2. Sort: 把所有數據按照Key排序,提高處理速度和性能

　　3. Reducer: 業務處理,需要用戶自己編程

　　4. OutputFormat:數據輸出將處理的結果輸出到HDSF,該過程可以用戶自定義也可以使用系統內置輸出格式.

　　具體流程如下:

　　流程解析:

1. 將HDFS上的數據以Split的方式輸入到MR,Split是MR最小的計算單元,Block是HDFS的存儲單元,兩個並不矛盾,block只是機械的將數據按照數據塊大小進行切分,這樣極有可能將一行數據階段,默認情況一個Split對應一個Block但是這種匹配關系是可以修改的,這種對應關系是有InputFormat決定,所在在InputFormat中會處理數據換行問題.InputFormat將數據處理成多個KeyValue對,之後交給Mapper處理
2. 用戶對Mapper的輸出進行業務處理,之後將其輸出成需要的K-V
3. Mapper解析的K-V經過Partitioner處理後就會知道需要選擇那個Reducer處理K-V對,並保存到本地磁盤
4. 每個Reduce都需要從網絡拉去需要處理的數據,該階段稱為Shuffle,拉去完成之後對數據進行排序,最後才作為Reduce計算的輸入
5. 對Reduce的結果通過OutputFormat格式輸出到HDFS上

　　MapReduce計算結構:

　　MR和HDFS一樣也是Master-Slave結構,該圖是hadoop 1.0的任務運行圖

　　client將任務提交到JobTracker,JobTracker負責集群資源監控和任務調度.JobTracker將任務分割成多個MapTask和ReduceTask.並把這些Task分發到指定的TaskTracker.並監視TaskTracker和Job的運行情況,當發現任務失敗後,將其轉移到其他節點.JobTascker會監控任務的運行資源和狀態信息,並將這些信息通知給任務調度器,而任務調度器會在資源空閑時將這些資源分配其他任務.

　　TaskTracker:TaskTracker負責通過心跳向JobTracker報告本節點資源情況(CPU\內存\磁盤等),同時還會接受JobTracker發送過來的命令(啟動|結束服務等).TaskTracker將資源劃分成很多槽位slot(後續介紹),一個任務之後獲取到指定的槽位之後才可以運行,hadoop 調度器就是將空閑的槽位分配給等待的Task.

　　小總結:

　　JobTracker任務

• MR的Master節點
• 管理所有作業
• 將作業分解成很多任務
• 將任務指派給TaskTracker
• 作業/資源監控,錯誤處理

　　TaskTracker任務

• MR的Slave節點
• 運行MapTask和ReductTask
• 和JobTracker交互,執行接收的命令,並匯報任務狀態

　　Task:任務分為MapTask和ReduceTask,Task都是通過TaskTracker啟動.

　　HDFS存儲是以block為單位存儲的,但是MR是以Split位單位計算,所以就涉及到Split和Block對應的問題,其實在Split中只保存了數據的元數據信息,比如數據的開始位置,長度,數據所在那個節點等信息.其Split的劃分方式可以完成由用戶指定(自己實現InputFormat),Split的多少就決定了MapTask的數據,因為一個Split只會交給一個Map Task.Split和Block的對應關系如下:

　　HDSF中每一個block會分散到不同節點上,但是每一個split可以有多個block組成

　　Map Task執行流程:

　　MapTask從HDFS上依次讀取各個Split,對每個Split通過InputFormat解析成Key/Value對,之後調用用戶自定義map()行函數,將結果調用partition後保存在本地磁盤

　　Reduct Task執行流程：

　　每一個ReductTask從各個Map中拉取需要處理的數據(比如該ReductTask需要處理 分片1,則從Map節點拉取編號為1的數據)到本地,該操作稱為Shuffle,之後對所有的數據按照Key排序,將每一個Key和它的所有數據 value list,作為輸入調用reduce()函數,最後將結果輸出到HDFS上,每一個Reduct對每一個分片都會形成一個 partition-x 的結果.

　　MapReduct 流程調度圖:

　　MapReduct 資源管理(1.0)

　　1.0 的資源管理是通過JobTracker和TaskTracker完成的,1.0 是將任務管理和資源管理都在一個組件中處理(不好). Hadoop 1.0 的資源有兩部分組成:資源表示模型和資源分配模型,
　　其中資源表示模型用於描述資源組織方式,Hadoop1.0 使用槽位組織各個節點資源,而資源分配模型決定如何將資源分配給各個任務.
　　Hadoop 將各個節點的資源(包括CPU\內存\硬盤)切分成若幹份,每一位代表一個槽位,同時規定每一個任務可以占用多個槽位.槽位其實就是任務運行的許可證,一個任務得到槽位後
　　才能開始執行,否則就要處於等待狀態.所以節點上槽位的多少就定了該節點可以並發的個數.槽位也分類型,Map和Reduce都有各自的槽位數,這個數用戶可以自定義
　　mapred.tasktracker.map.tasks.maxinum | mapred.tasktrackerreduce.tasks.maxinum.

　　hadoop1.0 資源管理的缺點:
　　1. 靜態資源配置:每個節點的資源配置一旦確定,就無法更改
　　2. 資源無法共享:節點資源被分割成Map槽位和Reduce槽位,兩個槽位之間不允許共享,對於一個作業,Map時,Map槽位開始使用,但是Reduce槽位處於空閑狀態,這樣就降低隊了
　　槽位的利用率
　　3. 資源劃分粒度過大:槽位大小是事先規定好的,比如1個槽位:2G 內存1個CPU, 假如一個任務只需要1G內存,這樣就造成了1G內存的浪費,反之依然
　　4. 資源沒有隔離機制:1. 0 采用JVM資源隔離,這樣其實在一個節點上並沒有對資源進行隔離,可能會導致節點任務之間影響降低效率.

　　hadoop 2.0 資源管理方案:
　　hadoop2.0 使用了Yarn對資源進行管理,Hadoop 只有HDS和MapReduce兩部分組成,Yarn 負責集群資源的管理和調度,MR只是部署在Yarn上的離線應用,當然Yarn也可以不熟其他應用比如Spark等.如果說2.0 的資源
　　管理其實就是說Yarn對資源的管理:

　　資源其實是多個維度,CPU\內存\硬盤等等,如果簡單將他們映射成一個維度,就是1.0的槽位就會有1.0 對資源管理的缺點,所以Yarn中對資源的管理並非使用1.0中的槽位,而是使用最直接最簡單方式,直接要資源,比如
　　申請2G內存,1個CPU.Yarn會對任務進行資源的精細分配.

　　Yarn要求對每一個節點配置其資源使用總量,而中央調度器負責收集各個節點的資源,並將其分配給各個應用程序.節點配置參數如下:
　　1. 配置物理內存最大使用量
　　yarn.nodemanager.resource.memory-mb
　　2. 配置單位物理內存最多可使用虛擬內存的比例
　　yarn.nodemanager.vmem-pmen-ratio
　　比如: 2.1 ,代表,1M的物理內存,最多可使用的虛擬內存量位2.1M
　　3. 可分配虛擬CPU個數
　　yarn.nodenamager.recource.cpu-vcore
　　yarn可以對每個節點配置虛擬CPU數
　　目前Yarn引用cgroup的資源隔離方案降低各任務之間的幹擾.

Hadoop筆記 一