上一篇：084-BigData-12MapReduce入門

續(xù)上一篇

四、Hadoop數(shù)據(jù)壓縮

1、概述

壓縮技術(shù)能夠有效減少底層存儲系統(tǒng)（HDFS）讀寫字節(jié)數(shù)。壓縮提高了網(wǎng)絡(luò)帶寬和磁盤空間的效率。在Hadoop下，尤其是數(shù)據(jù)規(guī)模很大和工作負載密集的情況下，使用數(shù)據(jù)壓縮顯得非常重要。在這種情況下，I/O操作和網(wǎng)絡(luò)數(shù)據(jù)傳輸要花大量的時間。還有，Shuffle與Merge過程同樣也面臨著巨大的I/O壓力。
鑒于磁盤I/O和網(wǎng)絡(luò)帶寬是Hadoop的寶貴資源，數(shù)據(jù)壓縮對于節(jié)省資源、最小化磁盤I/O和網(wǎng)絡(luò)傳輸非常有幫助。不過，盡管壓縮與解壓操作的CPU開銷不高，其性能的提升和資源的節(jié)省并非沒有代價。
如果磁盤I/O和網(wǎng)絡(luò)帶寬影響了MapReduce作業(yè)性能，在任意MapReduce階段啟用壓縮都可以改善端到端處理時間并減少I/O和網(wǎng)絡(luò)流量。
壓縮Mapreduce的一種優(yōu)化策略：通過壓縮編碼對Mapper或者Reducer的輸出進行壓縮，以減少磁盤IO，提高MR程序運行速度（但相應(yīng)增加了cpu運算負擔(dān)）。
注意：壓縮特性運用得當(dāng)能提高性能，但運用不當(dāng)也可能降低性能。
基本原則：
（1）運算密集型的job，少用壓縮
（2）IO密集型的job，多用壓縮

2、MR支持的壓縮編碼

image.png

為了支持多種壓縮/解壓縮算法，Hadoop引入了編碼/解碼器，如下表所示

image.png

壓縮性能的比較

image.png

參考：http://google.github.io/snappy/

On a single core of a Core i7 processor in 64-bit mode, Snappy compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or more.

壓縮方式選擇

3、Gzip壓縮

優(yōu)點：壓縮率比較高，而且壓縮/解壓速度也比較快；hadoop本身支持，在應(yīng)用中處理gzip格式的文件就和直接處理文本一樣；大部分linux系統(tǒng)都自帶gzip命令，使用方便。

缺點：不支持split。

應(yīng)用場景：當(dāng)每個文件壓縮之后在130M以內(nèi)的（1個塊大小內(nèi)），都可以考慮用gzip壓縮格式。例如說一天或者一個小時的日志壓縮成一個gzip文件，運行mapreduce程序的時候通過多個gzip文件達到并發(fā)。hive程序，streaming程序，和java寫的mapreduce程序完全和文本處理一樣，壓縮之后原來的程序不需要做任何修改。

4、Bzip2壓縮

優(yōu)點：支持split；具有很高的壓縮率，比gzip壓縮率都高；hadoop本身支持，但不支持native(java和c互操作的API接口)；在linux系統(tǒng)下自帶bzip2命令，使用方便。

缺點：壓縮/解壓速度慢；不支持native。

應(yīng)用場景：適合對速度要求不高，但需要較高的壓縮率的時候，可以作為mapreduce作業(yè)的輸出格式；或者輸出之后的數(shù)據(jù)比較大，處理之后的數(shù)據(jù)需要壓縮存檔減少磁盤空間并且以后數(shù)據(jù)用得比較少的情況；或者對單個很大的文本文件想壓縮減少存儲空間，同時又需要支持split，而且兼容之前的應(yīng)用程序（即應(yīng)用程序不需要修改）的情況。

5、Lzo壓縮

優(yōu)點：壓縮/解壓速度也比較快，合理的壓縮率；支持split，是hadoop中最流行的壓縮格式；可以在linux系統(tǒng)下安裝lzop命令，使用方便。

缺點：壓縮率比gzip要低一些；hadoop本身不支持，需要安裝；在應(yīng)用中對lzo格式的文件需要做一些特殊處理（為了支持split需要建索引，還需要指定inputformat為lzo格式）。

應(yīng)用場景：一個很大的文本文件，壓縮之后還大于200M以上的可以考慮，而且單個文件越大，lzo優(yōu)點越越明顯。

6、Snappy壓縮

優(yōu)點：高速壓縮速度和合理的壓縮率。

缺點：不支持split；壓縮率比gzip要低；hadoop本身不支持，需要安裝；

應(yīng)用場景：當(dāng)Mapreduce作業(yè)的Map輸出的數(shù)據(jù)比較大的時候，作為Map到Reduce的中間數(shù)據(jù)的壓縮格式；或者作為一個Mapreduce作業(yè)的輸出和另外一個Mapreduce作業(yè)的輸入。

7、壓縮位置選擇

壓縮可以在MapReduce作用的任意階段啟用。

8、壓縮配置參數(shù)

要在Hadoop中啟用壓縮，可以配置如下參數(shù)：

image.png

image.png

五、Yarn

1、Hadoop1.x和Hadoop2.x架構(gòu)區(qū)別

在Hadoop1.x時代，Hadoop中的MapReduce同時處理業(yè)務(wù)邏輯運算和資源的調(diào)度，耦合性較大。
在Hadoop2.x時代，增加了Yarn。Yarn只負責(zé)資源的調(diào)度，MapReduce只負責(zé)運算

2、Yarn概述

Yarn是一個資源調(diào)度平臺，負責(zé)為運算程序提供服務(wù)器運算資源，相當(dāng)于一個分布式的操作系統(tǒng)平臺，而MapReduce等運算程序則相當(dāng)于運行于操作系統(tǒng)之上的應(yīng)用程序。

3、Yarn基本架構(gòu)

YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等組件構(gòu)成。

4、Yarn工作機制

image.png

5、名詞解釋：

1. 資源：在 YARN 的語境下，資源特指計算資源，包括 CPU 和內(nèi)存。計算機的每個進程都會占用一定的 CPU 和內(nèi)存，任務(wù)需要先向 RM 申請到資源后才能獲準(zhǔn)在 NM 上啟動自己的進程。

2. 隊列：YARN 將整個集群的資源劃分為隊列，每個用戶的任務(wù)必須提交到指定隊列。同時限制每個隊列的大小，防止某個用戶的任務(wù)占用整個集群，影響了其他用戶的使用。

3. Vcore & Mem：邏輯 CPU 和邏輯內(nèi)存，每個 NM 會向 RM 匯報自己有多少 vcore 和內(nèi)存可用，具體數(shù)值由集群管理員配置。比如一臺48核，128G內(nèi)存的機器，可以配置40vcore，120G內(nèi)存，意為可以對外提供這么多資源。具體數(shù)值可能根據(jù)實際情況有所調(diào)整。每個 NM 的邏輯資源加起來，就是整個集群的總資源量。

4. MinResources & MaxResources：為了使每個隊列都能得到一定的資源，同時又不浪費集群的空閑資源，隊列的資源設(shè)置都是“彈性”的。每個隊列都有 min 和 max 兩個資源值，min 表示只要需求能達到，集群一定會提供這么多資源；如果資源需求超過了 min 值而同時集群仍有空閑資源，則仍然可以滿足；但又限制了資源不能無限申請以免影響其他任務(wù)，資源的分配不會超過 max 值。

5. Container：任務(wù)申請到資源后在 NM 上啟動的進程統(tǒng)稱 Container。比如在 MapReduce 中可以是 Mapper 或 Reducer，在 Spark 中可以是 Driver 或 Executor。

6、工作機制簡化版

1. 用戶使用客戶端向 RM 提交一個任務(wù)job，同時指定提交到哪個隊列和需要多少資源。用戶可以通過每個計算引擎的對應(yīng)參數(shù)設(shè)置，如果沒有特別指定，則使用默認(rèn)設(shè)置。

2. RM 在收到任務(wù)提交的請求后，先根據(jù)資源和隊列是否滿足要求選擇一個 NM，通知它啟動一個特殊的 container，稱為 ApplicationMaster（AM），后續(xù)流程由它發(fā)起。

3. AM 向 RM 注冊后根據(jù)自己任務(wù)的需要，向 RM 申請 container，包括數(shù)量、所需資源量、所在位置等因素。

4. 如果隊列有足夠資源，RM 會將 container 分配給有足夠剩余資源的 NM，由 AM 通知 NM 啟動 container。

5. container 啟動后執(zhí)行具體的任務(wù)，處理分給自己的數(shù)據(jù)。NM 除了負責(zé)啟動 container，還負責(zé)監(jiān)控它的資源使用狀況以及是否失敗退出等工作，如果 container 實際使用的內(nèi)存超過申請時指定的內(nèi)存，會將其殺死，保證其他 container 能正常運行。

6. 各個 container 向 AM 匯報自己的進度，都完成后，AM 向 RM 注銷任務(wù)并退出，RM 通知 NM 殺死對應(yīng)的 container，任務(wù)結(jié)束。

container設(shè)置多少資源合適？
如果 container 內(nèi)存設(shè)置得過低，而實際使用的內(nèi)存較多，則可能會被 YARN 在運行過程中殺死，無法正常運行。而如果 container 內(nèi)部線程并發(fā)數(shù)較多而 vcore 設(shè)置的較少，則可能會被分配到一個 load 已經(jīng)比較高的機器上，導(dǎo)致運行緩慢。所以需要預(yù)估單個 container 處理的數(shù)據(jù)量對應(yīng)的內(nèi)存，同時 vcore 數(shù)設(shè)置的不應(yīng)該比并發(fā)線程數(shù)低。

7、Yarn復(fù)雜運行機制

image.png

2）工作機制詳解
（0）Mr程序提交到客戶端所在的節(jié)點。
（1）Yarnrunner向Resourcemanager申請一個Application。
（2）rm將該應(yīng)用程序的資源路徑返回給yarnrunner。
（3）該程序?qū)⑦\行所需資源提交到HDFS上。
（4）程序資源提交完畢后，申請運行mrAppMaster。
（5）RM將用戶的請求初始化成一個task。
（6）其中一個NodeManager領(lǐng)取到task任務(wù)。
（7）該NodeManager創(chuàng)建容器Container，并產(chǎn)生MRAppmaster。
（8）Container從HDFS上拷貝資源到本地。
（9）MRAppmaster向RM 申請運行maptask資源。
（10）RM將運行maptask任務(wù)分配給另外兩個NodeManager，另兩個NodeManager分別領(lǐng)取任務(wù)并創(chuàng)建容器。
（11）MR向兩個接收到任務(wù)的NodeManager發(fā)送程序啟動腳本，這兩個NodeManager分別啟動maptask，maptask對數(shù)據(jù)分區(qū)排序。
（12）MrAppMaster等待所有maptask運行完畢后，向RM申請容器，運行reduce task。
（13）reduce task向maptask獲取相應(yīng)分區(qū)的數(shù)據(jù)。
（14）程序運行完畢后，MR會向RM申請注銷自己。

8、作業(yè)提交全過程

作業(yè)提交全過程詳解
（1）作業(yè)提交
第0步：client調(diào)用job.waitForCompletion方法，向整個集群提交MapReduce作業(yè)。
第1步：client向RM申請一個作業(yè)id。
第2步：RM給client返回該job資源的提交路徑和作業(yè)id。
第3步：client提交jar包、切片信息和配置文件到指定的資源提交路徑。
第4步：client提交完資源后，向RM申請運行MrAppMaster。
（2）作業(yè)初始化
第5步：當(dāng)RM收到client的請求后，將該job添加到容量調(diào)度器中。
第6步：某一個空閑的NM領(lǐng)取到該job。
第7步：該NM創(chuàng)建Container，并產(chǎn)生MRAppmaster。
第8步：下載client提交的資源到本地。
（3）任務(wù)分配
第9步：MrAppMaster向RM申請運行多個maptask任務(wù)資源。
第10步：RM將運行maptask任務(wù)分配給另外兩個NodeManager，另兩個NodeManager分別領(lǐng)取任務(wù)并創(chuàng)建容器。
（4）任務(wù)運行
第11步：MR向兩個接收到任務(wù)的NodeManager發(fā)送程序啟動腳本，這兩個NodeManager分別啟動maptask，maptask對數(shù)據(jù)分區(qū)排序。
第12步：MrAppMaster等待所有maptask運行完畢后，向RM申請容器，運行reduce task。
第13步：reduce task向maptask獲取相應(yīng)分區(qū)的數(shù)據(jù)。
第14步：程序運行完畢后，MR會向RM申請注銷自己。
（5）進度和狀態(tài)更新
YARN中的任務(wù)將其進度和狀態(tài)(包括counter)返回給應(yīng)用管理器, 客戶端每秒(通過mapreduce.client.progressmonitor.pollinterval設(shè)置)向應(yīng)用管理器請求進度更新, 展示給用戶。
（6）作業(yè)完成
除了向應(yīng)用管理器請求作業(yè)進度外, 客戶端每5分鐘都會通過調(diào)用waitForCompletion()來檢查作業(yè)是否完成。時間間隔可以通過mapreduce.client.completion.pollinterval來設(shè)置。作業(yè)完成之后, 應(yīng)用管理器和container會清理工作狀態(tài)。作業(yè)的信息會被作業(yè)歷史服務(wù)器存儲以備之后用戶核查。

9、資源調(diào)度器

資源調(diào)度器
目前，Hadoop作業(yè)調(diào)度器主要有三種：FIFO、Capacity Scheduler和Fair Scheduler。目前默認(rèn)的資源調(diào)度器是Capacity Scheduler。

具體設(shè)置詳見：yarn-default.xml文件

<property>
    <description>The class to use as the resource scheduler.</description>
    <name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>

先進先出調(diào)度器（FIFO）

image.png

優(yōu)點:調(diào)度算法簡單，JobTracker（job提交任務(wù)后發(fā)送得地方）工作負擔(dān)輕。
缺點:忽略了不同作業(yè)的需求差異。例如如果類似對海量數(shù)據(jù)進行統(tǒng)計分析的作業(yè)長期占據(jù)計算資源，那么在其后提交的交互型作業(yè)有可能遲遲得不到處理，從而影響到用戶的體驗。

容量調(diào)度器（Capacity Scheduler）===>Yahoo開發(fā)

image.png

1.多隊列支持，每個隊列采用FIFO
2.為了防止同一個用戶的作業(yè)獨占隊列中的資源，該調(diào)度器會對同一個用戶提交多的作業(yè)所占資源量進行限定
3.首先，計算每個隊列中正在運行的任務(wù)數(shù)與其應(yīng)該分得的計算資源之間的比值，選擇一個該比值最小的隊列
4.其次，根據(jù)作業(yè)的優(yōu)先級和提交時間順序，同時考慮用戶資源量限制和內(nèi)存限制對隊列內(nèi)任務(wù)排序
5.三個隊列同時按照任務(wù)的先后順序依次執(zhí)行，比如，job1，job21和job31分別排在隊列最前面，是最先運行，也是同時運行

該調(diào)度默認(rèn)情況下不支持優(yōu)先級，但是可以在配置文件中開啟此選項，如果支持優(yōu)先級，調(diào)度算法就是帶有優(yōu)先級的FIFO。
不支持優(yōu)先級搶占，一旦一個作業(yè)開始執(zhí)行，在執(zhí)行完之前它的資源不會被高優(yōu)先級作業(yè)所搶占。
對隊列中同一用戶提交的作業(yè)能夠獲得的資源百分比進行了限制以使同屬于一用戶的作業(yè)不能出現(xiàn)獨占資源的情況。

3）公平調(diào)度器（Fair Scheduler）===>Facebook開發(fā)

image.png

1.支持多隊列多用戶，每個隊列中的資源量可以配置，同一個隊列中的作業(yè)公平共享隊列中所有資源
2.比如有三個隊列A，B，C.每個隊列中的job按照優(yōu)先級分配資源，優(yōu)先級越高分配的資源越多，但是每個job都分配到資源以確保公平。在資源有限的情況下，每個job理想情況下，獲得的計算資源與實際獲得的計算資源存在一種差距，這個差距叫做缺額。同一個隊列，job的資源缺額越大，越先獲得的資源優(yōu)先執(zhí)行，作業(yè)是按照缺額的高低來先后執(zhí)行的，而且可以看到上圖有多個作業(yè)同時運行

10、任務(wù)的推測執(zhí)行

推測執(zhí)行(Speculative Execution)是指在集群環(huán)境下運行MapReduce，可能是程序Bug，負載不均或者其他的一些問題，導(dǎo)致在一個JOB下的多個TASK速度不一致，比如有的任務(wù)已經(jīng)完成，但是有些任務(wù)可能只跑了10%，根據(jù)木桶原理，這些任務(wù)將成為整個JOB的短板，如果集群啟動了推測執(zhí)行，這時為了最大限度的提高短板，Hadoop會為該task啟動備份任務(wù)，讓speculative task與原始task同時處理一份數(shù)據(jù)，哪個先運行完，則將誰的結(jié)果作為最終結(jié)果，并且在運行完成后Kill掉另外一個任務(wù)。

1）作業(yè)完成時間取決于最慢的任務(wù)完成時間
一個作業(yè)由若干個Map任務(wù)和Reduce任務(wù)構(gòu)成。因硬件老化、軟件Bug等，某些任務(wù)可能運行非常慢。
典型案例：系統(tǒng)中有99%的Map任務(wù)都完成了，只有少數(shù)幾個Map老是進度很慢，完不成，怎么辦？
2）推測執(zhí)行機制：
發(fā)現(xiàn)拖后腿的任務(wù)，比如某個任務(wù)運行速度遠慢于任務(wù)平均速度。為拖后腿任務(wù)啟動一個備份任務(wù)，同時運行。誰先運行完，則采用誰的結(jié)果。
3）執(zhí)行推測任務(wù)的前提條件
（1）每個task只能有一個備份任務(wù)；
（2）當(dāng)前job已完成的task必須不小于0.05（5%）
（3）開啟推測執(zhí)行參數(shù)設(shè)置，mapred-site.xml文件中默認(rèn)是打開的。

<property>
  <name>mapreduce.map.speculative</name>
  <value>true</value>
  <description>If true, then multiple instances of some map tasks                may be executed in parallel.</description>
</property>

<property>
  <name>mapreduce.reduce.speculative</name>
  <value>true</value>
  <description>If true, then multiple instances of some reduce tasks 
               may be executed in parallel.</description>
</property>

4）不能啟用推測執(zhí)行機制情況
（1）任務(wù)間存在嚴(yán)重的負載傾斜；
（2）特殊任務(wù)，比如任務(wù)向數(shù)據(jù)庫中寫數(shù)據(jù)。

下一篇：086-BigData-14MapReduce實戰(zhàn)