Hadoop权威指南中文版.docx
《Hadoop权威指南中文版.docx》由会员分享，可在线阅读，更多相关《Hadoop权威指南中文版.docx（97页珍藏版）》请在冰豆网上搜索。
Hadoop权威指南中文版
目录 I
初识Hadoop 1
1.1 数据！
数据 1
1.2 数据的存储和分析 3
1.3 相较于其他系统 4
1.4 Hadoop发展简史 9
1.5 ApacheHadoop项目 12
MapReduce简介 15
2.1 一个气象数据集 15
2.2 使用UnixTools来分析数据 17
2.3 使用Hadoop进行数据分析 19
2.4 分布化 30
2.5 Hadoop流 35
2.6 Hadoop管道 40
Hadoop分布式文件系统 44
3.1 HDFS的设计 44
3.2 HDFS的概念 45
3.3 命令行接口 48
3.4 Hadoop文件系统 50
3.5 Java接口 54
3.6 数据流 68
3.7 通过distcp进行并行复制 75
3.8 Hadoop归档文件 77
Hadoop的I/O 80
4.1 数据完整性 80
4.2 压缩 83
4.3 序列化 92
4.4 基于文件的数据结构 111
MapReduce应用开发 125
5.1 API的配置 126
5.2 配置开发环境 128
5.3 编写单元测试 134
5.4 本地运行测试数据 138
5.5 在集群上运行 144
5.6 作业调优 159
5.7 MapReduce的工作流 162
MapReduce的工作原理 166
6.1 运行MapReduce作业 166
6.2 失败 172
6.3 作业的调度 174
6.4 shuffle和排序 175
6.6 任务的执行 181
MapReduce的类型与格式 188
7.1 MapReduce类型 188
7.3 输出格式 217
MapReduce特性 227
8.1 计数器 227
8.2 排序 235
8.3 联接 252
8.4 次要数据的分布 258
8.5 MapReduce的类库 263
Hadoop集群的安装 264
9.1 集群说明 264
9.2 集群的建立和安装 268
9.3 SSH配置 270
9.4 Hadoop配置 271
9.5 安装之后 286
9.6 Hadoop集群基准测试 286
9.7 云计算中的Hadoop 290
Hadoop的管理 293
10.1 HDFS 293
10.2 监控 306
10.3 维护 313
Pig简介 321
11.1 安装和运行Pig 322
11.2 实例 325
11.3 与数据库比较 329
11.4 PigLatin 330
11.5 用户定义函数 343
11.6 数据处理操作符 353
11.7 Pig实践提示与技巧 363
Hbase简介 366
12.1 HBase基础 366
12.2 概念 367
12.3 安装 371
12.4 客户端 374
12.5 示例 377
12.6 HBase与RDBMS的比较 385
12.7 实践 390
ZooKeeper简介 394
13.1 ZooKeeper的安装和运行 395
13.2 范例 396
13.3 ZooKeeper服务 405
13.4 使用ZooKeeper建立应用程序 417
13.5 工业界中的ZooKeeper 428
案例研究 431
14.1 Hadoop在Last.fm的应用 431
14.2 Hadoop和Hive在Facebook的应用 441
14.3 Hadoop在Nutch搜索引擎 451
14.4 Hadoop用于Rackspace的日志处理 466
14.5 Cascading项目 474
14.6 ApacheHadoop的1TB排序 488
ApacheHadoop的安装 491
Cloudera的Hadoop分发包 497
预备NCDC气象资料 502
第1章初识Hadoop
古时候，人们用牛来拉重物，当一头牛拉不动一根圆木的时候，他们不曾想过培育个头更大的牛。
同样，我们也不需要尝试更大的计算机，而是应该开发更多的计算系统。
--格蕾斯·霍珀
1.1 数据！
数据
我们生活在数据时代！
很难估计全球存储的电子数据总量是多少，但是据IDC估计2006年"数字全球"项目（digitaluniverse）的数据总量为0.18ZB，并且预测到2011年这个数字将达到1.8ZB，为2006年的10倍。
1ZB相当于10的21次方字节的数据，或者相当于1000EB，1000000PB，或者大家更熟悉的10亿TB的数据！
这相当于世界上每个人一个磁盘驱动器的数量级。
这一数据洪流有许多来源。
考虑下文：
纽约证券交易所每天产生1TB的交易数据。
著名社交网站Facebook的主机存储着约100亿张照片，占据PB级存储空间。
A，一个家谱网站，存储着2.5PB数据。
互联网档案馆（TheInternetArchive）存储着约2PB数据，并以每月至少20TB的速度增长。
瑞士日内瓦附近的大型强子对撞机每年产生约15PB的数据。
此外还有大量数据。
但是你可能会想它对自己有何影响。
大部分数据被锁定在最大的网页内容里面（如搜索引擎）或者是金融和科学机构，对不对？
是不是所谓的"大数据"的出现会影响到较小的组织或个人？
我认为是这样的。
以照片为例，我妻子的祖父是一个狂热的摄影爱好者，并且他成人之后，几乎一直都在拍照片。
他的所有照片（中等格式、幻灯片和35mm胶片），在扫描成高解析度照片时，占了大约10GB的空间。
相比之下，我家去年一年用数码相机拍摄的照片就占用了5GB的空间。
我家产生照片数据的速度是我妻子祖父的35倍！
并且，随着拍摄更多的照片变得越来越容易，这个速度还在增加中。
更常见的情况是，个人数据的产生量正在快速地增长。
微软研究院的MyLifeBits项目（GB的大小。
当存储成本下降到使其可以存储连续的音频和视频时，服务于未来MyLifeBits项目的数据量将是现在的许多倍。
个人数据的增长的确是大势所趋，但更重要的是，计算机所产生的数据可能比人所产生的数据更大。
机器日志、RFID读取器、传感器网络、车载GPS和零售交易数据等，这些都会促使"数据之山越来越高"。
公开发布的数据量也在逐年增加。
作为组织或企业，再也不能只管理自己的数据，未来的成功在很大程度上取决于它是否能从其他组织的数据中提取出价值。
这方面的先锋（如亚马逊网络服务器、Infochimps.org或者andtheinfo.org）的公共数据集，它们的存在就在于促进"信息共享"，任何人都可以共享并自由（或以AWS平台的形式，或以适度的价格）下载和分析这些数据。
不同来源的信息混合处理后会带来意外的效果和至今难以想像的应用。
以A项目为例，这是一个研究Flickr网站上天体爱好者群中新照片的项目。
它分析每一张上传的照片，并确定它是天空的哪一部分，或者是否是有趣的天体，如恒星或者星系。
虽然这只是一个带实验性质的新服务，但是它显示了数据（这里特指摄影照片）的可用性并且被用来进行某些活动（图像分析），而这些活动很多时候并不是数据创建者预先能够想像到的。
有句话是这么说的：
"算法再好，通常也难敌更多的数据。
"意思是说对于某些问题（譬如基于既往偏好生成的电影和音乐推荐），不论你的算法有多么猛，它们总是会在更多的数据面前无能为力（更不用说没有优化过的算法了）。
现在，我们有一个好消息和一个坏消息。
好消息是有海量数据！
坏消息是我们正在为存储和分析这些数据而奋斗不息。
1.2 数据的存储和分析
问题很简单：
多年来硬盘存储容量快速增加的同时，访问速度--数据从硬盘读取的速度--却未能与时俱进。
1990年，一个普通的硬盘驱动器可存储1370MB的数据并拥有4.4MB/s的传输速度，所以，只需五分钟的时间就可以读取整个磁盘的数据。
20年过去了，1TB级别的磁盘驱动器是很正常的，但是数据传输的速度却在100MB/s左右。
所以它需要花两个半小时以上的时间读取整个驱动器的数据。
从一个驱动器上读取所有的数据需要很长的时间，写甚至更慢。
一个很简单的减少读取时间的办法是同时从多个磁盘上读取数据。
试想一下，我们拥有100个磁盘，每个存储百分之一的数据。
如果它们并行运行，那么不到两分钟我们就可以读完所有的数据。
只使用一个磁盘的百分之一似乎很浪费。
但是我们可以存储100个数据集，每个1TB，并让它们共享磁盘的访问。
我们可以想像，此类系统的用户会很高兴看到共享访问可以缩短分析时间，并且，从统计角度来看，他们的分析工作会分散到不同的时间点，所以互相之间不会有太多干扰。
尽管如此，现在更可行的是从多个磁盘并行读写数据。
第一个需要解决的问题是硬件故障。
一旦开始使用多个硬件设施，其中一个会出故障的概率是非常高的。
避免数据丢失的常见做法是复制：
通过系统保存数据的冗余副本，在故障发生时，可以使用数据的另一份副本。
这就是冗余磁盘阵列的工作方式。
Hadoop的文件系统HDFS（HadoopDistributedFilesystem）也是一个例子，虽然它采取的是另一种稍有不同的方法，详见后文描述。
第二个问题是大部分分析任务需要通过某种方式把数据合并起来，即从一个磁盘读取的数据可能需要和另外99个磁盘中读取的数据合并起来才能使用。
各种不同的分布式系统能够组合多个来源的数据，但是如何保证正确性是一个非常难的挑战。
MapReduce提供了一个编程模型，其抽象出上述磁盘读写的问题，将其转换为计算一个由成对键/值组成的数据集。
这种模型的具体细节将在后面的章节讨论。
但是目前讨论的重点是，这个计算由两部分组成：
Map和Reduce。
这两者的接口就是"整合"之地。
就像HDFS一样，MapReduce是内建可靠性这个功能的。
简而言之，Hadoop提供了一个稳定的共享存储和分析系统。
存储由HDFS实现，分析由MapReduce实现。
纵然Hadoop还有其他功能，但这些功能是它的核心所在。
1.3 相较于其他系统
MapReduce似乎采用的是一种蛮力方法。
即，针对每个查询，每一个数据集--至少是很大一部分--都会被处理。
但这正是它的能力。
MapReduce可以处理一批查询，并且它针对整个数据集处理即席查询并在合理时间内获得结果的能力也是具有突破性的。
它改变了我们对数据的看法，并且解放了以前存储在磁带和磁盘上的数据。
它赋予我们对数据进行创新的机会。
那些以前需要很长时间才能获得答案的问题现在已经迎刃而解，但反过来，这又带来了新的问题和见解。
例如，Rackspace的邮件部门Mailtrust，用Hadoop处理邮件的日志。
他们写的一个查询是找到其用户的地理分布。
他们是这样说的：
"随着我们的壮大，这些数据非常有用，我们每月运行一次MapReduce任务来帮助我们决定哪些Rackspace数据中心需要添加新的邮件服务器。
"
通过将数百GB的数据整合，借助于分析工具，Rackspace的工程师得以了解这些数据，否则他们永远都不会了解，并且他们可以运用这些信息去改善他们为用户提供的服务。
第14章将详细介绍Rackspace公司是如何运用Hadoop的。
1.3.1 关系型数据库管理系统
为什么我们不能使用数据库加上更多磁盘来做大规模的批量分析？
为什么我们需要MapReduce？
这个问题的答案来自于磁盘驱动器的另一个发展趋势：
寻址时间的提高速度远远慢于传输速率的提高速度。
寻址就是将磁头移动到特定位置进行读写操作的工序。
它的特点是磁盘操作有延迟，而传输速率对应于磁盘的带宽。
如果数据的访问模式受限于磁盘的寻址，势必会导致它花更长时间（相较于流）来读或写大部分数据。
另一方面，在更新一小部分数据库记录的时候，传统的B树（关系型数据库中使用的一种数据结构，受限于执行查找的速度）效果很好。
但在更新大部分数据库数据的时候，B树的效率就没有MapReduce的效率高，因为它需要使用排序/合并来重建数据库。
在许多情况下，MapReduce能够被视为一种RDBMS（关系型数据库管理系统）的补充。
（两个系统之间的差异见表1-1）。
MapReduce很适合处理那些需要分析整个数据集的问题，以批处理的方式，尤其是AdHoc（自主或即时）分析。
RDBMS适用于点查询和更新（其中，数据集已经被索引以提供低延迟的检索和短时间的少量数据更新。
MapReduce适合数据被一次写入和多次读取的应用，而关系型数据库更适合持续更新的数据集。
表1-1：
关系型数据库和MapReduce的比较
传统关系型数据库
MapReduce
数据大小
GB
PB
访问
交互型和批处理
批处理
更新
多次读写
一次写入多次读取
结构
静态模式
动态模式
集成度
高
低
伸缩性
非线性
线性
MapReduce和关系型数据库之间的另一个区别是它们操作的数据集中的结构化数据的数量。
结构化数据是拥有准确定义的实体化数据，具有诸如XML文档或数据库表定义的格式，符合特定的预定义模式。
这就是RDBMS包括的内容。
另一方面，半结构化数据比较宽松，虽然可能有模式，但经常被忽略，所以它只能用作数据结构指南。
例如，一张电子表格，其中的结构便是单元格组成的网格，尽管其本身可能保存任何形式的数据。
非结构化数据没有什么特别的内部结构，例如纯文本或图像数据。
MapReduce对于非结构化或半结构化数据非常有效，因为它被设计为在处理时间内解释数据。
换句话说：
MapReduce输入的键和值并不是数据固有的属性，它们是由分析数据的人来选择的。
关系型数据往往是规范的，以保持其完整性和删除冗余。
规范化为MapReduce带来问题，因为它使读取记录成为一个非本地操作，并且MapReduce的核心假设之一就是，它可以进行（高速）流的读写。
Web服务器日志是记录集的一个很好的非规范化例子（例如，客户端主机名每次都以全名来指定，即使同一客户端可能会出现很多次），这也是MapReduce非常适合用于分析各种日志文件的原因之一。
MapReduce是一种线性的可伸缩的编程模型。
程序员编写两个函数-- map函数和Reduce函数--每一个都定义一个键/值对集映射到另一个。
这些函数无视数据的大小或者它们正在使用的集群的特性，这样它们就可以原封不动地应用到小规模数据集或者大的数据集上。
更重要的是，如果放入两倍的数据量，运行的时间会少于两倍。
但是如果是两倍大小的集群，一个任务任然只是和原来的一样快。
这不是一般的SQL查询的效果。
随着时间的推移，关系型数据库和MapReduce之间的差异很可能变得模糊。
关系型数据库都开始吸收MapReduce的一些思路（如ASTERDATA的和GreenPlum的数据库），另一方面，基于MapReduce的高级查询语言（如Pig和Hive）使MapReduce的系统更接近传统的数据库编程人员。
1.3.2 网格计算
高性能计算（HighPerformanceComputing，HPC）和网格计算社区多年来一直在做大规模的数据处理，它们使用的是消息传递接口（MessagePassingInterface，MPI）这样的API。
从广义上讲，高性能计算的方法是将作业分配给一个机器集群，这些机器访问共享文件系统，由一个存储区域网络（StorageAreaNetwork，SAN）进行管理。
这非常适用于以主计算密集型为主的作业，但当节点需要访问的大数据量（数百GB的数据，这是MapReduce实际开始"发光"的起点）时，这会成为一个问题，因为网络带宽成为"瓶颈"，所以计算节点闲置下来了。
MapReduce尝试在计算节点本地存储数据，因此数据访问速度会因为它是本地数据而比较快。
这项"数据本地化"功能，成为MapReduce的核心功能并且也是它拥有良好性能的原因之一。
意识到网络带宽在数据中心环境是最有价值的资源（到处复制数据会很容易的把网络带宽饱和）之后，MapReduce便通过显式网络拓扑结构不遗余力地加以保护。
请注意，这种安排不会排除MapReduce中的高CPU使用分析。
MPI赋予程序员很大的控制，但也要求显式控制数据流机制，需要使用传统的C语言的功能模块完成（例如socket），以及更高级的算法来进行分析。
而MapReduce却是在更高层面上完成任务，即程序员从键/值对函数的角度来考虑，同时数据流是隐含的。
在一个大规模分布式计算平台上协调进程是一个很大的挑战。
最困难的部分是恰当的处理失效与错误--在不知道一个远程进程是否已经失败的时候--仍然需要继续整个计算。
MapReduce将程序员从必须考虑失败任务的情况中解放出来，它检测失败的map或者reduce任务，在健康的机器上重新安排任务。
MapReduce能够做到这一点，因为它是一个无共享的架构，这意味着各个任务之间彼此并不依赖。
（这里讲得稍微简单了一些，因为mapper的输出是反馈给reducer的，但这由MapReduce系统控制。
在这种情况下，相对于返回失败的map，应该对返回reducer给予更多关注，因为它必须确保它可以检索到必要的map输出，如果不行，必须重新运行相关的map从而生成必要的这些输出。
）因此，从程序员的角度来看，执行任务的顺序是无关紧要的。
相比之下，MPI程序必须显式地管理自己的检查点和恢复机制，从而把更多控制权交给程序员，但这样会加大编程的难度。
MapReduce听起来似乎是一个相当严格的编程模型，而且在某种意义上看的确如此：
我们被限定于键/值对的类型（它们按照指定的方式关联在一起），mapper和reducer彼此间的协作有限，一个接一个地运行（mapper传输键/值对给reducer）。
对此，一个很自然的问题是：
你是否能用它做点儿有用或普通的事情？
答案是肯定的。
MapReduce作为一个建立搜索索引产品系统，是由Google的工程师们开发出来的，因为他们发现自己一遍又一遍地解决相同的问题（MapReduce的灵感来自传统的函数式编程、分布式计算和数据库社区），但它后来被应用于其他行业的其他许多应用。
我们惊喜地看到许多算法的变体在MapReduce中得以表示，从图像图形分析，到基于图表的问题，再到机器学习算法。
它当然不能解决所有问题，但它是一个很普遍的数据处理工具。
第14章将介绍一些Hadoop应用范例。
1.3.3 志愿计算
人们第一次听说Hadoop和MapReduce的时候，经常会问：
"和SETI@home有什么区别？
"SETI，全称为SearchforExtra-TerrestrialIntelligence（搜寻外星人），运行着一个称为SETI@home的项目（http:
//setiathome.berkeley.edu）。
在此项目中，志愿者把自己计算机CPU的空闲时间贡献出来分析无线天文望远镜的数据借此寻外星智慧生命信号。
SETI@home是最有名的拥有许多志愿者的项目，其他的还有GreatInternetMersennePrimeSearch（搜索大素数）与Folding@home项目（了解蛋白质构成及其与疾病之间的关系）。
志愿计算项目通过将他们试图解决的问题分为几个他们成为工作单元的块来工作，并将它们送到世界各地的电脑上进行分析。
例如，SETI@home的工作单元大约是0.35MB的无线电望远镜数据，并且一个典型的计算机需要数小时或数天来分析。
完成分析后，结果发送回服务器，客户端获得的另一项工作单元。
作为防止欺骗的预防措施，每个工作单元必须送到三台机器上并且需要有至少两个结果相同才会被接受。
虽然SETI@home在表面上可能类似于MapReduce（将问题分为独立的块，然后进行并行计算），但差异还是显著的。
SETI@home问题是CPU高度密集型的，使其适合运行于世界各地成千上万台计算机上，因为相对于其计算时间而言，传输工作单元的时间微不足道。
志愿者捐献的是CPU周期，而不是带宽。
MapReduce被设计为用来运行那些需要数分钟或数小时的作业，这些作业在一个聚集带宽很高的数据中心中可信任的专用硬件设备上运行。
相比之下，SETI@home项目是在接入互联网的不可信的计算机上运行，这些计算机的网速不同，而且数据也不在本地。
1.4 Hadoop发展简史
Hadoop是DougCutting--ApacheLucene创始人--开发的使用广泛的文本搜索库。
Hadoop起源于ApacheNutch，后者是一个开源的网络搜索引擎，本身也是由Lucene项目的一部分。
Hadoop名字的起源
Hadoop这个名字不是一个缩写，它是一个虚构的名字。
该项目的创建者，DougCutting如此解释Hadoop的得名：
"这个名字是我孩子给一头吃饱了的棕黄色大象命名的。
我的命名标准就是简短，容易发音和拼写，没有太多的意义，并且不会被用于别处。
小孩子是这方面的高手。
Googol就是由小孩命名的。
"
Hadoop及其子项目和后继模块所使用的名字往往也与其功能不相关，经常用一头大象或其他动物主题（例如：
"Pig"）。
较小的各个组成部分给与更多描述性（因此也更俗）的名称。
这是一个很好的原则，因为它意味着可以大致从其名字猜测其功能，例如，jobtracker的任务就是跟踪MapReduce作业。
从头开始构建一个网络搜索引擎是一个雄心勃勃的目标，不只是要编写一个复杂的、能够抓取和索引网站的软件，还需要面临着没有专有运行团队支持运行它的挑战，因为它有那么多独立部件。
同样昂贵的还有：
据MikeCafarella和DougCutting估计，一个支持此10亿页的索引需要价值约50万美元的硬件投入，每月运行费用还需要3万美元。
不过，他们相信这是一个有价值的目标，因为这会开放并最终使搜索引擎算法普及化。
Nutch项目开始于2002年，一个可工作的抓取工具和搜索系统很快浮出水面。
但他们意识到，他们的架构将无法扩展到拥有数十亿网页的网络。
在2003年发表的一篇描述Google分布式文件系统（简称GFS）的论文为他们提供了及时的帮助，文中称Google正在使用此文件系统。
GFS或类似的东西，可以解决他们在网络抓取和索引过程中产生的大量的文件的存储需求。
具体而言，GFS会省掉管理所花的时间，如管理存储节点。
在2004年，他们开始写一个开放源码的应用，即Nutch的分布式文件系统（NDFS）。
2004年，Google发表了论文，向全世界介绍了MapReduce。
2005年初，Nutch的开发者在Nutch上有了一个可工作的MapReduce应用，到当年年中，所有主要的Nutch算法被移植到使用MapReduce和NDFS来运行。
Nutch中的NDFS和MapReduce实现的应用远不只是搜索领域，在2006年2月，他们从Nutch转移出来成为一个独立的Lucene子项目，称为Hadoop。
大约在同一时间，DougCutting加入雅虎，Yahoo提供一个专门的团队和资源将Hadoop发展成一个可在网络上运行的系统（
升级会员 