分布式环境下的新问题（主讲人：徐冬）在线视频

大家好

我叫徐冬

我来自阿里云

今天我们讨论的主题是

MAPREDUCE 编程框架

工程视角

这是本轮课程的最后一节课

在之前课程中

我们了解到了

分布式系统设计的各个方面

包括不同子系统

不同编程接口的原理和概念

今天我们尝试

从工程视角观察

实现这样一个

分布式系统的挑战是什么

实现过程中有什么要点

我们主要以

MAPREDUCE 编程模型

为范例

讲解 MAPREDUCE

是如何以它自己的方式

实现这些工程问题的

同时这次课程也是

一次动手的课程

我们要求同学

在学完本次课程后

完成一个课程设计

也就是实现一个

单机可运行的

MAPREDUCE 编程框架

区别于原理和概念

作为工程视角

我们本次课程只关注

系统实现

首先我们提出

作为分布式大数据

处理环境下

区别于传统单机编程方式的

新的问题

然后我会和大家

一起分析几个

经典的工程实现

学习一下工业界

是怎么解决这些问题的

最后我会解释

课程设计的要求

分布式环境下

很多传统软件领域的问题

被放大了

同时引入了一些新的问题

我们首先探讨

分布式环境下

有哪些新问题

不需要过多解释

我们在数据时代环境下

对软件的需求

与之前是截然不同的

一个需求来源是

膨胀的数据量

我们今天提到

大数据处理

通常指的量级是

计算以TB为单位

存储以PB为单位

因为一个本质的差距

也就是硬件技术发展

无法满足当前

数据量的处理与需求

膨胀的数据量带来了

很多问题

首先我们已经无法把

数据的计算和存储

放在一台机器上完成

需要扩展到

更多的计算节点

一种方式是

使用通用的计算机

作为计算节点

而且使用通用的网络

连接计算节点

我们今天只讨论这种方式

扩展到更多计算结点

要求我们实现的软件

必须高可用

高容错

因为更多的节点

放大了单机

硬件失败的概率

另一个重要的需求来源是

非结构化数据处理

这和传统以数据库为中心的

信息系统概念是不同的

今天我们面对的大数据

有很大一部分是

非结构化的

它们是一些用户点击日志

地理位置信息

或是多媒体文件

需要一个平台化的系统

去统一的处理这些

非结构化数据

这时候

提供给用户的接口

是怎样一种形式

成为了关键的问题

这也是早期

MAPREDUCE 编程模型

获得巨大成功的原因

因为它提供了一种

简单的抽象用户逻辑的能力

我们可以简单回顾一下

工业界在

分布式计算上的发展

分布式计算的研究

已经有很长时间了

但是引爆工业界

大规模的应用

是起源于2004年

GOOLGLE在VLDB上

发表的有关

MAPREDUCE 编程模型

的论文

MAPREDUCE也是

我们今天课程

主要关注的一个

编程模型

MAPREDUCE通过一个被称为

简单一致性模型的抽象

很好的解决了

之前我们提到的

两个新需求

它启发了很多开源的实现

其中Hadoop是最成功的实现

YAHOO公司把Hadoop

捐献给了Apache基金会

很快它成为

Apache的顶级项目

这一切都发生在了2005年

也就是GOOGLE发表

MAPREDUCE论文的后一年

阿里云 飞天 和ODPS系统

也是在此之后开发的

受到了MAPREDUCE的启发

MAPREDUCE获得巨大成功

得到大规模应用

这时候很多人开始

重新审视MAPREDUCE

一个严厉的评价

来自于数据库研究者

Stonebraker

他当时写了著名的

MAPREDUCE一个巨大的倒退

这篇文章

感兴趣的同学

可以找来读一下

他提到了MAPREDUCE

暴力扫描所有数据的方式

浪费了之前数据库领域

大量的研究成果

事实上

在分布式领域

已经有人在做

相关优化的尝试了

其中之一就是对

GOOGLE BigTable

的参考实现

叫做Hbase

他使用索引和缓存技术

在分布式文件系统上

提供随机读写数据的能力

我们后续会探讨随机读写

和顺序读写在工程实现上

有什么差异

这种非关系型存储的

解决方案

后来被定义为NoSQL

包括了很多其他的实现

另一些评价

来自于客户

他们认为

MAPREDUCE 编程模型

太底层

限制了生产力

因此

很多用户接口的抽象

应运而生

包括Facebook的Hive

和YAHOO的Pig

现在的分布式计算领域

比以往任何时期都要活跃

一个显著的特点是

业界开发了大量

应用场景不同的编程模型

我们之前学习到了

MAPREDUCE是一个

批处理模式的典型例子

批处理的编程模型

还有基于有向无环图调度

的编程模型

基于SQL语言

的编程模型 等等

除此之外

为了满足

用户日益复杂的需求

还有实时流式数据处理

帮助用户更快更早的

获取数据分析的结果

或类似BSP内存计算的

编程模型

提供了迭代计算的能力

等等

另一个特点是

不同的系统

是层叠搭建在一起的

没有一个系统

会贯穿满足所有的应用

这种方式构造了

一个良好的生态圈

经典的设计

至少分成四层

一个分布式文件系统

一个调度系统

一个编程模型

和实现在

对应编程模型上的应用

对于阿里云的系统来说

对应的是盘古 伏羲 ODPS

这些系统

实现一个用户需求

不需要从底向上

开发所有的组建

底层组建也不绑定

上层组建的实现

最后越来越多的

分布式大数据处理系统

在和云计算做整合

前面介绍了

分布式环境下的需求

工业界的发展的历史

和现状

现在我们有必要

抽象出

实现这样一个

分布式处理系统

面临的挑战会有哪些

一个显然的挑战

在性能上

分布式系统占的每一层

都要关注性能

层叠的架构中

哪一层性能的下降

会被上面的系统放大

例如分布式文件系统

如果在打开文件操作上

比较慢

会导致

作为计算层的

MAPREDUCE 编程模型

在启动任务这个操作上

会变得很慢

同样 MAPREDUCE

要非常关注数据传输

数据读写的性能

这部分

稍候我们会专注的看一下

性能指标包括处理速度

例如每单位的数据量

处理消耗的时间

也包括整响应时间

例如任务提交

任务清理的消耗

除了时间维度

我们还需要考虑

其他硬件的消耗

包括CPU消耗

IO消耗等

第二个挑战

是用户友好度

包括例如这个平台的应用型

对不同需求的通用程度

这通常是由编程模型的设计

来体现的

第三个挑战是高可用

就像我们之前聊到的

在分布式系统中

硬件故障的概率被放大了

我们经常说

分布式系统中

硬件故障是常态

而不是异常

高可用至少包含两个概念

一个是可用性

也就是说当集群中

某些节点发生了故障

最好不要影响

整个集群的服务

另一个是容错性

是说部分节点的故障

不会让数据的计算和存储

出现以外的结果

最后一点是扩展性

简单来说就是

更多节点可以做更多事情

一个指标是线性扩展

是说一个集群的

计算和存储能力

是否随着计算节点的

数量增加而线性增加

一般来说

完美自线性扩展

是不存在的

按照现在的硬件条件

节点数超过五千

通常就会引入

很多复杂的问题

影响计算和存储能力的

进一步提升

另一个指标是弹性扩展

是说这样一个系统

是否支持

在已经运行的情况下

增加或减少节点

这种特性

特别在互联网行业

是非常重要的

因为数据增长

通常无法预先规划

在我们进一步探讨

具体的工程实现之前

有一点需要强调的是

没有一个系统

可以同时满足

所有用户的需求

我们通常需要

实现不同的系统

来满足不同的需求

这是因为

某些需求本身

是相互冲突的

典型的需求冲突范例是

OPTP和OLAP

两者之间的冲突

这两个术语是关系型

数据库中的术语

OLTP是

Online Transaction

Processing的缩写

指的是

数据的事务性处理

通常是随即读写的

少量改变的

快速返回的操作

对应的OLAP是

Online Analytical

Processing的缩写

指的是

对数据分析型的处理

通常是批处理的

大量改变的

长时间的操作

它通常是数据仓库的操作

可以理解为

MAPREDUCE是一种OLAP

而BigTable或HBase

是一种OLTP

一个不太合适的做法是

尝试将这两种操作

用同一种模式去处理

因为当前硬件的限制

没法在一种模式下

处理随机读写和顺序读写

使两种操作都很快

后续我们会

专门讨论这个问题

另一个在设计层面上的冲突

抽象为著名的CAP理论

Eric Brewer

提到了一个

分布式系统设计中

一致性

可用性和可分区性

这三个特性中

至多只能满足其中两者

这不是一个理论证明

而更像是一个经验总结

事实上在工程中

它经常被证明

是有意义的

一致性指的是

所有节点看到的

同一份数据的内容

是相同的

可用性指的是

每个用户的请求

都能被可靠的处理

分区性

类似我们提到的扩展性

指的是一个大的问题

可以被分解到

多个物理节点上

去处理的能力

我们后续也会回顾

CAP理论

对于工程实践的指导意义