新版新特色，内容更详细，更适合收藏和找Hadoop之父签名儿！
准备好释放数据的强大潜能了吗？借助于这本本书，你将学习如何使用ApacheHadoop构建和维护稳定性高、伸缩性强的分布式系统。本书是为程序员写的，可帮助他们分析任何大小的数据集。本书同时也是为管理员写的，帮助他们了解如何设置和运行Hadoop集群。
本书通过丰富的案例学习来解释Hadoop的幕后机理，阐述了Hadoop如何解决现实生活中的具体问题。第3版覆盖Hadoop的新动态，包括新增的MapReduceAPI，以及MapReduce2及其灵活性更强的执行模型（YARN）。
初识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的一些典型应用。
......
