1.2数据的存储于分析

我们遇到的问题很简单:在硬盘存储容量多年不断提升的同时,访问速度(硬盘数据读取速度)却没有与时俱进。1990年,一个普通硬盘可以存储1370MB的数据,传输速度为4.4MB/S,因此只需要5分钟就可以读完整个硬盘中的数据。20年过了,1TB的硬盘已然成为主流,氮气数据传输速度为100MB/S,读完整个硬盘中的数据至少得花2.5个小时。

读完整个硬盘中的数据需要更长时间。写入数据就更别提了。一个很简单的,减少读取时间的办法是同时从多个硬盘上读数据。试想,如果我们有100个硬盘。每个硬盘存储1%的数据,并行读取,那么不到两分钟就可以读完所有数据。

仅使用硬盘容量的1%似乎很浪费,但是我们可以存储100个数据集,每个数据集1TB。并实现共享硬盘的读取。可以想象,用户肯定很乐于通过硬盘共享来缩短数据分析时间;并且,从统计角度来看,用户的分析工作都是在不同时间点进行的,所以彼此之间的干扰并不大。

虽然如此,但要对多个硬盘中的数据并行进行读写数据,还有更多问题要解决。第一个需要解决的是硬件故障问题,一旦开始使用多个硬件,其中个别硬件就很有可能发生故障。为了避免数据丢失,最常用的做法是复制:系统保存数据的复本。一旦有系统发生故障,就可以使用另外保存的复本。例如,冗余硬盘阵列(RAID)就是按这个原理实现的,另外,Hadoop文件系统(HDFS,Hadoop Distributed[分布式的] File System)也是一类,不过它采用的方法稍有不同,这个在后面会详细说明。

第二个问题是大多数分析任务需要以某种方式结合大部分数据来共同完成分析,即从一个硬盘读取的数据可能需要与从另外99个硬盘中读取的数据结合使用,各种分布式系统允许结合不同来源的数据进行分析,但保证其正确性是一个非常大的挑战。MapReduce提出一个编程模型,该模型抽象出这些硬盘读写问题并将其转化为对一个数据集(由键值对组成)的计算。后面会详细讨论这个模型,这样的计算由map和reduce两部分组成,而且只有这两部分提供对外的接口。与HDFS类似,MapReduce自身也有很高的可靠性。

简而言之,Hadoop为我们提供了一个可靠的共享存储和分析系统,HDFS实现数据的存储,MapReduce实现数据的分析和处理。虽然Hadoop还有其他功能,但HDFS和MapReduce是它的核心价值。

1.3相较于其他系统的优势

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

1.3.1关系型数据库管理系统(简称RDBMS r=relationnal关系 db=database数据库 m=management管理 s=system系统)

为什么不能用数据库来对大量硬盘上的大规模数据进行批量分析呢?我们为什么需要MapReduce?

这两个问题的答案来自于计算机硬盘的另一个发展趋势,寻址时间的提升远远不低敌于传输速率的提升。寻址是将磁头移动到特定硬盘位置进行读写操作的过程。它是导致磁盘操作延迟的主要原因,而传输速率取决于硬盘的贷款。

如果数据访问模式中包含大量的硬盘寻址,那么读取大量数据集j就必然会花更长的时间(相较于流数据读取模式,流读取主要取决于传输速率)。另一方面,如果数据库系统只更新一小部分记录,那么传统的B树就更有优势(关系型数据库中使用的一种数据结构,受限于寻址的比例)。但数据库系统如果有大量数据更新时,B树的效率就明显落后于MapReduce,因为需要使用“排序/合并”(sort/merge:合并)来重建数据库。

在许多情况下,可以将MapReduce视为关系型数据库管理系统的补充。两个系统之间的差异如表:
Hadoop权威指南第三版笔记第一章-LMLPHP

MapReduce比较适合批处理方式处理需要分析整个数据集的问题,尤其是动态分析。RDBMS适用于点查询和更新,数据集被索引之后,数据库系统能够提供延迟的数据检索和快速的少量数据更新。MapReduce适合一次写入、多次读取数据的应用,关系型数据库则更适合持续更新的数据集。

MapReduce和关系型数据库之间的另一个区别在于它们所操作的数据集的机构化程度。结构化程度是具有既定格式的实体化数据,如XML文档或满足特定格式的数据库表。这是RDBMS包括的内容。另一方面,半结构化数据比较松散,虽然可能有格式,但经常被忽略,所以它只能作为对数据结构的一般性指导。例如电子表格,它在结构上是由单元格组成的网格,但是每个单元格内可以保证任何形式的数据。非结构化数据没有什么特别的内部结构,例如纯文本或图像数据。MapReduce对非结构化或半结构化数据非常有效,因为它是在处理数据时才对数据进行解释。换句话说,MapReduce输入的键和值并不是数据固有的属性,而是分析数据的人来选的。

关系型数据往往是规范的,以保证其数据的完整性且不含冗余。规范给MapReduce带来了问题,因为它使记录读取成为非本地操作,而MapReduce的核心假设之一偏偏就是可以进行(高速的)流读写操作。

Web服务器日志是典型非规范化数据记录(例如,每次都需要记录客户端主机全名,只会导致同一客户端的全名多次出现),这也是MapReduce非常适用于分析各种日志文件的原因之一。

MapReduce是一种线性的可伸缩编程模型。程序员要写两个函数,分别为map函数和reduce函数,每个函数定义从一个键值对集合到另一个键值对集合的映射,这些函数不必关注数据集及其所用集群的大小,可以原封不动地应用于小规模数据集或大规模的数据集。更重要的是,如果输入的数据量是原来的两倍,那么运行的时间也需要两倍,但如果集群是原来的两倍,作业的运行速度却仍然与原来一样快。SQL查询一般不具备该特性。

但是,在不久的将来,关系型数据库和MapReduce系统之间的差异很可能变得模糊。关系型数据库都开始吸收MapReduce的一些思路m另一方面,基于MapReduce的高级查询语言使传统数据库的程序员更容易接受MapReduce系统。

1.3.2网络计算

高性能计算(HPC,High Performance Computing)和网络计算组织多年以来一直在研究

大规模数据处理,主要使用类似于消息传递接口(MPI,Message Passing Interface )的

API。从广义上讲,高性能计算采用的方法是将作业分散到集群的各台机器上,这些

机器访问存储区域网络所组成的共享文件系统。这比较适用于计算密集型的作业,但

如果节点需要访问的数据量更庞大(高达几百GB,MapReduce开始施展它的魔法),

很多计算节点就会因为网络带宽的瓶颈问题不得不闲下来等数据。

MapReduce尽量在计算节点上存储数据,以实现数据的本地快速访问。数据本地化

特性是MapReduce的核心特征,并因此获得良好的性能。意识到网络带宽是数据中

心环境最珍贵的资源(到处复制数据很容易消耗网络带宽)之后,MapReduce通过

显示网络拓扑结构来保留网络带宽。注意:这种排列方式并没有降低MapReduce对

计算密集型数据进行分析的能力。

虽然MPI赋予程序员很大的控制权,但需要程序员显示控制数据流机制,包括用C语

言结构化功能模块和高层的数据分析算法。而MapReduce则在更高层次上执行任务,

即程序员仅从键值对函数的角度考虑任务的执行,而且数据流是隐含的。

在大规模分布式计算环境下,协调各个进程执行时一个很大的挑战。最困难的是合理

处理系统的部分失效问题-----在不知道一个远程进程是否挂了的情况下-----同时还需要

继续完成整个计算。有了MapReduce,程序员不必操心系统部分失效的问题,因为

它有自己的系统实现能够检测到并重新执行那些失败的map和reduce任务。正因为采

用的是无共享框架,MapReduce才能够实现失败检测,这意味着各个任务之间是

彼此独立的。因此,从程序员的角度来看,任务的执行顺序无关紧要。相比之下,

MPI程序必须显示管理自己的检查点和恢复机制。

MapReduce听起来似乎是一个相当严格的编程模型,而且在某种意义上看的确

如此:限定用户使用具有特定关联的键值对,mapper和reducer彼此间协调非常

有限(每个mapper将键值对传给reducer)。因此,我们自然联想到一个问题:能

用这个编程模型做一些有用或实际的事情吗?

答案是肯定的。MapReduce由谷歌的工程师开发,用于构建搜索引擎的索引,

而且,事实已经证明它能够一次又一次地解决这个问题。有很多算法都可以用

MapReduce来表达,从图像分析到各种各样基于图像分析的问题,再到机器

学习算法。当然,它也不是包治百病的灵丹妙药,不能解决所有问题,但它

真的是一个很通用的数据处理工具。

1.3.3

MapReduce有三大设计目标:[1]为只需要短短几分钟或几个小时就可以完成的作

业提供服务[2]运行于同一个内部有高速网络连接的数据中心[3]数据中心内的计算机

都是可靠的、定制的硬件。

1.5Apache Hadoop和Hadoop生态系统

尽管Hadoop因MapReduce及其分布式文件系统HDFS而出名,但Hadoop这个名字

也用于泛指一组相关的项目,这些相关项目使用这个基础平台进行分布式计算和

海量数据处理。

随着Hadoop生态系统的成长,新出现的项目越来越多,其中不泛一些Apache主

管的项目,这些项目对Hadoop是很好的补充或提供一些更高的抽象。

本书所提到的Hadoop项目:
1Common:一系列组件和接口,用于分布式文件系统和通用I/O(序列化、JAVAPRC

和持久化数据存储)

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

作业)

 

 

 

 

 

10-06 17:34