1. 概述

在 Google 三篇大數(shù)據(jù)論文發(fā)表之后罐氨，Cloudera 公司在這幾篇論文的基礎(chǔ)上臀规，開發(fā)出了現(xiàn)在的 Hadoop 。但 Hadoop 開發(fā)出來也并非一帆風(fēng)順的栅隐，Hadoop 1.0 版本有諸多局限塔嬉。在后續(xù)的不斷實踐之中， Hadoop 2.0 橫空出世租悄，而后 Hadoop 2.0 逐漸成為主流谨究。這次我們就來看看 Hadoop 從 1.0 遇到了哪些問題，又為什么需要做架構(gòu)的升級呢泣棋？

2. Hadoop 1.0

首先我們來看 hadoop1.0 的整體結(jié)構(gòu)胶哲。在 hadoop1.0 中有兩個模塊，一個是分布式文件系統(tǒng) HDFS(Hadoop Distrbuted File System) 外傅。另一個則是分布式計算框架 MapReduce 纪吮。我們分別來看看這兩個模塊的架構(gòu)吧俩檬。

2.1 HDFS

對HDFS來說萎胰，其主要的運行架構(gòu)則是 master-slave 架構(gòu)，即主從架構(gòu)棚辽。其中呢技竟，master 主節(jié)點稱之為 Namenode 節(jié)點，而slave從節(jié)點稱為 DataNode 節(jié)點屈藐。

image

1. NameNode管理著整個文件系統(tǒng)，負(fù)責(zé)接收用戶的操作請求
2. NameNode管理著整個文件系統(tǒng)的目錄結(jié)構(gòu)联逻，所謂目錄結(jié)構(gòu)類似于我們Windows操作系統(tǒng)的體系結(jié)構(gòu)
3. NameNode管理著整個文件系統(tǒng)的元數(shù)據(jù)信息搓扯，所謂元數(shù)據(jù)信息指定是除了數(shù)據(jù)本身之外涉及到文件自身的相關(guān)信息
4. NameNode保管著文件與block塊序列之間的對應(yīng)關(guān)系以及block塊與DataNode節(jié)點之間的對應(yīng)關(guān)系

在hadoop1.0中，namenode有且只有一個包归，雖然可以通過SecondaryNameNode與NameNode進(jìn)行數(shù)據(jù)同步備份锨推，但是總會存在一定的延時，如果NameNode掛掉，但是如果有部份數(shù)據(jù)還沒有同步到SecondaryNameNode上换可，還是可能會存在著數(shù)據(jù)丟失的問題椎椰。

值得一提的是，在HDFS中,我們真實的數(shù)據(jù)是由DataNode來負(fù)責(zé)來存儲的沾鳄，但是數(shù)據(jù)具體被存儲到了哪個DataNode節(jié)點等元數(shù)據(jù)信息則是由我們的NameNode來存儲的慨飘。

這種架構(gòu)實現(xiàn)的好處的簡單，但其局限同樣明顯：

• 單點故障問題：因為NameNode含有我們用戶存儲文件的全部的元數(shù)據(jù)信息译荞，當(dāng)我們的NameNode無法在內(nèi)存中加載全部元數(shù)據(jù)信息的時候瓤的，集群的壽命就到頭了。
• 拓展性問題：NameNode在內(nèi)存中存儲了整個分布式文件系統(tǒng)中的元數(shù)據(jù)信息吞歼，并且NameNode只能有一臺機器堤瘤，無法拓展。單臺機器的NameNode必然有到達(dá)極限的地方浆熔。
• 性能問題：當(dāng)HDFS中存儲大量的小文件時本辐，會使NameNode的內(nèi)存壓力增加。
• 隔離性問題：單個namenode難以提供隔離性医增，即：某個用戶提交的負(fù)載很大的job會減慢其他用戶的job慎皱。

2.2 MapReduce

對MapReduce來說，同樣時一個主從結(jié)構(gòu)叶骨，是由一個JobTracker（主）和多個TaskTracker（從）組成茫多。

而JobTracker在hadoop1.0的MapReduce中做了很多事情，可以說當(dāng)?shù)之?dāng)媽忽刽。

1. 負(fù)責(zé)接收client提交給的計算任務(wù)天揖。
2. 負(fù)責(zé)將接收的計算任務(wù)分配給各個的TaskTracker進(jìn)行執(zhí)行。
3. 通過heartbeat(心跳)來管理TaskTracker機器的情況跪帝，同時監(jiān)控任務(wù)task的執(zhí)行狀況今膊。

這個架構(gòu)的缺陷：

• 單點故障：依舊是單點故障問題，如果JobTracker掛掉了會導(dǎo)致MapReduce作業(yè)無法執(zhí)行伞剑。
• 資源浪費：JobTracker 完成了太多的任務(wù)斑唬，造成了過多的資源消耗，當(dāng) map-reduce job 非常多的時候黎泣，會造成很大的內(nèi)存開銷恕刘，潛在來說，也增加了 JobTracker 失效的風(fēng)險抒倚，這也是業(yè)界普遍總結(jié)出老 Hadoop 的 Map-Reduce 只能支持 4000 節(jié)點主機的上限褐着；
• 只支持簡單的MapReduce編程模型：要使用Hadoop進(jìn)行編程的話只能使用基礎(chǔ)的MapReduce，而無法使用諸如Spark這些計算模型托呕。并且它也不支持流式計算和實時計算含蓉。

3. Hadoop 2.0

image

Hadoop 2.0 比起 Hadoop 1.0 來說洋访，最大的改進(jìn)是加入了 資源調(diào)度框架 Yarn ，我們依舊分為HDFS和 Yarn/MapReduce2.0 兩部分來講述Hadoop的改進(jìn)谴餐。

3.1 HDFS

針對 Hadoop 1.0 中 NameNode 制約HDFS的擴展性問題姻政，提出HDFS Federation 以及高可用 HA 。此時 NameNode 間相互獨立岂嗓，也就是說它們之間不需要相互協(xié)調(diào)汁展。且多個NameNode分管不同的目錄進(jìn)而實現(xiàn)訪問隔離和橫向擴展。

這樣 NameNode 的可拓展性自然而然可用增加厌殉，據(jù)統(tǒng)計 Hadoop 2.0 中最多可以達(dá)到 10000 個節(jié)點同時運行食绿，并且這樣的架構(gòu)改進(jìn)也解決了NameNode單點故障問題。

再來說說高可用 (HA) , HA 主要指的是可以同時啟動2個 NameNode 公罕。其中一個處于工作 (Active) 狀態(tài)器紧，另一個處于隨時待命（Standby）狀態(tài)。這樣楼眷，當(dāng)一個NameNode所在的服務(wù)器宕機時铲汪，可以在數(shù)據(jù)不丟失的情況下，手工或者自動切換到另一個 NameNode 提供服務(wù)罐柳。

3.2 Yarn/MapReduce2

針對 Hadoop 1.0 中 MR 的不足掌腰，引入了Yarn 框架。Yarn 框架中將 JobTracker 資源分配和作業(yè)控制分開张吉，分為 Resource Manager (RM) 以及 Application Master (AM) 齿梁。

image

而Yarn框架作為一個通用的資源調(diào)度和管理模塊，同時支持多種其他的編程模型肮蛹，比如最出名的 Spark 勺择。

Yarn的主要三個組件如下：

• Resource Manager：ResourceManager包含兩個主要的組件：定時調(diào)用器(Scheduler)以及應(yīng)用管理器(ApplicationManager)。

  1. 定時調(diào)度器(Scheduler)：定時調(diào)度器負(fù)責(zé)向應(yīng)用程序分配資源伦忠，它不做監(jiān)控以及應(yīng)用程序的狀態(tài)跟蹤省核，并且它不保證會重啟由于應(yīng)用程序本身或硬件出錯而執(zhí)行失敗的應(yīng)用程序。

  2. 應(yīng)用管理器(ApplicationManager)：應(yīng)用程序管理器負(fù)責(zé)接收新任務(wù)缓苛，協(xié)調(diào)并提供在ApplicationMaster容器失敗時的重啟功能芳撒。

• Application Master：每個應(yīng)用程序的ApplicationMaster負(fù)責(zé)從Scheduler申請資源邓深，以及跟蹤這些資源的使用情況以及任務(wù)進(jìn)度的監(jiān)控未桥。

• Node Manager：NodeManager是ResourceManager在每臺機器的上代理，負(fù)責(zé)容器的管理芥备，并監(jiān)控他們的資源使用情況（cpu冬耿，內(nèi)存，磁盤及網(wǎng)絡(luò)等）萌壳，以及向 ResourceManager/Scheduler提供這些資源使用報告亦镶。

一點點感悟

沒有什么是一開始就完美的日月，當(dāng)下最流行的 Hadoop 也一樣。從上面說的缤骨，我們可以知道 Hadoop 1.0 是比較簡陋的爱咬，這樣做的目的就是為了易于實現(xiàn)。Hadoop 這樣做也契合了敏捷開發(fā)的原則绊起，也可以說契合產(chǎn)品經(jīng)理口中的最小可行性產(chǎn)品（MVP）精拟，就是先實現(xiàn)一個簡單些，但核心功能齊全的版本出來虱歪，讓市場對其進(jìn)行檢驗蜂绎，而有了結(jié)果之后再進(jìn)行拓展升級。

在當(dāng)時那種許多公司都苦惱于沒有自己的大數(shù)據(jù)環(huán)境的情況下笋鄙，Hadoop 一炮而紅师枣。這時候再根據(jù)市場，也就是開源社區(qū)給出的反饋萧落，不斷迭代践美，更新升級。最終成為大數(shù)群山中最為堅固的一座山峰找岖。

我們在平時的產(chǎn)品開發(fā)中應(yīng)該也要像 Hadoop 學(xué)習(xí)拨脉，先做出最小可行性產(chǎn)品出來，再在后面進(jìn)行更新升級宣增，不斷完善玫膀。當(dāng)然這對一些完美主義者來說，可能會讓他感到比較痛苦爹脾。

你看帖旨，世間的事多是相通，技術(shù)的發(fā)展過程其實也暗合產(chǎn)品之道灵妨。有時候我們或許可以跳出技術(shù)之外解阅，思考它背后產(chǎn)品的邏輯，這其中又有哪些是我們可以學(xué)習(xí)的泌霍，這些同樣是珍貴的寶藏货抄，所謂他山之石，可以攻玉朱转，莫過于此~~

以上~

歡迎關(guān)注公眾號蟹地，有數(shù)據(jù)，代碼和深度的思考藤为。
PS：關(guān)注后回復(fù)“數(shù)據(jù)挖掘一”可獲得數(shù)據(jù)挖掘思維導(dǎo)圖

哈爾的數(shù)據(jù)城堡