工程实现范例（主讲人：徐冬）在线视频

接下来

我们检查几个

经典的工程实现

影响性能的一个关键点是

locality

分布式领域的工程实践

有一个原则叫做

移动计算比移动数据更划算

简单的来说

批处理的情形下

一次子任务处理的数据量

通常是百兆级别的

而处理逻辑

比如一个二进制文件

或者一个JAVA编译的jar包

通常只有数兆

或更小

把代码移动到

数据所在的节点去运行

显然比传输所有的数据

代价更小

locality的意思是

这种不移动数据的情形

所占的比例

通常这个比例越大越好

实现带locality的调度

需要依赖两个接口

一个是存储系统

需要有能力告诉我

某个分片

存储在哪个物理节点上

另一个是

调度系统需要按照

物理节点分配子任务

我们看一下

Hadoop MapReduce

是怎么做到locality的

Hadoop维护一个

网络拓扑结构

在它的中心节点

是一个拓扑结构

通常是三层的

按照常见的网络部署

第一层节点

指代用户中心

第二层节点

指代用户中心中的机架

第三层指代一个物理机器

哪片数据存储一个物理机器

用树中的一个叶子节点指带

当MapReduce调度任务时

会考虑当前调度的子任务

所属的数据分片

对应的物理机器是否空闲

如果空闲

把任务分配给那台机器

如果繁忙

考虑降级分配到

相同机架的另一台空闲机器

以此类推

这保证了任务总被分配给

离数据最近的那台机器

为了使得这种算法

获得的locality比较高

存储系统需要尽可能

平均的分配负载

在整个集群中

事实上

Hadoop默认使用了

随机分配的方式

放置数据

这种方式

可以获得最大的扩展性

同时损失了

随机读取的效率

因为

每次我读取一份数据

都要先询问中心节点

获取这份数据存放的位置

另一种放置数据的策略

是固定的

而不是随机的

它或是像HBase

的实现那样

动态维护一个

可被缓存的列表

从而获取高效的

随机读写能力

或是像Teradata的MPT

数据仓库那样

对数据内容

用函数计算出一个地址

保证每片数据

每次动会落入确定的分区

这使得在特殊的算法

比如join时

数据已经落在

相同的物理节点

节省了巨大网络IO的开销

那么看来HBase

或是MPT数据仓库的

数据存放策略更优秀

是这样吗

事实上

这两种思路是各有优劣的

我想把个问题

留给同学们去思考

让我们来看看容灾的问题

首先考虑存储层

Hadoop为了保证

硬件故障不丢失

在写入数据时

链式的写入多份相同的数据

在不同的物理节点

这种思路

和硬件领域的Read

没什么不同

有意思的是

它决定写入物理节点的算法

考虑之前我们提到的

三层树结构

Hadoop会尝试离自己

最近的节点

先写入一份数据

再找相同机架的另一个节点

写入一份数据

再找不同机架的另一个节点

写入一份数据

以此类推

在备份出一定量的前提下

通常是三份

可以保证集群中的

任何一个节点失效

或任何一个机架失效

机架失效的情况

通常是交换机故障

或是供电故障

我们不会丢失数据

而且可以保证正常的服务

HBase遇到物理失效的处理

会更棘手一些

HBase是一个Hadoop存储层

也就是被称为

HDFS的文件系统上

搭建的一个带缓存和索引的

Key Value系统

它的数据可靠性

都交给底层的HDFS

当节点失效的瞬时

是不能保证服务的

失效节点的负载

会分担到其他所有节点上

直到这个分担操作结束

用户才能正常读写

失效节点所属的

那一部分的分片

Greenplum这种

MPT数据仓库

则对每个物理节点

都安排一个备份节点

写入是遵循两阶段

提交的一个双写协议

读取则随机分配在

配对的任意一台机器

让我们回顾CAP理论

在这个章节里

三种解决方案

代表了不同的取舍

有的系统牺牲了可用性

换取了分区性

有的系统则相反

我想请同学们考虑

为什么这些系统

做了这样的取舍

这种取舍

对于它们的应用场景

有什么影响

另一个影响性能的实现

是数据读写

因为分布式环境下

我们面临更复杂的

硬件和网络条件

因此在数据读写时

要非常细致的选择

我们使用的硬件特性

和使用的方式

举一个简单的例子

实现一个随机读写的系统

通常需要重度依赖内存

而实现一个批处理系统

对内存的依赖

相对就弱一些

这里列出的是

硬件特性相关的

经典的消耗列表

可以看到

不同的硬件

不同的使用方式的性能

差异是巨大的

例如

内存和磁盘的读取效率

相差五到六个数量集

磁盘读取时

顺序读取和随机读取

又相差了一个数量集

首先我们看

MapReduce的shuffle

是如何优化数据读写的

之前我们提到了

MapReduce如何

用一个树型结构

来记录物理拓扑结构

从而提高locality

这可以保证大部分数据

都是从本地磁盘读取

减少了网络传输消耗

然而有一个操作

几乎是无法避免网络传输的

那就是shuffle

那我们再回顾一下

之前课程里提到的

MapReduce算法原理

框架提供Map Reduce

两个函数式风格的抽象

作为用户接口

在Map端

写出Key Value对

会聚合到Reduce端

保证相同的Key

数据落在相同的节点上

并且按照Key有序排列

这个对数据做

重分发和排序的过程

叫Shuffle
Shuffle的实现是一个

优化利用磁盘性能的典范

为了保证Reduce端

的数据按Key有序

我们要对Reduce端

做数据排序

因为数据量可能会超过

内存空间

所以这里一定是外部排序

一个直观的想法是

直接把Map的输出

顺序写入磁盘

Reduce端按照它需要的分区

随机读取这些数据

或者Map的输出

随机写到预先分配的

分区文件中

这样Reduce端就可以

顺序读取它感兴趣的

分区数据了

这两种直观的方案

无论如何都

无法避免随机读写

这会导致磁盘IO拖慢

整个任务的执行

Hadoop MapReduce

的做法是在Map端

先做一次排序

并输出局部有序的数据

Reduce在输出数据之前

做一次归并排序

这种方案极大减少了

随机读写的情况

具有做法是

Map的每一次输出

会进入一个缓冲区

这个缓冲区是一个环形数组

存放输出的Key Value对

另外一有一个索引

指向每一个Key Value对

在缓冲区中的偏移量

一旦缓冲区满了

使用快速排序

对Key做排序

并修改索引元素的顺序

最后按索引顺序

把一批Key Value对

输出到磁盘

这个操作是顺序的

这一次输出称为一个Spill

因为Map输出的数据量

可能大于内存空间

所以可能产生多个Spill

当一个Map做完之后

启动一个归并排序

合并这些Spill

作为一个大文件

这样Reduce就可以

顺序读取感兴趣的分片了

同样在Reduce端

会读取多个Map的输出数据

这些数据就像之前提到的

都是局部的有序的

我们只要施加一个归并排序

就可以保证全局有序了

如果清楚了这个过程

我想留几个问题

让同学们思考

一个问题是

整个过程一共发生了

几次读 几此写

总共读取的数据量是多大

是否有可能调整参数

减少这些读写

另一个问题是

当运行时

Map或Reduce端各自发生

硬件失败的时候

如何保证容灾