Hadoop權威指南(第3版)（簡體書）

準備好釋放數據的強大潛能了嗎？借助于這本《Hadoop權威指南》，你將學習如何使用ApacheHadoop構建和維護穩定性高、伸縮性強的分布式系統。本書是為程序員寫的，可幫助他們分析任何大小的數據集。本書同時也是為管理員寫的，幫助他們了解如何設置和運行Hadoop集群。
《Hadoop權威指南（第3版 修訂版）》通過豐富的案例學習來解釋Hadoop的幕后機理，闡述了Hadoop如何解決現實生活中的具體問題。第3版覆蓋Hadoop的最新動態，包括新增的MapReduceAPI，以及MapReduce2及其靈活性更強的執行模型（YARN）。

Tom White，數學王子&Hadoop專家。身為Apache Hadoop提交者八年之久，Apache軟件基金會成員之一。全球知名云計算公司Cloudera的軟件工程師。Tom擁有英國劍橋大學數學學士學位和利茲大學科學哲學碩士學位。

新版新特色，內容更權威，更適合收藏和找Hadoop之父簽名兒！
2014年12月13日中國大數據大會
歡迎光臨新云南皇冠假日酒店，與Hadoop之父DougCutting不見不散！

數學科普作家馬丁?加德納(Martin Gardner)曾在一次采訪中談到：
“在我的世界里，只有微積分。這是我的專欄 取得成功奧秘。我花了很多時間才明白如何以大多數讀者都能明白的方式將自己所知道的東西娓娓道來。” ^
這也是我對Hadoop的諸多感受。它的內部工作機制非常復雜，是一個集分布式系統理論、實際工程和常識于一體的系統。而且，對門外漢而言，Hadoop更像是“天外來客”。^
但Hadoop其實并沒有那么讓人費解，抽絲剝繭，我們來看它的“廬山真面目”。它提供的用于構建分布式系統的每個工具(用于數據存儲、數據分析和協調處理)都非常簡單。如果說這些工具有一個共同的主題，那就是它們更抽象，對偶爾有大量數據需要存儲的程序員、有大量數據需要分析的程序員、有大量計算機需要管理的程序員同時卻沒有足夠的時間、技能或者不想成為分布式系統專家的程序員提供一套組件，使其能夠利用Hadoop來構建基礎平臺。^
這樣一個簡單、通用的特性集，促使我在開始使用Hadoop時便明顯感覺到Hadoop真的值得推廣。但最開始的時候(2006年初)，安裝、配置和Hadoop應用編程是一門高深的藝術。之后，情況確實有所改善：文檔增多了；示例增多了；碰到問題時，可以向大量活躍的郵件列表發郵件求助。對新手而言，最大的障礙是理解Hadoop有哪些能耐，它擅長什么，它如何使用。這些問題使我萌發了寫作本書的動機。^
Apache Hadoop社區的發展來之不易。在過去的三年多時間里，Hadoop項目開花結果并孵化出大約半打子項目。到目前，它在性能、可靠性、可擴展性和可管理性方面都實現了巨大的飛躍。但是，為了讓更多人采用Hadoop，我認為我們要讓Hadoop更好用。這需要創建更多新的工具，集成更多的系統，創建新的、改進的API。我希望我自己能夠參與，同時也希望本書能夠鼓勵并吸引其他人也參與Hadoop項目。

第1章 初識Hadoop
1.1 數據！數據！
1.2 數據的存儲與分析
1.3 相較于其他系統的優勢
1.3.1 關系型數據庫管理系統
1.3.2 網格計算
1.3.3 志愿計算
1.4 Hadoop發展簡史
1.5 Apache Hadoop和Hadoop生態系統
1.6 Hadoop的發行版本
1.6.1 本書包含的內容
1.6.2 兼容性
第2章 關于MapReduce
2.1 氣象數據集
2.2 使用Unix工具來分析數據
2.3 使用Hadoop來分析數據
2.3.1 map和reduce
2.3.2 Java MapReduce
2.4 橫向擴展
2.4.1 數據流
2.4.2 combiner函數
2.4.3 運行分布式的MapReduce作業
2.5 Hadoop Streaming
2.5.1 Ruby版本
2.5.2 Python版本
2.6 Hadoop Pipes
第3章 Hadoop分布式文件系統
3.1 HDFS的設計
3.2 HDFS的概念
3.2.1 數據塊
3.2.2 namenode和datanode
3.2.3 聯邦HDFS
3.2.4 HDFS的高可用性
3.3 命令行接口
3.4 Hadoop文件系統
3.5 Java接口
3.5.1 從Hadoop URL讀取數據
3.5.2 通過FileSystem API讀取數據
3.5.3 寫入數據
3.5.4 目錄
3.5.5 查詢文件系統
3.5.6 刪除數據
3.6 數據流
3.6.1 剖析文件讀取
3.6.2 剖析文件寫入
3.6.3 一致模型
3.7 通過Flume和Sqoop導入數據
3.8 通過distcp并行復制
3.9 Hadoop存檔
3.9.1 使用Hadoop存檔工具
3.9.2 不足
第4章 Hadoop的I/O操作
4.1 數據完整性
4.1.1 HDFS的數據完整性
4.1.2 LocalFileSystem
4.1.3 ChecksumFileSystem
4.2 壓縮
4.2.1 codec
4.2.2 壓縮和輸入分片
4.2.3 在MapReduce中使用壓縮
4.3 序列化
4.3.1 Writable接口
4.3.2 Writable類
4.3.3 實現定制的Writable集合
4.3 序列化框架
4.4 Avro
4.4.1 Avro數據類型和模式
4.4.2 內存中的序列化和反序列化
4.4.3 Avro數據文件
4.4.4 互操作性
4.4.5 模式的解析
4.4.6 排列順序
4.4.7 關于Avro MapReduce
4.4.8 使用Avro MapReduce進行排序
4.4.9 其他語言的Avro MapReduce
4.5 基于文件的數據結構
4.5.1 關于SequenceFile
4.5.2 關于MapFile
第5章 MapReduce應用開發
5.1 用于配置的API
5.1.1 資源合并
5.1.2 可變的擴展
5.2 配置開發環境
5.2.1 管理配置
5.2.2 輔助類GenericOptionsParser，Tool和ToolRunner
5.3 用MRUnit來寫單元測試
5.3.1 關于Mapper
5.3.2 關于Reducer
5.4 本地運行測試數據
5.4.1 在本地作業運行器上運行作業
5.4.2 測試驅動程序
5.5 在集群上運行
5.5.1 打包作業
5.5.2 啟動作業
5.5.3 MapReduce的Web界面
5.5.4 獲取結果
5.5.5 作業調試
5.5.6 Hadoop日志
5.5.7 遠程調試
5.6 作業調優
5.7 MapReduce的工作流
5.7.1 將問題分解成MapReduce作業
5.7.2 關于JobControl
5.7.3 關于Apache Oozie
第6章 MapReduce的工作機制
6.1 剖析MapReduce作業運行機制
6.1.1 經典的MapReduce (MapReduce 1)
6.1.2 YARN (MapReduce 2)
6.2 失敗
6.2.1 經典MapReduce中的失敗
6.2.2 YARN中的失敗
6.3 作業的調度
6.3.1 公平調度器
6.3.2 容量調度器
6.4 shuffle和排序
6.4.1 map端
6.4.2 reduce端
6.4.3 配置調優
6.5 任務的執行
6.5.1 任務執行環境
6.5.2 推測執行
6.5.3 關于OutputCommitters
6.5.4 任務JVM重用
6.5.5 跳過壞記錄
第7章 MapReduce的類型與格式
7.1 MapReduce的類型
7.1.1 默認的MapReduce作業
7.1.2 默認的Streaming作業
7.2 輸入格式
7.2.1 輸入分片與記錄
7.2.2 文本輸入
7.2.3 二進制輸入
7.2.4 多個輸入
7.2.5 數據庫輸入(和輸出)
7.3 輸出格式
7.3.1 文本輸出
7.3.2 二進制輸出
7.3.3 多個輸出
7.3.4 延遲輸出
7.3.5 數據庫輸出
第8章 MapReduce的特性
8.1 計數器
8.1.1 內置計數器
8.1.2 用戶定義的Java計數器
8.1.3 用戶定義的Streaming計數器
8.2 排序
8.2.1 準備
8.2.2 部分排序
8.2.3 全排序
8.2.4 輔助排序
8.3 連接
8.3.1 map端連接
8.3.2 reduce端連接
8.4 邊數據分布
8.4.1 利用JobConf來配置作業
8.4.2 分布式緩存
8.5 MapReduce庫類
第9章 構建Hadoop集群
9.1 集群規范
9.2 集群的構建和安裝
9.2.1 安裝Java
9.2.2 創建Hadoop用戶
9.2.3 安裝Hadoop
9.2.4 測試安裝
9.3 SSH配置
9.4 Hadoop配置
9.4.1 配置管理
9.4.2 環境設置
9.4.3 Hadoop守護進程的關鍵屬性
9.4.4 Hadoop守護進程的地址和端口
9.4.5 Hadoop的其他屬性
9.4.6 創建用戶帳號
9.5 YARN配置
9.5.1 YARN守護進程的重要屬性
9.5.2 YARN守護進程的地址和端口
9.6 安全性
9.6.1 Kerberos和Hadoop
9.6.2 委托令牌
9.6.3 其他安全性改進
9.7 利用基準評測程序測試Hadoop集群
9.7.1 Hadoop基準評測程序
9.7.2 用戶作業
9.8 云端的Hadoop
第10章 管理Hadoop
10.1 HDFS
10.1.1 永久性數據結構
10.1.2 安全模式
10.1.3 日志審計
10.1.4 工具
10.2 監控
10.2.1 日志
10.2.2 度量
10.2.3 Java管理擴展(JMX)
10.3 維護
10.3.1 日常管理過程
10.3.2 委任和解除節點
10.3.3 升級
第11章 關于Pig
11.1 安裝與運行Pig
11.1.1 執行類型
11.1.2 運行Pig程序
11.1.3 Grunt
11.1.4 Pig Latin編輯器
11.2 示例
11.3 與數據庫進行比較
11.4 Pig Latin
11.4.1 結構
11.4.2 語句
11.4.3 表達式
11.4.4 類型
11.4.5 模式
11.4.6 函數
11.4.7 宏
11.5 用戶自定義函數
11.5.1 過濾UDF
11.5.2 計算UDF
11.5.3 加載UDF
11.6 數據處理操作
11.6.1 數據的加載和存儲
11.6.2 數據的過濾
11.6.3 數據的分組與連接
11.6.4 數據的排序
11.6.5 數據的組合和切分
11.7 Pig實戰
11.7.1 并行處理
11.7.2 參數代換
第12章 關于Hive
12.1 安裝Hive
12.2 示例
12.3 運行Hive
12.3.1 配置Hive
12.3.2 Hive服務
12.3.3 Metastore
12.4 Hive與傳統數據庫相比
12.4.1 讀時模式vs.寫時模式
12.4.2 更新、事務和索引
12.5 HiveQL
12.5.1 數據類型
12.5.2 操作與函數
12.6 表
12.6.1 托管表和外部表
12.6.2 分區和桶
12.6.3 存儲格式
12.6.4 導入數據
12.6.5 表的修改
12.6.6 表的丟棄
12.7 查詢數據
12.7.1 排序和聚集
12.7.2 MapReduce腳本
12.7.3 連接
12.7.4 子查詢
12.7.5 視圖
12.8 用戶定義函數
12.8.1 寫UDF
12.8.2 寫UDAF
第13章 關于HBase
13.1 HBase基礎
13.2 概念
13.3.1 數據模型的"旋風之旅"
13.3.2 實現
13.3 安裝
13.4 客戶端
13.4.1 Java
13.4.2 Avro、REST和Thrift
13.5 示例
13.5.1 模式
......

初識Hadoop
在古時候，人們用牛來拉重物。當一頭牛拉不動一根圓木時，人們從來沒有考慮過要培育更強壯的牛。同理，我們也不該想方設法打造超級計算機，而應該千方百計綜合利用更多計算機來解決問題。
——格蕾斯·霍珀(Grace Hopper)
1.1 數據！數據！
我們生活在這個數據大爆炸的時代，很難估算全球電子設備中存儲的數據總共有多少。國際數據公司(IDC)曾經發布報告稱，2006年數字世界(digital universe)項目統計得出全球數據總量為0.18 ZB并預測在2011年將達到1.8 ZB。 1 ZB等于1021字節，等于1000 EB(exabytes)，1 000 000 PB (petabytes)，等于大家更熟悉的10億TB(terrabytes)！這相當于全世界每人一個硬盤中保存的數據總量！
數據“洪流”有很多來源。以下面列出的為例：
紐約證交所每天產生的交易數據多達1 TB
臉譜網(Facebook)存儲的照片約100 億張，存儲容量約為 1 PB
家譜網站Ancestry.com存儲的數據約為2.5 PB
互聯網檔案館(The Internet Archive)存儲的數據約為2 PB，并以每月至少20 TB的速度持續增長
瑞士日內瓦附近的大型強子對撞機每年產生的數據約為15 PB
還有其他大量的數據。但是你可能會想它對自己又有哪些影響呢？地球人都知道，大部分數據都嚴密鎖存在一些大型互聯網公司(如搜索引擎公司)或科學機構與金融機構中。難道所謂的“大數據”只影響小機構和個人？
我個人是這樣認為的。以照片為例，我妻子的爺爺是一個骨灰級的攝影愛好者。在成年之后，他一直都在拍照。他的整個相冊，包括普通膠片、幻燈片、35mm膠片，在掃描成高分辨率的圖片之后，大約有10 GB。相比之下，在2008年，我家用數碼相機拍攝的照片總共有5 GB。對照爺爺的照片生成速度，我家是他老人家的35倍！并且，而且這個速度還在不斷增長中，因為現在拍照片真的是越來越容易了。
有句話說得好：“大數據勝于好算法。” 意思是說對于某些應用 (譬如根據以往的偏好來推薦電影和音樂)，不論算法有多牛，基于小數據的推薦效果往往都不如基于大量可用數據的一般算法的推薦效果。
現在，我們已經有了大量數據，這是個好消息。但不幸的是，我們必須想方設法好好地存儲和分析這些數據。
1.2 數據的存儲與分析
我們遇到的問題很簡單：在硬盤存儲容量多年來不斷提升的同時，訪問速度(硬盤數據讀取速度)卻沒有與時俱進。1990年，一個普通硬盤可以存儲1370 MB數據，傳輸速度為4.4 MB/s ，因此只需要5分鐘就可以讀完整個硬盤中的數據。20年過去了，1 TB的硬盤已然成為主流，但其數據傳輸速度約為100 MB/s，讀完整個硬盤中的數據至少得花2.5個小時。
讀完整個硬盤中的數據需要更長時間，寫入數據就別提了。一個很簡單的減少讀取時間的辦法是同時從多個硬盤上讀數據。試想，如果我們有100個硬盤，每個硬盤存儲1%的數據，并行讀取，那么不到兩分鐘就可以讀完所有數據。
僅使用硬盤容量的1%似乎很浪費。但是我們可以存儲100個數據集，每個數據集1 TB，并實現共享硬盤的讀取。可以想象，用戶肯定很樂于通過硬盤共享來縮短數據分析時間；并且，從統計角度來看，用戶的分析工作都是在不同時間點進行的，所以彼此之間的干擾并不太大。
雖然如此，但要對多個硬盤中的數據并行進行讀寫數據，還有更多問題要解決。第一個需要解決的是硬件故障問題。一旦開始使用多個硬件，其中個別硬件就很有可能發生故障。為了避免數據丟失，最常見的做法是復制(replication)：系統保存數據的復本(replica)，一旦有系統發生故障，就可以使用另外保存的復本。例如，冗余硬盤陣列(RAID)就是按這個原理實現的，另外，Hadoop的文件系統(HDFS，Hadoop Distributed FileSystem)也是一類，不過它采取的方法稍有不同，詳見后文的描述。
第二個問題是大多數分析任務需要以某種方式結合大部分數據來共同完成分析，即從一個硬盤讀取的數據可能需要與從另外99個硬盤中讀取的數據結合使用。各種分布式系統允許結合不同來源的數據進行分析，但保證其正確性是一個非常大的挑戰。MapReduce提出一個編程模型，該模型抽象出這些硬盤讀寫問題并將其轉換為對一個數據集(由鍵值對組成)的計算。后文將詳細討論這個模型，這樣的計算由map和reduce兩部分組成，而且只有這兩部分提供對外的接口。與HDFS類似，MapReduce自身也有很高的可靠性。
簡而言之，Hadoop為我們提供了一個可靠的共享存儲和分析系統。HDFS實現數據的存儲，MapReduce實現數據的分析和處理。雖然Hadoop還有其他功能，但HDFS和MapReduce是它的核心價值。
1.3 相較于其他系統的優勢
MapReduce看似采用了一種蠻力方法。每個查詢需要處理整個數據集或至少一個數據集的絕大部分。但反過來想，這也正是它的能力。MapReduce是一個批量查詢處理器，能夠在合理的時間范圍內處理針對整個數據集的動態查詢。它改變了我們對數據的傳統看法，解放了以前只是保存在磁帶和硬盤上的數據。它讓我們有機會對數據進行創新。以前需要很長時間處理才能獲得結果的問題，到現在變得頃刻之間就迎刃而解，同時還可以引發新的問題和新的見解。
例如，Rackspace公司的郵件部門Mailtrust就用Hadoop來處理郵件日志。他們寫動態查詢，想借此找出用戶的地理分布。他們是這么描述的：“這些數據非常有用，我們每月運行一次MapReduce任務來幫助我們決定哪些Rackspace數據中心需要添加新的郵件服務器。”
通過整合好幾百GB的數據，用MapReduce來分析這些數據，Rackspace的工程師從中發現了以前從來沒有注意到的數據，甚至還運用這些信息來改善了現有的服務。第16章將詳細介紹Rackspace公司內部是如何使用Hadoop的。
1.3.1 關系型數據庫管理系統
為什么不能用數據庫來對大量硬盤上的大規模數據進行批量分析呢？我們為什么需要MapReduce？
這兩個問題的答案來自于計算機硬盤的另一個發展趨勢：尋址時間的提升遠遠不敵于傳輸速率的提升。尋址是將磁頭移動到特定硬盤位置進行讀寫操作的過程。它是導致硬盤操作延遲的主要原因，而傳輸速率取決于硬盤的帶寬。
如果數據訪問模式中包含大量的硬盤尋址，那么讀取大量數據集就必然會花更長的時間(相較于流數據讀取模式，流讀取主要取決于傳輸速率)。另一方面，如果數據庫系統只更新一小部分記錄，那么傳統的B樹就更有優勢(關系型數據庫中使用的一種數據結構，受限于尋址的比例)。但數據庫系統如果有大量數據更新時，B樹的效率就明顯落后于MapReduce，因為需要使用“排序/合并“(sort/merge)來重建數據庫。
在許多情況下，可以將MapReduce視為關系型數據庫管理系統的補充。兩個系統之間的差異如表1-1所示。
MapReduce比較適合以批處理方式處理需要分析整個數據集的問題，尤其是動態分析。RDBMS適用于點查詢 (point query)和更新，數據集被索引之后，數據庫系統能夠提供低延遲的數據檢索和快速的少量數據更新。MapReduce適合一次寫入、多次讀取數據的應用，關系型數據庫則更適合持續更新的數據集。
表1-1. 關系型數據庫和MapReduce的比較
傳統的關系型數據庫 MapReduce
數據大小 GB PB
數據存取 交互式和批處理 批處理
更新 多次讀/寫 一次寫入，多次讀取
結構 靜態模式 動態模式
完整性 高 低
橫向擴展 非線性的 線性的
MapReduce和關系型數據庫之間的另一個區別在于它們所操作的數據集的結構化程度。結構化數據(structured data)是具有既定格式的實體化數據，如XML文檔或滿足特定預定義格式的數據庫表。這是RDBMS包括的內容。另一方面，半結構化數據(semi-structured data)比較松散，雖然可能有格式，但經常被忽略，所以它只能作為對數據結構的一般性指導。例如電子表格，它在結構上是由單元格組成的網格，但是每個單元格內可以保存任何形式的數據。非結構化數據(unstructured data)沒有什么特別的內部結構，例如純文本或圖像數據。MapReduce對非結構化或半結構化數據非常有效，因為它是在處理數據時才對數據進行解釋。換句話說，MapReduce輸入的鍵和值并不是數據固有的屬性，而是由分析數據的人來選的。
關系型數據往往是規范的(normalized)，以保持其數據的完整性且不含冗余。規范給MapReduce帶來了問題，因為它使記錄讀取成為非本地操作，而MapReduce的核心假設之一偏偏就是可以進行(高速的)流讀寫操作。
Web服務器日志是典型的非規范化數據記錄(例如，每次都需要記錄客戶端主機全名，這會導致同一客戶端的全名可能多次出現)，這也是MapReduce非常適用于分析各種日志文件的原因之一。
MapReduce是一種線性的可伸縮編程模型。程序員要寫兩個函數，分別為map函數和reduce函數，每個函數定義從一個鍵值對集合到另一個鍵值對集合的映射。這些函數不必關注數據集及其所用集群的大小，可以原封不動地應用于小規模數據集或大規模的數據集。更重要的是，如果輸入的數據量是原來的兩倍，那么運行時間也需要兩倍。但如果集群是原來的兩倍，作業的運行速度卻仍然與原來一樣快。SQL查詢一般不具備該特性。
但是，在不久的將來，關系型數據庫系統和MapReduce系統之間的差異很可能變得模糊。關系型數據庫都開始吸收MapReduce的一些思路(如Aster Data的數據庫和GreenPlum的數據庫)，另一方面，基于MapReduce的高級查詢語言(如Pig和Hive)使傳統數據庫的程序員更容易接受MapReduce系統。
1.3.2 網格計算
高性能計算(High Performance Computing，HPC)和網格計算(Grid Computing)組織多年以來一直在研究大規模數據處理，主要使用類似于消息傳遞接口(Message Passing Interface，MPI)的API。從廣義上講，高性能計算采用的方法是將作業分散到集群的各臺機器上，這些機器訪問存儲區域網絡(SAN)所組成的共享文件系統。這比較適用于計算密集型的作業，但如果節點需要訪問的數據量更龐大 (高達幾百GB，MapReduce開始施展它的魔法)，很多計算節點就會因為網絡帶寬的瓶頸問題不得不閑下來等數據。
MapReduc盡量在計算節點上存儲數據，以實現數據的本地快速訪問。 數據本地化(data locality)特性是MapReduce的核心特征，并因此而獲得良好的性能。意識到網絡帶寬是數據中心環境最珍貴的資源(到處復制數據很容易耗盡網絡帶寬)之后，MapReduce通過顯式網絡拓撲結構來保留網絡帶寬。注意，這種排列方式并沒有降低MapReduce對計算密集型數據進行分析的能力。
雖然MPI賦予程序員很大的控制權，但需要程序員顯式控制數據流機制，包括用C語言構造底層的功能模塊(例如套接字)和高層的數據分析算法。而MapReduce則在更高層次上執行任務，即程序員僅從鍵值對函數的角度考慮任務的執行，而且數據流是隱含的。
在大規模分布式計算環境下，協調各個進程的執行是一個很大的挑戰。最困難的是合理處理系統的部分失效問題——在不知道一個遠程進程是否掛了的情況下——同時還需要繼續完成整個計算。有了MapReduce，程序員不必操心系統部分失效的問題，因為它自己的系統實現能夠檢測到并重新執行那些失敗的map或reduce任務。正因為采用的是無共享(shared-nothing)框架，MapReduce才能夠實現失敗檢測，這意味著各個任務之間是彼此獨立的。 因此，從程序員的角度來看，任務的執行順序無關緊要。相比之下，MPI程序必須顯式管理自己的檢查點和恢復機制，雖然賦予程序員的控制權加大了，但編程的難度也增加了。
MapReduce聽起來似乎是一個相當嚴格的編程模型，而且在某種意義上看的確如此：限定用戶使用有特定關聯的鍵值對，mapper和reducer彼此間的協調非常有限(每個mapper將鍵值對傳給reducer)。由此，我們自然聯想到一個問題：能用這個編程模型做一些有用或實際的事情嗎？
答案是肯定的。MapReduce由谷歌的工程師開發，用于構建搜索引擎的索引，而且，事實已經證明它能夠一次又一次地解決這個問題(MapReduce 的靈感來自于傳統的函數式編程、分布式計算和數據庫社區)，但此后，該模型在其他行業還有著很多其他的應用。我們欣喜地發現，有很多算法都可以用 MapReduce來表達，從圖像圖形分析到各種各樣基于圖像分析的問題，再到機器學習算法。 當然，它也不是包治百病的靈丹妙藥，不能解決所有問題，但它真的是一個很通用的數據處理工具。
我們將在第16章介紹Hadoop的一些典型應用。
......