作者：Garry Turkington
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Hadoop基础教程试读：
前言
本书目的在于帮助读者理解Hadoop，并用它解决大数据问题。能使用Hadoop这样的数据处理技术进行工作是令人激动的。对大规模数据集进行复杂分析的能力，曾一度被大公司和政府机构所垄断，而现在通过免费的OSS（open source software，开源软件）即可获得这种能力。
该领域看上去有些复杂，并且变化节奏很快，所以理解这方面的基本知识让人望而生畏。这就是本书诞生的意义所在，它帮助读者了解什么是Hadoop，Hadoop是如何工作的，以及如何使用Hadoop从数据中提取有价值的信息。
除了解释Hadoop的核心机制，本书也会用几章内容来学习其他相关技术，这些技术要么用到了Hadoop，要么需要与Hadoop配套使用。我们的目标是，让读者不仅理解Hadoop是什么，还要理解如何在更宽泛的技术设施中使用Hadoop。
本书中提到的另一种技术是云计算的应用，尤其是AWS（Amazon Web Services，亚马逊网络服务）产品。本书中，我们将展示如何使用这些服务来承载Hadoop工作负载。这就意味着，读者无需购买任何物理硬件, 就能处理大规模数据。
本书内容
本书包括3个主要部分：第1~5章讲述了Hadoop的核心机制及Hadoop的工作模式；第6~7章涵盖了Hadoop更多可操作的内容；第8~11章介绍了Hadoop与其他产品和技术的组合使用。每章内容具体如下所。
第1章“绪论”。简要介绍了产生Hadoop和云计算的背景。如今看来，这些技术是如此重要。
第2章“安装并运行Hadoop”。指导读者完成本地Hadoop集群的安装，并运行一些示例作业。为了进行对比，在托管于亚马逊服务的Hadoop上执行同样的任务。
第3章“理解MapReduce”。深入研究Hadoop运行原理，揭示了MapReduce作业的执行方式，并展示了如何使用Java API编写MapReduce应用程序。
第4章“开发MapReduce程序”。通过对一个中等规模数据集案例的学习研究，演示如何着手处理和分析新数据源。
第5章“高级MapReduce技术”。介绍一些更复杂的应用MapRedece解决问题的方法，Hadoop似乎并不直接适用于这些问题。
第6章“故障处理”。详细检查Hadoop备受赞誉的高可用性和容错能力，通过强制结束进程和故意使用错误数据等方式故意制造破坏，以检验Hadoop在上述情况下的表现。
第7章“系统运行与维护”。从更具操作性的角度讲解Hadoop，这对于Hadoop集群的管理人员非常有用。本章在介绍一些最佳做法的同时，也描述了如何预防最糟糕的操作性灾难，因此系统管理员可以高枕无忧了。
第8章“Hive：数据的关系视图”。介绍Apache Hive，它允许使用类似SQL的语法对Hadoop数据进行查询。
第9章“与关系数据库协同工作”。探讨Hadoop如何与现有数据库融合，特别是如何将数据从一个数据库移到另一个数据库。
第10章“使用Flume收集数据”。介绍如何使用Apache Flume从多个数据源收集数据，并传送至Hadoop这样的目的地。
第11章“展望未来”。以更广泛的Hadoop生态系统概述结束全书，重点突出其他产品和技术的潜在价值。此外，还提供了一些如何参与Hadoop社区并获得帮助的方法。
准备工作
本书每章内容分别介绍该章用到的Hadoop相关软件包。但是，无论哪章内容都要用到运行Hadoop集群的硬件设施。
在最简单的情况下，一台基于Linux的主机可作为运行几乎全书所有示例的平台。任何可运行Linux命令行的先进操作系统都可满足需求，文中假设读者使用的是Ubuntu的最新发布版。
后面几章中的一些例子确实需要在多台机器上运行，所以读者需要拥有至少4台主机的访问权限。虚拟机也是可以的。虽然对于产品来讲，它们并非理想选择，但完全能够满足学习和研究的需要。
本书中，我们还将研究AWS，读者可以在EC2实例上运行所有示例。本书中，我们将更多地着眼于AWS针对Hadoop的具体用途。 任何人都可以使用AWS服务，但需要一张信用卡进行注册！
目标读者
我们认为，本书读者想要学习更多关于Hadoop的实践知识。本书的主要受众是，有软件开发经验却没有接触过Hadoop或类似大数据技术的人员。
对于那些想知道如何编写MapReduce应用的开发者，假设他们能轻松地编写Java程序并熟悉Unix命令行接口。本书还包含几个Ruby程序示例，但这些通常只是说明语言的独立性，并不要求读者成为一位Ruby专家。
对于架构师和系统管理员而言，本书也具有重大价值。它解释了Hadoop的工作原理，Hadoop在更广阔的系统架构中所处的位置，以及如何管理Hadoop集群。这类受众对一些复杂技术可能缺乏直接兴趣，如第4章和第5章。
约定
本书中，有几个经常出现的标题。
为了明确说明如何完成一个程序或任务，本书使用下面的格式详细描述操作步骤。
实践环节：标题
1. 操作12. 操作23. 操作3通常，需要一些额外的解释帮助读者理解这些指令，因此紧随其后的是是下面的原理分析。原理分析
这部分内容对任务运行原理或刚完成的指令进行解释说明。
本书还包含一些其他的学习辅助标记，包括：随堂测验：标题这是一些简短的多选题，目的在于帮助读者测试对相关内容的理解是否正确。一展身手：标题这部分内容设置一些实际问题，并为读者提供一些验证所学内容的方法。
本书使用多种文字风格来区分不同种类的信息。下面是一些例子还有对其意义的解释。
代码块设置如下：你也许注意到，我们使用Unix命令rm而不是DOSdel命令移除Drush目录。# * Fine Tuning#key_buffer = 16M key_buffer_size = 32M max_allowed_packet = 16M thread_stack = 512K thread_cache_size = 8 max_connections = 300
如果代码块的特定部分需要特别关注，相应行或内容会加粗显示。# * Fine Tuning#key_buffer = 16M key_buffer_size = 32M max_allowed_packet = 16Mthread_stack = 512K thread_cache_size = 8 max_connections = 300
命令行的输入或输出会以如下形式显示。cd /ProgramData/Propeople rm -r Drushgit clone --branch master http://git.drupal.org/project/drush.git
新词或者重要的词会以黑体字显示。以菜单或对话框为例，读者在屏幕上看到的内容如下所示“在Select Destination Location（选择目的地址）页面，点击Next（下一步）按钮接受默认输出地址”。提示：警告或重要提示会出现在这样的方框里。技巧：小窍门和技巧会以这样的形式出现。
读者反馈
我们非常欢迎来自读者的反馈。将你对本书的看法告诉我们，哪些内容是你喜欢的或哪些是你不喜欢的。读者反馈可以帮助我们不断提高书稿质量，这是非常重要的。
你只需向我们发送一封电子邮件，在邮件主题中提及书名即可反馈你的意见。我们的邮箱是：feedback@packtpub.com。
如果你擅长某个领域并对写作或者创作有兴趣，请参阅www.packtpub.com/authors上的作者指南。
客户支持
既然你购买了Packt的图书，我们将为你提供多种服务，使你本次购买物超所值。
下载示例代码
你可以通过http://www.packtpub.com网站的账号下载所购买Packt书籍的示例代码文件。或者登录网站http://www.packtpub.com/support进行注册，随后我们将通过电子邮件向你发送本书配套的示例代码文件。
勘误表
虽然作者尽最大努力保证本书内容的准确性，然而错误在所难免。如果你在Packt出版的书中发现了文字错误或是代码错误，衷心希望你能及时向我们反馈，并预致谢意。你的意见可以帮助我们改进图书的后续版本，并能帮助其他读者避免错误。请通过以下步骤提交你发现的错误之处：访问网站http://www.packtpub.com/submit-errata，选择相应图书，点击提交勘误表，登记你的勘误表详情。勘误表通过验证之后将上传到Packt网站，或添加到已有的勘误列表中。
关于盗版
互联网上的盗版
问题
由来已久，而且各种形式的媒介都存在这个问题。Packt出版社非常重视版权保护问题。如果你在互联网上看到了Packt图书的任何非法拷贝，无论它以何种形式存在，请立即向我们提供其位置或网站名称以便及时补救。请通过邮箱copyright@packtpub.com与我们联系，并附上涉嫌盗版材料的链接。
你的帮助保障了Packt图书作者的权益，也让我们能持续提供高品质图书。问题
如果你有关于本书任何方面的问题，可以通过questions@packtpub.com联系我们。我们将会尽力解决。第1章绪论本书介绍一种大规模数据处理的开源框架——Hadoop。在深入探讨它的技术细节和应用之前，很有必要花点时间来了解Hadoop及其取得巨大成功的历史背景。Hadoop并不是凭空想象出来的，它的出现源于人们创建和使用的数据量的爆炸性增长。在此背景下，不仅是庞大的跨国公司面临着海量数据处理的困难，小型创业公司同样如此。与此同时，其他历史变革改变了软件和系统的部署方式，除了传统的基础设施，人们开始使用甚至偏好于云资源。
本章将要探讨Hadoop出现的背景，并详细讲解Hadoop想要解决的问题和决定其最终设计的内在驱动因素。
本章包括以下内容：● 概述大数据革命；● 讲解Hadoop是什么以及如何从数据中获取有价值信息；● 探秘云计算并了解AWS（Amazon Web Services，亚马逊网
络服务）的功能；● 了解大数据处理技术与云计算相结合带来的巨大威力；● 概述本书其余章节内容。
现在我们开始吧！1.1 大数据处理
审视现有技术，不难发现，所有技术都以数据为核心。作为用户，我们对富媒体的欲望与日俱增，比如观看的电影和创建并上传到网络的照片和视频。我们也常常在日常生活中，不经意地在网上留下一串数据。
不仅是数据总量在迅速增加，同时数据生成速率也在不断增加。从电子邮件到Facebook留言，从网上购物记录到网站链接，到处都是不断增长的大数据集。在此背景下，最大的挑战在于，如何从这些数据中提取最有价值的信息。有时是提取特定的数据元素，有时是分析数据间的关系或是判断一种趋势。
微妙的变化悄然发生，数据的使用方式变得越来越有意义。一段时间以来，大型公司已经意识到了数据的价值，并用它来提升服务质量。例如，Google在用户正在访问的网页上显示内容相关的广告，Amazon或Netflix向用户推荐合乎其口味和兴趣的新产品或新电影。1.1.1 数据的价值
如果不会带来有价值的回报或者明显的竞争优势，这些大型企业是不会投资发展大数据处理技术的。应当从以下几个方面来认识大数据。● 只有在数据集足够大的时候，某些问题才变得有意义。例如，
在其他影响因素缺失的情况下，基于一个第三人的喜好推荐电影
是不可能非常精准的。然而，当参考样本增加到100时，推荐成
功的几率略有上升。而使用1000万人的观看记录，可以大幅提
升获得推荐模型的可能性。● 与之前的解决方案相比，大数据处理工具通常能够以较低的
成本处理更大规模的数据。因此，能够在可接受的成本范围内执
行以往花费极高的数据处理任务。● 大规模数据处理的成本不仅体现在财务费用上，等待时间也
是一个重要因素。如果一个系统能够处理所有到达数据，但是其
平均处理时间以周为计量单位，那么该系统也是不可用的。大数
据处理工具通过将增加的数据量分配到附加的硬件，来保证即使
在数据量增加的情况下，处理时间也不会失控。● 为了满足数据库中最大数据的需要，可能需要重新审视之前
关于数据库形式或者其中数据结构的假设。● 综合上述几点内容，足够大的数据集以及灵活的工具可以使
之前无法想象的问题得到解答。1.1.2 受众较少
前面讨论的从大数据中提取有价值信息用于改进服务质量的例子，往往属于大型搜索引擎和在线公司的创新模式。这是因为在早期发展过程中，大数据处理不仅成本高而且实现困难，超出了中小企业的能力范围。
同样，比大数据处理技术应用更为广泛的数据挖掘方法已经存在了很长一段时间，但是在大型企业和政府部门之外却从来没有真正得到推广使用。
这种情况的出现可能令人感到遗憾。但在过去，对于大多数小公司来讲却无关紧要，因为它们的数据量很少，并不需要投入大量的资金来处理这些数据。
然而，现如今数据量的增加不再局限于大型组织，许多中小型公司甚至一些个人收集到的数据也越来越多。他们也意识到这些数据中可能包含着正待发掘的价值。
在理解如何实现这一目标之前，很有必要了解奠定Hadoop系统基础的背景情况。1. 经典的数据处理系统
造成大数据挖掘系统稀有且昂贵的根本原因是，将现有小型计算系统扩展为大数据处理系统是非常困难的。正如我们所见，一直以来，数据处理系统的处理能力一直受限于单台计算机的极限运算能力。
随着数据规模的增长，出现了两种常用的扩展系统的方法，通常称之为“向上扩展”和“向外扩展”。● 向上扩展
在大多数企业，数据处理任务通常由相当昂贵的大型机来执行。随着数据规模的增长，向上扩展的方法就是将数据处理任务迁移到更大的服务器或者存储矩阵。即便以今天的视角来看，这种架构确实有效，但其硬件成本会很容易达到几十万甚至几百万美元。本章的后续内容对此有所涉及。
简单的向上扩展系统的优点是，系统的架构并不会随着数据量的增大而发生显著变化。尽管采用了更大型的部件，但部件之间的基本关系（例如数据服务器和存储矩阵）却依然保持一致。对于像商业数据库引擎这样的应用而言，可以通过软件来处理使用硬件带来的复杂性。但是从理论上来讲，数据处理能力是通过把相同的软件迁移到规模越来越大的服务器上来实现的。需要注意的是，把软件迁移到越来越多的处理器上也存在一定困难。同时，单台计算机的处理能力也受到现实条件的约束。因此，向上扩展的系统达到其极限后，无法进一步扩展数据处理的规模。
单一架构的数据处理器的规模不可能无限扩大。从概念上来讲，通过向上扩展系统的方式设计一个处理能力为1TB、100TB到1PB数据的系统，可能仅需使用更大规模的相同部件。但随着数据规模的增长，这些定制硬件之间连接的复杂性可能与之前的廉价部件有所不同。● 早期向外扩展的方法
向外扩展的方法并不通过升级系统的硬件来获得更强的处理能力，而是将数据处理任务分发给越来越多的机器。如果数据集的规模翻倍了，那就使用两台机器来处理，而不是一台有着两倍处理能力的机器。如果数据规模继续翻倍，那就使用四台机器来处理。
与向上扩展的方法相比，向外扩展系统的明显优势在于采购成本大大低于前者。大型机的硬件成本随着处理能力的增长而激增——假设一台主机的采购成本为5000美元，那么一台具有10倍处理能力的机器可能要花掉百倍的钱。向外扩展系统方法的不足之处在于，需要确定一种策略来把数据处理任务分发给不同的机器，而经验证明具有上述用途的工具异常复杂。
因此，部署一套向外扩展的解决方案是一项浩大的工程。系统研发人员不仅要设计数据切分和重组机制，还要设计在处理器集群间调度工作和处理个别机器故障的逻辑。2. 制约因素
除大型企业、政府和学术研究机构外，上述向上扩展和向外扩展的方法并没有得到广泛应用。通常，系统的采购成本很高，研发和维护这些系统的成本同样很高。这些因素导致这些系统很难被小型企业所接纳。此外，这些方法本身的缺陷也随着时间推移逐步显现。● 随着向外扩展的系统规模变大或者向上扩展的系统所需CPU
数量增多，由系统并发带来的系统复杂性问题日益明显。如何有
效利用多台主机或多个CPU是一个大难题。要想在整个数据处理
任务执行期间保持系统高效运作，需要付出极大的努力。● 通常硬件性能（用摩尔定律描述）的提升在不同硬件上的表
现大相径庭。CPU性能的提升速度远远超过了网络或硬盘性能提
升的速度。CPU周期一度是系统中最有价值的资源，现在却并非
如此。现代CPU的运行速度是20年前的数百万倍，然而内存和
硬盘的速度却只提升了上千倍甚至上百倍。用这种高性能CPU很
容易搭建一个现代系统，但在该系统中，存储系统提供数据的速
率却无法满足CPU的工作需要。1.1.3 一种不同的方法
上述场景中，有一些技术成功地解决了令人头疼的将数据处理系统扩展为大数据处理系统的问题。1. 条条大路通罗马：向外扩展
如上所述，采用向上扩展的方法并不是一种开放式的策略。它受限于从主流的硬件供应商购买的单个服务器的规模，甚至专业的供应商都无法提供足够大的服务器。在某些情况下，工作负载的增量会超出单台整体向上扩展的服务器的能力，这时该怎么办呢？很遗憾，最好的办法就是使用两台大型服务器，而不是一台服务器。以此类推，就会有三台、四台，甚至更多服务器。或者换言之，在极端情况下，向上扩展架构的必然趋势是加入向外扩展的策略，将二者结合起来。尽管这样同时吸收了两种方法的部分优点，但也综合了两种方法的缺陷和成本：单一的方法要么需要昂贵的硬件，要么需要手工开发跨集群逻辑，而在混合架构中缺一不可。
向上扩展架构的终极趋势和成本曲线导致其在大数据处理领域鲜有应用，而向外扩展的架构却成了事实上的标准。技巧：假如待解决的问题涉及的数据具有很强的内部交叉引用，并需保证事务完整性，基于大型计算机的向上扩展的关系数据库仍不失为一个好的选择。2. 不共享任何内容
父母会花相当长的时间去教孩子，这是一个很好的共享案例。但是，不应将共享原则延伸到数据处理系统，这一原则既适用于数据也适用于硬件。
从概念上看，向外扩展架构刻意凸显了主机的独立性，每台主机处理整个数据集的一个子集，并输出最终结果的一部分。现实情况通常并非如此简单。相反，主机之间可能需要通信，多台主机可能会用到相同的一些数据片段。主机间相互依赖给系统带来了两个负面影响：瓶颈问题和增加了故障风险。
如果系统的每次运算都要调用同一块数据或同一个服务器，那么多个相互竞争的客户端访问同一数据或同一主机很可能造成系统延迟。例如，由25台主机组成的系统中，所有的主机都必须访问其中一台主机，整个系统的性能就会受限于这台关键主机的处理能力。
更糟糕的是，如果这个“热点”服务器或存储系统的关键数据失效，那么整个工作将会瞬间瘫痪。早期的集群解决方案往往证明了这一风险——即便使用多台服务器共同处理工作任务，却往往使用同一个共享存储系统保存所有数据。
与共享资源不同，一个系统的各个组成部分应当尽可能保持独立。这种情况下，每个部件都能正常工作，而不用理会其余部件是否忙于处理复杂的工作，或是否已处于故障状态。3. 故障预期
上述原则提倡尽可能保持独立，然而潜在的弊端是要消耗更多的硬件。如果组成系统的个别组件会经常定期或不定期地发生故障，这是可以实现的。提示：读者可能经常听到“五个九”这样的词，它指的是99.999%的正常运行时间或者可用性。虽然从绝对意义上来讲，这是最好的可用性，但也要认识到，由许多这种设备组成的系统的整体可靠性可以相差很大，这取决于该系统能否容忍单个组件故障。假设一套系统需要5台可靠性达99%的服务器才能运行。那么，该系统的可用性为0.99*0.99*0.99*0.99*0.99，也就是可用性为95%。但是如果单个服务器的可靠性仅为95%的话，那么整个系统的可靠性就下降到只有76%。
相反，如果在任意时刻，只要保证5台服务器中的1台正常工作，系统即运行正常。那么，系统的可用性就高达99.999%。系统的正常运行时间与各个组件的可靠性临界点相关，这个观点有助于更直观地认识什么是系统可用性。技巧：如果“系统可用性为99%”这样的表述有点抽象的话，可以从系统在给定时间段内的故障时间来考虑这一问题。举个例子来说明，99%的可用性相当于一年中有3.5天的故障时间，或者是一个月中有7个小时的故障时间。99%的可用性还是听上去那么美好吗？
接受故障的做法，往往是新手在充分理解大数据处理系统过程中感到最为困惑的一个方面。这也是它与向上扩展系统架构的方法区别最大的地方。大型的向上扩展的服务器成本昂贵的一个主要原因是，生产商要投入巨大努力来减少部件故障给系统带来的影响。即便是低端服务器也会有冗余电源，但在大型计算机机箱里，多个CPU安装在CPU卡上，这些CPU卡又通过多个背板连接至内存插槽和存储系统。大型计算机厂商经常通过各种形式的极端方法来展示其产品的健壮性，如将正在运行的系统部件直接拔出，甚至用枪向其射击。如果系统构建时，设计者考虑到了可能出现的故障并保证其发生的概率在可接受范围内，而不是将每次故障作为必须消除的危机，将会出现完全不同的体系结构。4. 软件智能化，硬件傻瓜化
如果我们希望尽可能地灵活使用硬件集群，为许多并行工作流程提供托管服务，解决方案就是为软件注入智能并从硬件抽离智能。
在这种模式下，硬件被视为资源的集合，由软件层来负责向硬件分配特定的工作任务负载。这就使得硬件成为通用的，并且价格较为低廉，更易于获得。同时，有效利用硬件的功能转移到了软件，而关于如何有效执行任务的知识恰恰贮存在软件中。5. 移动处理程序，而非移动数据
假设需要对一个很大的数据集（比如1000 TB，也就是1 PB）中的每块数据执行4项操作。下面看一下解决上述问题的系统的不同实现方法。
传统的基于大型计算机的向上扩展方案会用到一个巨大的服务器，它连接到一个同样令人印象深刻的存储系统。几乎可以肯定，该系统使用了诸如光纤信道之类的技术来最大限度地提高存储带宽。该系统可以完成上述任务，却会变成I/O密集型系统；即便是高端存储交换机也会限制从存储系统到主机的数据传输速率。
另一种方法基于之前提到的集群技术，该方法会用到一个由1000台机器组成的集群。这1000台主机被划分为4个象限，每个象限对应一种操作。每台主机都存有1 TB数据并负责执行四项操作之一。集群管理软件将会协调数据在集群间的流转，确保每块数据都经过4个处理过程。当每块数据在其自身驻留的主机上进行一次运算之后，就会被传送到其他三个象限。因此，这个数据处理任务实际上消耗了3 PB的网络带宽。
请注意，CPU处理能力提升的速度已经超过了网络或硬盘技术。那么，难道这些是解决问题的最好办法吗？最近的经验表明，答案是否定的，另一种替代方法是移动处理过程而避免移动数据。使用刚才提到的集群技术，但不要分阶段处理数据，而是让1000个节点中的每个节点对其存储的数据执行全部4个处理阶段。如果幸运的话，此时只需将数据在硬盘上流转一次，而在网络上传输的将是二进制程序和状态报告，二者相对于有问题的实际数据集来讲，真是小巫见大巫。
如果一个有着1000个节点的集群听起来大得离谱，那么想像一下那些用于大数据解决方案的现代服务器的构成模块。每台这种单机都配有12个容量为1 TB甚至2 TB的硬盘。因为现代处理器是多核的，构建一个由50个节点组成的集群并非难事，这个集群有1 PB的存储能力，并有一个CPU专门用于处理从每个硬盘传出的数据。6. 构建应用程序，而非基础架构
当思考上节中提到的问题时，多数人会将精力集中在数据迁移和数据处理的问题上。但是，曾经搭建过这种系统的人就会知道，大部分精力却是用在设计一些不太明显的因素的处理逻辑上，如任务调度、异常处理、协调配合等。
我们必须实现一些机制来确定在哪台主机上执行处理任务、实现处理过程、将子结果合并为整体结果，并且无法从以前的模型中获得多少帮助。我们需要明确地管理数据分区，这只是用一个难题换来了另一个难题。
上述问题与我们将强调的最新研究趋势相关：透明处理集群的大部分结构问题，让开发者专注于思考业务问题。基于明确定义的系统接口，开发者可以创建特定业务领域的应用程序；提供此类接口的框架将是开发者和系统效率的最佳组合。1.1.4 Hadoop
得知上述方法都是Hadoop的主要特性之后，思维缜密的读者并不会感到惊讶。但直到现在，我还没有准确地回答什么是Hadoop。1. 感谢Google
Hadoop起源于Google。Google公司于2003年和2004年发表了两篇描述Google技术的学术论文：谷歌文件系统（GFS）（http://research.google.com/archive/gfs.html）和MapReduce （http://research.google.com/archive/mapreduce.html）。它们提供了一个高效处理极大规模数据的平台。2. 感谢Doug
与此同时，Doug Cutting正在研究开源的网页搜索引擎Nutch。他一直致力于系统原理的工作，当Google的GFS和MapReduce论文发表后，引起了他的强烈共鸣。Doug开始着手实现这些Google系统，不久之后，Hadoop诞生了。Hadoop早期以Lucene子项目的形式出现，不久之后成了Apache开源基金会的顶级项目。因此，从本质上来讲，Hadoop是一个实现了MapReduce和GFS技术的开源平台，它可以在由低成本硬件组成的集群上处理极大规模的数据集。3. 感谢Yahoo
2006年，Yahoo雇用了Doug Cutting并迅速成为Hadoop项目最重要的支持者之一。除了经常推广一些全球最大规模的Hadoop部署之外，Yahoo允许Doug和其他工程师们在受雇于Yahoo期间，致力于Hadoop的工作。同时，Yahoo也贡献了一些公司内部开发的Hadoop改进和扩展程序。尽管Doug目前已经转到Cloudera（另一家大力支持Hadoop团体的创业公司）任职，Yahoo的Hadoop团队已经分拆为名叫Hortonworks的创业公司，Yahoo依然是Hadoop的一个主要支持者。4. Hadoop的组成部分
作为一个顶级项目，Hadoop项目包含许多组件子项目。本书中将讨论其中几个子项目，最主要的两个子项目分别为Hadoop分布式文件系统（HDFS）和MapReduce。这两个子项目是对Google特有的GFS和MapReduce的直接实现。本书将详细讨论HDFS及MapReduce，但现在最好将它们视为一对独立而又互补的技术。
HDFS是一个可以存储极大数据集的文件系统，它是通过向外扩展方式构建的主机集群。它有着独特的设计和性能特点，特别是，HDFS以时延为代价对吞吐量进行了优化，并且通过副本替换冗余达到了高可靠性。
MapReduce是一个数据处理范式，它规范了数据在两个处理阶段（被称为Map和Reduce）的输入和输出，并将其应用于任意规模的大数据集。MapReduce与HDFS紧密结合，确保在任何情况下，MapReduce任务直接在存储所需数据的HDFS节点上运行。5. 公共构建模块
HDFS和MapReduce都体现了一些上一节描述的体系原则。特别是：● 都是面向廉价服务器（也就是说，中低端）集群设计的；● 都是通过增加更多的服务器来实现系统扩展（向外扩展）；● 都包含了检测和处理故障的机制；● 都透明地提供了许多服务，从而使用户可以更专注于手头的
问题；● 都采用了同样的架构， 其中驻留在物理服务器上的软件集
群控制着系统运行的各个方面。6. HDFS
HDFS（Hadoop Distributed File System，Hadoop分布式文件系统）与之前所见过的大部分文件系统都不太一样。HDFS是一个不具备POSIX兼容性的文件系统，这基本上意味着它不能提供像普通文件系统一样的保障。它也是一个分布式文件系统，这意味着它在众多节点上扩大了存储；在某些年以前的技术中，缺乏这种高效的分布式文件系统是一个限制性因素。HDFS的主要特点如下所示。● HDFS通常以最小64 MB的数据块存储文件，这比之前多数
文件系统中的4 KB~32 KB分块大得多。● HDFS在时延的基础上对吞吐量进行了优化，它能够高效处
理对大文件的读请求流，但不擅长对众多小文件的定位请求。● HDFS对普遍的“一次写入，多次读取”的工作负载进行了
优化。● 每个存储节点上运行着一个称为DataNode的进程，它管理
着相应主机上的所有数据块。这些存储节点都由一个称为
NameNode的主进程来协调，该进程运行于一台独立主机上。● 与磁盘阵列中设置物理冗余来处理磁盘故障或类似策略不
同，HDFS使用副本来处理故障。每个由文件组成的数据块存储
在集群中的多个节点，HDFS的NameNode不断地监视各个
DataNode发来的报告，以确保发生故障时，任意数据块的副本
数量都大于用户配置的复制因子。否则，NameNode会在集群中
调度新增一个副本。7. MapReduce
虽然MapReduce技术相对较新，但它建立在数学和计算机科学的众多基础工作之上，尤其是适用于每个数据元素的数据操作的描述方法。实际上，map和reduce函数的概念直接来自于函数式编程语言。在函数式编程语言中，map和reduce函数被用于对输入数据列表进行操作。
另一个关键的基本概念是“分而治之”。这个概念的基本原则是，将单个问题分解成多个独立的子任务。如果多个子任务能够并行执行，这种方法更为强大。在理想情况下，一个需要运行1000分钟的任务可以通过分解成1000个并行的子任务，在1分钟内即可完成。
MapReduce是一个基于上述原理的处理范式，它实现了从源数据集到结果数据集的一系列转换。在最简单的情况下，作业的输入数据作为map函数的输入，所得到的临时数据作为reduce函数的输入。开发人员只需定义数据转换形式，Hadoop的MapReduce作业负责并行地对集群中的数据实施所需转换。虽然基本的想法可能并无太大新意，但Hadoop的一个主要优势在于它如何将这些想法变成一个精心设计的可用平台。
传统的关系型数据库适用于符合定义模式的结构化数据。与之不同，MapReduce和Hadoop在半结构化或非结构化数据上表现最好。与符合刚性模式的数据不同，MapReduce和Hadoop仅要求将数据以一系列键值对的形式提供给map函数。map函数的输出是其他键值对的集合，reduce函数收集汇总最终的结果数据集。
Hadoop为map和reduce函数提供了一个标准规范（即接口），上述规范的具体实现通常被称为mapper和reducer。一个典型的MapReduce作业包括多个mapper和reducer，通常这些mapper和reducer并不是很简单。开发人员将精力集中于表达从数据源到结果数据集的转化关系上，而Hadoop框架会管理任务执行的各个方面：并行处理，协调配合，等等。
最后一点可能是Hadoop最重要的一个方面。Hadoop平台负责执行数据处理的各个方面。在用户定义了任务的关键指标后，其余事情都变成了系统的责任。更重要的是，从数据规模的角度来看，同一个MapReduce作业适用于存储在任意规模集群上的任意大小的数据集。如果要处理的是单台主机上的1 GB数据， Hadoop会相应地安排处理过程。即便要处理的是托管在超过1000台机器上的1 PB数据，Hadoop依然同样工作。它会确定如何最高效地利用所有主机进行工作。从用户的角度来看，实际数据和集群的规模是透明的，除了处理作业所花费的时间受影响外，它们不会改变用户与Hadoop的交互方式。8. 组合使用效果更佳
我们有可能已经体会到了HDFS和MapReduce各自的价值，但当它们组合使用时威力更强大。作为一个大规模数据存储平台，HDFS并非必须与MapReduce配套使用。尽管MapReduce可以从HDFS之外的数据源读取数据，并且对这些数据执行的处理操作与HDFS是一致的，但截至目前，将HDFS和MapReduce组合使用是最为常见的情况。
当执行MapReduce作业时，Hadoop需要决定在哪台主机执行代码才能最高效地处理数据集。如果MapReduce集群中的所有主机从单个存储主机或存储阵列获取数据，在很大程度上，在哪台主机执行代码并不重要，因为存储系统是一个会引发竞争的共享系统。但如果使用HDFS作为存储系统，基于移动数据处理程序比迁移数据本身成本更低的原则，MapReduce可以在目标数据的存储节点上执行数据处理过程。
最常见的Hadoop部署模型是将HDFS和MapReduce集群部署在同一组服务器上。其中每台服务器不仅承载了待处理数据及管理这些数据的HDFS组件，同时也承载了调度和执行数据处理过程的MapReduce组件。当Hadoop接收到作业后，它尽可能对驻留在主机上的数据调度进行优化，达到网络流量最小化和性能最大化的目标。
回想一下以前的例子，如何对分布在1000台服务器上的1 PB数据执行4个步骤的处理任务。MapReduce模型（以一种稍微简化和理想化的方式）对HDFS中每台主机上的每块数据执行map函数定义的处理操作，随后在reduce函数中，复用集群以收集各个主机的结果并转化为最终的结果集。
Hadoop的部分挑战在于，如何将单个问题分解成map函数和reduce函数的最佳组合。前述方法只适用于4阶段处理链可独立应用于每个数据元素的情况。在后续章节将会看到，有时要使用多个MapReduce作业，其中某个作业的输出将作为下一个作业的输入。9. 公共架构
正如之前所提到的，HDFS和MapReduce软件集群有着下列共同特点。● 采用了相同的体系结构，用专门的主节点对工作节点集群进
行管理。● 每种情景的主节点（HDFS的主节点是NameNode，
MapReduce的主节点是JobTracker）监视集群的运行状况并处理
故障，处理方式包括移走数据块或者重新调度失败的作业。● 每台服务器上的进程（HDFS的进程是DataNode，
MapReduce的进程是TaskTracker）负责在物理主机上执行任
务，包括从NameNode或者JobTracker接收指令和向其报告健康
状态和运行状况。
作为一个小的术语点，主机或服务器通常指的是承载各种Hadoop组件的物理硬件。节点指的是作为集群组成部分的软件部件。10. 优势与劣势
与其他工具一样，弄清楚在什么情况下选择使用Hadoop解决面临的问题非常重要。本书大部分内容会在之前大数据处理技术综述的基础上强调Hadoop的优势，但在早期阶段，理解在什么情况下Hadoop并非最好的选择也同样重要。
Hadoop选用的体系架构使其成为现在这样灵活且可扩展的数据处理平台。但是，与选择大多数架构或设计类似，必须理解一些由此引发的后果。其中最主要的是，Hadoop是一个批量处理系统。当对一个大数据集执行作业时，Hadoop框架会不断进行数据转换直到生成最终结果。由于采用了大的集群，Hadoop会相对快速地生成结果，但事实上，结果生成的速度还不足以满足缺乏耐心的用户的需求。因此，单独的Hadoop不适用于低时延查询，例如网站、实时系统或者类似查询。
当使用Hadoop处理大数据集时，安排作业、确定每个节点上运行的任务及其他所有必需的内务管理活动需要的时间开销在整个作业执行时间中是微不足道的。但是，对于小数据集而言，上述执行开销意味着，即使是简单的MapReduce作业都可能花费至少10秒钟。提示： HBase是广义Hadoop家族的另一位成员，它是另一种谷歌技术的开源实现。它提供了一个基于Hadoop的非关系型数据库，使用了多种方法提供低延迟的查询服务。
但是，难道Google和Yahoo不是Hadoop最强大的支持者吗？在它们的网站中，难道响应时间不是最重要的吗？答案是肯定的，这种现象强调了一个重要方面，即如何将Hadoop与其他技术结合起来发挥共同优势。在一篇论文里（http://research.google.com/archive/googlecluster.html），谷歌简述了他们如何实时地使用MapReduce：在网络爬虫获取到更新的网页数据后，MapReduce对庞大的数据集进行处理，并基于此生成网页索引，这些检索被一组MySQL服务器用于为终端用户的搜索请求提供服务。1.2 基于Amazon Web Services的云计算
云计算是本书介绍的另一个技术领域。书中以Amazon Web Services作为云计算平台的例子，介绍它的一些使用实例。但首先，我们需要了解一些围绕云计算的炒作和流行语。1.2.1 云太多了
云计算已经成为一个被滥用的术语，可以说，云计算概念的滥用使其面临变得毫无意义的风险。因此，在本书中使用这个术语的时候，务必清楚并谨慎表达我们的真实意思。云有两个主要的特点：既是一种新的可选架构，也是一种解决成本的不同方法。1.2.2 第三种方法
我们已经讨论了扩展数据处理系统的两种方法：向上扩展和向外扩展。但是迄今为止，前述讨论想当然地认为无论哪一种方法的实现，都需要系统开发团队购买、拥有、安装并管理物理硬件。云计算提供了第三种办法：用户把应用程序放到云端，让供应商处理系统扩展的问题。
当然，这并不总是那么简单。但是对于许多云服务来讲，这种模式才是真正的革命。用户根据一些公开的指南或者接口开发软件，然后把它部署到云平台，并允许它在成本允许的前提下根据需要扩展服务。但是由于扩展系统通常涉及成本，所以这是一个引人关注的命题。1.2.3 不同类型的成本
这种云计算方式同时也改变了系统硬件的付费方式。通过降低硬件基础设施成本，构建能承载数千甚至数百万客户的平台，云服务提供商借此获得规模经济，同时所有用户都从中受益。作为使用者，不仅有人替你操心难度较大的工程问题，如扩展系统的问题，而且你可以根据需要的负载付费，而不必基于可能需要的最大工作负载来确定系统规模。相反，用户获得了弹性系统带来的好处，可以根据工作负载的需要使用或多或少的资源。
下面这个例子可以说明这一点。因为要计算税费和工资数据，许多公司的财务组在月底的工作量较大，而且通常年底的数据处理任务会更大。如果需要设计一个这种系统，购买多少硬件最为合适？如果购买的硬件仅够处理日常工作量，系统可能会在月底陷入困境，真正的麻烦可能出现于年底处理任务运转起来的时候。如果以月底的工作量来度量系统规模，系统的部分硬件将会在一年的大部分时间处于闲置状态，而且仍然可能在处理年底任务的时候陷入困境。如果根据年底的工作量来确定系统规模，在一年的其余时间里，系统会有大量的闲置产能。除了考虑购买硬件的成本，还要考虑托管和运行成本（服务器的用电量可能占到其生命周期中成本的一大部分），你基本上浪费了大量的金钱。
云计算按需服务的特性可让用户的应用程序在一个规模不大的硬件上起步，然后随着时间的发展，向上或向下动态调整其硬件规模。基于按需付费的模式，用户成本随着其硬件使用情况而变化。用户拥有处理负载的能力，却无需购买足够处理峰值负载的硬件。
这种模型更微妙的特性在于，它大大降低了企业发布在线服务的进入成本。众所周知，一个无法满足需求并遭遇性能问题的新的热点服务，将很难恢复其发展势头和重新引起用户兴趣。例如，在2000年，一个企业要想成功地推出新品，需要在发布当天落实到位足够的容量来应对用户流量的激增，这既是他们所期望的，同时也是他们不愿看到的。将物理单元的成本考虑在内，在产品发布上很容易就会花掉数百万元。
如今，基于云计算，最初的基础设施成本甚至可以低至每月几十或几百美元，而且这只在需要流量的时候才会有所增加。1.2.4 AWS：Amazon的弹性架构
Amazon Web Services (AWS) 是Amazon 提供的一整套云计算服务。本书将会用到其中几种服务。1. 弹性计算云（EC2）
Amazon的弹性计算云（EC2，参见http://aws.amazon.com/ec2/），其本质上是一个弹性服务器。在注册AWS和EC2之后，只需凭个人信用卡的有关信息即可获得专用虚拟机的访问权限，在这些服务器上可以很容易地运行多种操作系统，包括Windows和Linux的许多变种。
需要更多的服务器吗？只需启动更多的机器。需要更强大的服务器吗？只需切换到提供更高规格的服务器上，当然使用成本也随之上升。不仅如此，EC2提供了一系列免费服务，包括负载均衡器、静态IP地址、额外的高性能虚拟磁盘驱动器，和其他更多服务。2. 简单存储服务（S3）
Amazon的S3（Simple Storage Service，简单存储服务，参见http://aws.amazon.com/s3/） 是一种提供简单键值存储模式的存储服务。利用网络、命令行或者编程接口创建对象，这些对象可以是从文本文件到图片到MP3的一切对象。基于层次模型，用户能够在S3中存储并获取数据。在这个模型中，用户可以创建存放对象的桶（bucket）。每个桶都有一个唯一标识符，并且桶中的每个对象都是唯一命名的。这种简单的策略成就了一个非常强大的服务，Amazon 负责数据的可靠性和可用性，以及服务扩展等各个方面。3. 弹性 MapReduce（EMR）
Amazon的弹性MapReduce（EMR，参见 http://aws.amazon.com/elasticmapreduce/），从根本上来讲是以EC2和S3为基础的云端Hadoop。同样地，使用多种接口（CLI，Web控制台或API），用户可定义一些Hadoop工作流属性，例如所需的Hadoop主机数和源数据的位置等。EMR提供了MapReduce作业的Hadoop实现代码，之后虚拟的开始按钮被按下。
在其最令人印象深刻的模式中，EMR可以从S3获取源数据，利用基于EC2创建的Hadoop集群来处理这些数据，将结果返回到S3，然后终止Hadoop集群及承载它的EC2虚拟机的运行。当然，每个服务都是有成本的，通常以存储的数据量（以GB为单位）和服务器使用时间为计费基准，但无需专用硬件即可获得如此强大的数据处理能力，其功能真的是强大。1.2.5 本书内容
本书中，我们将学习如何编写MapReduce程序做一些重要的数据转换，以及如何在本地管理和AWS托管的Hadoop集群上运行MapReduce程序。
我们不仅会把Hadoop视为执行MapReduce作业的引擎，同时也会探索将Hadoop融入企业其他基础设施和系统的方法。我们会看到一些共同的结合点，如从Hadoop和关系型数据库中获取数据，以及如何使Hadoop看起来更像是一个关系数据库。双管齐下
本书不会将讨论局限在EMR或Amazon EC2托管的Hadoop。我们在讨论如何创建和管理本地Hadoop集群（在Ubuntu Linux系统上）的同时，也会演示如何通过EMR将处理过程推入云端。
这样做的原因来自两方面：首先，虽然EMR使Hadoop更易访问，但只有当手工管理集群时，才能充分体会Hadoop技术的各项特点。尽管在手工模式下也可以使用EMR，然而通常使用本地集群来进行学习研究。其次，使用托管Hadoop还是本地Hadoop并不是一个非此即彼的选择，有时用户会担忧对一个独立的外部供应商的过度依赖，所以许多企业混合使用本地和云托管的Hadoop服务。从实践来讲，在本地进行开发和小规模测试更为方便，然后再根据产品规模将其部署到云端。
在后面的一些章节中，我们会讨论与Hadoop组合使用的其他产品。在这部分内容中，本书只给出一些本地集群的例子，因为无论Hadoop部署在何处，工作原理都是不变的。1.3 小结
本章介绍了关于大数据、Hadoop和云计算的大量知识。
专门探讨了大数据的出现以及它对数据处理方法及系统架构的改变，这一变革几乎可以让任何组织实现曾经昂贵得令人望而却步的技术。
本章还回顾了，作为一个灵活而又功能强大的海量数据处理平台，Hadoop的产生历史和构建方式。我们还研究了云计算提供的另一种系统架构方式。这种方式从前期巨额成本和直接的物理责任转变为按需付费模式，并依赖云服务提供商来提供硬件、管理服务和扩展系统。我们也明白了什么是Amazon Web Services，以及弹性MapReduce服务怎样利用其他AWS服务实现云端Hadoop。
我们还讨论了本书的目标，以及如何学习本地Hadoop和AWS托管的Hadoop。
现在，我们已经掌握了Hadoop的基础知识，并了解了这项技术的起源和优势。我们需要动手让系统运行起来，这也是第2章将要做的：安装并运行Hadoop。第2章安装并运行Hadoop既然我们已经研究了大数据处理带来的机遇和挑战，并且了解了Hadoop的优势所在，现在就来安装并运行Hadoop吧。
本章包括以下内容：● 学习如何在本地Ubuntu主机安装并运行Hadoop；● 运行一些Hadoop程序实例并熟悉Hadoop系统；● 注册使用Amazon Web Services产品（如EMR）所需要的账
号；● 在Elastic MapReduce上创建符合需求的Hadoop集群；● 研究本地Hadoop集群与托管Hadoop集群的关键区别。2.1 基于本地Ubuntu主机的Hadoop系统
为了研究云外的Hadoop，本节将以一台或多台Ubuntu主机为例。一台主机（一台物理计算机或虚拟机）即可满足运行Hadoop所有组件和研究MapReduce的需要。然而，企业产品集群很可能由多台机器组成，所以如果能在部署于多台主机的Hadoop集群进行开发，读者将获得很好的经验。然而，对于起步而言，单台主机就足够了。
我们将讨论的内容并非仅限于Ubuntu操作系统，Hadoop能够在任何Linux操作系统上运行。很明显，如果读者使用了Ubuntu之外的操作系统，可能需要修改一下环境配置，但区别应该不大。其他操作系统
Hadoop在其他平台上运行效果良好。Windows和Mac OS X都是开发者的热门选择。Windows只能作为Hadoop的开发平台，而Mac OS X没有得到Hadoop的正式支持。
如果选择使用这类平台，情况将与使用其他Linux发行版本相类似。在这两个平台上使用Hadoop处理工作任务的方法是相同的，但需要使用操作系统自带的特定机制设置环境变量和类似任务。Hadoop FAQ包含一些其他平台的信息，如果读者打算在其他平台运行Hadoop，应当首先参考Hadoop FAQ（参见http://wiki.apache.org/hadoop/FAQ）解决相关问题。2.2 实践环节：检查是否已安装JDK
Hadoop是用Java实现的，所以需要首先在Ubuntu主机上安装最新的Java开发工具包（JDK）。执行下列步骤检查JDK是否可用：1. 首先，打开一个终端并输入以下内容来检查JDK是否可用：$ javac $ java -version2. 如果上述命令返回“不存在这样的文件或路径”或者类似的
错误，或者第二个命令返回“打开JDK”的提示，很可能需要下
载完整的JDK。JDK可以从Oracle下载页面获得，地址是http://
www.oracle.com/technetwork/java/javase/downloads/index.html，
从中选择最新发布的版本。3. 一旦安装了Java之后，将JDK/bin路径添加到用户路径，并
用下列命令设置JAVA_HOME环境变量，注意将Java版本号修改
成读者使用的Java版本。$ export JAVA_HOME=/opt/jdk1.6.0_24$ export PATH=$JAVA_HOME/bin:${PATH}原理分析
上述步骤确保用户安装了正确的Java版本，并可以在命令行下调用，而无须使用冗长的路径名指明安装位置。
请注意，上面的命令只对当前正在运行的shell产生影响。这些设置将在注销用户，关闭shell，或重新启动系统之后清除。为了确保相同的设置始终有效，可以把这些设置添加到读者选中的shell启动文件内。例如，对于Bash shell来讲，其启动文件为.bash _profile，对于TCSH来讲，其启动文件为.cshrc。
我所青睐的另一种方法是，把所有必需的配置放入一个独立的文件，然后从命令行显式地调用此文件。例如：$ source Hadoop_config.sh
这种方法允许读者在同一账户内保持多个安装文件，而不致于使shell启动过程过于复杂。更不用说，某些应用程序所需的配置确实可能与其他程序的配置不兼容。别忘了在每次开启会话前载入该文件。2.2.1 安装Hadoop
对于初学者来讲，Hadoop最令人困惑的一个方面在于它众多的组件、工程、子工程，以及它们之间的内在关系。事实上，随着时间的推移，这些组件都发生了变化，然而却并没有使这一切变得更容易理解。不过，从今往后，访问网站http://hadoop.apache.org会看到Hadoop包括曾提到过的3个主要工程：● Common● HDFS● MapReduce
通过第1章的解释，我们应该对后两项内容较为熟悉。Common工程是Hadoop项目的核心部分，包括一组运行库和各种工具，它们帮助Hadoop实际运作。目前重要的是，标准的Hadoop发行版软件包含了这3个项目的最新版本，它们的组合正是运行Hadoop所需要的。各版本的注意事项
从0.19到0.20版本，Hadoop发生了重大的变化。尤其是，用于开发MapReduce应用的API迁移到了一组新API。本书中，我们将主要使用新API，但是后面的章节中也包含了一些旧API的例子，这是因为现在并没有将现有的所有功能都移植到新API。
自从0.20分支被重命名为1.0，Hadoop的版本管理也变得复杂。0.22和0.23分支仍然存在，事实上还包含了一些1.0分支所不包含的特性。在写作本书的时候，由于1.1和2.0分支被用作将来的开发版本，所以事情变得更加清晰。由于大多数现有的系统和第三方工具是针对
试读结束[说明：试读内容隐藏了图片]