第 1 章　Hadoop 2.X

“沒有什么是不能通過搜索引擎或互聯網找到的。”

——埃里克·施密特，谷歌執行主席

在大規模、高并行和分布式計算處理這個行業中，Hadoop實際上是大家所使用的一種開源框架標準。它為并行和分布式處理提供了一個計算層，與這個計算層緊密聯系的是一個高度容錯的存儲層——Hadoop分布式文件系統（Hadoop Distributed File System，HDFS），而且它們都運行在低價、常見和相互兼容的普通硬件上。

本章我們將回顧Hadoop的發展歷程，并著重介紹其準企業級特性。經過6年的發展和部署，Hadoop已經從一個只支持MapReduce模式的框架轉變成更通用的集群計算框架。本章主要涵蓋如下內容：

• 概括Hadoop代碼的演進過程，以及主要的里程碑

• 介紹Hadoop從1.X版本發展到2.X版本所經歷的變化，以及其如何演進為一個通用集群計算框架

• 介紹企業級Hadoop的可選項及其評估參數

• 概述一些流行的準企業級Hadoop發行版本

1.1　Hadoop的起源

互聯網的誕生和發展孕育了萬維網（WWW），它將大量使用標記語言（HTML）編寫的文檔用一個超鏈接連接在一起。它的客戶端，也就是瀏覽器，成為了用戶通往萬維網的窗口。由于萬維網上的文檔易于創建、編輯和發布，于是海量的文檔出現在了萬維網中。

在20世紀90年代后半段，萬維網中海量的數據導致了查找的問題。用戶發現在有信息需求的時候，很難發現和定位正確的文檔，于是眾多互聯網公司在萬維網的搜索領域掀起了一股淘金浪潮，諸如Lycos、Altavista、Yahoo!和Ask Jeeves這樣的搜索引擎或者目錄服務變得司空見慣。

搜索引擎開始攝取和匯總網頁信息，而遍歷網絡、攝取文檔的程序則被稱為爬蟲。已經開發出來的優秀爬蟲可以快速下載文檔，能避免鏈接成環路，并且可以檢測文檔的更新。

在本世紀初期，谷歌的出現引領了搜索技術的發展。它的成功不僅是因為引入了強健的、反垃圾郵件的技術，還得益于它簡潔的方法和快速的數據處理。對于前者，它創造了像PageRank這樣新穎的概念，而對于后者，則在大規模并行、分布式的數據分析中，獨具匠心地結合和應用了已有的技術，如MapReduce。

PageRank是一個以谷歌創始人Larry Page的名字命名的算法，它是為用戶的網頁搜索結果排序的算法之一。搜索引擎使用關鍵字匹配網站，以此來判斷它與搜索查詢間的相關度。受此啟發，垃圾蟲們就會在網站上加入許多相關或不相關的關鍵詞，從而欺騙搜索引擎使它們出現在幾乎所有的查詢結果中。例如，一個汽車銷售商卻包含了關于購物和電影的關鍵字，這樣他所對應的搜索查詢范圍就更廣了。而用戶則飽受這些無用信息的困擾。

PageRank通過分析指向某一特定頁面的鏈接的質量和數量，阻礙了這種欺騙行為，它的出發點是重要的頁面會有更多的入站鏈接。

大約在2004年，谷歌向世人公開了它的MapReduce技術實現，這項技術引入了與MapReduce引擎配合使用的GFS（Google File System，谷歌文件系統）。從此，其他許多公司在并行和分布式處理大數據時，都最喜歡使用MapReduce模式。Hadoop是MapReduce框架的一個開源實現，Hadoop和相關的HDFS，分別是受到了谷歌的MapReduce和GFS啟發。

自從誕生以來，Hadoop和其他基于MapReduce的系統在各個領域執行著各種不同負載的任務，而網頁搜索是其中一項。舉個例子，http://www.last.fm/廣泛使用Hadoop來產生圖表和跟蹤利用率的統計數據；Hadoop也被云服務提供商Rackspace用來做日志處理；雅虎（Yahoo!）是Hadoop最大的支持者之一，它不僅使用Hadoop集群創建網頁索引，而且還用其執行復雜的廣告植入和內容優化算法。

1.2　Hadoop的演進

大概在2003年，Doug Cutting和Mike Cafarella開始從事一個叫Nutch的項目，這是一個具有高可擴展性、特性豐富的開源爬蟲和索引構建項目，目的是提供一個現成的爬蟲框架去滿足文檔搜索的需求。Nutch能在多臺機器組成的分布式集群上工作，并且遵守網頁服務器上robots.txt文件中定義的協議。它之所以具有高擴展性是因為提供了一個插件框架，程序員能添加自定義的組件在上面運行，例如，一個可以從互聯網讀取不同類型媒體的第三方插件。

　機器人排除標準（Robot Exclusion Standard），即robots.txt協議，是一個建議爬蟲如何抓取網頁的忠告性協議。它是一個放在網頁服務器根目錄下的文件，用來建議爬蟲應該或者不應該抓取某個公共網頁或者目錄。作為一個有禮貌的爬蟲，其中一個特征就是遵守放置在robots.txt文件內的建議。

Nutch搭配其他諸如Lucene和Solr這樣的索引技術，為構建搜索引擎提供了必要的組件，但還不能滿足互聯網級別規模的需要。早期的Nutch曾演示過使用4臺機器處理1億個網頁，不過調試和維護工作很繁瑣。2004年，谷歌發布的頗具影響力的MapReduce和GFS概念解決了Nutch遇到的一些擴展性問題。Nutch的貢獻者開始將分布式文件系統和MapReduce編程模型集成到這個項目中。到2006年，Nutch的擴展性雖然提升了，但是也沒能達到互聯網級別。它使用20臺機器可以抓取和構建幾億的網頁文檔的索引。同時，編程、調試和維護搜索引擎的工作變得容易一些了。

2006年，雅虎將Doug Cutting招入麾下，Hadoop誕生了！Hadoop項目是受Apache軟件基金會（Apache Software Foundation，ASF）支持的，不過它是從Nutch項目中分離出來的，并可以獨立發展。2006到2008年間，Hadoop發行了大量的小版本，最終成長為一個穩定的、互聯網級別的、基于MapReduce原理的數據處理框架。2008年，Hadoop在太字節（terabyte）級別數據的排序性能標桿競賽中獲勝，正式宣告它成為了一個基于MapReduce、適用于大規模的、可靠的集群計算框架。

Hadoop 家族

從2007年和2008年發布的早期版本算起，Hadoop項目的族譜可不短。由于它歸屬于Apache軟件基金會，所以在本書中統稱為Apache Hadoop。Apache Hadoop項目是后續發行的Hadoop版本的父項目，就像一條河流的分布一樣，這個父項目相當于河流的干流，而它的分支或者說發布版本就像是支流。

參照Apache Hadoop的發展歷程，下頁圖顯示了Hadoop的血緣關系。在圖中，黑色實線方框顯示了Apache Hadoop的主發行版本，橢圓實線框則對應Hadoop的分支版本，而黑色虛線方框代表其他的Hadoop發行版本。

Apache Hadoop有三個關系非常密切的重要分支，它們是：

• 0.20.1分支

• 0.20.2分支

• 0.21分支

在0.20版本之前，Apache Hadoop一直是沿著一條主線發行版本的，并且每次總是一個單獨的主版本，沒有創建分支版本。在發行0.20版本的時候，這個項目分裂成了三個主要的分支，其中0.20.2分支被稱為MapReduce 1.0版本、MRv1或者簡稱為Hadoop 1.0.0；0.21分支被稱為MapReduce 2.0版本、MRv2或者簡稱為Hadoop 2.0；其他一些舊一點的發行版本派生于0.20.1版本。2011年，各個不同分支發行的版本數量創下了最高紀錄。

另外有兩個發行版本雖然不屬于主發行版本，但也非常重要，那就是：Hadoop-0.20-append和Hadoop-0.20-security。這兩個發行版本分別引入了HDFS文件追加和安全相關的特性。隨著這些增強特性的加入，Apache Hadoop漸漸被企業用戶所接受。

1. Hadoop-0.20-append

文件追加（append）特性是Hadoop-0.20-append版本的主要特性，它讓用戶在執行HBase的時候不再擔心數據丟失的風險。在HDFS上運行的HBase是一種被廣泛使用的列存儲應用，可以在面向批處理的Hadoop平臺上提供在線存儲功能。具體來說，文件追加特性使得HBase的日志能夠持久存儲，確保了數據的安全。傳統的HDFS為MapReduce批處理作業提供文件的寫入和輸出功能。在完成這些作業時，一次只能打開一個文件，將很多數據寫入其中，然后再關閉文件。被關閉的文件可以被讀取很多次，但是不能再被修改。語義上提供的是一種一次寫入多次讀取（ write-once-read-many-times）的模式，且當文件被寫入時，沒有人能讀取文件的內容。

任何程序在寫HDFS文件的過程中，當寫操作失敗或者程序崩潰時，都必須重寫這個文件的全部內容。在MapReduce中，用戶總是重新執行任務來產生新的文件，但是在像HBase這樣的在線系統中卻不是這樣的。如果日志文件寫失敗，事務（transaction）操作就不能再被執行，從而導致數據的丟失。如果能夠根據日志內容重新執行事務操作，那數據就不會丟失。文件追加功能使HBase和其他需要事務操作的應用能夠在HDFS上執行，從而降低了這一風險。

2. Hadoop-0.20-security

雅虎的Hadoop團隊在Hadoop-0.20-security版本中主動承擔了添加安全特性的工作。企業內的團隊各種各樣，并且他們處理的數據類型也各不相同。為了遵守法規、保護客戶隱私和保障數據安全，進行數據隔離、數據認證以及Hadoop作業和數據的授權是非常重要的。這個安全相關的版本的發布包含了豐富的特性以支持上述三方面的企業安全需求。

這個版本將Kerberos認證系統完整集成到Hadoop中。訪問控制列表（Access Control Lists，ACL）的引入確保了作業的運行和數據的訪問得到恰當的授權。認證與授權為系統中屬于不同用戶的作業和數據提供了必要的隔離性。

3. Hadoop年鑒

下圖展示了Apache Hadoop的主要發行版本和里程碑。雖然該項目已經持續了8年，但是直到最后的4年，Hadoop才在大數據處理領域發揮了巨大影響力。2010年1月，谷歌獲得了MapReduce技術的專利，但是4個月后這項技術專利就授權給了Apache軟件基金會，這為Hadoop打了一針強心劑。擺脫了法律糾紛的煩擾，各家企業，不論規模大小，都張開雙臂準備迎接Hadoop。至此，Hadoop也經歷了一些重大改進，并發布了相關版本。這也為Hadoop的分銷、支持、培訓以及相關業務帶來了商機。

Hadoop 1.0系列版本在本書中統稱為1.X版本，它經歷了Hadoop作為一個純粹的MapReduce作業處理框架從誕生到演進的全過程，它廣泛采用了大數據處理工具，發揮的作用遠遠超出了人們的預期。這個時期，Hadoop 1.X發行版的穩定版本是1.2.1，它包括了文件追加和安全等特性。Hadoop 1.X試圖通過不斷的改變來保持其靈活性，例如HDFS文件追加功能，以支持HBase這樣的在線系統。然而，盡管Hadoop 1.X的靈活性得到了擴展，但是原有的MapReduce計算模型卻不能支持所有大數據應用涉及的領域，除非在它的架構上做出改變。

Hadoop 2.0系列版本在本書中統稱為2.X版本。自2013年問世以來，這一系列的版本也經歷了重大改進，拓展了Hadoop可以處理的應用范圍。這個系列還針對企業內現有的Hadoop集群提升了效率，并擴大了優勢。顯然，Hadoop正在快速趕超MapReduce，由于它還具有向后兼容的優勢，因此在大數據領域保持著遙遙領先的地位。它正在從一個僅針對MapReduce的框架成長為一種通用的集群計算和存儲平臺。

1.3　Hadoop 2.X

Hadoop 1.X在一些組織機構內大受歡迎，也讓人們認識到了它的局限性。

• Hadoop對集群計算資源賦予了史無前例的準入方式，組織機構內的每一個人都有權訪問。并且由于MapReduce編程模型比較簡單，且支持“一次開發，任意部署”（develop once deploy at any scale）的模式，因此，用戶將一些不怎么適合MapReduce實現的數據處理作業也部署到了Hadoop上，例如，網頁服務端應用被部署到一個長時間運行的map作業中。眾所周知，MapReduce難以承擔迭代類型的算法運算，但是一些黑客通過改造使Hadoop能執行迭代算法，這使得集群的資源利用和容量規劃面臨眾多挑戰。

• Hadoop 1.X采用集中式作業流控制，然而集中式系統由于其負載的單點問題，很難實現擴展。一旦JobTracker（作業跟蹤器）出現故障，系統中所有的作業都必須重新啟動，這對整個集中式組件造成了極大壓力。按照這種模式，Hadoop很難與其他類型的集群進行集成。

• 早期發行的Hadoop 1.X版本將所有HDFS目錄和文件的元數據存儲到一個NameNode單點。整個集群的數據狀態取決于這個單點的成敗。隨后的版本添加了一個作為冷備的從NameNode（secondary NameNode）節點。從NameNode節點周期性地將寫日志（edit log）和NameNode的映象文件（image file）合并，這樣做有兩個優點：首先，由于主NameNode節點在啟動的時候不需要完全合并寫日志和映象文件，因此主NameNode節點的啟動時間縮短了；其次，從NameNode節點復制NameNode的所有信息，這樣當NameNode節點出現不可恢復的故障時，數據丟失會降到最低。但是，從NameNode（它并不是NameNode的一個實時備份）并不是一個熱備份節點，這意味著故障切換時間和恢復時間較長，且集群可用性會受到影響。

• Hadoop 1.X主要是一個基于Unix系統的大數據處理框架，想要直接在微軟的Windows Server操作系統上執行是不可能的。隨著微軟大舉進入云計算和大數據分析領域，再加上業界已經在Windows Server上有了大量投入，Hadoop也應該支持微軟Windows系統的功能，這一點非常重要。

• Hadoop的成功主要得益于企業的參與，而它被采用則是由于有現成的、企業需要的特性。盡管Hadoop 1.X嘗試支持其中的一些企業特性（例如安全），但是還是有其他的企業需求亟待解決。

1.3.1　Yet Another Resource Negotiator（YARN）

在Hadoop 1.X中，資源的分配和任務的執行是由JobTracker完成的。由于計算模型是和集群的資源緊密聯系的，所以只能支持MapReduce一種計算模型。這種緊密的耦合導致開發者強行適配其他的計算模型，從而出現了與MapReduce設計意圖相悖的使用方式。

YARN的主要設計目標是將大家比較關注的資源管理（resource management）和應用執行（application execution）之間的耦合隔離，然后其他的應用模式就可以在Hadoop集群上執行了。增強不同計算模型和各種應用之間的交互，使得集群的資源得到高效的利用，同時也能更好地與企業中已經存在的計算結構集成在一起。

然而，為了達到資源管理和作業管理的低耦合性，也不能犧牲了向后兼容性。在過去的6年里，Hadoop已經引領了大數據并行與分布式處理領域的潮流，這意味著大量的開發、測試和部署已經投入到位了。

YARN能夠保持與Hadoop 1.X（Hadoop-0.20.205+）版本API的向后兼容性。一份老版本的MapReduce程序不做任何代碼修改就能繼續在YARN上執行。當然，重新編譯是必需的。

架構概述

下頁圖展示了YARN的架構。YARN將資源管理的功能抽象成一個叫資源管理器（Resource- Manager，RM）的組件。每個集群都有一個RM，它主要用來跟蹤資源的使用情況，同時也負責資源的分配和解決集群中的資源競爭問題。RM使用通用的資源模型，而且不感知資源的具體情況以及應用使用資源做什么。例如，RM不需要知道資源對應一個Map還是一個Reduce。

Application Master（AM）負責一個作業的調度和執行工作，而且每個應用有一個單獨的AM實例（例如，每個MapReduce作業都有一個AM）。AM向RM請求資源，然后使用資源執行作業，并處理作業執行中可能出現的錯誤。

一般情況下在集群中指定一臺機器以守護進程（daemon）的方式運行RM，RM維護著整個集群的全局狀態和資源分配情況。由于擁有全局的信息，RM可以根據集群的資源使用率做出公平的資源配置。當收到資源請求時，RM動態地分配一個容器（container）給請求方。容器是一個與節點綁定的資源抽象概念，例如，一個節點上的2個CPU和4 GB內存可以作為一個容器。

節點管理器（NodeManager，NM）是集群中每個節點上執行的一個后臺進程，它協助RM做節點的本地資源管理工作。NM承擔容器的管理功能，例如啟動和釋放容器，跟蹤本地資源的使用，以及錯誤通知工作。NM發送心跳信息給RM，而RM通過匯總所有的NM的心跳信息從而了解整個系統的狀態。

作業（job）是直接向RM提交的，RM基于集群的資源可用情況調度作業執行。作業的基本信息保存在可靠的存儲系統中，這樣當RM崩潰后很容易恢復作業重新執行。在一個作業被調度執行后，RM在集群的某個節點上分配一個容器給該作業，作為這個作業的AM。

然后，AM就接管了這個作業的后續處理，包括請求資源、管理任務執行、優化和處理任務的異常。AM可以用任何語言編寫，并且不同版本的AM可以獨立地運行在同一個集群里面。

AM請求的資源明確了本地化信息和期望的資源類型，RM會基于資源分配策略和當前可用資源的情況盡力滿足AM的要求。當AM獲取到一個容器時，它能在容器內執行自己的應用程序，并且可以自由地和這個容器通信，而RM并不知道這些通信的存在。

1.3.2　存儲層的增強

Hadoop 2.X發行版中做了大量的存儲層的增強，它們的主要目的就是為Hadoop在企業中的使用鋪平道路。

1. 高可用

NameNode其實是Hadoop的一個目錄服務，它包含著整個集群存儲的文件的元數據。Hadoop 1.X有一個從NameNode作為冷備節點，它滯后主NameNode節點幾分鐘。而Hadoop 2.X則具備NameNode的熱備節點。當主NameNode節點故障了，從NameNode就能夠在幾分鐘內轉變成主NameNode。如果有熱備份節點，就能夠提供無數據丟失且不間斷的NameNode服務，并且自動故障切換也比較容易實現。

熱備份的關鍵在于維護它的數據盡可能與主NameNode節點保持一致，可以通過讀取主NameNode的寫日志文件并在備份節點上執行來實現，并且延時也是非常低的。寫日志文件的共享可以使用以下兩種方法來實現。

• 在主NameNode和從NameNode節點間使用共享的網絡文件系統（Network File System，NFS）存儲目錄：主NameNode往共享目錄中寫入日志，而從NameNode監聽這個共享目錄的變更消息，然后拉取這些變更。

• 使用一組JournalNode（quorum of Journal Nodes）：主NameNode將寫日志發送到部分JournalNode以記錄信息，而從NameNode持續監聽這些JournalNode，從而更新和同步主NameNode的狀態。

下圖展示了一種使用基于有效配額的存儲系統的高可用實現框架。DateNode需要同時發送數據塊報告信息（block report）到主從兩個NameNode。

ZooKeeper等高可用的監聽服務可以用來跟蹤NameNode的故障，并且可以觸發故障切換的流程，使從NameNode節點提升為主節點。

2. HDFS聯合

類似于YARN對計算層的改進措施，在Hadoop 2.X中也實現了一個更為通用的存儲模型。一個通用的塊存儲（block storage）層已經從文件系統層隔離出來。這種隔離使得其他存儲服務有機會被集成到Hadoop集群中。在此之前，HDFS和塊管理層緊緊地耦合在一起，難以集成其他的存儲服務。

這種通用存儲模型使得HDFS聯合（HDFS Federation）功能得以實現。這個功能允許多個HDFS命名空間使用相同的底層存儲設備，且聯合的NameNode節點提供了文件系統層面的隔離功能。在第10章中，我們會詳細介紹這個特性。

3. HDFS快照

快照（snapshot）是文件系統的整體或部分目錄在某個時間點的只讀鏡像（image），通常是為了以下三個原因：

• 防止用戶的錯誤操作導致的數據損壞或丟失

• 備份

• 容災

快照僅在NameNode上實現，它不會涉及數據從一個數據節點復制到另一個數據節點，而僅僅是復制了塊列表以及文件的大小。生成一個快照的操作幾乎是瞬間完成的，它不會影響NameNode節點的性能。

4. 其他增強功能

在Hadoop 2.X中，還有大量其他的增強功能，如下所示。

• 以前，Hadoop的RPC通信協議是使用Java的Writables序列化實現的，但在Hadoop 2.X是基于Protocol Buffers1實現的。這個改進不僅很容易保持向后兼容，而且幫助集群中的不同組件實現了滾動升級（rolling the upgrades）。另外，RPC也允許在客戶端實現重試功能。

• Hadoop 1.X是不感知存儲設備的類型的，這意味著機械硬盤和SSD（固態硬盤）被無區別對待。用戶無法對數據的布局做任何干預。2014年發布的Hadoop 2.X版本能夠識別存儲設備的類型，并且應用程序可以獲取到這些信息。這樣，應用程序就可以通過這些信息來優化它們的數據存取和布局策略。

• Hadoop 2.X發行版支持HDFS的文件追加功能。

• Hadoop 1.X發行版是通過HDFS客戶端訪問文件系統的。Hadoop 2.X開始支持NFSv3，促進了NFS網關組件的誕生。現在，HDFS可以掛載（mount）到用戶本地兼容的文件系統上，他們可以直接往HDFS下載或上傳文件。往已有的文件追加內容是可以的，但是隨機寫（random write）是不支持的。

• 對Hadoop的I/O進行了大量的改進。例如，在Hadoop 1.X中，當客戶端運行在某個數據節點上時，它需要通過TCP來讀取本地數據。但是，有了本地快捷讀取（short-circuit local reads），客戶端就可以直接讀取本地的數據；通過特定的接口還可以實現零復制（zero-copy）數據讀取；讀或寫數據的CRC校驗碼計算方法也使用英特爾的SSE 4.2 CRC 32指令進行了優化。

1這是谷歌開發的高效序列化組件。——譯者注

1.3.3　支持增強

Hadoop通過支持其他平臺和框架增廣了它支持的應用的范圍。上面我們展示了通過YARN支持其他的計算模型，還有通過塊存儲層支持其他存儲系統。此外還有如下其他方面的支持增強。

• Hadoop 2.X天然支持微軟的Windows系統。這個轉變使得微軟的Windows服務器有極好的機會進入大數據處理領域。當然，部分原因得歸功于Hadoop開發使用的Java編程語言有很好的可移植性，但更重要的原因在于Hadoop對計算和存儲的通用性的增強，使其能支持包括Windows在內的系統。

• 云服務商將Hadoop作為一種按需分配的服務，作為其平臺即服務（Platform-as-a-Service）產品的一部分。Hadoop 2.X支持OpenStack，促進了在云端的彈性和虛擬化部署。

1.4　Hadoop的發行版

如今，Hadoop和其生態圈中的各個組件都成為了一項項復雜的工程。如上所述，Hadoop在不同的發行版本上有很多的代碼分支，同時也有好幾種不同的發行方式。其中，最活躍也是社區參與度最高的，是通過Apache軟件基金會的方式。這是一種免費發行的方式，并且背后有強大的社區支持。同時，Apache Hadoop發行中的社區貢獻影響著Hadoop發展的大方向。Apache Hadoop通過在線論壇的方式提供支持，問題是提交給社區，并由論壇的成員來解答的。

在企業內部部署和管理Apache Hadoop發行版本是很枯燥和繁瑣的。Apache Hadoop使用Java來開發并且針對Linux的文件系統進行了優化。這可能與企業已有的應用程序和基礎架構不匹配。另外，當與Hadoop生態系統的其他組件集成時，Apache Hadoop版本有不少的bug，并且也不夠直觀。

為了解決這樣的問題，出現了幾個為Hadoop提供新的發行模式的公司，主要有三種不同風格的發行方式。

• 第一種風格是為Apache Hadoop發行版提供付費的商業支持和培訓。

• 第二種風格是一些公司通過提供一系列的工具來部署和管理Apache Hadoop。這些公司也為Hadoop生態圈內不同的組件提供健壯的集成層。

• 第三種模式是有些公司通過自己私有的特性和代碼來增強Apache Hadoop，這些特性屬于付費的增強功能，而它們中的大部分是為了解決具體的用戶案例。

所有這些發行版本都以Apache軟件基金會的Hadoop作為共同的源頭。這些版本的用戶，尤其是那些使用第三種模式發行版本的用戶，很可能會集成一些私有代碼到Apache Hadoop中。但是這些發行版本總是和Apache Hadoop保持緊密的聯系并緊跟它的趨勢，而且通常是經過了完善的測試，并能提供深入、及時的支持，為企業減少了大量管理成本。如果使用的并非是Apache Hadoop發行版，那就會因為被束縛于某個服務商而陷入不利的形勢。一個服務商所提供的工具和私有特性往往與其他服務商發布的版本或者其他第三方所提供的工具不兼容，從而產生代碼遷移的費用，而且這個費用不僅僅是指技術上的，還包括機構的培訓、能力規劃和架構調整等。

1.4.1　選哪個Hadoop發行版

自2008年以來，多家公司都提供了Hadoop發行版本，并且各有千秋。對于某家企業或者機構，到底該如何選擇合適的發行版，這需要具體問題具體分析。發行版本的評估標準也各不相同，下面將就重點的幾項進行分析。

1. 性能

讓Hadoop能夠在集群上快速處理數據當然是眾望所歸的一項能力。通常，這一直都是所有性能基準參考標準的重要基礎。這項特殊的性能標準被稱為“吞吐量”（throughput）。Hadoop能夠處理各類分析工作，同時，這些分析工作所支持的使用案例也多種多樣，因此，“延時”（latency）也成為了一項重要的性能標準。為了實現低延時的分析，Hadoop就一定要能夠快速讀取輸入數據并且給出輸出數據，這種輸入到輸出的成本形成了數據處理流程的主要組成部分。

延時是為了得到結果而需要等待的時間，它的度量單位是時間單位，例如毫秒、秒、分鐘或者小時。

吞吐量是在單位時間內能執行操作的數量，它表明在單位時間內能完成的工作量。

無論哪種Hadoop發行版，要想達到低延時的目的，都可以采用擴充硬件規模的方法。然而這種方法的成本很高，而且很快就沒有了提升的空間。從架構上說，低的I/O延時可以采用不同的方法實現。一種方法是減少數據發送器（data source）或數據接收器（data sink）與Hadoop集群之間中間數據駐留層的數量。有些發行版本提供了流（streaming）的方式寫入Hadoop集群，從而減少中間駐留層數。在數據流到存儲系統之前，可以在流層面插入一些用于過濾、壓縮以及輕量級別數據處理的運算符，對數據進行預處理。

Apache Hadoop發行版是使用運行在虛擬機上的Java語言編寫的，盡管它增加了應用程序的可移植性，但是系統負載也隨之升高，比如它在執行的時候由于轉換字節碼解析（byte-code interpretation）以及后臺垃圾回收（garbage collection）而產生額外的間接層。這樣一來，執行速度比直接在目標設備上編譯應用要慢。一些廠商針對特殊的硬件做了優化，提升了每個節點上作業執行的性能。例如，壓縮和解壓特性就可以在某些硬件類型上進行優化。

2. 可擴展性

總有一天，數據的大小會超出一家機構所能提供的計算或存儲資源的物理容量，這就要求我們能夠對計算資源和存儲資源做擴展。自然擴展可以通過垂直擴展或者水平擴展兩種方式實現。垂直擴展（或者稱產品升級）成本較高，而且會受硬件技術發展的限制，此外，缺乏靈活性也是它的一個劣勢。水平擴展（或者稱向外擴展）是對計算和存儲進行擴展的首選方式。

理想情況下，水平擴展僅僅是集群網絡中添加節點和磁盤，因此配置變更最小。然而，對于Hadoop集群的擴容，不同的發行版本其難易程度也不盡相同，主要體現在工作量和成本上。水平擴展可能會大幅增加管理和部署的成本，說不定還需要重寫許多應用程序的代碼。擴展的成本還取決于現有的架構，以及如何讓其與正在評估的Hadoop發行版本兼容。

垂直擴展（或者稱產品升級）是指在系統中的一個單一節點處添加更多的資源，例如，添加更多的CPU、內存或者存儲設備到一臺計算機上。垂直擴展可以增加容量，但是不會減少系統的負載。

水平擴展（或者稱向外擴展）是在系統中添加額外的節點。例如，通過網絡連接添加一臺計算機到一個分布式系統中。由于新機器也承擔了一部分的負載，所以水平擴展能減輕系統負載。然而，集群中單個節點的容量并沒有增加。

3. 可靠性

任何分布式系統都飽受部分故障的困擾。故障可能來自硬件、軟件、網絡問題，而且若在普通硬件上運行，發生故障的間隔時間還會更短。要想成為高可用、高度一致的系統，首要目標都是在處理好這些故障的同時不得中斷服務或破壞數據的完整性。

重視可靠性的發行版都會令其提供的組件具有高可用性。減少單點故障（Single Point of Failures，SPOF）可以確保組件的可用性，而這也意味著需要增加組件的冗余度。在過去很長一段時間內，Apache Hadoop只有唯一一個NameNode，NameNone的硬件故障就意味著整個集群不可用了。現在，由于增加了從NameNode和熱備份的概念，在NameNode故障的時候可以使用它們來恢復NameNode功能。

能夠減少集群管理員手動操作的發行版會更可靠一些。手動的干預往往會導致更高的錯誤率，比如對故障切換的處理。故障切換是系統的危急時刻，因為此時的冗余度較低。這時，任何一個操作錯誤對于應用而言都是致命的。而運用自動故障切換處理，系統就能在較短的時間內恢復運行，故障恢復時間越短，系統的可用性就越好。

無論是正常操作還是處理故障，都必須保證數據的完整性。數據校驗可以檢測到數據中的錯誤并盡可能修復，這就可以確保數據安全，此外還有數據復制、數據鏡像和快照等方式。數據復制會按照一定的冗余度要求來確保數據的可用性。需要密切注意感知機架信息的智能數據布局，以及對復制不足或復制過多的處理方式。鏡像是通過互聯網將數據異步地復制到其他站點，在主站故障的時候可以恢復數據。快照是任何發行版本都期望具有的性能，它不僅有助于災難恢復，而且還能幫助數據的離線訪問。數據分析會涉及大量數據的試驗和評估，而快照就能幫助數據科學家在完成這項工作的同時不破壞分析成果。

4. 可管理性

部署和管理Apache Hadoop開源的發行版需要對代碼和配置有深入的了解，這項技能在IT管理員團隊中可能并不是普遍擁有的。同時，IT管理員需要管理企業大量的系統，Hadoop只是其中的一個。

面對各種不同的Hadoop版本，可能需要對這些版本及其所支持的生態圈內其他組件之間的適用性進行評估。新版本的Hadoop支持集群中執行MapReduce以外的其他應用模式，所以新版本可以根據企業的規劃，更有效地利用企業內的硬件資源。

對于企業而言，要想選擇一個合適的Hadoop發行版，它的管理工具的能力是很關鍵的鑒別標準。管理工具需要提供集中式的集群管理、資源管理、配置管理以及用戶管理。此外，作業調度、自動升級、用戶配額管理和集中的調試功能也是大家希望看到的性能。

集群的健康檢測是管理性功能中另一項重要特性。發行版中最好包含可視化集群健康面板（Dashboard），并且最好有集成其他工具的能力。另外，更便捷的數據訪問也是需要評估的因素，例如，Hadoop上支持POSIX文件系統接口會使工程師和程序員更容易瀏覽和訪問數據，但這也有不利的一面，它使得修改數據成為了可能，事實證明這在某些情況下是存在風險的。

數據安全選項評估同樣至關重要，它包括Hadoop用戶認證、數據授權和數據加密。每家機構和企業可能已經有了自己的授權系統，例如Kerberos或者LDAP。如果Hadoop發行版能夠集成已有的認證系統，它就在節約成本、提高兼容性方面獲得了巨大優勢。細化的授權有助于控制不同層面對數據和作業的訪問權限。當數據遷入或遷出企業集群時，保護數據不被竊取的重要方法是使用加密的傳輸通道。

不同發行版本都會提供與開發和調試工具的集成。如果它所提供的工具能和機構工程師或科學家正在使用的工具有很多重合之處，那也是一個優勢，這不僅體現在購買軟件授權的成本上，而且也體現在更少的培訓和指導上。同時，由于工作人員已經習慣使用這些工具，這也能提高機構的生產力。

1.4.2　可用的發行版

當前有好幾種可用的Hadoop發行版，具體列表可參見網站：http://wiki.apache.org/hadoop/Distributions%20and%20Commercial%20Support。我們將選擇其中4個進行詳細探討：

• Cloudera Distribution of Hadoop（CDH）

• Hortonworks Data Platform（HDP）

• MapR

• Pivotal HD

1. Cloudera Distribution of Hadoop

Cloudera公司創建于2009年3月，它的主營業務是提供Hadoop軟件、支持、服務和企業級Hadoop及其生態圈組件部署培訓。這套軟件被稱為Cloudera Distribution of Hadoop。作為Apache軟件基金會的贊助商之一，該公司在提供Hadoop支持和服務的同時，將大部分對Hadoop的增強功能合并到了Apache Hadoop的主線中。

CDH現在已升級到第五個主版本（CDH5.X），并且被認為是一個成熟的Hadoop發行版。它的付費版本包含一個獨家的管理軟件——Cloudera Manager。

2. Hortonworks Data Platform

2011年1月，雅虎公司的Hadoop團隊出走創建了Hortonworks公司，它的主營業務類似于Cloudera。他們的發行版稱為Hortonworks Data Platform。HDP提供的Hadoop和其他軟件是完全免費的，只對技術支持和培訓收費。Hortonworks也將增強功能合入到Apache Hadoop主線中。

HDP當前已升級到第二個主版本，被認為是Hadoop發行版中一顆冉冉升起的新星。它擁有一款免費并開源的管理軟件——Ambari。

3. MapR

MapR創建于2009年，它的使命是提供企業級的Hadoop。它的Hadoop發行版相較于Apache Hadoop提供了大量的私有代碼，其中一些組件他們承諾會與現有的Apache Hadoop項目保持兼容。MapR發行版的關鍵私有代碼是使用了POSIX兼容的網絡文件系統（POSIX-compatible NFS）來替換HDFS，另一個關鍵特性是支持快照功能。

MapR擁有自己的管理控制臺（management console）。不同級別的版本分別命名為M3、M5和M7。其中，M5是他們的標準商業版本；M3是免費版本，但可用性不高；M7是付費版，具有重寫的HBase API。

4. Pivotal HD

Greenplum是EMC公司一個主要的并行數據存儲產品，EMC將Greenplum集成到Hadoop中，形成了一個較高級的Hadoop發行版本——Pivotal HD。這種整合減少了Greenplum與HDFS之間的數據導入和導出操作，從而減少了成本和延時。

Pivotal HD提供的HAWQ技術能夠高效、低延時地對HDFS中的數據進行查詢，在某些MapReduce工作上相對于Apache Hadoop有100倍的性能提升。HAWQ支持在Hadoop上使用SQL處理數據，使得熟悉SQL的用戶能加入到Hadoop的大家庭中。

1.5　小結

本章，我們展示了Hadoop的演進、里程碑和發行版本，深入了解了Hadoop 2.X以及它給Hadoop帶來的變化。從本章中學到的主要內容如下。

• MapReduce是由于互聯網規模的數據收集、處理和索引需求而誕生的，Apache Hadoop是MapReduce計算模型的一個開源發行版本。

• 在Hadoop 6年的發展歷程中，它變成了大數據并行和分布式計算領域的首選框架。社區已經為Hadoop在企業中運用做好了準備。Hadoop 1.X版本實現了HDFS的文件追加功能和安全特性，這是對企業用戶非常有利的關鍵特性。

• MapReduce支持的使用實例有限，通過融入其他的應用模式，Hadoop擴展了它在數據分析領域的領地，并增加了集群資源的利用率。在Hadoop 2.X中，JobTracker被分解，而YARN可以處理集群資源管理和作業調度。MapReduce屬于能夠運行在YARN上的一種應用模式。

• Hadoop 2.X將塊管理器從文件系統層隔離出來，從而增強了它的存儲層。這樣它能支持多命名空間并集成其他類型的文件系統。Hadoop 2.X還對存儲可用性和快照方面進行了改進。

• Hadoop的各種發行版都提供了企業級的管理軟件、工具、技術支持、培訓和其他服務。它們中的大部分在功能上都勝于Apache Hadoop。

MapReduce依然是Hadoop核心中不可分割的部分。在下一章，我們將探討MapReduce的優化和最佳實踐。

from:?http://www.ituring.com.cn/tupubarticle/8410

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的《精通Hadoop》：第 1 章　Hadoop 2.X的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。