文章目錄
面向面試的博客，以問答式Q/A方式呈現。
Question1：簡要介紹一下 Hadoop ？
Answer1：
Hadoop是一個大數據解決方案，它提供了一套分佈式系統基礎架構，其核心內容包含 hdfs 和mapreduce（附：hadoop2.0 引入 yarn，目前穩定可用版本已到Hadoop3.0）。
hdfs 是用於提供數據存儲的，mapreduce 是用於方便數據計算的。
- hdfs 又對應 namenode 和 datanode，其中，namenode 負責保存元數據的基本信息，datanode 直接存放數據本身；
- mapreduce 對應 jobtracker 和 tasktracker，其中，jobtracker 負責分發任務，tasktracker 負責執行具體任務；
- 對應到 master/slave 架構，namenode 和 jobtracker 就應該對應到 master, datanode和 tasktracker 就應該對應到 slave。無論是hdfs 還是 mapreduce ,主從節點之間的都是通過heartbeat心跳來確認存活的。
Question2：簡要介紹一下 HDFS ？
Answer2：
HDFS 架構圖，如下圖所示：
HDFS中，NameNode 和 Secondary NameNode 是Master，所有的 Datanode 是Slave。
1、Client
Client（代表用戶） 通過與 NameNode 和 DataNode 交互訪問 HDFS 中 的文件。 Client 提供了一個類似 POSIX 的文件系統接口供用戶調用。
2、NameNode
功能：負責管理 HDFS 的目錄樹和相關的文件元數據信息。
整個 Hadoop 集羣中只有一個 NameNode。 它是整個系統的“ 總管”， 負責管理 HDFS 的目錄樹和相關的文件元數據信息。 這些信息是以“ fsimage”（ HDFS 元數據鏡像文件）和“editlog”（HDFS 文件改動日誌）兩個文件形式存放在本地磁盤，當 HDFS 重啓時重新構造出來的。此外， NameNode 還負責監控各個 DataNode 的健康狀態， 一旦發現某個 DataNode 宕掉，則將該 DataNode 移出 HDFS 並重新備份其上面的數據。
3、Secondary NameNode
功能：定期合併fsimage 和 edits 日誌， 並傳輸給 NameNode。
Secondary NameNode 最重要的任務並不是爲 NameNode 元數據進行熱備份， 而是定期合併fsimage 和 edits 日誌， 並傳輸給 NameNode。 這裏需要注意的是，爲了減小 NameNode 壓力， NameNode 自己並不會合併 fsimage 和 edits， 並將文件存儲到磁盤上， 而是交由Secondary NameNode 完成。
4、DataNode
功能：負責實際的數據存儲， 並將數據信息定期彙報給 NameNode。
一般而言， 每個 Slave 節點上安裝一個 DataNode， 它負責實際的數據存儲， 並將數據信息定期彙報給 NameNode。 DataNode 以固定大小的 block 爲基本單位組織文件內容， 默認情況下block 大小爲 64MB。 當用戶上傳一個大的文件到 HDFS 上時， 該文件會被切分成若干個 block，分別存儲到不同的 DataNode ； 同時，爲了保證數據可靠， 會將同一個 block 以流水線方式寫到若干個（默認是 3，該參數可配置）不同的 DataNode 上。 這種文件切割後存儲的過程是對用戶透明的。
Question3：簡要介紹一下 MapReduce ？
Answer3：
Hadoop MapReduce 採用了 Master/Slave（M/S）架構，具體如圖所示。
Map Reduce中，JobTracker 是Master，所有的 TaskTracker 是Slave。
MapReduce主要由以下幾個組件組成：Client、JobTracker、TaskTracker 和 Task。 下面分別對這幾個組件進行介紹。
1、Client
用戶編寫的 MapReduce 程序通過 Client 提交到 JobTracker 端； 同時， 用戶可通過 Client 提供的一些接口查看作業運行狀態。
在 Hadoop 內部用“作業”（Job） 表示 MapReduce 程序。一個 MapReduce 程序可對應若干個作業（Job），而每個作業（Job）會被分解成若干個 Map/Reduce 任務（Task）。
2、JobTracker
JobTracker 主要負責資源監控和作業調度。JobTracker 監控所有 TaskTracker 與作業的健康狀況，一旦發現失敗情況後，其會將相應的任務轉移到其他節點；同時 JobTracker 會跟蹤任務的執行進度、資源使用量等信息，並將這些信息告訴任務調度器，而調度器會在資源出現空閒時，選擇合適的任務使用這些資源。
在 Hadoop 中，任務調度器是一個可插拔的模塊，用戶可以根據自己的需要設計相應的調度器。
3、TaskTracker
TaskTracker 會週期性地通過 Heartbeat 將本節點上資源的使用情況和任務的運行進度彙報給 JobTracker， 同時接收 JobTracker 發送過來的命令並執行相應的操作（如啓動新任務、 殺死任務等）。
TaskTracker 使用“slot” 等量劃分本節點上的資源量。“slot” 代表計算資源（CPU、內存等）。一個 任務Task 獲取到一個 slot 後纔有機會運行，而 Hadoop 調度器的作用就是將各個TaskTracker 上的空閒 slot 分配給 Task 使用。 slot 分爲 Map slot 和 Reduce slot 兩種，分別供MapTask 和 Reduce Task 使用。
這樣一來，TaskTracker 通過 slot 數目（可配置參數）限定 Task 的併發度。
4、Task
Task 分爲 Map Task 和 Reduce Task 兩種， 均由 TaskTracker 啓動。
相對於 HDFS 以固定大小的 block 爲基本單位存儲數據， MapReduce 的其處理單位是 split。split 是一個邏輯概念， 它只包含一些元數據信息， 比如數據起始位置、數據長度、數據所在節點等。它的劃分方法完全由用戶自己決定。
但需要注意的是，split 的多少決定了 Map Task 的數目 ，因爲每個 split 會交由一個 Map Task 處理。
5、Map Task 執行過程
Map Task 執行過程如圖所示：
由該圖可知，Map Task 先將對應的 split 迭代解析成一個個key/value 對，依次調用用戶自定義的 map() 函數進行處理，然後臨時數據被分成若干個 partition（每個 partition 將被一個 Reduce Task 處理），最終將臨時結果存放到本地磁盤上。
6、Reduce Task 執行過程
上面的Map Task執行流程圖中，中間一個步驟是臨時數據被分成若干個 partition，其實，每個 partition 將被一個 Reduce Task 處理，那麼 Reduce Task 是如何處理的呢？
Reduce Task 執行過程分爲三個階段：
- 從遠程節點上讀取 MapTask 中間結果（稱爲“Shuffle 階段”）；
- 按照 key 對 key/value 對進行排序（稱爲“ Sort 階段”）；
- 依次讀取<key, value list>，調用用戶自定義的 reduce() 函數處理，並將最終結果存到 HDFS 上（稱爲“ Reduce 階段”）。
Question4：談一談 Hadoop MapReduce 作業的生命週期 ？
Answer4：
步驟一：作業提交與初始化
作業提交：用戶提交作業（即Job）後， 首先由 JobClient 實例將作業相關信息， 比如將程序 jar 包、作業配置文件、 分片元信息文件等上傳到分佈式文件系統（ 一般爲 HDFS）上，其中，分片元信息文件記錄了每個輸入分片的邏輯位置信息。 然後 JobClient 通過 RPC （即Romote Procedure Call,遠程過程調用）通知 JobTracker。
作業初始化：JobTracker 收到新作業提交請求後， 由作業調度模塊對作業進行初始化：爲作業創建一個 JobInProgress 對象以跟蹤作業運行狀況， 而 JobInProgress 則會爲每個 Task 創建一個 TaskInProgress 對象以跟蹤每個任務的運行狀態， TaskInProgress 可能需要管理多個“ Task 運行嘗試”（ 稱爲“ Task Attempt”）。
步驟二：任務調度與監控
由於任務調度和監控的功能均由 JobTracker 完成，TaskTracker 週期性地通過Heartbeat 向 JobTracker 彙報本節點的資源使用情況， 一旦出現空閒資源， JobTracker會按照一定的策略選擇一個合適的任務使用該空閒資源， 這由任務調度器完成。 任務調度器是一個可插拔的獨立模塊， 且爲雙層架構， 即首先選擇作業（即Job）， 然後從該作業（Job）中選擇任務（即Task）， 其中，選擇任務時需要重點考慮數據本地性。
此外，JobTracker 跟蹤作業的整個運行過程，併爲作業的成功運行提供全方位的保障。 首先， 當 TaskTracker 或者 Task 失敗時， 轉移計算任務 ； 其次， 當某個 Task 執行進度遠落後於同一作業的其他 Task 時，爲之啓動一個相同Task， 並選取計算快的 Task 結果作爲最終結果。
步驟三：任務運行環境準備
運行環境準備包括 JVM 啓動和資源隔離，均由 TaskTracker 實現。
JVM啓動：TaskTracker 爲每個Task 啓動一個獨立的 JVM 以避免不同 Task 在運行過程中相互影響 ；
資源隔離：TaskTracker 使用了操作系統進程實現資源隔離以防止 Task 濫用資源。
步驟四：任務執行
TaskTracker 爲 Task 準備好運行環境後， 便會啓動 Task。 在運行過程中， 每個 Task 的最新進度首先由 Task 通過 RPC 彙報給 TaskTracker， 再由 TaskTracker 彙報給 JobTracker。
步驟五：作業完成
待所有 Task 執行完畢後， 整個作業（即Job）執行成功。
Question5：簡要介紹一下 Yarn ？
Answer5：
YARN 是一個資源管理、任務調度的框架，主要包含三大模塊ResourceManager（RM）、NodeManager（NM）、ApplicationMaster（AM）。其中，ResourceManager 負責所有資源的監控、分配和管理；NodeManager 負責每一個節點的維護；ApplicationMaster 負責每一個具體應用程序的調度和協調。
對於所有的 applications，RM 擁有絕對的控制權和對資源的分配權。而每個 AM 則會和 RM 協商資源，同時和 NodeManager 通信來執行和監控 task。
幾個模塊之間的關係如圖所示。
對於上圖的解釋：
圖中左邊兩個Client客戶實例請求，一個紅色一個藍色。
第一條線MapReduce Status表示傳遞當前的MapReduce的狀態，每個應用程序都包含一個主節點AM，由於圖中表示兩個應用程序正在被處理，三個紅色的Container容器都將自己正在處理的MapReduce的狀態傳遞給紅色的AM應用程序主節點，藍色的Container容器也是將當前的MapReduce的狀態傳遞給藍色的AM應用程序主節點。
第二條線Job Submission表示作業提交，就是指左邊兩個Client將作業提交給RM。
第三條線Node Status表示節點狀態，NodeManager 負責每一個節點的維護，三個NodeManager將節點狀態信息提交給RM全局資源管理器。
第四條線Resource Request表示做出資源請求動作，圖中是兩個AM爲自己的應用程序對RM做出資源請求。
問題1：AM和NM是否存在包含、並列或其他關係？
回答1：AM和NM不存在任何關係，AM對應的是應用程序，一個應用程序包含一個AM，NM對應的是Yarn內部節點，一個內部節點需要一個NM來維護。
問題2：AM與RM的關係？NM與RM的關係？
回答2：因爲AM對應的是一個應用程序，所以自然會向RM發出Resource Request資源請求，爲應用程序請求資源；因爲NM對應的是一個內部節點，所以自然會向RM彙報Node Status節點狀態信息。
ResourceManager 模塊
- RM含義：ResourceManager 負責整個集羣的資源管理和分配，是一個全局的資源管理系統。
- RM與NM：NodeManager 以心跳的方式向 ResourceManager 彙報資源使用情況（目前主要是 CPU 和內存的使用情況）。RM 只接受 NM 的資源回報信息，對於具體的資源處理則交給 NM 自己處理。
- RM與AM：YARN Scheduler 根據 application 的請求爲其分配資源，不負責 application job 的監控、追蹤、運行狀態反饋、啓動等工作。
NodeManager 模塊
- NM含義：NodeManager 是每個節點上的資源和任務管理器，它是管理這臺機器的代理，負責該節點程序的運行，以及該節點資源的管理和監控。YARN集羣每個節點都運行一個NodeManager。
- NM與RM：NodeManager 定時向 ResourceManager 彙報本節點資源（CPU、內存）的使用情況和Container 的運行狀態。當 ResourceManager 宕機時 NodeManager 自動連接 RM 備用節點。
- NM與AM：NodeManager 接收並處理來自 ApplicationMaster 的 Container 啓動、停止等各種請求。
ApplicationMaster 模塊
- AM含義：用戶提交的每個應用程序均包含一個ApplicationMaster，它可以運行在ResourceManager以外的機器上。
- AM與RM：負責與 RM 調度器協商以獲取資源（用 Container 表示）。
- AM與NM：與 NM 通信以啓動/停止任務。
- AM與任務Task：將得到的任務進一步分配給內部的任務(資源的二次分配)。
- AM與任務Task：監控所有任務運行狀態，並在任務運行失敗時重新爲任務申請資源以重啓任務。
注：RM 只負責監控 AM，並在 AM 運行失敗時候啓動它。RM 不負責 AM 內部任務的容錯，任務的容錯由 AM 完成。
Question6：介紹一下 YARN 運行流程 ？
Answer6：
- client 向 RM 提交應用程序，其中包括啓動該應用的 ApplicationMaster 的必須信息，例如ApplicationMaster 程序、啓動 ApplicationMaster 的命令、用戶程序等。
- ResourceManager 啓動一個 container 用於運行 ApplicationMaster。
- 啓動中的ApplicationMaster向ResourceManager註冊自己，啓動成功後與RM保持心跳。
- ApplicationMaster 向 ResourceManager 發送請求，申請相應數目的 container。
- ResourceManager 返回 ApplicationMaster 的申請的 containers 信息。申請成功的
container，由 ApplicationMaster 進行初始化。container 的啓動信息初始化後，AM 與對應的 NodeManager 通信，要求 NM 啓動 container。AM 與 NM 保持心跳，從而對 NM 上運行的任務進行監控和管理。 - container 運行期間，ApplicationMaster 對 container 進行監控。container 通過 RPC 協議向對應的 AM 彙報自己的進度和狀態等信息。
- 應用運行期間，client 直接與 AM 通信獲取應用的狀態、進度更新等信息。
- 應用運行結束後，ApplicationMaster 向 ResourceManager 註銷自己，並允許屬於它的container 被收回。
Question7：簡要闡述一下 Hadoop2 與 Hadoop3 的區別 ？
Answer7：
hadoop2.X 與 hadoop3.X 的 22 條區別，如下：
1.License
adoop 2.x - Apache 2.0，開源
Hadoop 3.x - Apache 2.0，開源
2.支持的最低Java版本
Hadoop 2.x - java的最低支持版本是java 7
Hadoop 3.x - java的最低支持版本是java 8
3.容錯
Hadoop 2.x - 可以通過複製（浪費空間）來處理容錯。
Hadoop 3.x - 可以通過Erasure編碼處理容錯。
4.數據平衡
Hadoop 2.x - 對於數據，平衡使用HDFS平衡器。
Hadoop 3.x - 對於數據，平衡使用Intra-data節點平衡器，該平衡器通過HDFS磁盤平衡器CLI調用。
5.存儲Scheme
Hadoop 2.x - 使用3X副本Scheme
Hadoop 3.x - 支持HDFS中的擦除編碼。
6.存儲開銷
Hadoop 2.x - HDFS在存儲空間中有200％的開銷。
Hadoop 3.x - 存儲開銷僅爲50％。
7.存儲開銷示例
Hadoop 2.x - 如果有6個塊，那麼由於副本方案（Scheme），將有18個塊佔用空間。
Hadoop 3.x - 如果有6個塊，那麼將有9個塊空間，6塊block，3塊用於奇偶校驗。
8.YARN時間線服務
Hadoop 2.x - 使用具有可伸縮性問題的舊時間軸服務。
Hadoop 3.x - 改進時間線服務v2並提高時間線服務的可擴展性和可靠性。
9.默認端口範圍
Hadoop 2.x - 在Hadoop 2.0中，一些默認端口是Linux臨時端口範圍。所以在啓動時，他們將無法綁定。
Hadoop 3.x - 但是在Hadoop 3.0中，這些端口已經移出了短暫的範圍。
10.工具
Hadoop 2.x - 使用Hive，pig，Tez，Hama，Giraph和其他Hadoop工具。
Hadoop 3.x - 可以使用Hive，pig，Tez，Hama，Giraph和其他Hadoop工具。
11.兼容的文件系統
Hadoop 2.x - HDFS（默認FS），FTP文件系統：它將所有數據存儲在可遠程訪問的FTP服務器上。 Amazon S3（簡單存儲服務）文件系統Windows Azure存儲Blob（WASB）文件系統。
Hadoop 3.x - 它支持所有前面以及Microsoft Azure Data Lake文件系統。
12.Datanode資源
Hadoop 2.x - Datanode資源不專用於MapReduce，我們可以將它用於其他應用程序。
Hadoop 3.x - 此處數據節點資源也可用於其他應用程序。
13.MR API兼容性
Hadoop 2.x - 與Hadoop 1.x程序兼容的MR API，可在Hadoop 2.X上執行
Hadoop 3.x - 此處，MR API與運行Hadoop 1.x程序兼容，以便在Hadoop 3.X上執行
14.支持Microsoft Windows
Hadoop 2.x - 它可以部署在Windows上。
Hadoop 3.x - 它也支持Microsoft Windows。
15.插槽/容器
Hadoop 2.x - Hadoop 1適用於插槽的概念，但Hadoop 2.X適用於容器的概念。通過容器，我們可以運行通用任務。
Hadoop 3.x - 它也適用於容器的概念。
16.單點故障
Hadoop 2.x - 具有SPOF的功能，因此只要Namenode失敗，它就會自動恢復。
Hadoop 3.x - 具有SPOF的功能，因此只要Namenode失敗，它就會自動恢復，無需人工干預就可以克服它。
17.HDFS聯盟
Hadoop 2.x - 在Hadoop 1.0中，只有一個NameNode來管理所有Namespace，但在Hadoop 2.0中，多個NameNode用於多個Namespace。
Hadoop 3.x - Hadoop 3.x還有多個名稱空間用於多個名稱空間。
18.可擴展性
Hadoop 2.x - 我們可以擴展到每個羣集10,000個節點。
Hadoop 3.x - 更好的可擴展性。 我們可以爲每個羣集擴展超過10,000個節點。
19.更快地訪問數據
Hadoop 2.x - 由於數據節點緩存，我們可以快速訪問數據。
Hadoop 3.x - 這裏也通過Datanode緩存我們可以快速訪問數據。
20.HDFS快照
Hadoop 2.x - Hadoop 2增加了對快照的支持。 它爲用戶錯誤提供災難恢復和保護。
Hadoop 3.x - Hadoop 2也支持快照功能。
21.平臺
Hadoop 2.x - 可以作爲各種數據分析的平臺，可以運行事件處理，流媒體和實時操作。
Hadoop 3.x - 這裏也可以在YARN的頂部運行事件處理，流媒體和實時操作。
22.羣集資源管理
Hadoop 2.x - 對於羣集資源管理，它使用YARN。 它提高了可擴展性，高可用性，多租戶。
Hadoop 3.x - 對於集羣，資源管理使用具有所有功能的YARN。
