眾人拾柴火焰高，這里貼個本面經(jīng)的共享在線文檔，大家可以自由編輯，共同豐富題庫。

整理不易，來個關(guān)注+收藏+點贊唄

在線文檔：

Hadoop面試大全

HBase面試大全

Kafka面試大全

-----------------------------------------分界線-----------------------------------------

1.基礎(chǔ)

1.1 介紹下Hadoop

Hadoop是一個分布式系統(tǒng)基礎(chǔ)架構(gòu)，以分布式文件系統(tǒng)（HDFS）為基礎(chǔ)，利用MapReduce編程模型實現(xiàn)分布式數(shù)據(jù)處理，通過橫向擴(kuò)展方式，可以在計算機(jī)集群中運行并行任務(wù)，提高數(shù)據(jù)處理效率。具有高可靠性、高容錯性、高可擴(kuò)展性等特點。

（1）特點

高可用：Hadoop 底層對同一個數(shù)據(jù)維護(hù)這多個復(fù)本，即使Hadoop某個計算元素或者存儲出現(xiàn)問題，也不會導(dǎo)致數(shù)據(jù)的丟失。

高擴(kuò)展：在集群之間分配任務(wù)數(shù)據(jù)，可以方便的擴(kuò)展跟刪除多個節(jié)點。

高效性：在MapReduce的思想下 Hadoop是并行工作的，以加快任務(wù)的處理速度

高容錯性：如果一個子任務(wù)速度過慢或者任務(wù)失敗 Hadoop會有響應(yīng)策略會自動重試

（2）核心組件

HDFS是一個分布式文件系統(tǒng)。HDFS 有著高容錯性，被設(shè)計用來部署在低廉的硬件上來提供高吞吐量的訪問應(yīng)用程序的數(shù)據(jù)，適合超大數(shù)據(jù)集的應(yīng)用程序。

• NameNode：管理HDFS命名空間；配置副本策略；管理數(shù)據(jù)塊映射信息；處理客戶端讀寫請求。
• DataNode：存儲實際的數(shù)據(jù)塊以及校驗和；執(zhí)行數(shù)據(jù)塊的讀寫操作
• Secondary NameNode：定期合并Fsimage和Edits，并推送給NameNode；在緊急情況下可輔助恢復(fù)NameNode
• Client：文件上傳HDFS時將文件切分為Block；與NameNode交互，獲取文件位置信息；與DataNode交互，讀取/寫入數(shù)據(jù)；提供一些命令來管理HDFS；通過一些命令來訪問HDFS，比如增刪改查。

MapperReduce是一個分布式運算程序的編程框架，將用戶編寫的業(yè)務(wù)邏輯代碼和自帶默認(rèn)組件整合成一個完整的分布式運算程序，并發(fā)運行在一個Hadoop集群上。

Yarn是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統(tǒng)，可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度，它的引入為集群在利用率、資源統(tǒng)一管理和數(shù)據(jù)共享等方面帶來了巨大好處。

• ResourceManager：處理客戶端請求；監(jiān)控NodeManager；啟動/監(jiān)控ApplicationMaster；資源分配與調(diào)度。
• NodeManager：管理單個節(jié)點上的資源；處理來自ResourceManager的命令；處理來自ApplicationMaster的命令。
• ApplicationMaster：負(fù)責(zé)數(shù)據(jù)的切分；為應(yīng)用程序申請資源并分配給內(nèi)部任務(wù)；任務(wù)的監(jiān)控與容錯。
• Container：Yarn中資源的抽象，封裝了某個節(jié)點上的多維度資源：內(nèi)存，CPU，磁盤，網(wǎng)絡(luò)。

1.2 Hadoop 1.x，2x，3.x的區(qū)別

• 1.X

主從架構(gòu)由一個主節(jié)點Jobtrack和多個從節(jié)點Tasktrack組成，真正執(zhí)行任務(wù)的是tasktrack中運行著的maptask和reducetask，沒有提供架構(gòu)中主節(jié)點NameNode及jobtrack的高可用及負(fù)載均機(jī)制，MR兼具計算和資源調(diào)度兩個作用，默認(rèn)塊大小64M。

• 2.XYarn負(fù)責(zé)資源調(diào)度工作，MR專門執(zhí)行計算；引入了高可用特性；默認(rèn)塊大小128M。
• 3.X最低Java版本改為Java8支持糾刪碼：原始數(shù)據(jù)中加入新的校驗特性，使各個部分的數(shù)據(jù)產(chǎn)生關(guān)聯(lián)性，在一定范圍下數(shù)據(jù)出錯時，通過糾刪碼技術(shù)可進(jìn)行恢復(fù)。

缺點：消耗網(wǎng)絡(luò)，消耗CPU，適用于冷數(shù)據(jù)集群

優(yōu)點：將原來3倍的存儲消耗降低到1.4倍；支持多于2個NameNode。

1.3 Hadoop集群工作時啟動哪些進(jìn)程?它們有什么作用?

NameNode：Hadoop中的主服務(wù)器，管理文件系統(tǒng)Namespace，對集群中存儲的文件訪問，保存有metadate。

SecondaryNameNode：周期性的將Namespace鏡像與操作日志(Edit Log)合并，防止Edit Log文件過大。

DataNode：文件系統(tǒng)的工作節(jié)點，他們根據(jù)客戶端或者是NameNode的調(diào)度存儲和檢索數(shù)據(jù)，并且定期向NameNode發(fā)送他們所存儲的塊(block)的列表。

ResourceManager：負(fù)責(zé)集群中所有資源的統(tǒng)一管理和分配，它接收來自各個節(jié)點（NodeManager）的資源匯報信息，并把這些信息按照一定的策略分配給ApplicationMaster

NodeManager：以心跳的方式向 ResourceManager 匯報資源使用情況（目前主要是 CPU 和內(nèi)存的使用情況）。RM 只接受 NM 的資源回報信息，對于具體的資源處理則交給 NM 自己處理；監(jiān)督Container的生命周期管理，監(jiān)控每個Container的資源使用（內(nèi)存、CPU等）情況，追蹤節(jié)點健康狀況，管理日志和不同應(yīng)用程序用到的附屬服務(wù)

ZKFailoverController：負(fù)責(zé)整體的故障轉(zhuǎn)移控制等。它是一個守護(hù)進(jìn)程，通過main()方法啟動。

1.4 在集群計算的時候，什么是集群的主要瓶頸

磁盤I/O，I/O的好壞直接影響集群對數(shù)據(jù)的處理，網(wǎng)絡(luò)是稀缺資源，不是瓶頸。

1.5 搭建Hadoop集群的xml文件有哪些?

• core-site.xml

定義文件系統(tǒng)地址，默認(rèn)是本地文件系統(tǒng) 需要我們改成 hdfs://分布式文件存儲系統(tǒng);

指定臨時文件存放目錄;

指定NameNode的URL。

• hdfs-site.xml

指定HDFS保存數(shù)據(jù)的副本數(shù)量；

設(shè)置文件存儲的block塊大小。

• mapred-site.xml

指定MR運行方式；

開啟mapreduce的小任務(wù)模式，用于調(diào)優(yōu)；

配置mapreduce 的jobhistory，可以查看我們所有運行完成的任務(wù)的一些情況。

• hadoop-env.sh

Java路徑

• Yarn-site.xml

指定我們的resourceManager運行在哪臺機(jī)器上面；

日志的聚合功能，方便我們查看任務(wù)執(zhí)行完成之后的日志記錄；

聚合日志的保存時長。

1.6 Hadoop的checkpoint流程

SecondaryNameNode將NameNode上的fsimage和edits文件拷貝過來，合并成新的fsimage并傳到NameNode。

1.7 Block劃分的原因

為了提高讀寫速率，分成最佳大小

1.8 Hadoop常見的壓縮算法?

Snappy：無需安裝，不支持切分，壓縮后和文本處理一樣

適用：Mapper輸出數(shù)據(jù)較大時，作為中間數(shù)據(jù)的壓縮格式，或者作為一個MR到另一個MR的中間數(shù)據(jù)

LZO：需要安裝，支持切分，壓縮后需要建立索引

適用：壓縮后體積還超過塊大小的，單個文件越大，優(yōu)點越明顯

GZip：無需安裝，壓縮率高，無需處理

缺點：不支持切片

適用：壓縮后一個塊大小內(nèi)

Bzip2：壓縮率極高，無需安裝

缺點：速度慢

適用：對速度要求低，對壓縮率要求高；或存儲后使用較少

1.9 Hadoop作業(yè)提交到Y(jié)arn的流程?

a. 用戶向 Yarn 中提交應(yīng)用程序，其中包括 MRAppMaster 程序，啟動 MRAppMaster 的命令，用戶程序等。；

b. ResourceManager 為該程序分配第一個 Container，并與對應(yīng)的 NodeManager 通訊，要求它在這個 Container 中啟動應(yīng)用程序 AppMaster；

c. AppMaster首先向ResourceManager 注冊，這樣用戶可以直接通過 ResourceManager查看應(yīng)用程序的運行狀態(tài)，然后將為各個任務(wù)申請資源，并監(jiān)控它的運行狀態(tài)，直到運行結(jié)束，重復(fù) 4 到 7 的步驟；

d. AppMaster 采用輪詢的方式通過 RPC 向 ResourceManager 申請和領(lǐng)取資源；

e. AppMaster 申請到資源后，與對應(yīng)的 NodeManager 通訊，要求它啟動任務(wù)；

f. NodeManager 為任務(wù)設(shè)置好運行環(huán)境（包括環(huán)境變量、JAR 包、二進(jìn)制程序等）后，將任務(wù)啟動命令寫到一個腳本中，并通過運行該腳本啟動任務(wù)；

g. 各個任務(wù)通過 RPC 協(xié)議向 AppMaster 匯報自己的狀態(tài)和進(jìn)度，以便 AppMaster隨時掌握各個任務(wù)的運行狀態(tài)，從而可以在任務(wù)敗的時候重新啟動任務(wù)；

h. 應(yīng)用程序運行完成后，MRAppMaster 向 ResourceManager 注銷并關(guān)閉自己。

1.10 Hadoop序列化和反序列化

序列化：內(nèi)存中的數(shù)據(jù)轉(zhuǎn)為字節(jié)序列，一般存儲于磁盤或網(wǎng)絡(luò)傳輸；

反序列化：將網(wǎng)絡(luò)接收到的字節(jié)序列或者從硬盤讀取到的字節(jié)序列轉(zhuǎn)化為內(nèi)存中的對象

1.11 Hadoop的運行模式

本地模式：沒有守護(hù)進(jìn)程，所有進(jìn)程都在一個JVM上運行

偽分布式：守護(hù)進(jìn)程在本地，模擬分布式的各個節(jié)點

完全分布式：由多個節(jié)點構(gòu)成，守護(hù)進(jìn)程運行在集群上

1.12 Hadoop小文件處理問題

• 數(shù)據(jù)采集前合并小文件
• 業(yè)務(wù)處理前，在HDFS上通過MR合并小文件
• 在MR處理時，采用CombineTextInputFormat提高效率
• 實現(xiàn)jvm重用
• Hadoop Archive：能夠高效將小文件放入HDFS，并將多個小文件打包為一個HAR文件，從而減少NN的內(nèi)存使用
• 使用SequenceFile二進(jìn)制格式文件

1.13 Hadoop從2.x升級到3.x的優(yōu)化?

容錯提升：傳統(tǒng)的復(fù)制處理容錯升級為Erasure編碼來處理容錯；

數(shù)據(jù)平衡：2.x中單一DN管理多個磁盤時，每個磁盤用量比較均勻，但是添加或者更換磁盤時，會導(dǎo)致部分磁盤使用不均，3.x通過DN內(nèi)部均衡功能Intra-data節(jié)點平衡器已經(jīng)可以處理上述情況；

1.14 Hadoop的優(yōu)缺點

（1）優(yōu)點

高可靠性：具有按位存儲和處理數(shù)據(jù)能力；

高擴(kuò)展性：Hadoop通過可用的計算機(jī)集群分配數(shù)據(jù)，完成存儲和計算任務(wù)，這些集群可以方便地擴(kuò)展到數(shù)以千計的節(jié)點中；

高效性：能夠在節(jié)點之間進(jìn)行動態(tài)地移動數(shù)據(jù)，并保證各個節(jié)點的動態(tài)平衡，處理速度非?？?；

高容錯性：能夠自動保存數(shù)據(jù)的多個副本，并且能夠自動將失敗的任務(wù)重新分配。

（2）缺點

不適用于低延遲數(shù)據(jù)訪問；

不能高效存儲大量小文件；

不支持多用戶寫入并任意修改文件。

2.HDFS

2.1 介紹下HDFS，說下HDFS優(yōu)缺點，以及使用場景

（1）概念

HDFS（Hadoop Distributed File System）是一個分布式文件系統(tǒng)，是hadoop生態(tài)系統(tǒng)的一個重要組成部分，是hadoop中的存儲組件，是最基礎(chǔ)且極為重要的一部分，因為它涉及到數(shù)據(jù)存儲，MapReduce等計算模型都要依賴于存儲在HDFS中的數(shù)據(jù)。

（2）優(yōu)點

• 高容錯性

文件以block的方式，多副本存儲在集群的節(jié)點上，保證硬件的容錯，當(dāng)某一機(jī)器損壞時，不至于數(shù)據(jù)丟失。

• 流式數(shù)據(jù)訪問

一次寫入，多次讀取的操作。

• 適合存儲大文件

目前的hadoop集群能夠存儲幾百TB甚至PB級的數(shù)據(jù)。

• 可構(gòu)建在廉價的機(jī)器上

設(shè)備不需要多么昂貴和特殊，只要是一些日常使用的普通硬件即可。

（3）缺點

• 不支持低時間延遲的數(shù)據(jù)訪問

hdfs關(guān)心的是高數(shù)據(jù)吞吐量，不適合那些要求低時間延遲數(shù)據(jù)訪問的應(yīng)用。

• 單用戶寫入，不支持任意修改

hdfs的數(shù)據(jù)以讀為主，只支持單個寫入者，并且寫操作總是以添加的形式在文末追加，不支持在任意位置進(jìn)行修改。

（4）HDFS作用

為海量的數(shù)據(jù)提供了存儲，能提供高吞吐量的數(shù)據(jù)訪問，HDFS有高容錯性的特點，并且設(shè)計用來部署在低廉的硬件上；而且它提供高吞吐量來訪問應(yīng)用程序的數(shù)據(jù)，適合那些有著超大數(shù)據(jù)集的應(yīng)用程序。

2.2 HDFS文件寫入流程

a. 客戶端通過Distributed FileSystem模塊向NameNode請求上傳文件，NameNode檢查目標(biāo)文件是否已存在，父目錄是否存在；

b. NameNode返回是否可以上傳；

c. 客戶端請求第一個 Block上傳到哪幾個DataNode服務(wù)器上；

d. NameNode返回3個（副本數(shù)）DataNode節(jié)點，分別為dn1、dn2、dn3；

e. 客戶端通過FSDataOutputStream模塊請求dn1上傳數(shù)據(jù)，dn1收到請求會繼續(xù)調(diào)用dn2，然后dn2調(diào)用dn3，將這個通信管道建立完成；

f. dn1、dn2、dn3逐級應(yīng)答客戶端；

g. 客戶端開始往dn1上傳第一個Block（先從磁盤讀取數(shù)據(jù)放到一個本地內(nèi)存緩存），以Packet為單位，dn1收到一個Packet就會傳給dn2，dn2傳給dn3；dn1每傳一個packet會放入一個應(yīng)答隊列等待應(yīng)答；

h. 當(dāng)一個Block傳輸完成之后，客戶端再次請求NameNode上傳第二個Block的服務(wù)器。

2.3 HDFS文件讀流程

a. 客戶端通過DistributedFileSystem向NameNode請求下載文件，NameNode通過查詢元數(shù)據(jù)，找到文件塊所在的DataNode地址；

b. 挑選一臺DataNode（就近原則，然后隨機(jī)）服務(wù)器，請求讀取數(shù)據(jù)；

c. DataNode開始傳輸數(shù)據(jù)給客戶端（從磁盤里面讀取數(shù)據(jù)輸入流，以Packet為單位來做校驗）；

d. 客戶端以Packet為單位接收，先在本地緩存，然后寫入目標(biāo)文件。

2.4 副本選擇策略

第一個放在Client所在節(jié)點上，如果Client在集群外，則隨機(jī)選擇一個；

第二個在另一個機(jī)架的節(jié)點上；

第三個在第二個副本所在機(jī)架的隨機(jī)節(jié)點上；

2.5 HDFS組成架構(gòu)

（1）Client

文件上傳HDFS時，將文件切分為Block；

與NameNode交互，獲取文件位置信息；

與DataNode交互，讀取/寫入數(shù)據(jù)；

提供一些命令來管理HDFS，如NameNode格式化；

通過一些命令來訪問HDFS，比如增刪改查。

（2）NameNode

管理HDFS命名空間；

?? 配置副本策略；

管理數(shù)據(jù)塊映射信息；

處理客戶端讀寫請求。

（3）DataNode

存儲實際的數(shù)據(jù)塊以及校驗和；

執(zhí)行數(shù)據(jù)塊的讀寫操作。

（4）Secondary NameNode

定期合并Fsimage和Edits，并推送給NameNode；

在緊急情況下可輔助恢復(fù)NameNode。

2.6 列式存儲格式和行存儲格式異同點？

2.7 HDFS如何保證數(shù)據(jù)不丟失?

• 數(shù)據(jù)被存在默認(rèn)大小為128M的塊上，每個塊默認(rèn)有三個副本；
• 每個塊定時向NameNode做心跳報告狀態(tài)，如果塊死掉，則DN會將該塊上面數(shù)據(jù)的副本再復(fù)制一份保持副本數(shù)量；
• 每個DN會定時向NN匯報自己所有塊信息，NN會計算block損壞率，低于99.9%時會進(jìn)入安全模式

2.8 HDFS NameNode高可用如何實現(xiàn)?需要哪些角色?

（1）原理

a. 高可用同時具有多個NN，但同一時刻只有一個NN是active狀態(tài)，對外提供服務(wù)，其余NN都是standby狀態(tài)。

b. 當(dāng)active的NN掛掉后，被節(jié)點內(nèi)的zkfc(Zookeeper Failover Controller)進(jìn)程檢測到，zkfc通知另一個NN的zkfc（多個NN的話會觸發(fā)選舉機(jī)制）

c. 備用NN會去給死掉的NN補上一刀，如果補刀失敗則調(diào)用用戶自定義程序

d. 備用NN激活本臺NN，切換為Active狀態(tài)

（2）需要組件

多個NameNode，Zookeeper

2.9 HDFS的默認(rèn)副本數(shù)?為什么是這個數(shù)量?

如果想修改副本數(shù)怎么修改?

（1）默認(rèn)是3

（2）存放策略

一個副本存放在本地機(jī)架節(jié)點上；

另一個副本存放在同一機(jī)架的另一個節(jié)點上；

第三個副本存放在在不同機(jī)架的節(jié)點上。

（3）策略原因

減少了機(jī)架間的數(shù)據(jù)傳輸，提高了寫操作的效率；

機(jī)架錯誤的概率遠(yuǎn)比節(jié)點錯誤的概率小，不會對數(shù)據(jù)的可靠性和可用性造成影響；

同時，因為數(shù)據(jù)只存在兩個機(jī)架上，這種策略減少了讀數(shù)據(jù)時需要的網(wǎng)絡(luò)傳輸帶寬。

（4）修改

hdfs-site.xml配置文件中dfs.replication參數(shù)。

2.10 介紹下HDFS的Block

磁盤有一個Block size的概念，它是磁盤讀/寫數(shù)據(jù)的最小單位。構(gòu)建在這樣的磁盤上的文件系統(tǒng)也是通過塊來管理數(shù)據(jù)的，文件系統(tǒng)的塊通常是磁盤塊的整數(shù)倍。文件系統(tǒng)的塊一般為幾千字節(jié)(byte)，磁盤塊一般為512字節(jié)(byte)。

HDFS 作為一種文件系統(tǒng)，當(dāng)然也需要有‘block’的概念。不過HDFS的block一般比較大，默認(rèn)為128MB。與普通的管理單個磁盤的文件系統(tǒng)一樣，HDFS也將文件分割成block，每個block都作為一個獨立的單元分別保存。不同點在于，在HDFS中，小于block的文件不會占用一個block的空間。（比如，文件大小為1MB，那么它會占用一個HDFS的block，但是只使用底層磁盤1MB的空間，而不是128MB。）

2.11 HDFS的塊默認(rèn)大小，64M和128M是在哪個版本更換的?怎么修改默認(rèn)塊大小?

64M在1.x中，128M在2.x之后。塊的大小在hdfs-site.xml配置文件中dfs.block.size參數(shù)設(shè)置。

2.12 HDFS的block為什么是128M?增大或減小有什么影響?

（1）目的

保證數(shù)據(jù)的最佳傳輸損耗比

在一次傳輸中，尋址時間占用總傳輸時間的1%時，本次傳輸?shù)膿p耗最小，為最佳性價比傳輸

（2）原理

目前普通磁盤的寫速率大概為100M/s，尋址時間一般為10ms；

10ms/0.01=1s，可知傳輸時間為1s時，傳輸損耗比最佳

塊在傳輸時，每64K還需要校驗一次，因此塊的大小必須為2的n次方，最接近100M的就是128M

（3）其他場景

如果公司用的是寫速度為300M/S的固態(tài)硬盤，則塊的最佳大小為256M

如果公司用的是寫速度為500M/S的固態(tài)硬盤，則塊的最佳大小為512M

2.13 HDFS跨節(jié)點怎么進(jìn)行數(shù)據(jù)遷移

（1）考慮問題

• 數(shù)據(jù)量新老集群之間的網(wǎng)絡(luò)帶寬，滿載時是否會影響其他任務(wù)遷移過程中，哪些目錄會新增/刪除數(shù)據(jù)遷移后數(shù)據(jù)的一致性如何保證遷移后文件的權(quán)限如果保持一致
• 遷移方案數(shù)據(jù)量評估制定遷移節(jié)奏遷移時間選擇 新老集群之間網(wǎng)絡(luò)的硬件改造
• 工具

Distcp

2.14 HDFS的數(shù)據(jù)一致性靠什么保證?

HDFS會為這個文件生成一個校驗和，校驗和文件和文件本身保存在同一空間中。傳輸數(shù)據(jù)時會將數(shù)據(jù)與校驗數(shù)據(jù)和一同傳輸，應(yīng)用收到數(shù)據(jù)后可以進(jìn)行校驗，如果兩個校驗的結(jié)果不同，則文件肯定出錯了，這個數(shù)據(jù)塊就變成無效的。如果判定無效，則需要從其他DataNode上讀取副本重新傳輸。

2.15 HDFS怎么保證數(shù)據(jù)安全

• 副本策略

2.16寫的時候發(fā)現(xiàn)故障

（1）Client掛掉

拓展知識：Client向一個文件寫入數(shù)據(jù)前，需要向NN申請一個租約（lease），只有持有租約才可以寫，其他的Client只能讀。有l(wèi)ease的Client關(guān)閉寫操作的時候，NN會釋放相應(yīng)的租約。有時候Client拿到lease后宕機(jī)，無法關(guān)閉文件，導(dǎo)致租約無法歸還，所以，NN采用定時機(jī)制，Client需要在規(guī)定的時間內(nèi)續(xù)租。

當(dāng)Client掛了的時候無法續(xù)租，HDFS會釋放該文件的租約并關(guān)閉該文件，避免文件一直被占用，這個過程中如果文件副本存在數(shù)據(jù)不一致情況，會恢復(fù)到一致狀態(tài)。

（2）DataNode掛掉

a. 首先會關(guān)閉pipline；

b. 將已經(jīng)發(fā)送到管道中但是沒有收到確認(rèn)的數(shù)據(jù)包重新寫回數(shù)據(jù)隊列，這樣無論哪個節(jié)點發(fā)生故障，都不會發(fā)生數(shù)據(jù)丟失。這個過程是在確認(rèn)隊列中將未收到確認(rèn)的數(shù)據(jù)包刪除，寫回到數(shù)據(jù)隊列；

c. 然后當(dāng)前正常工作的數(shù)據(jù)節(jié)點將會被賦予一個新的版本號（利用NameNode中租約的信息可以獲得最新的時間戳版本），這樣故障節(jié)點恢復(fù)后由于版本信息不對，故障DataNode恢復(fù)后會被刪除；

d. 在當(dāng)前正常的DataNode中根據(jù)租約信息選擇一個主DataNode，并與其他正常DataNode通信，獲取每個DataNode當(dāng)前數(shù)據(jù)塊的大小，從中選擇一個最小值，將每個正常的DataNode同步到該大小。然后重新建立管道；

e. 在pipline中刪除故障節(jié)點，并把數(shù)據(jù)寫入pipline中剩下的正常的DataNode，即新的管道；

f. 當(dāng)文件關(guān)閉后，NameNode發(fā)現(xiàn)副本數(shù)量不足時會在另一個節(jié)點上創(chuàng)建一個新的副本。

2.17 NameNode存數(shù)據(jù)嗎

存，管理文件的命名空間，HDFS的元數(shù)據(jù)信息。

2.18 使用NameNode的好處

職能拆分，DN專門存放數(shù)據(jù)，NN統(tǒng)一管理這些數(shù)據(jù)。

2.19 HDFS中DataNode怎么存儲數(shù)據(jù)的

（1）工作機(jī)制

• 一個數(shù)據(jù)塊在DataNode上以文件形式存儲在磁盤上，包括兩個文件，一個是數(shù)據(jù)本身，一個是元數(shù)據(jù)包括數(shù)據(jù)塊的長度，塊數(shù)據(jù)的校驗和，以及時間戳；
• DataNode啟動后向NameNode注冊，通過后，周期性（1小時）的向NameNode上報所有的塊信息；
• 心跳是每3秒一次，心跳返回結(jié)果帶有NameNode給該DataNode的命令，如復(fù)制塊數(shù)據(jù)到另一臺機(jī)器，或刪除某個數(shù)據(jù)塊。如果超過10分鐘沒有收到某個DataNode的心跳，則認(rèn)為該節(jié)點不可用

（2）完整性

• 當(dāng) DataNode 讀取 block 的時候，它會計算 checksum。
• 如果計算后的 checksum，與 block 創(chuàng)建時值不一樣，說明 block 已經(jīng)損壞。
• client 讀取其他 DataNode 上的 block。
• DataNode 在其文件創(chuàng)建后周期驗證 checksum。

（3）掉線時限參數(shù)設(shè)置

DataNode 進(jìn)程死亡或者網(wǎng)絡(luò)故障造成 DataNode 無法與 NameNode 通信， NameNode 不會立即把該節(jié)點判定為死亡，要經(jīng)過一段時間，這段時間暫稱作超時時長。 HDFS 默認(rèn)的超時時長為 10 分鐘+30 秒。如果定義超時時間為 timeout，則超時時長的計算公式為：

timeout = 2 * dfs.NameNode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval

2.20 HDFS服役新節(jié)點

(1) 新機(jī)器基礎(chǔ)環(huán)境準(zhǔn)備

a. 主機(jī)名、IP

b. Hosts映射

c. 防火墻、時間同步

d. SSH免密登錄

e. JDK環(huán)境配置

(2) Hadoop配置

a. NameNode節(jié)點配置

(3) 手動啟動DataNode進(jìn)程

(4) Hadoop Web頁面查看

(5) DataNode負(fù)載均衡服務(wù)

2.21 HDFS退役舊節(jié)點

（1）添加退役節(jié)點

（2）刷新集群

（3）手動關(guān)閉DataNode進(jìn)程

（4）DataNode負(fù)載均衡服務(wù)

3.Yarn(此部分NM指NodeManager，并不是NameNode)

3.1 Yarn有幾個模塊

（1）ResourceManager

中控模塊，負(fù)責(zé)統(tǒng)一規(guī)劃資源的使用；

通過心跳感知NodeManager的資源使用情況。

（2）NodeManager

資源節(jié)點模塊，負(fù)責(zé)節(jié)點的資源管理、程序的運行；

負(fù)責(zé)啟動/停止Container。

（3）ApplicationMaster

Yarn中每一個應(yīng)用都會啟動一個AppMaster，負(fù)責(zé)向RM申請資源，請求NM啟動Container，并向Container發(fā)送任務(wù)；

與NameNode通信，啟動/停止任務(wù)；

監(jiān)控所有任務(wù)運行狀態(tài)，并在任務(wù)運行失敗時為任務(wù)重新申請資源。

（4）Container

資源容器，Yarn中所有應(yīng)用都是在Container上運行的，AppMaster也在上面運行，AM的Container是RM申請的。

3.2 Yarn工作機(jī)制

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

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

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

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

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

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

3.3 Yarn容錯機(jī)制

（1）ApplicationMaster容錯

RM監(jiān)控AM的運行狀態(tài)，一旦發(fā)現(xiàn)它運行失敗或者超時，就會重新分配資源并啟動它（AppMaster在作業(yè)運行過程中將狀態(tài)信息動態(tài)記錄到HDFS上，一旦出現(xiàn)故障重啟后，它能夠從HDFS讀取并恢復(fù)之前的運行狀態(tài)，減少重復(fù)計算帶來的開銷）。

（2）NodeManager容錯

NM超時沒有心跳，則RM認(rèn)為它死掉，會將上面的Container狀態(tài)置為失敗，并告訴對應(yīng)的ApplicationMaster，以決定如何處理這些Container中運行的任務(wù)。

（3）Container容錯

如果AM在一定時間內(nèi)未啟動分配到的Container，則RM會將該Container狀態(tài)置為失敗并回收它；

如果一個Container在運行過程中，因為外界原因?qū)е逻\行失敗，則RM會轉(zhuǎn)告對應(yīng)的AM,由AM決定如何處理。

（4）ResourceManager容錯

為了解決單點故障問題，Hadoop2.0中的HDFS和Yarn均采用了基于共享存儲的HA解決方案，即Active Master不斷將信息寫入到一個共享存儲系統(tǒng)，而Standby Master則不斷讀取這些信息，以與Active Master的內(nèi)存信息保持同步，當(dāng)需要主備切換時，選中的Standby Master需先保證信息完全同步后，再將自己的角色切換至Active Master

3.4 Yarn高可用

類似于HDFS高可用

3.5 Yarn調(diào)度器

（1）FIFO

先進(jìn)先出

同一時間隊列只有一個任務(wù)

（2）容量調(diào)度器

多隊列：每個隊列都FIFO

同一時間隊列中只有一個任務(wù)在執(zhí)行

隊列的并行度為隊列的個數(shù)

（3）公平調(diào)度器

多隊列：每個隊列內(nèi)部按照缺額大小分配資源啟動任務(wù)

同一時間隊列中有多個任務(wù)執(zhí)行

隊列的并行度大于等于隊列的個數(shù)

3.6 Yarn中Container是如何啟動的?

由ApplicaationMaster向NM發(fā)起請求，要求啟動Container，請求中攜帶了上下文信息，NM根據(jù)上下文信息構(gòu)建對應(yīng)的啟動腳本，啟動Container

4.MapperReduce

4.1 Map有哪些階段

（1）Read階段：MapTask通過InputFormat獲得的RecordReader，從輸入InputSplit中解析出一個個key-value；

（2）Map階段：該節(jié)點主要是將解析出的key-value交給用戶編寫map()函數(shù)處理，并產(chǎn)生一系列新的key-value；

（3）Collect收集階段：在用戶編寫map()函數(shù)中，當(dāng)數(shù)據(jù)處理完成后，一般會調(diào)用OutputCollector.collect()輸出結(jié)果。在該函數(shù)內(nèi)部，它會將生成的key/value分區(qū)（調(diào)用Partitioner），并寫入一個環(huán)形內(nèi)存緩沖區(qū)中；

（4）Spill階段：即“溢寫”，當(dāng)環(huán)形緩沖區(qū)滿后，MapReduce會將數(shù)據(jù)寫到本地磁盤上，生成一個臨時文件；

（5）Merge階段：當(dāng)所有數(shù)據(jù)處理完成后，MapTask對所有臨時文件進(jìn)行一次合并，以確保最終只會生成一個數(shù)據(jù)文件。

4.2 InputFormat數(shù)據(jù)輸入

（1）切片（每一片由一個MT處理）

• FileInputFormat切片

a. 初始化minSize，maxSize，默認(rèn)為1和Long型所表示最大值

b. 根據(jù)max(min, min(max, blockSize))獲取片大小

c. 循環(huán)遍歷文件列表

d. 根據(jù)NN元數(shù)據(jù)拿到DN文件數(shù)據(jù)

e. 判斷文件是否能切分（大多數(shù)壓縮文件不能切分）

f. 循環(huán)判斷剩余文件大小是否大于片大小的1.1倍，是的話切片

g. 將最后不足片大小1.1倍的剩余文件單獨作為一個片

• CombineTextInputFormat切片機(jī)制

a. 逐個掃描文件大小，與setMaxInputSplitSize對比

b. >=預(yù)設(shè)值2倍的，直接切片（大小為預(yù)設(shè)值），剩余部分繼續(xù)對比

c. >預(yù)設(shè)值但<預(yù)設(shè)值2倍的平均分為兩塊

d. <=預(yù)設(shè)值的獨自為一塊

e. 最終掃描合并塊，使所有塊趨于預(yù)設(shè)值大小

4.3 Job提交過程

（1）建立連接

（2）提交Job

a. 創(chuàng)建給集群提交數(shù)據(jù)的Stag路徑

b. 獲取JobID，并創(chuàng)建Job路徑

c. 拷貝jar包到集群

d. 計算切片，生成切片規(guī)劃文件

e. 向Stag路徑寫XML配置文件

f. 提交Job，返回提交狀態(tài)

4.4 MapReduce中的Combine是干嘛的?有什么好外?

實現(xiàn)本地key的聚合，對map輸出的key進(jìn)行排序，value進(jìn)行迭代

類似于本地reduce的功能，例如wccon例子，combiner輸出與reduce一樣

4.5 mapjoin的原理(實現(xiàn))?應(yīng)用場景?

原理：小表加載到內(nèi)存中，遍歷大表

使用場景：大小表join

4.6 Map數(shù)量由什么決定

一個Job的Map階段并行度由客戶端在提交Job時的切片樹決定，每一個Split切片分配一個MapTask并行實例處理，控制maptask的個數(shù)的話，我們只需要調(diào)整maxSize和minsize這兩個值，那么切片的大小就會改變，切片大小改變之后，mapTask的個數(shù)就會改變。

4.7 map輸出的數(shù)據(jù)如何超出它的小文件內(nèi)存之后，是落地到磁盤還是落地到HDFS中?

磁盤

4.8 介紹下Combiner

combiner是Mapper、Reduce之外的組件，父類是Reduce，在每一個MT所在的節(jié)點運行，Reduce是接收全局所有Mapper的輸出結(jié)果，對每一個MT輸出結(jié)果進(jìn)行局部匯總，減小網(wǎng)絡(luò)傳輸量，能夠應(yīng)用的前提是不影響最終業(yè)務(wù)邏輯。

4.9 MapReduce通過哪個中間組件去存儲數(shù)據(jù)

環(huán)形緩沖區(qū)

4.10 mr在shuffle時溢寫為什么是在環(huán)形緩沖區(qū)？

環(huán)形緩沖區(qū)可以朝著一個方向讀寫并行，效率高，并且不會產(chǎn)生碎片。

4.11 為什么不是寫滿再寫出

剩下20%留作緩沖以保證讀寫能夠并行進(jìn)行而不會阻塞

4.12 MapReduce為什么一定要有Shuffle過程

不同的Map可能輸出相同的key，相同的key必須發(fā)送到同一個Reduce端處理，因此需要Shuffle進(jìn)行排序分區(qū)

4.13 MapReduce的Shuffle過程及其優(yōu)化

（1）過程

a. MT將<k, v>寫入環(huán)形緩沖區(qū)（默認(rèn)100M）

b. <k, v>在緩沖區(qū)內(nèi)將被分區(qū)，分區(qū)數(shù)量在提交map時已經(jīng)設(shè)置，分區(qū)號從0開始。

c. 默認(rèn)環(huán)形緩沖區(qū)占用達(dá)到80%時，數(shù)據(jù)通過快速排序進(jìn)行一次排序（區(qū)內(nèi)），開始向磁盤溢寫，低于80%后停止溢寫；

d. 每次溢寫生成一個文件

e. 當(dāng)MT結(jié)束時，所有的溢寫文件將會被歸并排序合稱為一個文件（區(qū)內(nèi)有序）

f. 如果開啟Combiner的話，文件內(nèi)的<k, v>將會初步合并以減小文件大小

g. RT拷貝MT產(chǎn)生的文件，N個分區(qū)將有N個RT，每個RT只拷貝自己分區(qū)的<k, v>，如果內(nèi)存不夠則溢寫到磁盤；

h. 拷貝結(jié)束后，MT產(chǎn)生的文件將被刪除

i. RT將不同MT拷貝來的<k, v>進(jìn)行歸并排序

j. 排序完，RT將<k, v>進(jìn)行分組，并調(diào)用reduce（）

k. 接下來reduce()寫文件屬于OutPutFormat負(fù)責(zé)，不屬于Shuttle

（2）優(yōu)化

a. 減少merge次數(shù)

b. 擴(kuò)大溢寫的閾值

c. 擴(kuò)大環(huán)形緩沖區(qū)的大小

d. 不影響業(yè)務(wù)的情況下，添加Combiner階段

4.14 shuffle為什么要排序?

map端：map端排序是為了減輕reduce端排序的壓力

reduce端：reduce端需要對數(shù)據(jù)進(jìn)行分組，將key相同的放在一起規(guī)約

4.15 MapReduce Shuffle的排序算法

環(huán)形緩沖區(qū)內(nèi)部排序用的快速排序算法

合并文件時用的是歸并排序算法

4.16 Reduce怎么知道去哪里拉Map結(jié)果集?

map任務(wù)成功后，它們會使用心跳機(jī)制通知它們的AM。因此，對于指定作業(yè)，AM知道m(xù)ap輸出和主機(jī)位置之間的映射關(guān)系。reduce中的一個線程定期詢問master以便于獲取map輸出主機(jī)的位置，直到獲得所有輸出位置。

由于第一個reducer可能失敗，因此主機(jī)并沒有在第一個reducer檢索到map輸出時就立即從磁盤上刪除它們。

4.17 Reduce階段都發(fā)生了什么

（1）Copy階段：ReduceTask從各個MapTask上遠(yuǎn)程拷貝一片數(shù)據(jù)，并針對某一片數(shù)據(jù)，如果其大小超過一定閾值，則寫到磁盤上，否則直接放到內(nèi)存中

（2）Merge階段：在遠(yuǎn)程拷貝數(shù)據(jù)的同時，ReduceTask啟動了兩個后臺線程對內(nèi)存和磁盤上的文件進(jìn)行合并，以防止內(nèi)存使用過多或磁盤上文件過多

（3）Sort階段：按照MapReduce語義，用戶編寫reduce()函數(shù)輸入數(shù)據(jù)是按key進(jìn)行聚集的一組數(shù)據(jù)

（4）Reduce階段：reduce()函數(shù)將計算結(jié)果寫到HDFS上

4.18 reducejoin如何執(zhí)行(原理)

Map端的主要工作：為來自不同表或者文件的key/value對打標(biāo)簽，以區(qū)別不同來源的記錄。然后用連接字段作為key，其余部分和新加的標(biāo)記作為value，最后輸出

Reduce端的主要工作：在Reduce端以連接字段作為key的分組已經(jīng)完成，我們只需要在每一個分組中將那些來源于不同文件的記錄分開，最后進(jìn)行合并就OK了

缺點：這種方式中， 合并的操作是在Reduce階段完成的，Reduce端的處理壓力太大，Map節(jié)點的運算負(fù)載則很低，資源的利用率不夠，且在Reduce階段及易產(chǎn)生數(shù)據(jù)傾斜問題。

4.19 ReduceTask數(shù)量和分區(qū)數(shù)量關(guān)系

ReduceTask的數(shù)量 > getPartition ==> 產(chǎn)生空文件

ReduceTask的數(shù)量 < getPartition ==> 報錯

reduceTask = 1 ==> 產(chǎn)生一個結(jié)果文件

4.20 reduce任務(wù)什么時候開始?

在mapred-site.xml中有個參數(shù)可以調(diào)整什么時候開始執(zhí)行reduce操作,mapred.reduce.slowstart.completed.maps ,默認(rèn)值是0.95，即在mapper執(zhí)行完95%時開始執(zhí)行reduce操作，我們可以根據(jù)自己的需要調(diào)整，0.0到1.00之間。

4.21 Map到Reduce默認(rèn)的分區(qū)機(jī)制是什么?

對map的key取hash，然后對reduce個數(shù)（默認(rèn)為1）取模

4.22 介紹下MapReduce

MapReduce 是一個分布式運算程序的編程框架，它的核心功能是將用戶編寫的業(yè)務(wù)邏輯代碼和自帶默認(rèn)組件整合成一個完整的分布式運算程序，并發(fā)運行在一個 Hadoop 集群上。

MapReduce的核心思想是將用戶編寫的邏輯代碼和架構(gòu)中的各個組件整合成一個分布式運算程序，實現(xiàn)一定程序的并行處理海量數(shù)據(jù)，提高效率。

4.23 HDFS的mapper和reducer的個數(shù)如何確定?

（1）Mapper個數(shù)

mapper的個數(shù)是由輸入數(shù)據(jù)的大小決定的，每個Mapper Tasker對應(yīng)一個split；

（2）reducer個數(shù)

分區(qū)號計算：(key.hashCode() & Integer.MAX_VALUE) % numReduceTasks，每一個分區(qū)對應(yīng)一個reducer。

numReduceTasks默認(rèn)為1，可以自定義，程序會自己算分區(qū)數(shù)；

同時也可以自定義分區(qū)器來控制分區(qū)數(shù)，但如果此時指定的reducer個數(shù)大于1，小于分區(qū)數(shù)，則會報錯；大于分區(qū)數(shù)則會產(chǎn)生空文件；設(shè)置為1，則會交給一個reducer。

官方建議：0.95或者1.75 *（節(jié)點數(shù) ×mapred.tasktracker.tasks.maximum參數(shù)值）

4.24 MapReduce優(yōu)缺點

（1）優(yōu)點

易于編程：它簡單的實現(xiàn)一些接口，就可以完成一個分布式程序，這個分布式程序可以分布到大量廉價的PC機(jī)器上運行。也就是說你寫一個分布式程序，跟寫一個簡單的串行程序是一模一樣的。

良好的擴(kuò)展性：計算資源不能得到滿足的時候，你可以通過簡單的增加機(jī)器來擴(kuò)展它的計算能力。

高容錯性：MapReduce設(shè)計的初衷就是使程序能夠部署在廉價的PC機(jī)器上，這就要求它具有很高的容錯性。比如其中一臺機(jī)器掛了，它可以把上面的計算任務(wù)轉(zhuǎn)移到另外一個節(jié)點上運行，不至于這個任務(wù)運行失敗，而且這個過程不需要人工參與，而完全是由Hadoop內(nèi)部完成的。

適合大數(shù)據(jù)量離線處理。

（2）缺點

• 不擅長實時計算
• 不擅長流式計算

流式計算的輸入數(shù)據(jù)是動態(tài)的，而MapReduce的輸入數(shù)據(jù)集是靜態(tài)的，不能動態(tài)變化。這是因為MapReduce自身的設(shè)計特點決定了數(shù)據(jù)源必須是靜態(tài)的；

• 不擅長DAG計算

多個應(yīng)用程序存在依賴關(guān)系，后一個應(yīng)用程序的輸入為前一個的輸出。在這種情況下，MapReduce并不是不能做，而是使用后，每個MapReduce作業(yè)的輸出結(jié)果都會寫入到磁盤，會造成大量的磁盤IO，導(dǎo)致性能非常的低下

4.25 MapReduce架構(gòu)

（1）client客戶端

每一個Job都會在用戶端通過Client類將應(yīng)用程序以及參數(shù)配置Configuration打包成Jar文件存儲在HDFS，并把路徑提交到JobTracker的master服務(wù)，然后由master創(chuàng)建每一個Task（即MapTask和ReduceTask），將它們分發(fā)到各個TaskTracker服務(wù)中去執(zhí)行。

（2）JobTracker

JobTracker負(fù)責(zé)資源監(jiān)控和作業(yè)調(diào)度。JobTracker監(jiān)控所有的TaskTracker與job的健康狀況，一旦發(fā)現(xiàn)失敗，就將相應(yīng)的任務(wù)轉(zhuǎn)移到其它節(jié)點；同時JobTracker會跟蹤任務(wù)的執(zhí)行進(jìn)度，資源使用量等信息，并將這些信息告訴任務(wù)調(diào)度器，而調(diào)度器會在資源出現(xiàn)空閑時，選擇合適的任務(wù)使用這些資源。

（3）TaskTracker

TaskTracker會周期性地通過HeartBeat將本節(jié)點上資源的使用情況和任務(wù)的運行進(jìn)度匯報給JobTracker，同時執(zhí)行JobTracker發(fā)送過來的命令 并執(zhí)行相應(yīng)的操作（如啟動新任務(wù)，殺死任務(wù)等）。

（4）Task

分為MapTask和Reduce Task兩種，均由TaskTracker啟動。HDFS以固定大小的block為基本單位存儲數(shù)據(jù)，而對于MapReduce而言，其處理單位是split。split是一個邏輯概念，它只包含一些元數(shù)據(jù)信息，比如數(shù)據(jù)起始位置、數(shù)據(jù)長度、數(shù)據(jù)所在節(jié)點等。它的劃分方法完全由用戶自己決定。但需要注意的是，split的多少決定了MapTask的數(shù)目，因為每一個split只會交給一個MapTask處理。

4.26 MapReduce哪個階段最費時間

溢寫階段，因為會發(fā)生多次I/O

4.27 MapReduce為什么不能產(chǎn)生過多小文件

• 原因

HDFS 上每個文件都要在 NameNode 上創(chuàng)建對應(yīng)的元數(shù)據(jù)，這個元數(shù)據(jù)的大小約為150byte，當(dāng)小文件比較多的時候，就會產(chǎn)生很多的元數(shù)據(jù)文件，一方面會大量占用NameNode 的內(nèi)存空間，另一方面就是元數(shù)據(jù)文件過多，使得尋址索引速度變慢；

小文件過多，在進(jìn)行 MR 計算時，會生成過多切片，需要啟動過多個 MapTask。每個MapTask 處理的數(shù)據(jù)量小，導(dǎo)致 MapTask 的處理時間比啟動時間還小，白白消耗資源。

• 優(yōu)化

在數(shù)據(jù)采集的時候，就將小文件或小批數(shù)據(jù)合成大文件再上傳 HDFS；

在業(yè)務(wù)處理之前，在 HDFS 上使用 MapReduce 程序?qū)π∥募M(jìn)行合并；

在 MapReduce 處理時，可采用 CombineTextInputFormat 提高效率；

開啟 uber 模式，實現(xiàn) jvm 重用；

使用SequenceFile二進(jìn)制格式文件。

4.28 MapReduce的reduce使用的是什么排序?

歸并排序

4.29 MapReduce中的ivm垃圾回收器怎么選擇可以提高吞吐量?

開啟JVM重用，即同一個JVM可以被該作業(yè)的所有任務(wù)使用，主要針對小文件情況

4.30 MapReduce數(shù)據(jù)傾斜產(chǎn)生的原因及其解決方案

原因：

k-v分布不均

機(jī)器配置不合理

業(yè)務(wù)數(shù)據(jù)自身特性

場景以及解決：

4.31 MapReduce運行過程中會發(fā)生OOM，OOM發(fā)生的位置？

Map階段：幾率很小

Reduce階段：數(shù)據(jù)傾斜，value對象過多或者過大

解決：

??增加reduce個數(shù)

??調(diào)大reduce內(nèi)存，然后設(shè)置垃圾回收器為并行標(biāo)記回收器，但會加大cpu負(fù)擔(dān)

??使用map join代替common join

Driver提交：job產(chǎn)生的執(zhí)行條目太多，掃描分區(qū)過多

解決：

??盡量少掃描同一張表，盡量少掃描分區(qū)

1. 調(diào)優(yōu)

5.1 MR跑得慢

• 計算機(jī)性能
• I/O操作優(yōu)化數(shù)據(jù)傾斜Map和Reduce數(shù)量設(shè)置不合理
• Map運行時間過長小文件過多大量不可切片的超大壓縮文件
• Spill次數(shù)過多
• Merge次數(shù)過多

5.2 MR調(diào)優(yōu)

• 數(shù)據(jù)輸入合并小文件CombineTextInputFormat來作為輸入
• Map階段減小Spill次數(shù)減少Merge次數(shù)不影響業(yè)務(wù)的前提下，Map后添加Combiner
• Reduce階段合理設(shè)置Reduce數(shù)量設(shè)置Map、Reduce共存規(guī)避適用Reduce階段合理使用Reduce端的Buffer，減少寫磁盤次數(shù)
• I/O傳輸采用數(shù)據(jù)壓縮使用SequenceFile二進(jìn)制文件
• 數(shù)據(jù)傾斜問題見上方
• Hadoop小文件優(yōu)化數(shù)據(jù)采集前合并小文件業(yè)務(wù)處理前，在HDFS上通過MR合并小文件在MR處理時，采用CombineTextInputFormat提高效率開啟uber模式，實現(xiàn)jvm重用Hadoop Archive：能夠高效將小文件放入HDFS，并將多個小文件打包為一個HAR文件，從而減少NN的內(nèi)存使用使用SequenceFile二進(jìn)制格式文件