5.5内存计算需求在线视频

下面我们来介绍内存计算的需求

我们前面学到的MapReduce

应该说开创了大数据

处理的一个时代

那么在2004年谷歌发表了它的

MapReduce论文以后

整个业界都为之轰动

雅虎公司为首的公司牵头开展了

开源社区Hadoop的开发

那么Hadoop实际上

就是MapReduce的一个开源的实现

那么MapReduce

它的成功之处在哪儿

那么首先用户只需要

编写串行程序

系统能够自动的进行

并行化和分布式的执行

另外我们刚才也讲到

MapReduce它可以做到自动容错

而且它还可以做到

自动的负载平衡

也就是说如果说某一个任务

执行的时间很长

那么系统可以自动的

把这个长时间执行的任务

把它分配到一些新的

节点上面去执行

这样的话使得

比如说这个任务执行很长

它的原因是由于这个

节点能力比较差

那么我们就可以把这个任务

放到一个新节点上

去执行就使得这个

一个比较快的节点

去执行这个任务

使得它也可以尽快的结束

另外如果说某些节点

原来给它分配的任务

它很快就执行完了

那么它可以再要到

一些新的任务来执行

所以MapReduce就可以让用户

不用去考虑容错

负载平衡和并行化执行

同步等等这样的一些

非常繁琐而且很容易出错的问题

而只需要集中精力

编写串行程序就好了

但是MapReduce

虽然取得了巨大的成功

它仍然不能够满足

用户对大数据处理的

所有要求

那么用户在用了

MapReduce以后

实际上会发现

它还有一些新的需求

MapReduce不能满足

比如说用户会需要一些

更复杂的多阶段任务

也就是并不是一个简单的

像我们说的page rank

word count这样的一些

简单的任务

而是一些相对来说

比较复杂的多阶段任务

比如说Key means

比如说最短路径等等

像这类问题使用Map Reduce

单个MapReduce任务

其实是很难解决的

它要么采用迭代的方法

要么采用多个MapReduce

任务集成来完成

那么用户也不希望说

我们提交一个MapReduce

任务以后需要等上几分钟

甚至几十分钟

甚至更长时间才能够拿到结果

我们现在很多大数据分析

非常期望能够做到

交互式的查询

也就是说我提交了

对大数据的一个查询

和分析任务之后

我希望能够在几秒钟

到几十秒钟的时间内

能够返回结果

那么这样MapReduce

就很难满足这样的要求了

Map Reduce的局限性

为什么它不能够满足

这个要求我们在这儿

列了它的三个局限性

第一个是

它的表达能力有限

它只有Map和Reduc两种操作

但是我们知道

实际上我们需要很多

其他类型的操作

比如说filter过滤

也就是说我们可能要从

一个数据集中找出

符合某种标准的

子数据集也许我们需要

把一个数据集和另一个数据集

合并起来等等

这些操作在MapReduce中

都没有直接的定义

通常需要通过比较复杂的

组合才能够完成

另外复杂的任务

通常需要迭代的MapReduce

这样就需要将中间的结果

保存在硬盘上

而这些就必然产生大量的

I/O操作我们前面讲过

一个随机的内存访问

比一个随机的硬盘访问

大概要快十万倍

但是即使我们能够做到

这个不是随机的硬盘访问

而是连续的硬盘访问

I/O操作还是会造成

性能的急剧下降

还是比访问内存要慢

两到三个数量级

那么引入的I/O操作过多

就必然产生一个结果

就是它的性能比较差

因此只能做离线分析

很难支持数据的交互式查询