本文节选于清华大学出版社推出的《Hadoop权威指南》一书，作者为Tom White，译者是华东师范大学数据科学与工程学院。本书从Hadoop的缘起开始，由浅入深，结合理论和实践，全方位地介绍Hadoop这一高性能处理海量数据集的理想工具。全书共16章，3个附录，涉及的主题包括：Haddoop；MapReduce；Hadoop分布式文件系统；Hadoop的I/O、MapReduce应用程序开发；MapReduce的工作机制；MapReduce的类型和格式；MapReduce的特性；如何构建Hadoop集群，如何管理Hadoop；Pig；HBase；Hive；ZooKeeper；开源工具Sqoop，最后还提供了丰富的案例分析。本书是Hadoop权威参考，程序员可从中探索如何分析海量数据集，管理员可以从中了解如何安装与运行Hadoop集群。
下文包括了第一章的所有内容：
1.1 数据！数据！
1.2 数据的存储与分析
1.3 相较于其他系统的优势
1.4 Hadoop发展简史
1.5 Apache Hadoop和Hadoop生态系统
1.6 Hadoop的发行版本
第1章 初识Hadoop
在古时候，人们用牛来拉重物。当一头牛拉不动一根圆木时，人们从来没有考虑过要培育更强壮的牛。同理，我们也不该想方设法打造超级计算机，而应该千方百计综合利用更多计算机来解决问题。
——格蕾斯·霍珀(Grace Hopper)
1.1 数据！数据！
我们生活在这个数据大爆炸的时代，很难估算全球电子设备中存储的数据总共有多少。国际数据公司(IDC)曾经发布报告称，2006年数字世界(digital universe)项目统计得出全球数据总量为0.18 ZB并预测在2011年将达到1.8 ZB。1 ZB等于1021字节，等于1000 EB(exabytes)，1 000000 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年，我家用数码相机拍摄的照片总共有5GB。对照爷爷的照片生成速度，我家是他老人家的35倍！并且，而且这个速度还在不断增长中，因为现在拍照片真的是越来越容易了。
有一种情况更普遍，个人产生的数据正在快速增长。微软研究院的MyLifeBits 项目(http://research.microsoft.com/enus/projects/mylifebits/default.aspx)显示，在不久的将来，个人信息档案将日益普及。MyLifeBits的一个实验是获取和保存个人的对外联系情况(包括电话、邮件和文件)，供日后存取。收集的数据中包括每分钟拍摄的照片等，数据量每月约为1GB。当存储成本急剧下降以至于可以存储音频和视频时，MyLifeBits项目在未来的存储的数据量将是现在的很多倍。
保存个人成长过程中产生的所有数据似乎逐渐成为主流，但更重要的是，计算机产生的数据可能远远超过我们个人所产生的。机器日志、RFID检测仪、传感器网络、车载GPS 和零售交易数据等——所有这些都将产生巨量的数据。
在网上公开发布的数据也在逐年增加。组织或企业，要想在未来取得成功，不仅需要管理好自己的数据，更需要从其他组织或企业的数据中获取有价值的信息。
这方面的先锋有Amazon Web Services(http://aws.amazon.com/publicdatasets)、Infochimps.org(http://infochimps.org/)和theinfo.org( http://theinfo.org )，它们所发布的共享数据集，正在促进信息共享(information commons)，供所有人自由下载和分析 (或者只需要支付合理的价格通过AWS 平台来共享)。不同来源的信息在经过混搭和处理之后，会带来意外的效果和我们今天难以想象的应用。
以Astrometry.net(http://astrometry.net)为例，主要查看和分析Flickr网站上星空机器人小组所拍摄的星空照片。它对每一张照片进行分析并能辨别出它来自星空或其他天体(例如恒星和银河系等)的哪一部分。虽然这项研究尚处于试验阶段，但也表明如果可用的数据足够多(在本例中，为加有标签的图片数据)，通过它们而产生的后续应用也许会超乎这些拍照片的人最初的想象 (图片分析)。
有句话说得好：“大数据胜于好算法。”意思是说对于某些应用 (譬如根据以往的偏好来推荐电影和音乐)，不论算法有多牛，基于小数据的推荐效果往往都不如基于大量可用数据的一般算法的推荐效果。
现在，我们已经有了大量数据，这是个好消息。但不幸的是，我们必须想方设法好好地存储和分析这些数据。
1.2 数据的存储与分析
我们遇到的问题很简单：在硬盘存储容量多年来不断提升的同时，访问速度(硬盘数据读取速度)却没有与时俱进。1990年，一个普通硬盘可以存储1370MB数据，传输速度为4.4 MB/s，因此只需要5分钟就可以读完整个硬盘中的数据。20年过去了，1TB的硬盘已然成为主流，但其数据传输速度约为100MB/s，读完整个硬盘中的数据至少得花2.5个小时。
读完整个硬盘中的数据需要更长时间，写入数据就别提了。一个很简单的减少读取时间的办法是同时从多个硬盘上读数据。试想，如果我们有100个硬盘，每个硬盘存储1%的数据，并行读取，那么不到两分钟就可以读完所有数据。
仅使用硬盘容量的1%似乎很浪费。但是我们可以存储100个数据集，每个数据集1TB，并实现共享硬盘的读取。可以想象，用户肯定很乐于通过硬盘共享来缩短数据分析时间；并且，从统计角度来看，用户的分析工作都是在不同时间点进行的，所以彼此之间的干扰并不太大。
虽然如此，但要对多个硬盘中的数据并行进行读写数据，还有更多问题要解决。第一个需要解决的是硬件故障问题。一旦开始使用多个硬件，其中个别硬件就很有可能发生故障。为了避免数据丢失，最常见的做法是复制(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的一些典型应用。
1.3.3 志愿计算
人们第一次听说Hadoop和MapReduce的时候，经常会问这个问题：“它们和SETI@home有什么不同？”SETI全称为Search for Extra-Terrestrial Intelligence(搜索外星智能)，项目名称为SETI@home(http://setiathome.berkeley.edu)。在该项目中，志愿者把自己计算机CPU的空闲时间贡献出来分析无线天文望远镜的数据，借此寻找外星智慧生命信号。SETI@home因为拥有庞大的志愿者队伍而非常出名，其他还有“搜索大素数”(Great Internet Mersenne Prime Search)项目与Folding@home项目(了解蛋白质构成及其与疾病之间的关系)。
志愿计算项目将问题分成很多块，每一块称为一个工作单元(work unit)，发到世界各地的计算机上进行分析。例如，SETI@home的工作单元是0.35MB无线电望远镜数据，要对这等大小的数据量进行分析，一台普通计算机需要几个小时或几天时间才能完成。完成分析后，结果发送回服务器，客户端随后再获得另一个工作单元。为防止欺骗，每个工作单元要发送到3台不同的机器上执行，而且收到的结果中至少有两个相同才会被接受。
从表面上看，SETI@home与MapReduce好像差不多(将问题分解为独立的小块，然后并行进行计算)，但事实上还是有很多明显的差异。SETI@home问题是CPU高度密集的，比较适合在全球成千上万台计算机上运行，因为计算所花的时间远远超过工作单元数据的传输时间。也就是说，志愿者贡献的是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[ 在本书中我们使用小写的jobtracker来代表实体(泛称)，用驼峰体JobTracker来表示对Java类的实现。]，一看就知道它是用来跟踪MapReduce作业的。
从头打造一个网络搜索引擎是一个雄心勃勃的计划，不只是因为写爬虫程序很复杂，更因为必须有一个专职团队来实现——项目中包含许许多多需要随时修改的活动部件。同时，构建这样的系统代价非常高——据Mike Cafarella和Doug Cutting估计，一个支持10亿网页的索引系统，单是硬件上的投入就高达50万美元，另外还有每月高达3万美元的运维费用。[ Mike Cafarella和Doug Cutting在2004年4月发表在ACM Queue上的文章“Building Nutch: Open Source Search”，网址为http://queue.acm.org/detail.cfm?id=988408。]不过，他们认为这个工作仍然值得投入，因为它开创的是一个优化搜索引擎算法的平台。
2004年，谷歌发表论文向全世界介绍他们的MapReduce系统。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集群上构建的。[ 参见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/。]
2008年1月，Hadoop已成为Apache的顶级项目，证明了它的成功、多样化和生命力。到目前为止，除雅虎之外，还有很多公司在用Hadoop，例如Last.fm、Facebook和《纽约时报》等。第16章和Hadoop 维基页面(英文)介绍了一些案例(http://wiki.apache.org/hadoop/PoweredBy)。
《纽约时报》的案例广为流传，他们把1851 年到 1980 年的存档扫描之后得到4 TB的文件并用亚马逊的EC2云服务将文件存为PDF格式放到网上共享。[ 参见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/。]整个过程一共使用了100台计算机，所花的时间不到24小时。如果没有亚马逊的按小时付费模式(即允许《纽约时报》短期内访问大量机器)和Hadoop好用的并发编程模型珠联璧合，这个项目不太可能这么快就启动和完成。
2008年4月，Hadoop打破世界纪录，成为最快的TB级数据排序系统。在一个910节点的群集，Hadoop在209 秒内(不到3.5分钟)完成了对1TB数据的排序，击败了前一年的297秒冠军(详情参见15.5节的补充材料“Apache Hadoop的TB级数据处理”)。同年11月，谷歌在报告中声称，它的MapReduce对1 TB数据排序只用了68秒。[ 全文参见2008年11月21日的文章“Sorting 1PB with MapReduce”(MapReduce处理1 PB数据)，网址为http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html。]2009年5月本书第1版出版的时候，有报道称雅虎有一个的团队使用 Hadoop对1 TB数据进行排序只花了62秒。
从那以后，Hadoop跃升为企业主流的部署系统。在工业界，Hadoop已经是公认的大数据通用存储和分析平台，这一事实主要体现在大量直接使用或者间接辅助Hadoop系统的产品如雨后春笋般大量涌现。一些大公司也发布Hadoop发行版本，包括EMC，IBM，Microsft和Oracle以及一些专注于Hadoop的公司，如Cloudera，Hortonworks[ 编者注：该公司是雅虎的几个核心开发人员创办的，主要提供Hadoop支持和咨询服务，他们已经与微软在2011年建立战略合作关系，帮助微软将Hadoop移植到Wiondows Server和Azure。]和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个节点上(每节点10GB)运行排序测试集需要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个节点上运行1TB排序测试集仅需209秒，成为全球最快 2008年10月 研究集群每天装载10TB的数据 2009年3月 17个集群共24000个节点 2009年4月 在每分钟排序中胜出，59秒内排序500 GB(在1400个节点上)和173分钟内排序100TB数据(在3400个节点上
1.5 Apache Hadoop和Hadoop生态系统
尽管Hadoop因MapReduce及其分布式文件系统(HDFS，由NDFS改名而来)而出名，但Hadoop这个名字也用于泛指一组相关的项目，这些相关项目都使用这个基础平台进行分布式计算和海量数据处理。
本书提到的大多数核心项目都受Apache软件基金会(http://hadoop.apache.org/)支持，该基金会对开源软件项目社区提供支持，包括最初的HTTP Server项目。随着Hadoop生态系统的成长，新出现的项目越来越多，其中不乏一些非Apache主管的项目，这些项目对Hadoop是很好的补充或提供一些更高层的抽象。
下面简单提一下本书所提到的Hadoop项目：
Common：一系列组件和接口，用于分布式文件系统和通用I/O(序列化、Java RPC和持久化数据结构) Avro：一种序列化系统，用于支持高效、跨语言的RPC和持久化数据存储 MapReduce：分布式数据处理模型和执行环境，运行于大型商用机集群 HDFS：分布式文件系统，运行于大型商用机集群 Pig：数据流语言和运行环境，用以探究非常庞大的数据集。Pig运行在MapReduce和HDFS集群上 Hive：一种分布式的、按列存储的数据仓库。Hive管理HDFS中存储的数据，并提供基于 SQL的查询语言(由运行时引擎翻译成MapReduce作业)用以查询数据 HBase：一种分布式的、按列存储的数据库。HBase使用HDFS作为底层存储，同时支持MapReduce的批量式计算和点查询(随机读取) ZooKeeper：一种分布式的、可用性高的协调服务。ZooKeeper提供分布式锁之类的基本服务用于构建分布式应用 Sqoop：该工具用于在结构化数据存储(如关系型数据库)和HDFS之间高效批量传输数据 Oozie：该服务用于运行和调度Hadoop作业(如MapReduce，Pig，Hive及Sqoop作业)
1.6 Hadoop的发行版本
应该用哪个版本的Hadoop呢？当然，这个问题的答案总是随着时间而变化，而且依赖于你所需要的特性。这里总结了现阶段Hadoop发行版本系列的概要特征。
有一系列活跃的发行版本。1.x发行版本系列是0.20发行版本系列的延续，并且包含有当前最稳定的Hadoop发行版本。这一系列中包含安全的Kerberos认证，该安全认证避免了非授权用户访问Hadoop数据(可参见第9章介绍的安全相关内容)。几乎所有集群运行的都是这些发行版本或扩展版本(例如商业版本)。
0.22和2.x发行版本系列[ 在这本书出版的时候，Hadoop社区通过投票决定将0.23发行版本系列重新命名为2.x发行版本系列。本书中使用的简写“1.x之后的版本”指的是0.22和2.x(之前的0.23)发行版本系列。]目前还不是非常稳定(2012年初)，但是在你读到这本书的时候这些发行版本系列已经发生了变化，因为这些版本正被越来越多的真实应用测试(请参考Apache Hadoop发行版页面了解最新状态)。2.x包含如下主要的新特性。
在新的YARN系统(Yet Another Resource Negotiator)系统上构建了一个新的运行环境，称为MapReduce 2。YARN是一个通用的用于运行分布式应用的资源管理器。MapReduce 2替代了前期发行版本中的“经典“运行环境。具体细节请参考6.1.2节。 HDFS联邦管理，该管理将HDFS的命名空间分散到多个namenode中以支持包含有大规模数据文件的集群。详情请参见3.2.3节。 HDFS的高可用性，针对系统崩溃而启用备用的namenode来避免namenode的单点故障问题。详情参见3.2.4节。
表1-2只包含HDFS和MapReduce的一些特性。Hadoop生态系统中其他一些项目也在不断演化中，同时在这些项目中选出一部分组件联合使用具有一定的挑战。幸运的是，现在我们不需要亲自做这些配置了。Apache Bigtop项目(http://incubator.apache.org/bigtop/)对Hadoop组件的软件栈进行了内部测试并提供Linux安装包(RPM和Debian安装包)。同时，也有一些厂商提供兼容套件的Hadoop版本。
表1-2. Hadoop发行版本系列支持的特性
特性 1.x 0.22 2.x 安全认证 是 否 是 旧的配置名称 是 弃用 弃用 新的配置名称 否 是 是> 旧的MapReduce API 是 是 是 新的MapReduce API 是(加入部分缺失类库) 是 是 MapReduce 1 运行环境 (经典) 是 是 否 MapReduce 2 运行环境(YARN) 否 否 是 HDFS联邦管理 否 否 是 HDFS高可用 否 否 是 1.6.1 本书包含的内容
本书包含表1-2中所有的发行版。我们在这里对一些特殊发行版中包含的特性进行说明。
除了我们明确说明的少数几个例子不能在任意一个发行版本上运行之外，本书中包含的代码可以在任意一个发行版本上运行。本书配套网站提供的示例代码我们已经在表中所包含的所有发行版本上多次测试过。
1. 配置名称
为了有一个更加规范的命名结构，在1.x之后的发行版本中的配置属性命名与之前的版本已经不同。例如，与namenode相关的HDFS属性增加了前缀dfs.namenode，故dfs.name.dir已修改为dfs.namenode.name.dir。类似，MapReduce属性增加了mapreduce前缀，而非原来的mapred前缀，因此mapred.job.name已修改为mapreduce.job.name。
对于1.x版本中已包含的属性，本书仍然使用原先的(被废弃的)命名方式，因为这些命名仍然可在表中列出的Hadoop发行版本中使用。如果使用1.x之后的版本，你可能希望在配置文件中使用新的属性名，以免出现使用被废弃命名时的警告。Hadoop网站( http://hadoop.apache.org/common/docs/r0.23.0/hadoop-project-dist/hadoop-common/DeprecatedProperties.html )列出了弃用的名称及其替代名称。
2. MapReduce API
在2.4.1节的补充内容“旧的和新的Java MapReduce API”中，提供了两组Java MapReduceAPI。本书中使用新的API提供示例代码，不过还是有一些本例使用了1.x版中没有的新的API，这些示例代码可以在本书列的所有发行版本使用。本书中使用旧API版本(在oldapi包中)的示例代码可以在本书配套网站下载。
这两类API中存在着本质的区别，我们将进行详细叙述。
1.6.2 兼容性
将Hadoop版本升级成另外一个版本时，需要仔细考虑需要升级步骤。同时还要考虑几个方面：API兼容性、数据兼容性和连接兼容性。
API兼容性重点考虑用户代码和发行的Hadoop API之间的对比，例如Java MapReduce API。主发行版本(例如从1.x.y到2.0.0)是允许破坏API兼容性的，因此用户的程序要修改并重新编译。次重点发行版本(例如从到1.0.x到1.1.0)和单点发行版本(例如从1.0.1到1.0.2)不应该破坏兼容性。
Hadoop针对API函数使用分类模式来表征其稳定性。按照先前的命名规则，API兼容性包括标记为InterfaceStability.Stable。公开发行的Hadoop API中包含有部分函数，标记为interfaceStability. Evolving或者InterfaceStability. Unstable(上述标注包含在org.apache.hadoop.classification软件包中)，这意味允许它们分别在次重点发行版本和单点发行版本中破坏兼容性。
数据兼容性主要考虑持久数据和元数据的格式，例如在HDFS namenode中用于存储持久数据的格式。这些格式允许在主重版本和次版本之间修改，但是这类修改对用户透明，因为系统升级时数据会自动迁移。系统升级路径有一些限制，这些限制包含在发行须知中。例如，在系统升级过程中可能需要通过某个中间发行版本依次升级，而非一步直接升级到最新版本。10.3.3节“升级”将对此进行详细讨论。
连接兼容性主要考虑通过利用RPC和HTTP这样的连接协议来实现客户端和服务器之间的互操作性。有两类客户端：外部客户端(由用户运行)和内部客户端(作为整个系统的一部分在集群中运行，例如datanode和tasktracker的后台进程)。总之，内部客户端需要在加锁状态进行升级；旧版本的tasktracker无法与新版本的jobtracker一起工作。未来可能支持升级的回滚，这种情况下需要允许集群后台程序按阶段进行升级，以便在升级过程中集群对外部客户端而言仍然是可用的。
对于用户所运行的外部客户端(例如某个程序从HDFS读写文件或MapReduce提交作业的客户端)客户端与服务器必须有相同的主版本号，但是允许有更低的次版本号和单点发行版本(例如，客户端1.0.1版本可以与服务器1.0.2或者1.1.0一起工作，但是与服务器2.0.0版本不能一起工作)。所有特例在发行须知中都有详细的说明。