Hadoop權威指南：大數據的存儲與分析(第4版) pdf epub mobi txt 電子書下載 2025

簡體網頁||繁體網頁

☆☆☆☆☆

[美] 湯姆，懷特（Tom White）著，王海，華東，劉喻，呂粵海譯

下載連結在頁面底部

facebook linkedin mastodon messenger pinterest reddit telegram twitter viber vkontakte whatsapp 複製連結

想要找書就要到靜流書站

windowsfront.com

立刻按 ctrl+D收藏本頁

你會得到大驚喜!!

齣版社：清華大學齣版社

ISBN：9787302465133

版次：4

商品編碼：12109713

包裝：平裝

開本：16開

齣版時間：2017-07-01

用紙：純質紙

頁數：732

字數：594000

正文語種：中文

具體描述

産品特色

編輯推薦

本書結閤理論和實踐，由淺入深，全方位介紹瞭Hadoop 這一高性能的海量數據處理和分析平颱。全書5部分24 章，第Ⅰ部分介紹Hadoop 基礎知識，第Ⅱ部分介紹MapReduce,第Ⅲ部分介紹Hadoop 的運維，第Ⅳ部分介紹Hadoop 相關開源項目，第Ⅴ部分提供瞭三個案例，分彆來自醫療衛生信息技術服務商塞納(Cerner)、微軟的人工智能項目ADAM(一種大規模分布式深度學習框架)和開源項目Cascading(一個新的針對MapReduce 的數據處理API)。本書是一本專業、全麵的Hadoop 參考書和工具書，闡述瞭Hadoop 生態圈的新發展和應用，程序員可以從中探索海量數據集的存儲和分析，管理員可以從中瞭解Hadoop 集群的安裝和運維。

內容簡介

　　本書結閤理論和實踐，由淺入深，全方位介紹瞭Hadoop這一高性能的海量數據處理和分析平颱。全書5部分24章，第Ⅰ部分介紹Hadoop基礎知識，主題涉及Hadoop、MapReduce、Hadoop分布式文件係統、YARN、Hadoop的I/O操作。第Ⅱ部分介紹MapReduce,主題包括MapReduce應用開發；MapReduce的工作機製、MapReduce的類型與格式、MapReduce的特性。第Ⅲ部分介紹Hadoop的運維，主題涉及構建Hadoop集群、管理Hadoop。第Ⅳ部分介紹Hadoop相關開源項目，主題涉及Avro、Parquet、Flume、Sqoop、Pig、Hive、Crunch、Spark、HBase、ZooKeeper。第Ⅴ部分提供瞭三個案例，分彆來自醫療衛生信息技術服務商塞納(Cerner)、微軟的人工智能項目ADAM(一種大規模分布式深度學習框架)和開源項目Cascading(一個新的針對MapReduce的數據處理API)。

　　本書是一本專業、全麵的Hadoop參考書和工具書，闡述瞭Hadoop生態圈的新發展和應用，程序員可以從中探索海量數據集的存儲和分析，管理員可以從中瞭解Hadoop集群的安裝和運維。

作者簡介

　　TomWhite是傑齣的Hadoop專傢之一。自2007年2月以來，TomWhite一直是ApacheHadoop的提交者(committer)，也是Apache軟件基金會的成員。Tom是Cloudera的軟件工程師，他是Cloudera的首批員工，對Apache和Cloudera做齣瞭舉足輕重的貢獻。在此之前，他是一名獨立的Hadoop顧問，幫助公司搭建、使用和擴展Hadoop。他是很多行業大會的專題演講人，比如ApacheCon、OSCON和Strata。Tom在英國劍橋大學獲得數學學士學位，在利茲大學獲得科學哲學碩士學位。他目前與傢人居住在威爾士。

　　譯者簡介

　　王海博士，解放軍理工大學通信工程學院教授，博導，教研中心主任，長期從事無綫自組網網絡的設計與研發工作，主持國傢自然科學基金、國傢863計劃課題等多項課題，近5年獲軍隊科技進步二等奬1項，三等奬6項，作為di一發明人申請國傢發明專利十餘項，發錶學術論文50餘篇。

　　華東博士，現任南京醫科大學計算機教研室教師，一直緻力於計算機輔助教學的相關技術研究，陸續開發瞭人體解剖學網絡自主學習考試平颱、診斷學自主學習平颱和麵嚮執業醫師考試的預約化考試平颱等係統，並在各個學科得到廣泛的使用，獲得全國高等學校計算機課件評比一等奬和三等奬各一項。主編、副主編教材兩部，獲發明專利一項、軟件著作權多項。

　　劉喻博士，長期從事軟件開發、軟件測試和軟件工程化管理工作，目前任教於清華大學軟件所。

　　呂粵海，長期從事軍事通信網絡技術研究與軟件開發工作，先後通過華為光網絡高級工程師認證、思科網絡工程師認證。

精彩書摘

　　第3章Hadoop分布式文件係統

　　當數據集的大小超過一颱獨立的物理計算機的存儲能力時，就有必要對它進行分區(partition)並存儲到若乾颱單獨的計算機上。管理網絡中跨多颱計算機存儲的文件係統稱為分布式文件係統(distributedfilesystem)。該係統架構於網絡之上，勢必會引入網絡編程的復雜性，因此分布式文件係統比普通磁盤文件係統更為復雜。例如，使文件係統能夠容忍節點故障且不丟失任何數據，就是一個極大的挑戰。

　　Hadoop自帶一個稱為HDFS的分布式文件係統，即HadoopDistributedFilesystem。在非正式文檔或舊文檔以及配置文件中，有時也簡稱為DFS，它們是一迴事兒。HDFS是Hadoop的旗艦級文件係統，也是本章的重點，但實際上Hadoop是一個綜閤性的文件係統抽象，因此接下來我們將瞭解將Hadoop與其他存儲係統集成的途徑，例如本地文件係統和AmazonS3係統。

　　3.1HDFS的設計

　　HDFS以流式數據訪問模式來存儲超大文件，運行於商用硬件集群上。①讓我們仔細看看下麵的描述。

　　*超大文件“超大文件”在這裏指具有幾百MB、幾百GB甚至幾百TB大小的文件。目前已經有存儲PB級數據的Hadoop集群瞭。②

　　*流式數據訪問HDFS的構建思路是這樣的：一次寫入、多次讀取是最高效的訪問模式。數據集通常由數據源生成或從數據源復製而來，接著長時間在此數據集上進行各種分析。每次分析都將涉及該數據集的大部分數據甚至全部，因此讀取整個數據集的時間延遲比讀取第一條記錄的時間延遲更重要。

　　*商用硬件Hadoop並不需要運行在昂貴且高可靠的硬件上。它是設計運行在商用硬件(在各種零售店都能買到的普通硬件③)的集群上的，因此至少對於龐大的集群來說，節點故障的幾率還是非常高的。HDFS遇到上述故障時，被設計成能夠繼續運行且不讓用戶察覺到明顯的中斷。

　　同樣，那些不適閤在HDFS上運行的應用也值得研究。目前HDFS對某些應用領域並不適閤，不過以後可能會有所改進。

　　*低時間延遲的數據訪問要求低時間延遲數據訪問的應用，例如幾十毫秒範圍，不適閤在HDFS上運行。記住，HDFS是為高數據吞吐量應用優化的，這可能會以提高時間延遲為代價。目前，對於低延遲的訪問需求，HBase(參見第20章)是更好的選擇。

　　*大量的小文件由於namenode將文件係統的元數據存儲在內存中，因此該文件係統所能存儲的文件總數受限於namenode的內存容量。根據經驗，每個文件、目錄和數據塊的存儲信息大約占150字節。因此，舉例來說，如果有一百萬個文件，且每個文件占一個數據塊，那至少需要300MB的內存。盡管存儲上百萬個文件是可行的，但是存儲數十億個文件就超齣瞭當前硬件的能力。④

　　*多用戶寫入，任意修改文件HDFS中的文件寫入隻支持單個寫入者，而且寫操作總是以“隻添加”方式在文件末尾寫數據。它不支持多個寫入者的操作，也不支持在文件的任意位置進行修改。可能以後會支持這些操作，但它們相對比較低效。

　　3.2HDFS的概念

　　3.2.1數據塊

　　每個磁盤都有默認的數據塊大小，這是磁盤進行數據讀/寫的最小單位。構建於單個磁盤之上的文件係統通過磁盤塊來管理該文件係統中的塊，該文件係統塊的大小可以是磁盤塊的整數倍。文件係統塊一般為幾韆字節，而磁盤塊一般為512字節。這些信息(文件係統塊大小)對於需要讀/寫文件的文件係統用戶來說是透明的。盡管如此，係統仍然提供瞭一些工具(如df和fsck)來維護文件係統，由它們對文件係統中的塊進行操作。

　　HDFS同樣也有塊(block)的概念，但是大得多，默認為128MB。與單一磁盤上的文件係統相似，HDFS上的文件也被劃分為塊大小的多個分塊(chunk)，作為獨立的存儲單元。但與麵嚮單一磁盤的文件係統不同的是，HDFS中小於一個塊大小的文件不會占據整個塊的空間(例如，當一個1MB的文件存儲在一個128MB的塊中時，文件隻使用1MB的磁盤空間，而不是128MB)。如果沒有特殊指齣，本書中提到的“塊”特指HDFS中的塊。

　　HDFS中的塊為什麼這麼大？

　　HDFS的塊比磁盤的塊大，其目的是為瞭最小化尋址開銷。如果塊足夠大，從磁盤傳輸數據的時間會明顯大於定位這個塊開始位置所需的時間。因而，傳輸一個由多個塊組成的大文件的時間取決於磁盤傳輸速率。

　　我們來做一個速算，如果尋址時間約為10ms，傳輸速率為100MB/s，為瞭使尋址時間僅占傳輸時間的1%，我們要將塊大小設置約為100MB。默認的塊大小實際為128MB，但是很多情況下HDFS安裝時使用更大的塊。以後隨著新一代磁盤驅動器傳輸速率的提升，塊的大小會被設置得更大。

　　但是這個參數也不會設置得過大。MapReduce中的map任務通常一次隻處理一個塊中的數據，因此如果任務數太少(少於集群中的節點數量)，作業的運行速度就會比較慢。

　　對分布式文件係統中的塊進行抽象會帶來很多好處。第一個最明顯的好處是，一個文件的大小可以大於網絡中任意一個磁盤的容量。文件的所有塊並不需要存儲在同一個磁盤上，因此它們可以利用集群上的任意一個磁盤進行存儲。事實上，盡管不常見，但對於整個HDFS集群而言，也可以僅存儲一個文件，該文件的塊占滿集群中所有的磁盤。

　　第二個好處是，使用抽象塊而非整個文件作為存儲單元，大大簡化瞭存儲子係統的設計。簡化是所有係統的目標，但是這對於故障種類繁多的分布式係統來說尤為重要。將存儲子係統的處理對象設置為塊，可簡化存儲管理(由於塊的大小是固定的，因此計算單個磁盤能存儲多少個塊就相對容易)。同時也消除瞭對元數據的顧慮(塊隻是要存儲的大塊數據，而文件的元數據，如權限信息，並不需要與塊一同存儲，這樣一來，其他係統就可以單獨管理這些元數據)。

　　不僅如此，塊還非常適閤用於數據備份進而提供數據容錯能力和提高可用性。將每個塊復製到少數幾個物理上相互獨立的機器上(默認為3個)，可以確保在塊、磁盤或機器發生故障後數據不會丟失。如果發現一個塊不可用，係統會從其他地方讀取另一個復本，而這個過程對用戶是透明的。一個因損壞或機器故障而丟失的塊可以從其他候選地點復製到另一颱可以正常運行的機器上，以保證復本的數量迴到正常水平(參見5.1節對數據完整性的討論，進一步瞭解如何應對數據損壞)。同樣，有些應用程序可能選擇為一些常用的文件塊設置更高的復本數量進而分散集群中的讀取負載。

　　與磁盤文件係統相似，HDFS中fsck指令可以顯示塊信息。例如，執行以下命令將列齣文件係統中各個文件由哪些塊構成，詳情可以參見11.1.4節對文件係統檢查(fsck)的討論：

　　%hdfsfsck/-files-blocks

　　3.2.2namenode和datanode

　　HDFS集群有兩類節點以管理節點-工作節點模式運行，即一個namenode(管理節點)和多個datanode(工作節點)。namenode管理文件係統的命名空間。它維護著文件係統樹及整棵樹內所有的文件和目錄。這些信息以兩個文件形式永久保存在本地磁盤上：命名空間鏡像文件和編輯日誌文件。namenode也記錄著每個文件中各個塊所在的數據節點信息，但它並不永久保存塊的位置信息，因為這些信息會在係統啓動時根據數據節點信息重建。

　　客戶端(client)代錶用戶通過與namenode和datanode交互來訪問整個文件係統。客戶端提供一個類似於POSIX(可移植操作係統界麵)的文件係統接口，因此用戶在編程時無需知道namenode和datanode也可實現其功能。

　　datanode是文件係統的工作節點。它們根據需要存儲並檢索數據塊(受客戶端或namenode調度)，並且定期嚮namenode發送它們所存儲的塊的列錶。

　　沒有namenode，文件係統將無法使用。事實上，如果運行namenode服務的機器毀壞，文件係統上所有的文件將會丟失，因為我們不知道如何根據datanode的塊重建文件。因此，對namenode實現容錯非常重要，Hadoop為此提供兩種機製。

　　第一種機製是備份那些組成文件係統元數據持久狀態的文件。Hadoop可以通過配置使namenode在多個文件係統上保存元數據的持久狀態。這些寫操作是實時同步的，且是原子操作。一般的配置是，將持久狀態寫入本地磁盤的同時，寫入一個遠程掛載的網絡文件係統(NFS)。

　　另一種可行的方法是運行一個輔助namenode，但它不能被用作namenode。這個輔助namenode的重要作用是定期閤並編輯日誌與命名空間鏡像，以防止編輯日誌過大。這個輔助namenode一般在另一颱單獨的物理計算機上運行，因為它需要占用大量CPU時間，並且需要與namenode一樣多的內存來執行閤並操作。它會保存閤並後的命名空間鏡像的副本，並在namenode發生故障時啓用。但是，輔助namenode保存的狀態總是滯後於主節點，所以在主節點全部失效時，難免會丟失部分數據。在這種情況下，一般把存儲在NFS上的namenode元數據復製到輔助namenode並作為新的主namenode運行。(注意，也可以運行熱備份namenode代替運行輔助namenode，具體參見3.2.5節對HDFS高可用性的討論。)

　　關於文件係統鏡像和編輯日誌的更多討論，請參見11.1.1節。

　　3.2.3塊緩存

　　通常datanode從磁盤中讀取塊，但對於訪問頻繁的文件，其對應的塊可能被顯式地緩存在datanode的內存中，以堆外塊緩存(off-heapblockcache)的形式存在。默認情況下，一個塊僅緩存在一個datanode的內存中，當然可以針每個文件配置datanode的數量。作業調度器(用於MapReduce、Spark和其他框架的)通過在緩存塊的datanode上運行任務，可以利用塊緩存的優勢提高讀操作的性能。例如，連接(join)操作中使用的一個小的查詢錶就是塊緩存的一個很好的候選。

　　用戶或應用通過在緩存池(cachepool)中增加一個cachedirective來告訴namenode需要緩存哪些文件及存多久。緩存池是一個用於管理緩存權限和資源使用的管理性分組。

　　3.2.4聯邦HDFS

　　namenode在內存中保存文件係統中每個文件和每個數據塊的引用關係，這意味著對於一個擁有大量文件的超大集群來說，內存將成為限製係統橫嚮擴展的瓶頸(參見10.3.2節)。在2.x發行版本係列中引入的聯邦HDFS允許係統通過添加namenode實現擴展，其中每個namenode管理文件係統命名空間中的一部分。例如，一個namenode可能管理/user目錄下的所有文件，而另一個namenode可能管理/share目錄下的所有文件。

　　在聯邦環境下，每個namenode維護一個命名空間捲(namespacevolume)，由命名空間的元數據和一個數據塊池(blockpool)組成，數據塊池包含該命名空間下文件的所有數據塊。命名空間捲之間是相互獨立的，兩兩之間並不相互通信，甚至其中一個namenode的失效也不會影響由其他namenode維護的命名空間的可用性。數據塊池不再進行切分，因此集群中的datanode需要注冊到每個namenode，並且存儲著來自多個數據塊池中的數據塊。

　　要想訪問聯邦HDFS集群，客戶端需要使用客戶端掛載數據錶將文件路徑映射到namenode。該功能可以通過ViewFileSystem和viewfs：//URI進行配置和管理。

　　3.2.5HDFS的高可用性

　　通過聯閤使用在多個文件係統中備份namenode的元數據和通過備用namenode創建監測點能防止數據丟失，但是依舊無法實現文件係統的高可用性。namenode依舊存在單點失效(SPOF,singlepointoffailure)的問題。如果namenode失效瞭，那麼所有的客戶端，包括MapReduce作業，均無法讀、寫或列舉(list)文件，因為namenode是唯一存儲元數據與文件到數據塊映射的地方。在這一情況下，Hadoop係統無法提供服務直到有新的namenode上綫。

　　在這樣的情況下，要想從一個失效的namenode恢復，係統管理員得啓動一個擁有文件係統元數據副本的新的namenode，並配置datanode和客戶端以便使用這個新的namenode。新的namenode直到滿足以下情形纔能響應服務：(1)將命名空間的映像導入內存中；(2)重演編輯日誌；(3)接收到足夠多的來自datanode的數據塊報告並退齣安全模式。對於一個大型並擁有大量文件和數據塊的集群，namenode的冷啓動需要30分鍾，甚至更長時間。

　　係統恢復時間太長，也會影響到日常維護。事實上，預期外的namenode失效齣現概率很低，所以在現實中，計劃內的係統失效時間實際更為重要。

　　Hadoop2針對上述問題增加瞭對HDFS高可用性(HA)的支持。在這一實現中，配置瞭一對活動-備用(active-standby)namenode。當活動namenode失效，備用namenode就會接管它的任務並開始服務於來自客戶端的請求，不會有任何明顯中斷。實現這一目標需要在架構上做如下修改。

　　*namenode之間需要通過高可用共享存儲實現編輯日誌的共享。當備用namenode接管工作之後，它將通讀共享編輯日誌直至末尾，以實現與活動namenode的狀態同步，並繼續讀取由活動namenode寫入的新條目。

　　*datanode需要同時嚮兩個namenode發送數據塊處理報告，因為數據塊的映射信息存儲在namenode的內存中，而非磁盤。

　　*客戶端需要使用特定的機製來處理namenode的失效問題，這一機製對用戶是透明的。

　　*輔助namenode的角色被備用namenode所包含，備用namenode為活動的namenode命名空間設置周期性檢查點。

　　可以從兩種高可用性共享存儲做齣選擇：NFS過濾器或群體日誌管理器(QJM，quorumjournalmanager)。QJM是一個專用的HDFS實現，為提供一個高可用的編輯日誌而設計，被推薦用於大多數HDFS部署中。QJM以一組日誌節點(journalnode)的形式運行，每一次編輯必須寫入多數日誌節點。典型的，有三個journal節點，所以係統能夠忍受其中任何一個的丟失。這種安排與ZooKeeper的工作方式類似，當然必須認識到，QJM的實現並沒使用ZooKeeper。(然而，值得注意的是，HDFSHA在選取活動的namenode時確實使用瞭ZooKeeper技術，詳情參見下一章。)

　　在活動namenode失效之後，備用namenode能夠快速(幾十秒的時間)實現任務接管，因為最新的狀態存儲在內存中：包括最新的編輯日誌條目和最新的數據塊映射信息。實際觀察到的失效時間略長一點(需要1分鍾左右)，這是因為係統需要保守確定活動namenode是否真的失效瞭。

　　在活動namenode失效且備用namenode也失效的情況下，當然這類情況發生的概率非常低，管理員依舊可以聲明一個備用namenode並實現冷啓動。這類情況並不會比非高可用(non-HA)的情況更差，並且從操作的角度講這是一個進步，因為上述處理已是一個標準的處理過程並植入Hadoop中。

　　故障切換與規避

　　係統中有一個稱為故障轉移控製器(failovercontroller)的新實體，管理著將活動namenode轉移為備用namenode的轉換過程。有多種故障轉移控製器，但默認的一種是使用瞭ZooKeeper來確保有且僅有一個活動namenode。每一個namenode運行著一個輕量級的故障轉移控製器，其工作就是監視宿主namenode是否失效(通過一個簡單的心跳機製實現)並在namenode失效時進行故障切換。

　　管理員也可以手動發起故障轉移，例如在進行日常維護時。這稱為“平穩的故障轉移”(gracefulfailover)，因為故障轉移控製器可以組織兩個namenode有序地切換角色。

　　但在非平穩故障轉移的情況下，無法確切知道失效namenode是否已經停止運行。例如，在網速非常慢或者網絡被分割的情況下，同樣也可能激發故障轉移，但是先前的活動namenode依然運行著並且依舊是活動namenode。高可用實現做瞭更進一步的優化，以確保先前活動的namenode不會執行危害係統並導緻係統崩潰的操作，該方法稱為“規避”(fencing)。

　　同一時間QJM僅允許一個namenode嚮編輯日誌中寫入數據。然而，對於先前的活動namenode而言，仍有可能響應並處理客戶過時的讀請求，因此，設置一個SSH規避命令用於殺死namenode的進程是一個好主意。當使用NFS過濾器實現共享編輯日誌時，由於不可能同一時間隻允許一個namenode寫入數據(這也是為什麼推薦QJM的原因)，因此需要更有力的規避方法。規避機製包括：撤銷namenode訪問共享存儲目錄的權限（通常使用供應商指定的NFS命令）、通過遠程管理命令屏蔽相應的網絡端口。訴諸的最後手段是，先前活動namenode可以通過一個相當形象的稱為“一槍爆頭”STONITH，shoottheothernodeinthehead)的技術進行規避，該方法主要通過一個特定的供電單元對相應主機進行斷電操作。

　　客戶端的故障轉移通過客戶端類庫實現透明處理。最簡單的實現是通過客戶端的配置文件實現故障轉移的控製。HDFSURI使用一個邏輯主機名，該主機名映射到一對namenode地址(在配置文件中設置)，客戶端類庫會訪問每一個namenode地址直至處理完成。

　　3.3命令行接口

　　現在我們通過命令行交互來進一步認識HDFS。HDFS還有很多其他接口，但命令行是最簡單的，同時也是許多開發者最熟悉的。

　　參照附錄A中僞分布模式下設置Hadoop的說明，我們先在一颱機器上運行HDFS。稍後介紹如何在集群上運行HDFS，以提供可擴展性與容錯性。

　　在我們設置僞分布配置時，有兩個屬性項需要進一步解釋。第一項是fs.defaultFS，設置為hdfs://localhost/，用於設置Hadoop的默認文件係統。⑤文件係統是由URI指定的，這裏我們已使用hdfsURI來配置HDFS為Hadoop的默認文件係統。HDFS的守護程序通過該屬性項來確定HDFSnamenode的主機及端口。我們將在localhost默認的HDFS端口8020上運行namenode。這樣一來，HDFS客戶端可以通過該屬性得知namenode在哪裏運行進而連接到它。

　　第二個屬性dfs.replication，我們設為1，這樣一來，HDFS就不會按默認設置將文件係統塊復本設為3。在單獨一個datanode上運行時，HDFS無法將塊復製到3個datanode上，所以會持續給齣塊復本不足的警告。設置這個屬性之後，上述問題就不會再齣現瞭。

　　文件係統的基本操作

　　至此，文件係統已經可以使用瞭，我們可以執行所有常用的文件係統操作，例如，讀取文件，新建目錄，移動文件，刪除數據，列齣目錄，等等。可以輸入hadoopfs-help命令獲取每個命令的詳細幫助文件。

　　首先從本地文件係統將一個文件復製到HDFS：

　　%hadoopfs-copyFromLocalinput/docs/quangle.txthdfs://localhost/user/tom/quangle.txt

　　該命令調用Hadoop文件係統的shell命令fs，後者提供瞭一係列子命令，在這個例子中，我們執行的是-copyFromLocal。本地文件quangle.txt被復製到運行在localhost上的HDFS實例中，路徑為/user/tom/quangle.txt。事實上，我們可以簡化命令格式以省略主機的URI並使用默認設置，即省略hdfs://localhost，因為該項已在core-site.xml中指定。

　　%hadoopfs-copyFromLocalinput/docs/quangle.txt/user/tom/quangle.txt

　　我們也可以使用相對路徑，並將文件復製到HDFS的home目錄中，本例中為/user/tom：

　　%hadoopfs-copyFromLocalinput/docs/quangle.txtquangle.txt

　　我們把文件復製迴本地文件係統，並檢查是否一緻：

　　%hadoopfs-copyToLocalquangle.txtquangle.copy.txt

　　%md5input/docs/quangle.txtquangle.copy.txt

　　MD5(input/docs/quangle.txt)=e7891a2627cf263a079fb0f18256ffb2

　　MD5(quangle.copy.txt)=e7891a2627cf263a079fb0f18256ffb2

前言/序言

　　前言

　　數學科普作傢馬丁·加德納(MartinGardner)曾經在一次采訪中談到：

　　“在我的世界裏，隻有微積分。這是我的專欄取得成功的奧秘。我花瞭很多時間纔明白如何以大多數讀者都能明白的方式將自己所知道的東西娓娓道來。”①

　　這也是我對Hadoop的諸多感受。它的內部工作機製非常復雜，是一個集分布式係統理論、實際工程和常識於一體的係統。而且，對門外漢而言，Hadoop更像是“天外來客”。

　　但Hadoop其實並沒有那麼讓人費解，抽絲剝繭，我們來看看它的“廬山真麵目”。Hadoop提供的用於處理大數據的工具都非常簡單。如果說這些工具有一個共同的主題，那就是它們更抽象，為(有大量數據需要存儲和分析卻沒有足夠的時間、技能或者不想成為分布式係統專傢的)程序員提供一套組件，使其能夠利用Hadoop來構建一個處理數據的基礎平颱。

　　這樣一個簡單、通用的特性集，促使我在開始使用Hadoop時便明顯感覺到Hadoop真的值得推廣。但最開始的時候(2006年初)，安裝、配置和Hadoop應用編程是一門高深的藝術。之後，情況確實有所改善：文檔增多瞭；示例增多瞭；碰到問題時，可以嚮大量活躍的郵件列錶發郵件求助。對新手而言，最大的障礙是理解Hadoop有哪些能耐，它擅長什麼，它如何使用。這些問題使我萌發瞭寫作本書的動機。

　　ApacheHadoop社區的發展來之不易。從本書的第1版發行以來，Hadoop項目如雨後春筍般發展興旺。“大數據”已成為大傢耳熟能詳的名詞術語。②當前，軟件在可用性、性能、可靠性、可擴展性和可管理性方麵都實現瞭巨大的飛躍。在Hadoop平颱上搭建和運行的應用增長迅猛。事實上，對任何一個人來說，跟蹤這些發展動嚮都很睏難。但為瞭讓更多的人采用Hadoop，我認為我們要讓Hadoop更好用。這需要創建更多新的工具，集成更多的係統，創建新的增強型API。我希望自己能夠參與，同時也希望本書能夠鼓勵並吸引其他人也參與Hadoop項目。

　　說明

　　在文中討論特定的Java類時，我常常會忽略包的名稱以免囉嗦雜亂。如果想知道一個類在哪個包內，可以查閱Hadoop或相關項目的JavaAPI文檔(ApacheHadoop主頁http://hadoop.apache.org上有鏈接可以訪問)。如果使用IDE編程，其自動補全機製(也稱“自動完成機製”)能夠幫助你找到你需要的東西。

　　與此類似，盡管偏離傳統的編碼規範，但如果要導入同一個包的多個類，程序可以使用星號通配符來節省空間(例如importorg.apache.hadoop.io.*)。

　　本書中的示例代碼可以從本書網站下載，網址為http://www.hadoopbook.com/。可以根據網頁上的指示獲取本書示例所用的數據集以及運行本書示例的詳細說明、更新鏈接、額外的資源與我的博客。

　　第4版新增內容

　　第4版的主題是Hadoop2。Hadoop2係列發行版本是當前應用最活躍的係列，且包含Hadoop的最穩定的版本。

　　第4版新增的章節包括YARN(第4章)、Parquet(第13章)、Flume(第14章)、Crunch(第18章)和Spark(第19章)。此外，為瞭幫助讀者更方便地閱讀本書，第1章新增瞭一節“本書包含的內容”(參見1.7節)。

　　第4版包括兩個新的實例學習(第22章和第23章)：一個是關於Hadoop如何應用於醫療健康係統，另一個是關於將Hadoop技術如何應用於基因數據處理。舊版本中的實例學習可以在綫查到，網址為http:/bit.ly/hadoop_tdg_prev。

　　為瞭和Hadoop最新發行版本及其相關項目同步，第4版對原有章節進行瞭修訂、更新和優化。

　　第3版新增內容

　　第3版概述ApacheHadoop1.x(以前的0.20)係列發行版本，以及新近的0.22和2.x(以前的0.23)係列。除瞭少部分(文中有說明)例外，本書包含的所有範例都在這些版本上運行過。

　　第3版的大部分範例代碼都使用瞭新的MapReduceAPI。因為舊的API仍然應用很廣，所以文中在討論新的API時我們還會繼續討論它，使用舊API的對應範例代碼可以到本書的配套網站下載。

　　Hadoop2.0最主要的變化是新增的MapReduce運行時MapReduce2，它建立在一個新的分布式資源管理係統之上，該係統稱為YARN。針對建立在YARN之上的MapReduce，第3版增加瞭相關的介紹，包括它的工作機製(第7章)及如何運行(第10章)。

　　第3版還增加瞭更多對MapReduce的介紹，包括豐富的開發實踐，比如用Maven打包MapReduce作業，設置用戶的Java類路徑，用MRUnit寫測試等(這些內容都請參見第6章)。第3版還深入介紹瞭一些特性，如輸齣committer和分布式緩存(第9章)，任務內存監控(第10章)。第3版還新增瞭兩小節內容，一節是關於如何寫MapReduce作業來處理Avro數據(參見第12章)，另一節是關於如何在Oozie中運行一個簡單的MapReduce工作流(參見第6章)。

　　關於HDFS的章節(第3章)，新增瞭對高可用性、聯邦HDFS、新的WebHDFS和HttpFS文件係統的介紹。

　　對Pig，Hive，Sqoop和ZooKeeper的相關介紹，第3版全部進行瞭相應的擴展，廣泛介紹其最新發行版本中的新特性和變化。

　　此外，第3版還對第2版進行瞭徹底的更新、修訂和優化。

　　第2版新增內容

　　《Hadoop權威指南》(第2版)新增兩章內容，分彆介紹Sqoop和Hive(第15章和第17章)，新增一個小節專門介紹Avro(參見第12章)，補充瞭關於Hadoop新增安全特性的介紹(參見第10章)以及一個介紹如何使用Hadoop來分析海量網絡圖的新實例分析。

　　第2版繼續介紹ApacheHadoop0.20係列發行版本，因為當時最新、最穩定的發行版本。書中有時會提到一些最新發行版本中的一些新特性，但在首次介紹這些特性時，有說明具體的Hadoop版本號。

　　本書采用的約定

　　本書采用以下排版約定。

　　斜體

　　用於錶明新的術語、URL、電子郵件地址、文件名和文件擴展名。

　　等寬字體Consolas

　　用於程序清單，在正文段落中齣現的程序元素(如變量或函數名)、數據庫、數據類型、環境變量、語句和關鍵字也采用這樣的字體。

　　等寬字體Consolas+加粗

　　用於顯示命令或應該由用戶鍵入的其他文本。

　　等寬字體Consolas+斜體

　　錶明這裏的文本需要替換為用戶提供的值或其他由上下文確定的值。

　　這個圖標錶示通用的說明。

　　這個圖標錶示重要的指示或建議。

　　這個圖標錶示警告或需要注意的問題。

　　示例代碼的使用

　　本書的補充材料（代碼、示例及練習等）可以從本書網站(http://www.hadoopbook.com)或GitHub(https://github.com/tomwhite/hadoop-book/)下載。

　　本書的目的是幫助讀者完成工作。通常情況下，可以在你的程序或文檔中使用本書中給齣的代碼。不必聯係我們獲得代碼使用授權，除非你需要使用大量的代碼。例如，在寫程序的時候引用幾段代碼不需要嚮我們申請許可。但以光盤方式銷售或重新發行O’Reilly書中的示例的確需要獲得許可。引用本書或引用本書中的示例代碼來迴答問題也不需要申請許可。但是，如果要將本書中的大量範例代碼加入你的産品文檔，則需要申請許可。

　　如果覺得使用示例代碼的情況不屬於前麵列齣的閤理使用或許可範圍，請通過電子郵件聯係我們，郵箱地址為permissions@oreilly.com。

　　SafariBooksOnline

　　SafariBooksOnline(www.safaribooksonline.com)是一個按需定製的數字圖書館，以圖書和視頻的形式提供全球技術領域和經管領域內知名作者的專業作品。

　　專業技術人員、軟件開發人員、網頁設計人員、商務人員和創意專傢將SafariBooksOnline用作自己開展研究、解決問題、學習和完成資格認證培訓的重要來源。

　　SafariBooksOnline為企業、政府部門、教育機構和個人提供廣泛、靈活的計劃和定價。

　　在這裏，成員們通過一個可以全文檢索的數據庫中就能夠訪問數韆種圖書、培訓視頻和正式齣版之前的書稿，這些內容提供商有O'ReillyMedia、PrenticeHallProfessional、Addison-WesleyProfessional、MicrosoftPress、Sams、Que、PeachpitPress、FocalPress、CiscoPress、JohnWiley&Sons;、Syngress、MorganKaufmann、IBMRedbooks、Packt、AdobePress、FTPress、Apress、Manning、NewRiders、McGraw-Hill、Jones&Bartlett;、CourseTechnology及其他上百傢齣版社。歡迎訪問SafariBooksOnline，瞭解更多詳情。

　　聯係我們

　　對於本書，如果有任何意見或疑問，請通過以下地址聯係齣版商：

　　美國：

　　O’ReillyMedia,Inc.

　　1005GravensteinHighwayNorth

　　Sebastopol,CA95472

　　中國：

　　北京市西城區西直門南大街2號成銘大廈C座807室(100035)

　　奧萊利技術谘詢(北京)有限公司

　　本書也有相關的網頁，我們在上麵列齣瞭勘誤錶、範例以及其他一些信息。網址如下：

　　http://bit.ly/hadoop_tdg_4e(英文版)

　　http://www.oreilly.com.cn/book.php?bn=978-7-302-46513-3(中文版)

　　對本書做齣評論或者詢問技術問題，請發送E-mail至以下郵箱：

　　bookquestions@oreilly.com

　　如果希望獲得關於本書、會議、資源中心和O’Reilly的更多信息，請訪問以下網址：

　　http://www.oreilly.com

　　http://www.oreilly.com.cn

　　緻謝

　　在本書寫作期間，我仰賴於許多人的幫助，直接的或間接的。感謝Hadoop社區，我從中學到很多，這樣的學習仍將繼續。

　　特彆感謝MichaelStack和JonathanGray，HBase這一章的內容就是他們寫的。我還要感謝AdrianWoodhead，MarcdePalol，JoydeepSenSarma，AshishThusoo，AndrzejBia?ecki，StuHood，ChrisK.Wensel和OwenO’Malley，他們提供瞭學習實例。

　　感謝為草稿提齣有用建議和改進建議的評審人：RaghuAngadi，MattBiddulph，ChristopheBisciglia，RyanCox，DevarajDas，AlexDorman，ChrisDouglas，AlanGates，LarsGeorge，PatrickHunt，AaronKimball，PeterKrey，HairongKuang，SimonMaxen，OlgaNatkovich，BenjaminReed，KonstantinShvachko，AllenWittenauer，MateiZaharia和PhilipZeyliger。AjayAnand組織本書的評審並使其順利完成。Philip(“flip”)Komer幫助我獲得瞭NCDC氣溫數據，使本書示例很有特色。特彆感謝OwenO’Malley和ArunC.Murthy，他們為我清楚解釋瞭MapReduce中shuffle的復雜過程。當然，如果有任何錯誤，得歸咎於我。

　　對於第2版，我特彆感謝JeffBean，DougCutting，GlynnDurham，AlanGates，JeffHammerbacher，AlexKozlov，KenKrugler，JimmyLin，ToddLipcon，SarahSproehnle，VinithraVaradharajan和IanWrigley，感謝他們仔細審閱本書，並提齣寶貴的建議，同時也感謝對本書第1版提齣勘誤建議的讀者。我也想感謝AaronKimball對Sqoop所做的貢獻和Philip(“flip”)Kromer對圖處理實例分析所做的貢獻。

　　對於第3版，我想感謝AlejandroAbdelnur，EvaAndreasson，EliCollins，DougCutting，PatrickHunt，AaronKimball，AaronT.Myers，BrockNoland，ArvindPrabhakar，AhmedRadwan和TomWheeler，感謝他們的反饋意見和建議。RobWeltman友善地對整本書提齣瞭非常詳細的反饋意見，這些意見和建議使得本書終稿的質量得以更上一層樓。此外，我還要嚮提交第2版勘誤的所有讀者錶達最真摯的謝意。

　　對於第4版，我想感謝JodokBatlogg，MeghanBlanchette，RyanBlue，JarekJarcecCecho，JulesDamji，DennisDawson，MatthewGast，KarthikKambatla，JulienLeDem，BrockNoland，SandyRyza，AkshaiSarma，BenSpivey，MichaelStack，KateTing，JoshWalter，JoshWills和AdrianWoodhead，感謝他們所有人非常寶貴的審閱反饋。RyanBrush，MicahWhitacre和MattMassiekindly為第4版友情提供新的實例學習。再次感謝提交勘誤的所有讀者。

　　特彆感謝DougCutting對我的鼓勵、支持、友誼以及他為本書所寫的序。

　　我還要感謝在本書寫作期間以對話和郵件方式進行交流的其他人。

　　在本書第1版寫到一半的時候，我加入瞭Cloudera，我想感謝我的同事，他們為我提供瞭大量的幫助和支持，使我有充足的時間好好寫書，並能及時交稿。

　　非常感謝我的編輯MikeLoukides、MeghanBlanchette及其O’ReillyMedia的同事，他們在本書的準備階段為我提供瞭很多幫助。Mike和Meghan一直為我答疑解惑、審讀我的初稿並幫助我如期完稿。

　　最後，寫作是一項艱巨的任務，如果沒有傢人一如既往地支持，我是不可能完成這本的。我的妻子Eliane，她不僅操持著整個傢庭，還協助我，參與本書的審稿、編輯和跟進案例學習。還有我的女兒Emilia和Lottie，她們一直都非常理解並支持我的工作，我期待有更多時間好好陪陪她們。

　　①摘自“Thescienceoffun”，網址為http://bit.ly/science_of_fun。此文2008年5月31日發錶於《衛報》。

　　②術語“大數據”在2013年被收入《牛津英語辭典》(OxfordEnglishDictionary)，網址為http://bit.ly/6_13_oed_update。