Hadoop權威指南（第3版 修訂版） [Hadoop: The Definitive Guide，3rd Edition] pdf epub mobi txt 電子書 下載 2025

簡體網頁||繁體網頁

☆☆☆☆☆

[美] Tom White 著，華東師範大學數據科學與工程學院 譯

圖書標籤:

• Hadoop
• 大數據
• 分布式存儲
• 分布式計算
• MapReduce
• YARN
• HDFS
• 數據分析
• 雲計算
• Java

齣版社： 清華大學齣版社

ISBN：9787302370857

版次：3

商品編碼：11566298

品牌：清華大學

包裝：平裝

外文名稱：Hadoop: The Definitive Guide，3rd Edition

開本：16開

齣版時間：2015-01-01

用紙：膠版紙

頁數：716

正文語種：中文

産品特色

編輯推薦

　　新版新特色，內容更詳細，更適閤收藏和找Hadoop之父簽名兒！

內容簡介

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

作者簡介

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

目錄

第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的一些典型應用。
　　......

前言/序言

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

評分☆☆☆☆☆

好好好好好好好好好好好好好好好好好好好好

評分☆☆☆☆☆

好好好好好好好好好好好好好好好

評分☆☆☆☆☆

以前不知道寫評論可以得京豆，浪費瞭很多京豆，現在知道瞭京豆的用處，可以抵現，就不會忘記評論瞭，把這段話留下來，隨時可以評價，走到哪評價到哪，既方便又可以得京豆哦！京東自己得快遞還是很快的，而且東西質量也有保證，是正品哦！以後買東西就在京東啦！

評分☆☆☆☆☆

書不錯加油好好乾

評分☆☆☆☆☆

hadoop學習必看書籍之一，對於瞭解hadoop有很好的幫助效果；

評分☆☆☆☆☆

經典之作，很好很喜歡，推薦給大傢。

評分☆☆☆☆☆

好好好，專業有用，十分好

評分☆☆☆☆☆

中文版，挺好的！！！！

評分☆☆☆☆☆

書是中文版的，還沒開始看，應該還可以。