搜索
目录目录I初识Hadoop11.1数据！数据11.2数据的存储和分析31.3相较于其他系统41.4Hadoop发展简史91.5ApacheHadoop项目12MapReduce简介152.1一个气象数据集152.2使用UnixTools来分析数据172.3使用Hadoop进行数据分析192.4分布化302.5Hadoop流352.6Hadoop管道40Hadoop分布式文件系统443.1HDFS的设计443.2HDFS的概念453.3命令行接口483.4Hadoop文件系统503.5Java接口543.6数据流683.7通过distcp进行并行复制753.8Hadoop归档文件77Hadoop的I/O804.1数据完整性804.2压缩834.3序列化924.4基于文件的数据结构111MapReduce应用开发1255.1API的配置1265.2配置开发环境1285.3编写单元测试1345.4本地运行测试数据1385.5在集群上运行1445.6作业调优1595.7MapReduce的工作流162MapReduce的工作原理1666.1运行MapReduce作业1666.2失败1726.3作业的调度1746.4shuffle和排序1756.6任务的执行181MapReduce的类型与格式1887.1MapReduce类型1887.3输出格式217MapReduce特性2278.1计数器2278.2排序2358.3联接2528.4次要数据的分布2588.5MapReduce的类库263Hadoop集群的安装2649.1集群说明2649.2集群的建立和安装2689.3SSH配置2709.4Hadoop配置2719.5安装之后2869.6Hadoop集群基准测试2869.7云计算中的Hadoop290Hadoop的管理29310.1HDFS29310.2监控30610.3维护313Pig简介32111.1安装和运行Pig32211.2实例32511.3与数据库比较32911.4PigLatin33011.5用户定义函数34311.6数据处理操作符35311.7Pig实践提示与技巧363Hbase简介36612.1HBase基础36612.2概念36712.3安装37112.4客户端37412.5示例37712.6HBase与RDBMS的比较38512.7实践390ZooKeeper简介39413.1ZooKeeper的安装和运行39513.2范例39613.3ZooKeeper服务40513.4使用ZooKeeper建立应用程序41713.5工业界中的ZooKeeper428案例研究43114.1Hadoop在Last.fm的应用43114.2Hadoop和Hive在Facebook的应用44114.3Hadoop在Nutch搜索引擎45114.4Hadoop用于Rackspace的日志处理46614.5Cascading项目47414.6ApacheHadoop的1TB排序488ApacheHadoop的安装491Cloudera的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级存储空间。Ancestry.com，一个家谱网站，存储着2.5PB数据。互联网档案馆(TheInternetArchive)存储着约2PB数据，并以每月至少20TB的速度增长。瑞士日内瓦附近的大型强子对撞机每年产生约15PB的数据。此外还有大量数据。但是你可能会想它对自己有何影响。大部分数据被锁定在最大的网页内容里面(如搜索引擎)或者是金融和科学机构，对不对？是不是所谓的大数据的出现会影响到较小的组织或个人？我认为是这样的。以照片为例，我妻子的祖父是一个狂热的摄影爱好者，并且他成人之后，几乎一直都在拍照片。他的所有照片(中等格式、幻灯片和35mm胶片)，在扫描成高解析度照片时，占了大约10GB的空间。相比之下，我家去年一年用数码相机拍摄的照片就占用了5GB的空间。我家产生照片数据的速度是我妻子祖父的35倍！并且，随着拍摄更多的照片变得越来越容易，这个速度还在增加中。更常见的情况是，个人数据的产生量正在快速地增长。微软研究院的MyLifeBits项目()显示，在不久的将来，个人信息档案将可能成为普遍现象。MyLifeBits是这样的一个实验：一个人与外界的联系(电话、邮件和文件)被抓取和存储供以后访问。收集的数据包括每分钟拍摄的照片等，导致整个数据量达到每月1GB的大小。当存储成本下降到使其可以存储连续的音频和视频时，服务于未来MyLifeBits项目的数据量将是现在的许多倍。个人数据的增长的确是大势所趋，但更重要的是，计算机所产生的数据可能比人所产生的数据更大。机器日志、RFID读取器、传感器网络、车载GPS和零售交易数据等，这些都会促使数据之山越来越高。公开发布的数据量也在逐年增加。作为组织或企业，再也不能只管理自己的数据，未来的成功在很大程度上取决于它是否能从其他组织的数据中提取出价值。这方面的先锋(如亚马逊网络服务器、Infochimps.org或者andtheinfo.org)的公共数据集，它们的存在就在于促进信息共享，任何人都可以共享并自由(或以AWS平台的形式，或以适度的价格)下载和分析这些数据。不同来源的信息混合处理后会带来意外的效果和至今难以想像的应用。以Astrometry.net项目为例，这是一个研究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的比较传统关