Hadoop學習筆記—21.Hadoop2的改進內容簡介

Hadoop2相比較於Hadoop1.x來講,HDFS的架構與MapReduce的都有較大的變化,且速度上和可用性上都有了很大的提升,Hadoop2中有兩個重要的變動:node

(1)HDFS的NameNode能夠以集羣的方式佈署,加強了NameNodes的水平擴展能力和高可用性,分別是:HDFS FederationHA編程

(2)MapReduce將JobTracker中的資源管理及任務生命週期管理(包括定時觸發及監控),拆分紅兩個獨立的組件,並改名爲YARN(Yet Another Resource Negotiator);服務器

1、HDFS的改進

1.1 Hadoop1.x時代的HDFS架構

  在Hadoop1.x中的NameNode只可能有一個,雖然能夠經過SecondaryNameNode與NameNode進行數據同步備份,可是總會存在必定的時延,若是NameNode掛掉,可是若是有部份數據尚未同步到SecondaryNameNode上,仍是可能會存在着數據丟失的問題。該架構如圖1所示:網絡

  圖1 Hadoop1.x時代的HDFS結構圖架構

  該架構包含兩層:Namespace 和 Block Storage Service;併發

  其中,Namespace 層面包含目錄、文件以及塊的信息,支持對Namespace相關文件系統的操做,如增長、刪除、修改以及文件和目錄的展現;框架

  而Block Storage Service層面又包含兩個部分:分佈式

  ①Block Management(塊管理)維護集羣中DataNode的基本關係,它支持數據塊相關的操做,如:建立數據塊,刪除數據塊等,同時,它也會管理副本的複製和存放。oop

  ②Physical Storage(物理存儲)存儲實際的數據塊並提供針對數據塊的讀寫服務。性能

  當前HDFS架構只容許整個集羣中存在一個Namespace,而該Namespace被僅有的一個NameNode管理。這個架構使得HDFS很是容易實現,可是,它(見上圖)在具體實現過程當中會出現一些模糊點,進而致使了不少侷限性(下面將要詳細說明),固然這些侷限性只有在擁有大集羣的公司,像baidu,騰訊等出現。

Hadoop1.x的HDFS架構的侷限:

(1)Block Storage和namespace高耦合

當前namenode中的namespace和block management的結合使得這兩層架構耦合在一塊兒,難以讓其餘可能namenode實現方案直接使用block storage。

(2)NameNode擴展性

HDFS的底層存儲是能夠水平擴展的(解釋:底層存儲指的是datanode,當集羣存儲空間不夠時,可簡單的添加機器已進行水平擴展),但namespace不能夠。當前的namespace只能存放在單個namenode上,而namenode在內存中存儲了整個分佈式文件系統中的元數據信息,這限制了集羣中數據塊,文件和目錄的數目。

(3)NameNode性能

文件操做的性能制約於單個Namenode的吞吐量,單個Namenode當前僅支持約60K的task,而下一代Apache MapReduce將支持多餘100K的併發任務,這隱含着要支持多個Namenode。

(4)隔離性

如今大部分公司的集羣都是共享的,天天有來自不一樣group的不一樣用戶提交做業。單個namenode難以提供隔離性,即:某個用戶提交的負載很大的job會減慢其餘用戶的job,單一的namenode難以像HBase按照應用類別將不一樣做業分派到不一樣namenode上。

1.1 HDFS Federation

  (1)全新的Feration架構

  在Hadoop2.x中,HDFS的變化主要體如今加強了NameNode的水平擴展(Horizontal Scalability)及高可用性(HA)->【這不就是針對咱們剛剛提到到的Hadoop1.x HDFS架構的侷限性而作的改進,麼麼嗒!】,能夠同時部署多個NameNode,這些NameNode之間是相互獨立,也就是說他們不須要相互協調,DataNode同時在全部NameNode中註冊,做爲他們共有的存儲節點,並定時向全部的這些NameNode發送心跳塊使用狀況的報告,並處理全部NameNode向其發送的指令。該架構如圖2所示:

圖2 Hadoop2.x時代的HDFS結構圖

  該架構引入了兩個新的概念:存儲塊池(Block Pool) 和 集羣ID(ClusterID);

  ①一個Bock Pool 是塊的集合,這些塊屬於一個單一的Namespace。DataNode存儲着集羣中全部Block Pool中的塊。Block Pool的管理相互之間是獨立的。這意味着一個Namespace能夠獨立的生成塊ID,不須要與其餘Namespace協調。一個NameNode失敗不會致使Datanode的失敗,這些Datanode還能夠服務其餘的Namenode。

  一個Namespace和它的Block Pool一塊兒稱做命名空間向量(Namespace Volume)。這是一個自包含單元。當一個NameNode/Namespace刪除後,對應的Block Pool也會被刪除。當集羣升級時,每一個Namespace Volume也會升級。

  ②集羣ID(ClusterID)的加入,是用於確認集羣中全部的節點,也能夠在格式化其它Namenode時指定集羣ID,並使其加入到某個集羣中。

  (2)HDFS Federation與老HDFS架構的比較

①老HDFS架構只有一個命名空間(Namespace),它使用所有的塊。而HDFS Federation 中有多個獨立的命名空間(Namespace),而且每個命名空間使用一個塊池(block pool)。

②老HDFS架構中只有一組塊。而HDFS Federation 中有多組獨立的塊。塊池(block pool)就是屬於同一個命名空間的一組塊。

③老HDFS架構由一個Namenode和一組datanode組成。而HDFS Federation 由多個Namenode和一組Datanode,每個Datanode會爲多個塊池(block pool)存儲塊。

1.2 NameNode的HA

  Hadoop中的NameNode比如是人的心臟,很是重要,絕對不能夠中止工做。在Hadoop1.x時代,只有一個NameNode。若是該NameNode數據丟失或者不能工做,那麼整個集羣就不能恢復了。這是Hadoop1.x中的單點問題,也是Hadoop1.x不可靠的表現,如圖1所示。Hadoop2的出現解決了這個問題,也被稱爲HA。

  Hadoop2中HDFS的HA主要指的是能夠同時啓動2個NameNode。其中一個處於工做(Active)狀態,另外一個處於隨時待命(Standby)狀態。這樣,當一個NameNode所在的服務器宕機時,能夠在數據不丟失的狀況下,手工或者自動切換到另外一個NameNode提供服務。如圖3所示,它展現了一個在Hadoop2下實現HA的一種方式結構:

圖3 Hadoop2.x時代實現HA的一種架構圖

  下面對上圖作一下簡單的介紹:

  (1)這些NameNode之間經過共享存儲同步edits信息,保證數據的狀態一致。多個NameNode之間共享數據,能夠經過Network File System(NFS)或者Quorum Journal Node。前者是經過Linux共享的文件系統,屬於操做系統層面的配置;後者是Hadoop自身的東西,屬於軟件層面的配置。

  (2)DataNode同時向兩個NameNode彙報塊信息。這是讓Standby NameNode保持集羣最新狀態的必需步驟。

  (3)使用Zookeeper來進行心跳監測監控,在Active NameNode失效時自動切換Standby NameNode爲Active狀態。

2、MapReduce的改進

2.1 Hadoop1.x時代的MapReduce

  在Hadoop1.x時代,Hadoop中的MapReduce實現是作了不少的事情,而該框架的核心Job Tracker則是既當爹又當媽的意思,如圖4所示:

  圖4 Hadoop1.x時代的MapReduce框架架構圖

  (1)首先用戶程序 (JobClient) 提交了一個 job,job 的信息會發送到 Job Tracker 中,Job Tracker 是 Map-reduce 框架的中心,他須要與集羣中的機器定時通訊 (heartbeat), 須要管理哪些程序應該跑在哪些機器上,須要管理全部 job 失敗、重啓等操做。

  (2)TaskTracker 是 Map-reduce 集羣中每臺機器都有的一個部分,他作的事情主要是監視本身所在機器的資源狀況。

  (3)TaskTracker 同時監視當前機器的 tasks 運行情況。TaskTracker 須要把這些信息經過 heartbeat發送給JobTracker,JobTracker 會蒐集這些信息以給新提交的 job 分配運行在哪些機器上。

Hadoop1.x的MapReduce框架的主要侷限:

(1)JobTracker 是 Map-reduce 的集中處理點,存在單點故障

(2)JobTracker 完成了太多的任務,形成了過多的資源消耗,當 map-reduce job 很是多的時候,會形成很大的內存開銷,潛在來講,也增長了 JobTracker 失效的風險,這也是業界廣泛總結出老 Hadoop 的 Map-Reduce 只能支持 4000 節點主機的上限;

2.2 Hadoop2中新方案:YARN+MapReduce

  首先的不要被YARN給迷惑住了,它只是負責資源調度管理。而MapReduce纔是負責運算的傢伙,因此YARN  != MapReduce2. 

YARN 並非下一代MapReduce(MRv2),下一代MapReduce與第一代MapReduce(MRv1)在編程接口、數據處理引擎(MapTask和ReduceTask)是徹底同樣的, 可認爲MRv2重用了MRv1的這些模塊,不一樣的是資源管理和做業管理系統,MRv1中資源管理和做業管理均是由JobTracker實現的,集兩個功能於一身,而在MRv2中,將這兩部分分開了。 其中,做業管理由ApplicationMaster實現,而資源管理由新增系統YARN完成,因爲YARN具備通用性,所以YARN也能夠做爲其餘計算框架的資源管理系統,不只限於MapReduce,也是其餘計算框架(例如Spark)的管理平臺。  

圖5 Hadoop2時代的新方案架構圖

  從圖5中也能夠看出,Hadoop1時代中MapReduce能夠說是啥事都幹,而Hadoop2中的MapReduce的話則是專門處理數據分析,而YARN則作爲資源管理器而存在。

  該架構將JobTracker中的資源管理及任務生命週期管理(包括定時觸發及監控),拆分紅兩個獨立的服務,用於管理所有資源的ResourceManager以及管理每一個應用的ApplicationMaster,ResourceManager用於管理嚮應用程序分配計算資源,每一個ApplicationMaster用於管理應用程序、調度以及協調。一個應用程序能夠是經典的MapReduce架構中的一個單獨的Job任務,也能夠是這些任務的一個DAG(有向無環圖)任務。ResourceManager及每臺機上的NodeManager服務,用於管理那臺主機的用戶進程,造成計算架構。每一個應用程序的ApplicationMaster其實是一個框架具體庫,並負責從ResourceManager中協調資源及與NodeManager(s)協做執行並監控任務。如圖6所示:

圖6 YARN架構圖

  (1)ResourceManager包含兩個主要的組件:定時調用器(Scheduler)以及應用管理器(ApplicationManager)。

  ①定時調度器(Scheduler):

  定時調度器負責嚮應用程序分配資源,它不作監控以及應用程序的狀態跟蹤,而且它不保證會重啓因爲應用程序自己或硬件出錯而執行失敗的應用程序。

  ②應用管理器(ApplicationManager):

  應用程序管理器負責接收新任務,協調並提供在ApplicationMaster容器失敗時的重啓功能。

  (2)ApplicationMaster:每一個應用程序的ApplicationMaster負責從Scheduler申請資源,以及跟蹤這些資源的使用狀況以及任務進度的監控。

  (3)NodeManager:NodeManager是ResourceManager在每臺機器的上代理,負責容器的管理,並監控他們的資源使用狀況(cpu,內存,磁盤及網絡等),以及向 ResourceManager/Scheduler提供這些資源使用報告。

參考資料

(1)馮立彬,《Hadoop1與Hadoop2的區別》:http://blog.csdn.net/fenglibing/article/details/32916445

(2)終身赤腳,《Hadoop中MapReduce框架入門》:http://my.oschina.net/codeWatching/blog/345374

(3)吳超,《Hadoop2的重大變化介紹》:http://www.superwu.cn/2013/11/29/854/

(4)董西成,《HDFS Federation的設計動機與原理》:http://dongxicheng.org/mapreduce/hdfs-federation-introduction/

(5)孫振南,《Hadoop2.0 HA和Ferderation實踐》:http://www.infoq.com/cn/articles/hadoop-2-0-namenode-ha-federation-practice-zh/

 

相關文章
相關標籤/搜索