Hadoop.docx
- 文档编号:4611966
- 上传时间:2022-12-07
- 格式:DOCX
- 页数:12
- 大小:403.09KB
Hadoop.docx
《Hadoop.docx》由会员分享,可在线阅读,更多相关《Hadoop.docx(12页珍藏版)》请在冰豆网上搜索。
Hadoop
Hadoop
第一章初识Hadoop
1.1背景
我们生活在数据时代!
很难估计全球以电子方式存储的数据总量有多少,但IDC的一项预测曾指出,“数据宇宙”项目统计得出,2006年的数据总量为0.18ZB,并预测在2011年,数据量将达到1.8ZB。
1ZB等于1021字节,或是大家熟悉的10亿TB的数据!
这相当于世界上每个一个磁盘驱动器所能容纳数据的数量级。
数据“洪流”有很多来源。
以下面列出的部分为例。
•纽约证券交易所每天产生1TB的交易数据
•社交网站Facebook存储着约100亿张照片,约1PB级存储空间
•A,一个家谱网站,存储着2.5PB数据。
•TheInternetArchive(互联网档案馆)存储着约2PB数据,并以每月至少20TB的速度增长。
•瑞士日内瓦附近的大型强子对撞机每年产生约15PB的数据。
现在,我们已经有了大量的数据,这对我们来说是好消息。
不幸的是,我们正纠结于如何存储和分析这些数据。
1.2数据存储与分析
我们遇到的问题很简单:
多年来磁盘存储容量快速增加的同时,其访问速度——磁盘数据读取速度——却未能与时俱进。
1990年,一个普通磁盘可存储1370MB的数据并拥有4.4MB/s的传输速度,因此,读取整个磁盘中的数据只需要5分钟。
20年后,1TB的磁盘逐渐普及,但其数据传输速度约为100MB/s,因此读取整个磁盘中的数据需要约两个半小时。
读取一个磁盘中所有的数据需要很长的时间,写甚至更慢。
一个很简单的减少读取时间的办法是同时从多个磁盘上读取数据。
试想,如果我们拥有100个磁盘,每个磁盘存储1%的数据,并行读取,那么不到两分钟就可以读取所有数据。
仅使用磁盘容量的1%似乎很浪费。
但是我们可以存储100个数据集,每个数据集1TB,并实现共享磁盘的访问。
尽管如此,但要实现对多个磁盘数据的并行读写,还有很多的问题要解决。
第一个需要解决的问题是硬件故障。
一旦使用多个硬件,其中任一硬件发生故障的概率将非常高。
第二个问题是大多数分析任务需要以某种方式结合大部分数据共同完成分析任务,即从一个磁盘读取的数据可能需要和从另外99个磁盘中读取的数据结合使用。
简而言之,Hadoop提供了一个可靠的共享存储和分析系统。
HDFS实现存储,而MapReduce实现分析处理。
纵然Hadoop还有其他功能,但这两部分是他的核心。
1.3关系型数据库管理系统
我们为什么不能使用数据库来对大量磁盘上的大规模数据进行批量分析呢?
这些问题的答案来自磁盘的另外一个发展趋势:
寻址时间的提高远远慢于传输速率的提高。
寻址是将磁头移动到特定磁盘位置进行读写操作的过程。
它是导致磁盘操作延迟的主要原因,而传输速率取决于磁盘的带宽。
如果数据的访问模式中包含大量的磁盘寻址,那么读取大量数据集所花的时间势必会更长(相较于流式数据读取模式),流式读取主要取决于传输速度。
另一方面,如果数据库系统只更新一小部分记录,那么传统的B树更有优势。
但数据库系统更新大部分数据时,B树的效率比MapReduce低得多,因为需要使用“排序/合并”来重建数据库。
在许多情况下,可以将MapReduce视为关系型数据库管理系统的补充。
两个系统之间的差异如下表所示。
MapReduce比较适合以批处理的方式处理需要分析整个数据集的问题,尤其是即席分析。
RDBMS适用于“点查询”和更新,数据集被索引后,数据库系统能够提供低延迟的数据检索和快速的少量数据更新。
MapReduce适合一次写入、多次读取数据的应用,而关系型数据库更适合持续更新的数据集。
关系型数据库和MapReduce的比较表
MapReduce和关系型数据库之间另一个区别在于它们所操作的数据集的结构化程度。
MapReduce对于非结构化或半结构化数据非常有效,因为在处理数据时才对数据进行解释。
换句话说:
MapReduce输入的键和值并不是数据固有的属性,而是由分析数据的人员来选择的。
关系型数据往往是规范的,以保持其数据的完整性且不含冗余。
但是在不久的将来,两者的差异很可能变得模糊。
另外,用关系型数据库存储数据成本较高。
传统关系型数据(oracle)的成本
Facebook的服务器大概1万台,按照oracle的标准10g版本计算大约需要21亿元。
1.4Hadoop发展简史
Hadoop是ApacheLucene创始人DougCutting创建的,Lucene是一个广泛使用的文本搜索系统库。
Hadoop起源于ApacheNutch,一个开源的网络搜索引擎,它本身也是Lucene项目的一部分。
2002年,Nutch项目开始运行,一个可以运行的网页爬取工具盒搜索引擎系统很快“浮出水面”。
但后来发现此架构可扩展度不够,不能解决数十亿网页的搜索问题。
2003年,谷歌发表了的一篇论文为此提供了帮助,文中描述的是谷歌产品架构,该架构成为谷歌分布式文件系统,简称GFS。
2004年,由DougCutting和MikeCafarella实现了现在HDFS和MapReduce的最初版本。
2005年12月,Nutch移植到新框架,Hadoop在20个节点上稳定运行。
2006年1月,DougCutting加入Yahoo!
。
2006年2月,ApacheHadoop项目正式启动以支持MapReduce和HDFS的独立发展。
2006年2月,Yahoo!
的网格计算团队采用Hadoop。
2006年4月,在188个节点上(每个节点10GB)运行排序测试集需要47.9个小时。
2006年5月,Yahoo!
建立了一个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个节点的集群。
2007年4月,在900个节点上运行1TB排序测试集仅需209秒,成为世界最快。
2008年10月,研究集群每天装载10TB的数据。
2009年3月,17个集群总共24000台机器。
2009年4月,赢得每分钟排序,59秒内排序500GB(在1400个节点上)和173分钟内排序100TB数据(在3400个节点上)。
2009年,HadoopCore项目更名为HadoopCommon;MapReduce、HDFS、Avro和Chukwa成为Hadoop项目的独立子项目。
2011年,PlatformComputing宣布在它的Symphony软件中支持HadoopMapReduceAPI。
2011年12月27日,1.0.0版本释出。
标志着Hadoop已经初具生产规模。
2013年2月,Wandisco推出了世界第一款可用于实际业务环境的ApacheHadoop2-WANdiscoDistro(WDD)。
第二章Hadoop的组成
2.1Hadoop的定义与组成
Hadoop是一个分布式系统基础架构,由Apache基金会开发。
用户可以在不了解分布式底层细节的情况下,开发分布式程序。
充分利用集群的威力高速运算和存储。
Hadoop由Pig、Chukwa、Hive、HBase、MapReduce、HDFS、ZooKeeper、Core、Avro九部分组成,其中最核心的设计是MapReduce和HDFS。
其中部分子项目的作用如下表所示:
部分子项目的作用表
2.2MapReduce
2.2.1关于MapReduce
MapReduce是一种编程模型,用于大规模数据集(大于1TB)的并行运算。
概念"Map(映射)"和"Reduce(化简)",和他们的主要思想,都是从函数式编程语言里借来的,还有从矢量编程语言里借来的特性。
他极大地方便了编程人员在不会分布式并行编程的情况下,将自己的程序运行在分布式系统上。
当前的软件实现是指定一个Map(映射)函数,用来把一组键值对映射成一组新的键值对,指定并发的Reduce(化简)函数,用来保证所有映射的键值对中的每一个共享相同的键组。
MapReduce任务过程被分为两个处理阶段:
map阶段和reduce阶段。
每个阶段都以键/值对作为输入和输出,并由程序员选定它们的类型。
程序员还需要具体定义两个函数:
map函数和reduce函数。
Hadoop的MapReduce中,map和reduce函数遵循如下常规格式:
map:
(k1,v1)→list(k2,v2)
reduce:
(k2,list(v2))→list(k3,v3)
一般来说,map函数输入的键/值对的类型(k1和v1)不同于输出类型(k2和v2)。
虽然,reduce函数的输入类型必须与map函数的输出类型相同,但reduce函数的输出类型(k3和v3)可以不同于输入类型。
2.2.2MapReduce的数据流
MapReduce作业是客户端需要执行的一个工作单元:
它包括输入数据、MapReduce程序和配置信息。
Hadoop将作业分成若干个小任务来执行,其中包括两类任务:
map任务和reduce任务。
MapReduce的工作原理图
一切都是从最上方的userprogram开始的,userprogram链接了MapReduce库,实现了最基本的Map函数和Reduce函数。
图中执行的顺序都用数字标记了。
1.MapReduce库先把userprogram的输入文件划分为M份(M为用户定义),每一份通常有16MB到64MB,如图左方所示分成了split0~4;然后使用fork将用户进程拷贝到集群内其它机器上。
2.userprogram的副本中有一个称为master,其余称为worker,master是负责调度的,为空闲worker分配作业(Map作业或者Reduce作业),worker的数量也是可以由用户指定的。
3.被分配了Map作业的worker,开始读取对应分片的输入数据,Map作业数量是由master决定的,和split一一对应;Map作业从输入数据中抽取出键值对,每一个键值对都作为参数传递给map函数,map函数产生的中间键值对被缓存在内存中。
4.缓存的中间键值对会被定期写入本地磁盘,而且被分为R个区,R的大小是由用户定义的,将来每个区会对应一个Reduce作业;这些中间键值对的位置会被通报给master,master负责将信息转发给Reduceworker。
5.master通知分配了Reduce作业的worker它负责的分区在什么位置(肯定不止一个地方,每个Map作业产生的中间键值对都可能映射到所有R个不同分区),当Reduceworker把所有它负责的中间键值对都读过来后,先对它们进行排序,使得相同键的键值对聚集在一起。
因为不同的键可能会映射到同一个分区也就是同一个Reduce作业(谁让分区少呢),所以排序是必须的。
6.reduceworker遍历排序后的中间键值对,对于每个唯一的键,都将键与关联的值传递给reduce函数,reduce函数产生的输出会添加到这个分区的输出文件中。
7.当所有的Map和Reduce作业都完成了,master唤醒正版的userprogram,MapReduce函数调用返回userprogram的代码。
所有执行完毕后,MapReduce输出放在了R个分区的输出文件中(分别对应一个Reduce作业)。
用户通常并不需要合并这R个文件,而是将其作为输入交给另一个MapReduce程序处理。
整个过程中,输入数据是来自底层分布式文件系统(GFS)的,中间数据是放在本地文件系统的,最终输出数据是写入底层分布式文件系统(GFS)的。
而且我们要注意Map/Reduce作业和map/reduce函数的区别:
Map作业处理一个输入数据的分片,可能需要调用多次map函数来处理每个输入键值对;Reduce作业处理一个分区的中间键值对,期间要对每个不同的键调用一次reduce函数,Reduce作业最终也对应一个输出文件。
2.2.2MapReduce应用实例
我们将使用国家气候数据中心(NationalClimaticDataCenter,简称NCDC,网址为http:
//www.ncdc.noaa.gov/)提供的数据。
这些数据按行并以ASCII编码存储,其中每一行是一条记录。
为全面了解map的工作方式,我们思考以下几行作为输入数据的示例数据:
0067011990999991950051507004…9999999N9+00001+99999999…
0043011990999991950051512004…9999999N9+00221+99999999…
0043011990999991950051518004…9999999N9-00111+99999999…
0043012650999991949032412004…0500001N9+01111+99999999…
0043012650999991949032418004…0500001N9+00781+99999999…
这些行以键/值对的方式来表示map函数:
(0,0067011990999991950051507004…9999999N9+00001+99999999…)
(106,0043011990999991950051512004…9999999N9+00221+99999999…)
(212,0043011990999991950051518004…9999999N9-00111+99999999…)
(318,0043012650999991949032412004…0500001N9+01111+99999999…)
(424,0043012650999991949032418004…0500001N9+00781+99999999…)
键(key)是文件中的行偏移量,map函数并不需要这个信息,所以将其忽略。
map函数的功能仅限于提取年份和气温信息(以蓝色显示),并将它们作为输出(气温值已用整数表示):
(1950,0)
(1950,22)
(1950,-11)
(1949,111)
(1949,78)
Map函数的输出经由MapReduce框架处理后,最后被发送到reduce函数。
这一处理过程中需要根据键/值对进行排序和分组。
因此,reduce函数会看到如下输入:
(1949,[111,78])(1950,[0,22,-11])
每一年份后紧跟着一系列气温数据。
所有reduce函数现在需要做的是遍历整个列表并从中找出最大的读数:
(1949,111)(1950,22)
这是最终输出结果:
每一年的全球最高气温纪录。
2.3HDFS
2.3.1HDFS的概念
HadoopDistributedFileSystem,简称HDFS,是一个分布式文件系统。
HDFS有着高容错性的特点,并且设计用来部署在低廉的硬件上。
而且它提供高吞吐量来访问应用程序的数据,适合那些有着超大数据集的应用程序。
HDFS放宽了POSIX的要求这样可以实现流的形式访问文件系统中的数据。
数据块
每个磁盘都有默认的数据块大小,这是磁盘进行数据读/写的最小单位,一般为512字节。
HDFS同样也有块的概念,默认为64MB。
但与其他文件系统不同的是,HDFS中小于一个块大小的文件不会占据整个块的空间。
namenode和datanode
HDFS集群有两类节点,并以管理者-工作者模式运行,即一个namenode(管理者)和多个datanode(工作者)。
namenode管理文件系统的命名空间。
它维护着文件系统树及整棵树内所有文件和目录。
datanode是文件系统的工作节点。
它们根据需要存储并检索数据块(受客户端或namenode调度),并且定期向namenode发送它们所存储的块的列表。
2.3.2HDFS的数据流
v文件写入(如下图所示):
1.客户端通过对DistributedFileSystem对象调用create()函数来创建文件。
2.DistributedFileSystem对NameNode创建一个RPC调用,再文件系统的命名空间中创建一个新文件,此时该文件中还没有相应的数据块。
3.在客户端写入数据时,DFSOutputStream将它分成一个个的数据包,并写入内部队列,称为“数据队列”。
4.DataStreamer将数据包流式传输到管线中的三个datanode中。
5.当收到管道中所有datanode确认信息后,该数据包才会从确认队列删除。
6.客户端完成数据的写入后,会对数据流调用close()方法。
客户端将数据写入HDFS
v文件读取(如下图所示):
1.客户端通过调用DistributedFileSystem对象的open()方法来打开希望读取的文件,对于HDFS来说,这个对象是分布式文件系统的一个实例。
2. DistributedFileSystem通过使用RPC来调用namenode,一确定文件起始块的位置。
3.客户端对这个输入流调用read()方法。
4.通过对数据流反复调用read()方法,可以将数据从datanode传输到客户端。
5.到达块的末端时,DFSInputStream会关闭与该datanode的连接,然后寻找下一个块的最佳datanode。
6.一旦客户端完成读取,就对FSDataInputStream调用close()方法。
客户端读取HDFS中的数据
v文件块复制:
1.NameNode发现部分文件的文件块不符合最小复制数或者部分DataNode失效。
2. 通知DataNode相互复制文件块。
3. DataNode开始直接相互复制。
Hadoop的默认布局策略是在运行客户端的节点上放第一个复本。
第二个复本放在与第一个不同且随机另外选择的机架中节点上(离架)。
第三个复本与第二个复本放在相同的机架,且随机选择另一个节点。
2.3.3HDFS的特点与不足
首先,HDFS设计目标之一是适合运行在通用硬件上的分布式文件系统。
硬件故障是常态,而不是异常。
整个HDFS系统将由数百或数千个存储着文件数据片断的服务器组成。
实际上它里面有非常巨大的组成部分,每一个组成部分都会频繁地出现故障,这就意味着HDFS里的一些组成部分是总是失效的,因此,故障的检测和自动快速恢复是HDFS一个很核心的结构目标。
从这个角度说,HDFS具有高度的容错性。
第二,HDFS的另一个设计目标是支持大文件存储。
运行在HDFS之上的程序有很大量的数据集。
这意味着典型的HDFS文件是GB到TB的大小,所以,HDFS是很好地支持大文件。
它应该提供很高的聚合数据带宽,应该一个集群中支持数百个节点,还应该支持一个集群中千万的文件。
第三,HDFS还要解决的一个问题是高数据吞吐量。
HDFS采用的是“一次性写,多次读”这种简单的数据一致性模型。
换句话说,文件一旦建立后写入,就不需要再更改了。
网络爬虫程序就很适合使用这样的模型。
第四,移动计算环境比移动数据划算。
HDFS提供了API,以便把计算环境移动到数据存储的地方,而不是把数据传输到计算环境运行的地方。
这对于数据大文件尤其适用,可以有效减少网络的拥塞、提高系统的吞吐量。
第五,HDFS不适用于低延迟数据访问、大量的小文件以及多用户写入、任意修改的情况。
第三章Hadoop的应用领域
其实Google最早提出MapReduce也就是为了海量数据分析。
HDFS最早是为了搜索引擎实现而开发的,后来才被用于分布式计算框架中。
海量数据被分割于多个节点,然后由每一个节点并行计算,将得出的结果归并到输出。
同时第一阶段的输出又可以作为下一阶段计算的输入,因此可以想象到一个树状结构的分布式计算图,在不同阶段都有不同产出,同时并行和串行结合的计算也可以很好地在分布式集群的资源下得以高效的处理。
Hadoop主要应用于以下领域:
☉数据挖掘与商业智能,包括日志处理,点击流分析,相似性分析,精准广告投放。
☉数据仓库,特别是使用Pig和Hive。
☉生物信息技术(基因分析)。
☉金融模拟(例如,蒙特卡洛模拟)。
☉文件处理(例如,jpeg大小改修)。
☉web索引。
☉日志分析
☉排序
第四章Hadoop的优点与不足
4.1Hadoop的优点
(1)经济
Hadoop是开源的Apache项目,所有人都可以免费使用。
Hadoop运行于普通硬件之上,因此无需购买专业的数据库服务器。
(2)高效
Hadoop可以在几分钟内处理TB级的数据,在几小时内可以处理完PB级的数据。
而且Hadoop还是那些互联网巨头如Facebook、Twitter、Yahoo、eBay、Amazon等快速处理大数据并制订决策的唯一方式。
(3)可扩展。
不论是存储的可扩展还是计算的可扩展都是Hadoop的设计根本,只需增加带硬盘驱动器的节点。
(4)可靠
布式文件系统的备份恢复机制以及MapReduce的任务监控保证了分布式处理的可靠性。
(5)数据类型灵活
由于Hadoop用于处理半结构化或非结构化的数据,所以Hadoop可以存储和处理任意类型的数据。
(6)编程语言多样。
Hadoop本身是用Java开发的,但是你可以使用类SQL语言如ApacheHive访问你的数据。
如果你想要过程式的语言进行分析,可以用ApachePig。
如果你想深入框架,你可以用Java、C/C++、Ruby、Python、C#、QBasic等任意语言自定义分析你的数据。
4.2Hadoop的不足
Hadoop作为一个基础数据处理平台,虽然其应用价值已得到大家认可,但仍存在很多问题,以下是主要几个:
(1)Namenode/jobtracker单点故障。
Hadoop采用的是master/slaves架构,该架构管理起来比较简单,但存在致命的单点故障和空间容量不足等缺点,这已经严重影响了Hadoop的可扩展性。
(2)HDFS小文件问题。
由于namenode将文件系统的元数据存储在内存中,因此该文件系统所能存储的文件总数受限于namenode的内存容量。
根据经验,每个文件、目录和数据块的存储信息大约占150byte。
举例来说,如果有10000000个小文件,每个文件占用一个block,则namenode需要2G空间。
如果存储1亿个文件,则namenode需要20G空间。
这样namenode内存容量严重制约了集群的扩展。
(3)jobtracker同时进行监控和调度,负载过大。
为了解决该问题,yahoo已经开始着手设计下一代HadoopMapReduce。
他们的主要思路是将监控和调度分离,独立出一个专门的组件进行监控,而jobtracker只负责总体调度,至于局部调度,交给作业所在的client。
(4)数据处理性能。
很多实验表明,其处理性能有很大的提升空间。
Hadoop类似于数据库,可能需要专门的优化工程师根据实际的应用需要对Hadoop进行调优,有人称之为“HadoopPerformanceOptimization”(HPO)。
第五章Hadoop的发展趋势
Hadoop的长期目标是提供世界级的分布式计算工具,也是对下一代业务(如搜索结果分析等)提供支持的Web扩展(web-scale)服务。
近十年来,由于很多大型公司和一些理论研究机构都在
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Hadoop