整套大数据学习资料(视频+笔记)百度网盘无门槛下载:http://www.edu360.cn/news/content?id=3377

第一章 Hadoop的前世今生

hadoop admin 379℃ 0评论

在古时候,人们用牛来拉重物。当一头牛拉不动一根圆木时,人 们从来没有考虑过要培育更强壮的牛。同理,我们也不该想方设 法打造超级计算机,而应该千方百计综合利用更多计算机来解决 问题。

格蕾斯•霍轴(Grace Hopper)

 

 

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倍!并且,而且这个速度还在不断增长 中,因为现在拍照片真的是越来越容易了。

微软研究院的 MyLifeBits 项目显示,在不久的将来,个人信息档案将日益普及。MyLifeBits 的一个实验是获取和保存个人的对外联系情况(包括电话、邮件和文件),供日后存取。收集的数据中包括每分钟拍摄的照片等,数据量每月约为 1GB。当存储成本急剧下降以至于可以存储音频和视频时,MyLifeBits项目在未来的存储的数据量将是现在的很多倍。

保存个人成长过程中产生的所有数据似乎逐渐成为主流,但更重要的是, 计算机产生的数据可能远远超过我们个人所产生的。机器日志、RFID检测仪、传感器网络、车载GPS和零售交易数据等——所有这些都将产生巨量的数据。

Astrometry.net主要査看和分析Flickr网站上星空机器人小组所拍摄的星空照片。它对每一张照片进行分析并能辨别出它来自星空或其他天体(例如恒星和银河系等)的哪一部分。虽然这项研究尚处于试验阶段,但也表明如果可用的数据足够多(在本例中,为加有标签的图片数据),通过它们而产生的后续应用也许会超乎这些拍照片的人最初的想象(图片分析)。

有句话说得好:“大数据胜于好算法。”意思是说对于某些应用(譬如根据以往的偏好来推荐电影和音乐),不论算法有多牛,基于小数据的推荐效果往往都不如基于大量可用数据的一般算法的推荐效果。

现在,我们已经有了大量数据,这是个好消息。但不幸的是,我们必须想方设法好好地存储和分析这些数据。

 

 

 

2. 数据的存储与分析

我们遇到的问题很简单:在硬盘存储容量多年来不断提升的同时,访问速度(硬盘数据读取速度)却没有与时俱进。1990年,一个普通硬盘可以存储 1370 MB数据,传输速度为4.4 MB/s,因此只需要5分钟就可以读完整个硬盘中的数据。20年过去了,1TB的硬盘已然成为主流,但其数据传输速度约为100 MB/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是它的核心价值。

 

3. 相较于其他系统的优势

MapReduce看似采用了一种蛮力方法。每个査询需要处理整个数据集或至少一个数据集的绝大部分。但反过来想,这也正是它的能力。MapReduce是一个批量査询处理器,能够在合理的时间范围内处理针对整个数据集的动态查询。它改变了我们对数据的传统看法,解放了以前只是保存在磁带和硬盘上的数据。它让我们有机会对数据进行创新。以前需要很长时间处理才能获得结果的问题,到现在变得顷刻之间就迎刃而解,同时还可以引发新的问题和新的见解。

例如,Rackspace公司的邮件部门Mailtrust就用Hadoop来处理邮件日志。 他们写动态查询,想借此找出用户的地理分布。他们是这么描述的:“这些数据非常有用,我们每月运行一次MapReduce任务来帮助我们决定哪些 Rackspace数据中心需要添加新的邮件服务器。”

通过整合好几百GB的数据,用MapReduce来分析这些数据,Rackspace的 工程师从中发现了以前从来没有注意到的数据,甚至还运用这些信息来改善了现有的服务。

 

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 系统。®

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来表达,从图像图形分析到各种各样基于图像分析的问 题,再到机器学习算法。当然,它也不是包治百病的灵丹妙药,不能解决 所有问题,但它真的是一个很通用的数据处理工具。

 

4. Hadoop发展简史

Hadoop 是 Apache Lucene 创始人 Doug Cutting 创建的,Lucene 是一个应用 广泛的文本搜索系统库。Hadoop起源于开源的网络搜索引擎Apache Nutch,它本身也是Lucene项目的一部分。

Hadoop不是缩写,它是一个生造出来的词。Hadoop之父Doug Cutting 这样解释Hadoop的来历:“这个名字是我的小孩给他的毛绒象玩具取的。我的命名标准 是好拼读,含义宽泛,不会被用于其他地方。小孩子是这方面 的高手。Googol就是小孩子起的名字。”

Hadoop的子项目及后续模块所使用的名称也往往与其功能不相关,通常也以大象或其他动物为主题取名(例如Pig)。较小一些的组件,名称通常都有较好的描述性(因此也更流俗)。这个原则很好,意味着我们可以望文知义,例如jobtracker, —看就知道它是用来跟踪MapReduce作业的。

从头打造一个网络搜索引擎是一个雄心勃勃的计划,不只是因为写爬虫程序很复杂,更因为必须有一个专职团队来实现——项目中包含许许多多需要随时修改的活动部件。同时,构建这样的系统代价非常高——据Mike Cafarella 和Doug Cutting估计,一个支持10亿网页的索引系统,单是硬件上的投入 就高达50万美元,另外还有每月高达3万美元的运维费用。不过,他们 认为这个工作仍然值得投入,因为它开创的是一个优化搜索引擎算法的平台。

Nutch项目开始干2002年,一个可以运行的网页爬取工具和搜索引擎系统 很快面试。但后来,开发者认为这一架构的灵活性不够,不足以解决数十亿网页的搜索问题。一篇发表于2003年的论文为此提供了帮助,文中描述的是谷歌产品架构,该架构称为“谷歌分布式文件系统”,简称GFS。sGFS 或类似的架构,可以解决他们在网页爬取和索引过程中产生的超大文件的 存储需求。特别关键的是,GFS能够节省系统管理(如管理存储节点)所花的 大量时间。在2004年,他们开始着手做开源版本的实现,即Nutch分布式 文件系统(NDFS)。

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年1月,Hadoop已成为Apache的顶级项目,证明了它的成功、多样 化和生命力。到目前为止,除雅虎之外,还有很多公司在用Hadoop,例如 Last.fm、Facebook和《纽约时报》等。第16章和Hadoop维基页面(英文) 介绍了一 些案例(http://wiki.apache.org/hadoop/PoweredBy)。

《纽约时报》的案例广为流传,他们把1851年到1980年的存档扫描之后 得到4TB的文件并用亚马逊的EC2云服务将文件存为PDF格式放到网h 共享。®整个过程一共使用了 100台计算机,所花的时间不到24小时。如果没有亚马逊的按小时付费模式(即允许《纽约时报》短期内访问大量机器) 和Hadoop好用的并发编程模型珠联璧合,这个项目不太可能这么快就启动 和完成。

2008年4月,Hadcwp打破世界纪录,成为最快的TB级数据排序系统。在 一个910节点的群集,Hadoop在209秒内(不到3.5分钟)完成了对1TB数 据的排序,击败了前一年的297秒冠军(详情参见15.5节的补充材料 “Apache Hadoop的TB级数据处理”)。同年11月,谷歌在报告中声称, 它的MapReduce对1 TB数据排序只用了 68秒。®2009年5月本书第1版 出版的时候,有报道称雅虎有一个的团队使用Hadoop对1 TB数据进行排 序只花了 62秒。

从那以后,Hadoop跃升为企业主流的部署系统。在工业界,Hadoop已经是 公认的大数据通用存储和分析平台,这一事实主要体现在大量直接使用或 者间接辅助Hadoop系统的产品如雨后春笋般大量涌现。一些大公司也发布 Hadoop发行版本,包括EMC,IBM, Microsft和Oracle以及一些专注于 Hadoop 的公司,如 Cloudera, Hortonworks和 MapR。

 

5. Apache Hadoop 和 Hadoop 生态系统

尽管Hadoop因MapReduce及其分布式文件系统(HDFS,由NDFS改名而来) 而出名,但Hadoop这个名字也用于泛指一组相关的项目,这些相关项目都使用这个基础平台进行分布式计算和海量数据处理。

本系列文章提到的项目都受Apache软件基金会支持,该基金会对开源软件项目社区提供支持,包括最初的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 作业)

 

 

6. Hadoop的发行版本

应该用哪个版本的Hadoop呢?当然,这个问题的答案总是随着时间而变化,而且依赖于你所需要的特性。这里总结了现阶段Hadoop发行版本系列的概要特征。

有一系列活跃的发行版本。1.x发行版本系列是0.20发行版本系列的延续,并且包含有当前最稳定的Hadoop发行版本。这一系列中包含安全的 Kerberos认证,该安全认证避免了非授权用户访问Hadoop数据。几乎所有集群运行的都是这些发行版本或扩展版本(例如商业版本)。

0.22和2.x发行版本系列目前还不是非常稳定(2012年初),但是在你读到这本书的时候这些发行版本系列已经发生了变化,因为这些版本正被越来越多的真实应用测试(请参考Apache Hadoop发行版页面了解最新状态)。

 

2.x包含如下主要的新特性:

  • 在新的YARN系统(Yet Another Resource Negotiator)系统上构建了一个新的运行环境,称为MapReduce 2。YARN是一个通用的用于运行分布式应用的资源管理器。MapReduce 2替代了前期发行版本中的“经典”运行环境。

  • HDFS联邦管理,该管理将HDFS的命名空间分散到多个namenode中以支持包含有大规模数据文件的集群。

  • HDFS的高可用性,针对系统崩溃而启用备用的namenode来避免 namenode的单点故障问题。

 

表1-2只包含HDFS和MapReduce的一些特性。Hadoop生态系统中其他一些项目也在不断演化中,同时在这些项目中选出一部分组件联合使用具有一定的挑战。幸运的是,现在我们不需要亲自做这些配置了。Apache 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高可用

 

 

 

转载请注明:全栈大数据 » 第一章 Hadoop的前世今生

喜欢 (3)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
(4)个小伙伴在吐槽
  1. 🙂
    明, 小小明2017-08-08 11:47 回复
    • 加油,
      harvey2017-08-13 09:40 回复
  2. 有价值
    王彦振2017-08-15 22:31 回复
    • 确实是
      harvey2017-08-18 23:17 回复