关于我们
新书资讯
新书推荐

Hadoop权威指南(第3版)

Hadoop权威指南(第3版)

定     价：¥99

中 教 价：¥62.37  (6.30折）

库 存 数： 0

  • 作者：（美）Tom White
  • 出版时间：2015/1/1
  • ISBN：9787302370857
  • 出 版 社：清华大学出版社
  • 中图法分类：TP274-62 
  • 页码：716
  • 纸张：胶版纸
  • 版次：3
  • 开本：16开
  • 商品库位：
9
7
3
8
7
7
0
3
8
0
5
2
7
购买数量：     

准备好释放数据的强大潜能了吗？借助于这本《Hadoop权威指南》，你将学习如何使用Apache Hadoop构建和维护稳定性高、伸缩性强的分布式系统。本书是为程序员写的，可帮助他们分析任何大小的数据集。本书同时也是为管理员写的，帮助他们了解如何设置和运行Hadoop集群。

 

本书通过丰富的案例学习来解释Hadoop的幕后机理，阐述了Hadoop如何解决现实生活中的具体问题。第3版覆盖Hadoop的最新动态，包括新增的MapReduce API，以及MapReduce2及其灵活性更强的执行模型（YARN）。

 

 

传统的关系型数据库

MapReduce

数据大小

GB

PB

数据存取

交互式和批处理

批处理

更新

多次读/写

一次写入，多次读取

结构

静态模式

动态模式

完整性

高

低

横向扩展

非线性的

线性的

 

MapReduce和关系型数据库之间的另一个区别在于它们所操作的数据集的结构化程度。结构化数据(structureddata)是具有既定格式的实体化数据，如XML文档或满足特定预定义格式的数据库表。这是RDBMS包括的内容。另一方面，半结构化数据(semi-structured data)比较松散，虽然可能有格式，但经常被忽略，所以它只能作为对数据结构的一般性指导。例如电子表格，它在结构上是由单元格组成的网格，但是每个单元格内可以保存任何形式的数据。非结构化数据(unstructureddata)没有什么特别的内部结构，例如纯文本或图像数据。MapReduce对非结构化或半结构化数据非常有效，因为它是在处理数据时才对数据进行解释。换句话说，MapReduce输入的键和值并不是数据固有的属性，而是由分析数据的人来选的。^

关系型数据往往是规范的(normalized)，以保持其数据的完整性且不含冗余。规范给MapReduce带来了问题，因为它使记录读取成为非本地操作，而MapReduce的核心假设之一偏偏就是可以进行(高速的)流读写操作。^

Web服务器日志是典型的非规范化数据记录(例如，每次都需要记录客户端主机全名，这会导致同一客户端的全名可能多次出现)，这也是MapReduce非常适用于分析各种日志文件的原因之一。^

MapReduce是一种线性的可伸缩编程模型。程序员要写两个函数，分别为map函数和reduce函数，每个函数定义从一个键值对集合到另一个键值对集合的映射。这些函数不必关注数据集及其所用集群的大小，可以原封不动地应用于小规模数据集或大规模的数据集。更重要的是，如果输入的数据量是原来的两倍，那么运行时间也需要两倍。但如果集群是原来的两倍，作业的运行速度却仍然与原来一样快。SQL查询一般不具备该特性。^

但是，在不久的将来，关系型数据库系统和MapReduce系统之间的差异很可能变得模糊。关系型数据库都开始吸收MapReduce的一些思路(如Aster Data的数据库和GreenPlum的数据库)，另一方面，基于MapReduce的高级查询语言(如Pig和Hive)使传统数据库的程序员更容易接受MapReduce系统。[6]^

1.3.2  网格计算^

高性能计算(High Performance Computing，HPC)和网格计算(Grid Computing)组织多年以来一直在研究大规模数据处理，主要使用类似于消息传递接口(MessagePassing Interface，MPI)的API。从广义上讲，高性能计算采用的方法是将作业分散到集群的各台机器上，这些机器访问存储区域网络(SAN)所组成的共享文件系统。这比较适用于计算密集型的作业，但如果节点需要访问的数据量更庞大 (高达几百GB，MapReduce开始施展它的魔法)，很多计算节点就会因为网络带宽的瓶颈问题不得不闲下来等数据。^

MapReduc尽量在计算节点上存储数据，以实现数据的本地快速访问。[7]数据本地化(datalocality)特性是MapReduce的核心特征，并因此而获得良好的性能。意识到网络带宽是数据中心环境最珍贵的资源(到处复制数据很容易耗尽网络带宽)之后，MapReduce通过显式网络拓扑结构来保留网络带宽。注意，这种排列方式并没有降低MapReduce对计算密集型数据进行分析的能力。^

虽然MPI赋予程序员很大的控制权，但需要程序员显式控制数据流机制，包括用C语言构造底层的功能模块(例如套接字)和高层的数据分析算法。而MapReduce则在更高层次上执行任务，即程序员仅从键值对函数的角度考虑任务的执行，而且数据流是隐含的。^

在大规模分布式计算环境下，协调各个进程的执行是一个很大的挑战。最困难的是合理处理系统的部分失效问题——在不知道一个远程进程是否挂了的情况下——同时还需要继续完成整个计算。有了MapReduce，程序员不必操心系统部分失效的问题，因为它自己的系统实现能够检测到并重新执行那些失败的map或reduce任务。正因为采用的是无共享(shared-nothing)框架，MapReduce才能够实现失败检测，这意味着各个任务之间是彼此独立的。[8]因此，从程序员的角度来看，任务的执行顺序无关紧要。相比之下，MPI程序必须显式管理自己的检查点和恢复机制，虽然赋予程序员的控制权加大了，但编程的难度也增加了。^

MapReduce听起来似乎是一个相当严格的编程模型，而且在某种意义上看的确如此：限定用户使用有特定关联的键值对，mapper和reducer彼此间的协调非常有限(每个mapper将键值对传给reducer)。由此，我们自然联想到一个问题：能用这个编程模型做一些有用或实际的事情吗？^

答案是肯定的。MapReduce由谷歌的工程师开发，用于构建搜索引擎的索引，而且，事实已经证明它能够一次又一次地解决这个问题(MapReduce 的灵感来自于传统的函数式编程、分布式计算和数据库社区)，但此后，该模型在其他行业还有着很多其他的应用。我们欣喜地发现，有很多算法都可以用MapReduce来表达，从图像图形分析到各种各样基于图像分析的问题，再到机器学习算法。[9]当然，它也不是包治百病的灵丹妙药，不能解决所有问题，但它真的是一个很通用的数据处理工具。^

我们将在第16章介绍Hadoop的一些典型应用。^


1.3.3  志愿计算^

人们第一次听说Hadoop和MapReduce的时候，经常会问这个问题：“它们和SETI@home有什么不同？”SETI全称为Searchfor Extra-Terrestrial Intelligence(搜索外星智能)，项目名称为SETI@home(http://setiathome.berkeley.edu)。在该项目中，志愿者把自己计算机CPU的空闲时间贡献出来分析无线天文望远镜的数据，借此寻找外星智慧生命信号。SETI@home因为拥有庞大的志愿者队伍而非常出名，其他还有“搜索大素数”(Great Internet MersennePrime Search)项目与Folding@home项目(了解蛋白质构成及其与疾病之间的关系)。^

志愿计算项目将问题分成很多块，每一块称为一个工作单元(work unit)，发到世界各地的计算机上进行分析。例如，SETI@home的工作单元是0.35 MB无线电望远镜数据，要对这等大小的数据量进行分析，一台普通计算机需要几个小时或几天时间才能完成。完成分析后，结果发送回服务器，客户端随后再获得另一个工作单元。为防止欺骗，每个工作单元要发送到3台不同的机器上执行，而且收到的结果中至少有两个相同才会被接受。^

从表面上看，SETI@home与MapReduce好像差不多(将问题分解为独立的小块，然后并行进行计算)，但事实上还是有很多明显的差异。SETI@home问题是CPU高度密集的，比较适合在全球成千上万台计算机上运行，[10]因为计算所花的时间远远超过工作单元数据的传输时间。也就是说，志愿者贡献的是CPU周期，而不是网络带宽。^

MapReduce有三大设计目标：(1)为只需要短短几分钟或几个小时就可以完成的作业提供服务；(2)运行于同一个内部有高速网络连接的数据中心内；(3)数据中心内的计算机都是可靠的、定制的硬件。相比之下，SETI@home则是在接入互联网的不可信的计算机上长时间运行，这些计算机的网络带宽不同，对数据本地化也没有要求。^


1.4  Hadoop发展简史^

Hadoop是Apache Lucene创始人Doug Cutting创建的，Lucene是一个应用广泛的文本搜索系统库。Hadoop起源于开源的网络搜索引擎Apache Nutch，它本身也是Lucene项目的一部分。^

Hadoop的得名

Hadoop不是缩写，它是一个生造出来的词。Hadoop之父Doug Cutting这样解释Hadoop的来历：

“这个名字是我的小孩给他的毛绒象玩具取的。我的命名标准是好拼读，含义宽泛，不会被用于其他地方。小孩子是这方面的高手。Googol就是小孩子起的名字。”

 

Hadoop的子项目及后续模块所使用的名称也往往与其功能不相关，通常也以大象或其他动物为主题取名(例如Pig)。较小一些的组件，名称通常都有较好的描述性(因此也更流俗)。这个原则很好，意味着我们可以望文知义，例如jobtracker[11]，一看就知道它是用来跟踪MapReduce作业的。

 

从头打造一个网络搜索引擎是一个雄心勃勃的计划，不只是因为写爬虫程序很复杂，更因为必须有一个专职团队来实现——项目中包含许许多多需要随时修改的活动部件。同时，构建这样的系统代价非常高——据Mike Cafarella和Doug Cutting估计，一个支持10亿网页的索引系统，单是硬件上的投入就高达50万美元，另外还有每月高达3万美元的运维费用。[12]不过，他们认为这个工作仍然值得投入，因为它开创的是一个优化搜索引擎算法的平台。^

Nutch项目开始于2002年，一个可以运行的网页爬取工具和搜索引擎系统很快面试。但后来，开发者认为这一架构的灵活性不够，不足以解决数十亿网页的搜索问题。一篇发表于2003年的论文为此提供了帮助，文中描述的是谷歌产品架构，该架构称为“谷歌分布式文件系统”，简称GFS。[13]GFS或类似的架构，可以解决他们在网页爬取和索引过程中产生的超大文件的存储需求。特别关键的是，GFS能够节省系统管理(如管理存储节点)所花的大量时间。在2004年，他们开始着手做开源版本的实现，即Nutch分布式文件系统(NDFS)。^

2004年，谷歌发表论文向全世界介绍他们的MapReduce系统。[14]2005年初，Nutch的开发人员在Nutch上实现了一个MapReduce系统，到年中，Nutch的所有主要算法均完成移植，用MapReduce和NDFS来运行。^

Nutch的NDFS和MapReduce实现不只适用于搜索领域。在2006年2月，开发人员将NDFS和MapReduce移出Nutch形成Lucene的一个子项目，命名为Hadoop。大约在同一时间，Doug Cutting加入雅虎，雅虎为此组织了专门的团队和资源，将Hadoop发展成能够处理Web数据的系统(参见后面的补充材料“Hadoop在雅虎“)。在2008年2月，雅虎宣布，雅虎搜索引擎使用的索引是在一个拥有1万个内核的Hadoop集群上构建的。[15]^

2008年1月，Hadoop已成为Apache的顶级项目，证明了它的成功、多样化和生命力。到目前为止，除雅虎之外，还有很多公司在用Hadoop，例如Last.fm、Facebook和《纽约时报》等。第16章和Hadoop 维基页面(英文)介绍了一些案例(http://wiki.apache.org/hadoop/PoweredBy)。^

《纽约时报》的案例广为流传，他们把1851 年到 1980 年的存档扫描之后得到4 TB的文件并用亚马逊的EC2云服务将文件存为PDF格式放到网上共享。[16]整个过程一共使用了100台计算机，所花的时间不到24小时。如果没有亚马逊的按小时付费模式(即允许《纽约时报》短期内访问大量机器)和Hadoop好用的并发编程模型珠联璧合，这个项目不太可能这么快就启动和完成。^

2008年4月，Hadoop打破世界纪录，成为最快的TB级数据排序系统。在一个910节点的群集，Hadoop在209 秒内(不到3.5分钟)完成了对1TB数据的排序，击败了前一年的297秒冠军(详情参见15.5节的补充材料“ApacheHadoop的TB级数据处理”)。同年11月，谷歌在报告中声称，它的MapReduce对1 TB数据排序只用了68秒。[17]2009年5月本书第1版出版的时候，有报道称雅虎有一个的团队使用 Hadoop对1 TB数据进行排序只花了62秒。^

从那以后，Hadoop跃升为企业主流的部署系统。在工业界，Hadoop已经是公认的大数据通用存储和分析平台，这一事实主要体现在大量直接使用或者间接辅助Hadoop系统的产品如雨后春笋般大量涌现。一些大公司也发布Hadoop发行版本，包括EMC，IBM，Microsft和Oracle以及一些专注于Hadoop的公司，如Cloudera，Hortonworks[18]和MapR。^

Hadoop在雅虎^

作者：Owen O’Melly

^

构建互联网规模的搜索引擎离不开大量的数据，因此也离不开大量的机器来处理巨量的数据。雅虎搜索引擎(Yahoo！Search)有4个主要组成部分：Crawler，从网页服务器爬取网页；WebMap，构建一个已知网页的链接图；Indexer，为最佳页面构建一个反向索引；Runtime，处理用户的查询。WebMap生成的链接图非常大，大约包括一万亿(1012)条边(每条边代表一个网页链接)和一千亿(1011)个节点(每个节点代表不同的网址)。创建并分析如此大的图需要大批计算机很多天长时间运行。到2005年初，WebMap用的底层架构Dreadnaught需要重新设计以便日后扩展到更多的节点。^

Dreadnaught从20个节点成功扩展到600个，但需要完全重新设计才能进一步扩大。Dreadnaught与MapReduce在很多方面都很相似，但灵活性更强，结构也更松散。说具体点，一个Dreadnaught作业的每一个片断(fragment，也称“分块”)都可以输送到下一阶段的各个片段继续执行，排序则是通过库函数来完成的。但实际情形是，大多数WebMap阶段是两两一对，对应于MapReduce。因此，WebMap应用不需要做大量重构操作就可以适应MapReduce。

Eric Baldeschwieler(Eric14)组建了一个小团队，于是我们开始设计并在GFS和MapReduce上用C++来建立一个新框架的原型，并打算用它来取代Dreadnaught。尽管我们的当务之急是需要一个新的WebMap框架，但更清楚的是，建立雅虎搜索引擎批处理平台的标准对我们更重要。使平台更通用以便支持其他用户，才能够更好地实现新平台的均衡性投资。

与此同时，我们也关注在Hadoop(当时也是Nutch的一部分)及其进展情况。2006年1月，雅虎聘请了Doug Cutting。一个月后，我们决定放弃原型，转而采用 Hadoop。与我们的原型和设计相比，Hadoop的优势在于它已经在20 个节点上实际应用过(Nutch)。这样一来，我们便能在两个月内搭建一个研究集群并能够以很快的速度帮助我们的客户使用这个新的框架。另一个显著的优点是Hadoop已经开源，比较容易(尽管也不是想象的那么容易！)从雅虎法务部门获得许可对该开源系统进行进一步研究。因此，我们在2006年初建立了一个200节点的研究集群并暂时搁置WebMap计划，转而为研究用户提供Hadoop支持和优化服务。

Hadoop大事记

2004年

Doug Cutting和Mike Cafarella实现了HDFS和MapReduce的初版

2005年12月

Nutch移植到新框架，Hadoop在20个节点上稳定运行

2006年1月

Doug Cutting加入雅虎

2006年2月

Apache Hadoop项目正式启动，支持MapReduce和HDFS独立发展

2006年2月

雅虎的网格计算团队采用Hadoop

2006年4月

在188个节点上(每节点10 GB)运行排序测试集需要47.9个小时)

2006年5月

雅虎建立了一个300个节点的Hadoop研究集群

2006年5月

在500个节点上运行排序测试集需要42个小时(硬件配置比4月份的更好)

2006年11月

研究集群增加到600个节点

 

 


 

 

2006年12月

排序测试集在20个节点上运行1.8个小时，100个节点上运行3.3小时，500个节点上运行5.2小时，900个节点上运行7.8个小时

2007年1月

研究集群增加到900个节点

2007年4月

研究集群增加到两个集群1000个节点

2008年4月

在900个节点上运行1 TB排序测试集仅需209秒，成为全球最快

2008年10月

研究集群每天装载10 TB的数据

2009年3月

17个集群共24 000个节点

2009年4月

在每分钟排序中胜出，59秒内排序500 GB(在1400个节点上)和173分钟内排序100 TB数据(在3400个节点上)

      

 


[1] Gantz等人2008年3月发表的文章“The Diverse and Exploding Digital Universe”(纷繁多样并不断膨胀的数字世界)，网址为http://china.emc.com/collateral/analyst-reports/expanding-digital-idc-white-paper.pdf。^

[2] http://www.intelligententerprise.com/showArticle.jhtml?articleID=207800705；http://mashable.com/ 2008/10/15/facebook-10-billion-photos/；http://blog.familytreemagazine.com/insider/ Inside+Ancestrycoms+TopSecret+Data+Center.aspx；http://www.archive.org/about/faqs.php；
http://www.interactions.org/cms/?pid=1027032。^

[3] 编注：更多详细介绍可以参见阮一峰的博客文章“微软的MyLifeBits项目”，网址为http://www.ruanyifeng.com/blog/2007/12/mylifebits.html。^

[4] 引自Anand Rajaraman发表的文章“Netflix Challenge”(Negfix挑战大赛)，网址为 http://anand.typepad.com/datawocky/2008/03more-data-usual.html。在这个挑战大赛中，Netflix公司公开自己的用户评分数据，让研究者根据这些数据对用户没有看过的电影预测评分，谁最先比现有系统好10%，谁就能赢得100万美元的奖金。Alon Halevy，Peter Norvig(谷歌研究主管)和Fernando Pereira在他们的一篇文章中也提出了类似的观点，题为“TheUnreasonable Effectiveness of Data”(数据的非理性效果)，发表于IEEE Intelligent Systems 2009年3/4月合刊。

[5] 这些规格对应的是希捷的ST-41600n硬盘。

[6]  2007年1月，数据库理论专家David J. DeWitt和Michael Stonebraker发表的论文引发一场激烈的口水大战，论文标题为“MapReduce: A major step backwards”(MapReduce：一个巨大的倒退)，原文可参见http://databasecolumn.vertica.com/ database-innovation/mapreduce a-major-step-backwards，中文版可参考http://wap.oschina.net/question/17793_31108)。在文中，他们认为MapReduce不宜取代关系型数据库。许多评论认为这是一种错误的比较，详情可参见Mark C. Chu-Carroll的文章“Databasesare hammers; MapReduce is a screwdriver”(如果说数据库是锤子，MapReduce则是螺丝刀)，英文版网址为http://scienceblogs.com/goodmath/2008/01 databases_are_hammers_mapreduc.php，中文版可以参考http://blog.csdn.net/ wanghai__/article/details/5954108。DeWitt与Stonebraker以“再说MapReduce”一文对其他人的观点进行了阐述，原文可参见http://databasecolumn.vertica.com/database-innovation/mapreduce-ii，他们对其他人的主要观点进行了阐述。

[7]  1998年图灵奖得主Jim Gray在2003年3月发表的“DistributedComputing Economics”(分布式计算经济学)一文中，率先提出这个结论：数据处理应该在离数据本身比较近的地方进行，因为这样有利于降低成本，尤其是网络带宽消费所造成的成本。原文网址为http://research.microsoft.com/apps/pubs/default.aspx?id=70001。

[8] 这里讲得太简单了一点，因为MapReduce 系统本身控制着mapper输出结果传给reducer的过程，所以在这种情况下，重新运行reducer比重新运行mapper更要小心，因为reducer需要获取必要的mapper输出结果，如果没有，必须再次运行对应的mapper，重新生成输出结果。

[9] Apache Mahout(http://mahout.apache.org/)是一个在Hadoop上运行的机器学习类库(例如分类和聚类算法)。

[10] 2008年1月，SETI@home发表评论说每天使用320 000台计算机处理300 GB数据，同时他们也在做其他的一些数据计算，原文参见http://www.planetary.org/programs/ projects/setiathome/setiathome_20080115。

[11] 在本书中我们使用小写的jobtracker来代表实体(泛称)，用驼峰体JobTracker来表示对Java类的实现。

[12] Mike Cafarella和Doug Cutting在2004年4月发表在ACM Queue上的文章“Building Nutch: Open Source Search”，网址为http://queue.acm.org/detail.cfm?id=988408。

[13] Sanjay Ghemawat，Howard Gobioff和Shun-Tak Leung在2003年10月发表的文章“The Google File System”，网址为http://labs.google.com/papers/gfs.html。

[14] 参见Jeffrey Dean和Sanjay Ghemawat 2004年12月发表的文章“MapReduce: Simplified Data Processing on Large Clusters”(MapReduce: 大型集群的数据简化处理)，网址为http://labs.google.com/papersmapreduce.html。

[15] 参见2008年2月19日发表的文章“雅虎发布全球最大的Hadoop产品应用”(Yahoo!Lauches World’s Largest Hadoop ProductionApplications)，网址为http://developer. yahoo.com/blogs/hadoop/posts/2008/ 02/yahoo-worlds-largest-production-hadoop/。

[16] 参见Derek Gottfrid在 2007年11月1日发表的文章“Self-service, Prorated Super Computing Fun!”(自助式比例分配超级计算的乐趣！)，网址为http://open.blogs.nytimes.com/2007/11/01/self-service-prorated-super-computing-fun/。

[17] 全文参见2008年11月21日的文章“Sorting 1PB with MapReduce”(MapReduce处理1 PB数据)，网址为http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html。

[18] 编者注：该公司是雅虎的几个核心开发人员创办的，主要提供Hadoop支持和咨询服务，他们已经与微软在2011年建立战略合作关系，帮助微软将Hadoop移植到Wiondows Server和Azure。

 你还可能感兴趣
 我要评论
您的姓名   验证码： 图片看不清？点击重新得到验证码
留言内容