1. hadoop1.0 和 hadoop2.0區別
1.1 hadoop1.0
1.1.1 HDFS
對HDFS來說，其主要的運行架構則是master-slave架構，即主從架構。其中呢，master主節點稱之爲Namenode節點，而slave從節點稱爲DataNode節點。
這個NameNode的職責是什麼呢？
- NameNode管理着整個文件系統，負責接收用戶的操作請求
- NameNode管理着整個文件系統的目錄結構，所謂目錄結構類似於我們Windows操作系統的體系結構
- NameNode管理着整個文件系統的元數據信息，所謂元數據信息指定是除了數據本身之外涉及到文件自身的相關信息
- NameNode保管着文件與block塊序列之間的對應關係以及block塊與DataNode節點之間的對應關係
在hadoop1.0中，namenode有且只有一個，雖然可以通過SecondaryNameNode與NameNode進行數據同步備份，但是總會存在一定的延時，如果NameNode掛掉，但是如果有部份數據還沒有同步到SecondaryNameNode上，還是可能會存在着數據丟失的問題。
值得一提的是，在HDFS中,我們真實的數據是由DataNode來負責來存儲的，但是數據具體被存儲到了哪個DataNode節點等元數據信息則是由我們的NameNode來存儲的。
這種架構實現的好處是簡單，但其侷限同樣明顯：
單點故障問題：因爲NameNode含有我們用戶存儲文件的全部的元數據信息，當我們的NameNode無法在內存中加載全部元數據信息的時候，集羣的壽命就到頭了。
拓展性問題：NameNode在內存中存儲了整個分佈式文件系統中的元數據信息，並且NameNode只能有一臺機器，無法拓展。單臺機器的NameNode必然有到達極限的地方。
性能問題：當HDFS中存儲大量的小文件時，會使NameNode的內存壓力增加。
隔離性問題：單個namenode難以提供隔離性，即：某個用戶提交的負載很大的job會減慢其他用戶的job。
1.1.2 Mapreduce
對MapReduce來說，同樣時一個主從結構，是由一個JobTracker（主）和多個TaskTracker（從）組成。
而JobTracker在hadoop1.0的MapReduce中做了很多事情，可以說當爹又當媽。
- 負責接收client提交給的計算任務。
- 負責將接收的計算任務分配給各個的TaskTracker進行執行。
- 通過heartbeat(心跳)來管理TaskTracker機器的情況，同時監控任務task的執行狀況。
這個架構的缺陷：
單點故障：依舊是單點故障問題，如果JobTracker掛掉了會導致MapReduce作業無法執行。
資源浪費：JobTracker完成了太多的任務，造成了過多的資源消耗，當map-reduce job非常多的時候，會造成很大的內存開銷，潛在來說，也增加了JobTracker失效的風險，這也是業界普遍總結出老Hadoop的Map-Reduce只能支持4000節點主機的上限；
只支持簡單的MapReduce編程模型：要使用Hadoop進行編程的話只能使用基礎的MapReduce，而無法使用諸如Spark這些計算模型。並且它也不支持流式計算和實時計算。
資源利用率不高：把資源強制劃分爲 Map/Reduce Slot，當只有 MapTask 時，TeduceSlot 不能用;當只有 Reduce Task 時，MapSlot 不能用，容易造成資源利用不足。
容易OOM: 在 TaskTracker 端，用 Map/Reduce Task 作爲資源的表示過於簡單，沒有考慮到 CPU、內 存等資源情況，當把兩個需要消耗大內存的 Task 調度到一起，很容易出現 OOM
1.2 hadoop2.0
Hadoop2.0比起Hadoop1.0來說，最大的改進是加入了資源調度框架Yarn，我們依舊分爲HDFS和Yarn/MapReduce2.0兩部分來講述Hadoop的改進。
1.2.1 HDFS
針對Hadoop1.0中NameNode制約HDFS的擴展性問題，提出HDFSFederation以及高可用HA。此時NameNode間相互獨立，也就是說它們之間不需要相互協調。且多個NameNode分管不同的目錄進而實現訪問隔離和橫向擴展。
這樣NameNode的可拓展性自然而然可用增加，據統計Hadoop2.0中最多可以達到10000個節點同時運行，並且這樣的架構改進也解決了NameNode單點故障問題。
再來說說高可用(HA),HA主要指的是可以同時啓動2個NameNode。其中一個處於工作(Active)狀態，另一個處於隨時待命（Standby）狀態。這樣，當一個NameNode所在的服務器宕機時，可以在數據不丟失的情況下，手工或者自動切換到另一個NameNode提供服務。
1.2.2 Yarn/MapReduce2
針對Hadoop1.0中MR的不足，引入了Yarn框架。Yarn框架中將JobTracker資源分配和作業控制分開，分爲Resource Manager(RM)以及Application Master(AM)。
下邊詳細介紹yarn
2. Yarn
2.1 Yarn(Yet Another Resource Negotiator)概述
YARN 是一個資源調度平臺，負責爲運算程序提供服務器運算資源，相當於一個分佈式的操
作系統平臺，而 MapReduce 等運算程序則相當於運行於操作系統之上的應用程序
YARN 是 Hadoop2.x 版本中的一個新特性。它的出現其實是爲了解決第一代 MapReduce 編程 框架的不足，提高集羣環境下的資源利用率，這些資源包括內存，磁盤，網絡，IO 等。Hadoop2.X 版本中重新設計的這個 YARN 集羣，具有更好的擴展性，可用性，可靠性，向後兼容性，以 及能支持除 MapReduce 以外的更多分佈式計算程序
- YARN 並不清楚用戶提交的程序的運行機制
- YARN 只提供運算資源的調度(用戶程序向 YARN 申請資源，YARN 就負責分配資源)
- YARN 中的主管角色叫 ResourceManager
- YARN 中具體提供運算資源的角色叫 NodeManager
- 這樣一來，YARN 其實就與運行的用戶程序完全解耦，就意味着 YARN 上可以運行各種類型的分佈式運算程序(MapReduce 只是其中的一種)，比如 MapReduce、Storm 程序，Spark程序，Tez …
- 所以，Spark、Storm 等運算框架都可以整合在 YARN 上運行，只要他們各自的框架中有符合 YARN 規範的資源請求機制即可
- yarn 就成爲一個通用的資源調度平臺，從此，企業中以前存在的各種運算集羣都可以整 合在一個物理集羣上，提高資源利用率，方便數據共享
2.2 Yarn的優點
- YARN/MRv2 最基本的想法是將原 JobTracker 主要的資源管理和 Job 調度/監視功能分開作爲兩個單獨的守護進程。
- 有一個全局的 ResourceManager(RM)和每個 Application 有一個 ApplicationMaster(AM)，Application 相當於 MapReduce Job 或者 DAG jobs。
- ResourceManager 和 NodeManager(NM)組成了基本的數據計算框架。ResourceManager 協調集羣的資源利用， 任何 Client 或者運行着的 applicatitonMaster 想要運行 Job 或者 Task 都得向 RM 申請一定的資源。
- ApplicatonMaster 是一個框架特殊的庫，對於 MapReduce 框架而言有它自己的 AM 實現， 用戶也可以實現自己的 AM，在運行的時候，AM 會與 NM 一起來啓動和監視 Tasks。
2.3 Yarn 重要概念
2.3.1 ResourceManager
ResourceManager 是基於應用程序對集羣資源的需求進行調度的 YARN 集羣主控節點，負責 協調和管理整個集羣(所有 NodeManager)的資源，響應用戶提交的不同類型應用程序的 解析，調度，監控等工作。ResourceManager 會爲每一個 Application 啓動一個 MRAppMaster， 並且 MRAppMaster 分散在各個 NodeManager 節點
它主要由兩個組件構成:調度器(Scheduler) 和 應用程序管理器(ApplicationsManager， ASM)
YARN 集羣的主節點 ResourceManager 的職責:
- 處理客戶端請求
- 啓動或監控 MRAppMaster
- 監控 NodeManager
- 資源的分配與調度
2.3.2 NodeManager
NodeManager 是 YARN 集羣當中真正資源的提供者，是真正執行應用程序的容器的提供者， 監控應用程序的資源使用情況(CPU，內存，硬盤，網絡)，並通過心跳向集羣資源調度器 ResourceManager 進行彙報以更新自己的健康狀態。同時其也會監督 Container 的生命週期 管理，監控每個 Container 的資源使用(內存、CPU 等)情況，追蹤節點健康狀況，管理日 志和不同應用程序用到的附屬服務(auxiliary service)。
YARN 集羣的從節點 NodeManager 的職責:
- 管理單個節點上的資源
- 處理來自 ResourceManager 的命令
- 處理來自 MRAppMaster 的命令
2.3.3 MRAppMaster
MRAppMaster 對應一個應用程序，職責是:向資源調度器申請執行任務的資源容器，運行
任務，監控整個任務的執行，跟蹤整個任務的狀態，處理任務失敗以異常情況
MRAppMaster也就是每一個job的老大：
- 負責啓動maptask任務和reducetask任務
- 負責幫助maptask reducetask向yarn（resourcemanager）申請資源
- 負責監控maptask或reducetask的運行狀態和進度
- 負責maptask或reducetask的失敗重啓
2.3.4 Container
Container 容器是一個抽象出來的邏輯資源單位。容器是由 ResourceManager Scheduler 服務 動態分配的資源構成，它包括了該節點上的一定量 CPU，內存，磁盤，網絡等信息，MapReduce 程序的所有 Task 都是在一個容器裏執行完成的，一個container對應一個yarnchild進程，容器的大小是可以動態調整的
2.3.5 ASM
應用程序管理器 ASM 負責管理整個系統中所有應用程序，包括應用程序提交、與調度器協商資源以啓動 MRAppMaster、監控 MRAppMaster 運行狀態並在失敗時重新啓動它等
2.3.6 Scheduler
調度器根據應用程序的資源需求進行資源分配，不參與應用程序具體的執行和監控等工作 資源分配的單位就是 Container，調度器是一個可插拔的組件，用戶可以根據自己的需求實 現自己的調度器。YARN 本身爲我們提供了多種直接可用的調度器，比如 FIFO，Fair Scheduler 和 Capacity Scheduler 等
2.4 Yarn架構及角色職責
2.5 Yarn 作業執行流程(概述版)
- 客戶端向rm發送提交job的命令
- RM會爲該job分配一個節點，並在該節點啓動MRappmaster
- 這個節點會先啓動一個container,然後在這個container中啓動MRappmaster
- MRappmaster向RM申請資源，啓動maptask、reducetask
- RM向MRapppmaster返回maptask/reducetask的對應節點(優先數據本地化、同機架、同機房)
- 在上一步返回的對應節點啓動maptask
- 在上一步啓動的maptask有一個執行完時，開始啓動reducetask
- maptask reducetask向MRappmaster彙報運行進度和狀態，當maptask/reducetask運行完成時，對應資源被回收。
- MRappmaster向RM彙報，並註銷自己
2.6 Yarn 作業執行流程(詳細版)
- 客戶端向RM發送job提交請求
- RM向當前客戶端返回一個applicationId(application_時間戳_Id)和共享資源(jar、split、job.xml)
- 客戶端將共享資源放在共享資源路徑下
/tmp/hadoop-yarn/staging/hadoop/.staging/job_1544520115116_004 - 客戶端向RM發送響應，告知共享資源放置完成，並開始真正提交Job
- RM會爲當前job分配一個nodemanager,並在該節點啓動MRappmaster
- 先在上一步指定的節點啓一個Container，再啓動MRappmaster
- MRappmaster會初始化這個job的工作簿(記錄maptask、reducetask工作進度的)
- MRappmaster會在共享資源路徑下載共享資源
- MRappmaster向RM申請資源運行maptask和reducetask(優先提交maptask的資源申請)
- RM向MRappmaster返回對應資源節點(數據本地化原則)
- MRappmaster到對應節點先啓動Container(再啓動maptask)
- maptask任務到共享資源路徑下載共享資源
- 運行maptask任務
- maptask向MRappmaster彙報自己的進度和狀態
- 當MRappmaster獲取到有一個maptask完成時，到對應節點優先啓動Container(啓動reducetask),開始進行數據的fetch
- reducetask到對應的共享資源路徑下載共享資源
- 執行reducetask
- reducetask運行過程向MRappmaster彙報自己的進度和狀態
- MRappmaster獲取到maptask或reducetask任務運行完成時，到對應節點上銷燬資源(container)
- MRappmaster向RM彙報運行完成，並註銷自己。
參考鏈接：
hadoop1.0與hadoop2.0區別
https://www.cnblogs.com/listenfwind/p/10121817.html
