MapReduce 简介

一、 MapReduce：计算框架和编程模型

今天我们来聊聊一个比较基础也比较重要的内容 MapReduce，说它基础，是因为它诞生的时间实在是太久远了，并不是什么新东西，说它重要则是因为基于它的提出衍生出很多重要的技术，比如我们关心的 Spark。

今天的内容主要有以下几点：

1. Google 的三驾马车；
2. MapReduce 编程模型与 MapReduce 计算框架；
3. 并发与并行；
4. 如何理解分布式计算框架的编程接口与背后的工程实现。

1. Google 的三驾马车

USNew 把计算机科学分为 4 个领域：人工智能、编程语言、系统以及理论。

其中的系统领域有两大顶级会议，一个是 ODSI（USENIX conference on Operating Systems Design and Implementation），另一个是 SOSP（ACM Symposium on Operating Systems Principles），这两个会议在业界的分量非常重，如果把近几十年关于这两个会议的重要论文收录到一本书，就可以看作是操作系统和分布式系统的一本教科书。

从 2003 年到 2006 年，Google 分别在 ODSI 与 SOSP 发表了 3 篇论文，引起了业界对于分布式系统的广泛讨论，这三篇论文分别是：

• SOSP2003：The Google File System；

• ODSI2004：MapReduce: Simplifed Data Processing on Large Clusters；

• ODSI2006：Bigtable: A Distributed Storage System for Structured Data。

在 2006 年，Google 首席执行官施密特提出了云计算这个词语，Google 的这 3 篇论文也被称为 Google 的三驾马车，代表 Google 大数据处理的基石、云计算的基础。不过值得注意的是，虽然 Google 作为业界领军者经常会将自己的技术开源出来，但是客观地讲，Google 开源出来的技术并不是内部使用的最新技术，中间甚至会有代差，这也侧面反映出 Google 的技术实力。

第 1 篇论文主要讨论分布式文件系统，第 2 篇论文主要讨论的分布式计算框架，第 3 篇论文则主要讨论分布式数据存储。这 3 篇论文揭开了分布式系统神秘的面纱，为大数据处理技术做出了重要的贡献。

有了这 3 篇论文的理论基础与后续的一系列文章，再加上开源社区强大的实践能力，Hadoop、HBase、Spark 等很快走上了台前，大数据技术开始呈现出一个百花齐放的状态。

2. MapReduce 编程模型与 MapReduce 计算框架

在发表的第 2 篇文章中，Google 很明确地表示 MapReduce 是其实现的一个分布式计算框架，其编程模型名为 MapReduce。开源社区基于这篇论文的内容，照猫画虎地实现了一个分布式计算框架，也叫作 MapReduce。但一些书籍和网上的资料在提到 MapReduce 的时候并未说明，容易造成困惑。其实 Google 拿编程模型的名字直接作为计算框架的名字这种例子还有很多，比如 Google Dataflow。而 MapReduce 有两个含义，一般来说，在说到计算框架时，我们指的是开源社区的 MapReduce 计算框架，但随着新一代计算框架如 Spark、Flink 的崛起，开源社区的 MapReduce 计算框架在生产环境中使用得越来越少，逐渐退出舞台。

MapReduce 的第二个含义是一种编程模型，这种编程模型来源于古老的函数式编程思想，在 Lisp 等比较老的语言中也有相应的实现，并随着计算机 CPU 单核性能以及核心数量的飞速提升在分布式计算中焕发出新的生机。

MapReduce 模型将数据处理方式抽象为 map 和 reduce，其中 map 也叫映射，顾名思义，它表现的是数据的一对一映射，通常完成数据转换的工作，如下图所示：

reduce 被称为归约，它表示另外一种映射方式，通常完成聚合的工作，如下图所示：

圆角框可以看成是一个集合，里面的方框可以看成某条要处理的数据，箭头表示映射的方式和要执行的自定义函数，运用 MapReduce 编程思想，我们可以实现以下内容：

1. 将数据集（输入数据）抽象成集合；

2. 将数据处理过程用 map 与 reduce 进行表示；

3. 在自定义函数中实现自己的逻辑。

   这样就可以实现从输入数据到结果数据的处理流程（映射）了。

3. 并发与并行

一般来说，底层的东西越简单，那么上层的东西变化就越复杂，对于 MapReduce 编程模型来说，map 与 reduce 的组合加上用户定义函数，对于业务的表现力是非常强的。这里举一个分组聚合的例子，如下图所示：

map 端的用户自定义函数与 map 算子对原始数据人名进行了转换，生成了组标签：性别，reduce 端的自定义函数与 reduce 算子对数据按照标签进行了聚合（汇总）。

MapReduce 认为，再复杂的数据处理流程也无非是这两种映射方式的组合，例如 map + map + reduce，或者 reduce 后面接 map，等等，在我展示出的这张图里你可以看到相对复杂的一种组合形式：

很多支持函数式编程的语言，对于语言本身自带的集合数据结构，都会提供 map、reduce 算子。现在，我们可以很容易的将第一个圆角方框想象成一个数十条数据的集合，它是内存中的集合变量，那么要实现上图中的变换，对于计算机来说，难度并不大，就算数据量再大些，我们也可以考虑将不同方框和计算流程交给同一台计算机的 CPU 不同的核心进行计算，这就是我们说的并行和并发。

4. 如何理解分布式计算框架的编程接口与背后的工程实现

现在你可以想象下，随着数据集继续增大，要处理的数据（上图中开始的集合）超过了计算内存的大小，那么就算是逻辑非常简单的流程，也要考虑中间结果的存储。比如计算过程涉及到硬盘和内存之前的数据交换等等之类的工程实现的问题，虽然在这个过程中上面 3 步并没有发生变化，但是背后实现的系统复杂度大大提高了。

我们可以再发挥想象，将上图中的圆角框想象成一个极其巨大的数据集，而方框想象成大数据集的一部分，我们会发现，对于从输入数据到结果数据的映射需求来说，前面 3 步仍然适用，只是这个集合变得非常大。

但是由于数据量的急剧扩大，相比于刚才的第 2 种情况，背后工程实现的复杂度会成倍增加，当整个数据集的容量和计算量达到 1 台计算机能处理的极限的时候，我们就会想办法把图中方框所代表的数据集分别交给不同的计算机来完成，那么如何调度计算机，如何实现 reduce 过程中不同计算机之间的数据传输等问题，就是 Spark 基于 MapReduce 编程模型的分布式实现，这也是我们常常所说的分布式计算。

从上图可以看出，在 reduce 过程中，会涉及到数据在不同计算机之间进行传输，这也是 MapReduce 模型下的分布式实现的一个关键点，后面我们会讲到 Spark 是如何做的。

看到这里，你可能对分布式运算有一个感性的认识，以小见大，函数式语言本身就提供了类似于 map、reduce 的操作，如下图第 1、2 行代码：

1、2 行是函数式编程语言 Scala 对于集合的处理，3、4 行是 Spark 对集合的处理，逻辑同样是对集合元素都加 1 再过滤掉小于等于 1 的元素并求和。对于 Spark 来说，处理几十 GB到几十 TB 的数据集，第2行代码或者说第4行代码同样适用，只是 list 变得比较特殊，它不是只存在于一台计算机的内存里，而是存在于多台计算机的磁盘和内存上。

现在，我们可以这样理解基于 MapReduce 编程模型的分布式计算框架，其编程接口与普通函数式语言的数据处理并没有什么不同（甚至可以说完全一样），但是背后的工程实现千差万别，而像 Spark、MapReduce 这样的框架，它们的目标都是尽力为用户提供尽可能简单的编程接口以及高效地工程实践。从这个角度上来讲，我们可以把 Spark 看成是一种分布式计算编程语言，它的终极目标是希望达到这样一种体验：让用户处理海量数据集时与处理内存中的集合变量并没有什么不同。

MapReduce 这种思想或者编程模型已经出现几十年了，不变的是思想，变得是使用场景和实现方法。我相信未来一定会有效率优于 Spark 的计算框架出现，就像 Spark 优于普通的编程语言一样。

5. 总结

本课时的主要目的是在深入讲解 Spark 之前，对 Spark 之前的技术、范式、抽象进行一个简单的讲解，为后面的学习打下基础。

二、Hadoop：集群的操作系统

在上个课时中我们提到，Google 在 2004~2006 年发表了被称为 Google 三驾马车的 3 篇论文，这在开源社区可谓是一石激起千层浪。很快，基于论文的开源实现就问世了，其中第 1 篇论文的 GFS 和第 2 篇论文的 MapReduce 开源实现为 HDFS 与 MapReduce，统称为 Hadoop，第 3 篇 Bigtable 论文开源实现为 HBase，本课时不展开讨论。

Hadoop 的出现，对于坐拥数据而苦于无法分析的用户来说，无疑是久旱逢甘霖，加之那段时间移动互联网的流行，数据呈几何倍数增长，Hadoop 在很大程度上解决了数据处理的痛点。在很长的一段时间里，Hadoop 是大数据处理的事实标准，直到现在，很多公司的大数据处理架构也是围绕 Hadoop 而建的。

基于此，本课时主要讨论以下几个问题：

• Hadoop 1.0

• Hadoop 2.0

• Hadoop 生态圈与发行版

• Hadoop 大数据平台

• Hadoop 的趋势

Hadoop 1.0

Hadoop 从问世至今一共经历了 3 个大版本，分别是 1.0、2.0 与最新的 3.0，其中最有代表性的是 1.0 与 2.0，3.0 相比于 2.0 变化不大。Hadoop 1.0 的架构也比较简单，基本就是按照论文中的框架实现，其架构如下图所示：

其中，下层是 GFS 的开源实现 HDFS（Hadoop 分布式文件系统），上层则是分布式计算框架 MapReduce，这样一来，分布式计算框架基于分布式文件系统，看似非常合理。但是，在使用的过程中，这个架构还是会出现不少问题，主要有 3 点：

1. 主节点可靠性差，没有热备；
2. 提交 MapReduce 作业过多的情况下，调度将成为整个分布式计算的瓶颈；
3. 资源利用率低，并且不能支持其他类型的分布式计算框架。

第 1 点是小问题，涉及到对系统可用性方面的改造，但是第 2 点与第 3 点提到的问题就比较犀利了。

第 2 个问题在于，Hadoop 1.0 的分布式计算框架 MapReduce 并没有将资源管理和作业调度这两个组件分开，造成当同时有多个作业提交的时候，资源调度器会不堪重负，导致资源利用率过低；

第 3 个问题则是不支持异构的计算框架，这是什么意思呢？其实当时 Spark 已经问世了，但是如果这个集群部署了 Hadoop 1.0，那么想要运行 Spark 作业就必须另外再部署一个集群，这样无疑是对资源的浪费，很不合理，不过这也没办法，因为这属于直接套用论文造成的历史遗留问题。

Hadoop 2.0

基于这些问题，社区开始着手 Hadoop 2.0 的开发，Hadoop 2.0 最大的改动就是引入了资源管理与调度系统 YARN，代替了原有的计算框架，而计算框架则变成了类似于 YARN 的用户，如下图：

YARN 将集群内的所有计算资源抽象成一个资源池，资源池的维度有两个：CPU 和内存。

同样是基于 HDFS，我们可以认为 YARN 管理计算资源，HDFS 管理存储资源。上层的计算框架地位也大大降低，变成了 YARN 的一个用户，另外，YARN 采取了双层调度的设计，大大减轻了调度器的负担，我会在后续课程详细讲解，这里不展开讨论

Hadoop 2.0 基本上改进了 Hadoop 的重大缺陷，此外 YARN 可以兼容多个计算框架，如 Spark、Storm、MapReduce 等，HDFS 也变成了很多系统底层存储，Hadoop 以一种兼收并蓄的态度网罗了一大批大数据开源技术组件，逐渐形成了一个庞大的生态圈，如下图所示（该图只展示了一部分组件）。在当时，如果你要想搭建一个大数据平台，绝对无法绕过 Hadoop。

Hadoop 生态圈与发行版

Hadoop 生态圈的各个组件包含了 Hadoop 的核心组件，如 HDFS、YARN。在计算层也有了更多的选择，如支持 SQL 的 Hive、Impala，以及 Pig、Spark、Storm 等。还有些工具类的组件，比如负责批量数据抽取的 Sqoop，负责流式数据传输的 Flume，负责分布式一致性的 Zookeeper。此外，还有一些运维类组件，例如负责部署的 Ambari、集群监控的 ganglia 等。这些组件看似繁杂，但都是一个生产环境的所必需的。所以在当时，将如此多的组件集成到一个平台，会有很多各式各样的问题。

很快有公司注意到了这个问题中的商机，其中做的最好的是 Cloudera 和 Hortonworks 这两家公司，它们核心产品就是将上述 Hadoop 生态圈中最常用到的开源组件打包为一个 Hadoop 发行版，Clouera 的叫 CDH，Hortonworks 的叫 HDP，这个发行版中的所有组件不会有兼容性等其他莫名其妙的问题，供用户免费使用，当然也为那些技术实力不强的公司准备了收费版。

在 Hadoop 最鼎盛的阶段，几乎所有公司的大数据平台都使用了这两家公司的 Hadoop 发行版，Cloudera 也得到了资本市场的认可，一度估值 50 亿美金，但随着 Hadoop 的没落，Cloudera 在上市后，股价一直缩水，最后与同样是上市公司的 Hortonworks 进行了合并，合并后的股价仅有 20 亿美金。值得一提的是，Hadoop 之父 Doug Cutting 也是是Cloudera 公司的成员。

Hadoop 大数据平台

学习大数据的时候，你可能习惯把 Hadoop 与原有的应用开发那一套进行类比，但会发现没办法完全对应上，例如Hadoop确实能够用来存储数据，那么Hadoop就是数据库了吗？而很多文章在提到Hadoop的时候，有时会用大数据平台、数据仓库、分布式数据库、分布式计算框架等字眼，看似合理，但又不完全正确，让人非常迷惑。

这里，我对 Hadoop 做一个简单的解释。举例来说，在做传统应用开发的时候，我们不会过多的关注磁盘驱动器，这是因为文件系统已经帮我们进行了抽象，我们只需要使用文件系统 API 就可以操作磁盘驱动器。

同样的，我们在开发应用时也无需关注 CPU 的使用时间，操作系统和编程语言已经帮我们做好了抽象和隔离。所以在提到大数据平台的时候，我们要知道它首先是一个分布式系统，换言之底层是由一组计算机构成的，也就是一个集群。所谓大数据平台，相当于把这个集群抽象成一台计算机，而隔离了底层的细节，让用户使用这个平台时，不会感觉到自己在使用一个分布式系统，而像是在使用一台计算机，很轻松地就可以让整个集群为他所用。为了加深印象，我们可以来对比下两条命令：

hadoop dfs -ls /
ls /

第一条命令是浏览 Hadoop 文件系统（HDFS）的根目录，第二条命令是浏览 Linux 本地文件系统的根目录，如果不进行说明的话，无法看出第一条命令基于分布式文件系统，此外，这么对比的话，可以看到基于集群，Hadoop 为用户提供了一套类似 Liunx 的环境。

因此，Hadoop 可以理解为是一个计算机集群的操作系统，而 Spark、MapReduce 只是这个操作系统支持的编程语言而已，HDFS 是基于所有计算机文件系统之上的文件系统抽象。

同理，YARN 是基于所有计算机资源管理与调度系统之上的资源管理与调度系统抽象，Hadoop 是基于所有计算机的操作系统之上的操作系统抽象。所以如果你一定要进行比较的话，Hadoop 应该和操作系统相比较。

Hadoop 的趋势

在 Hadoop 2.0 时期，Hadoop 的存在感还是非常强的，但是就像普通计算机一样，编程语言的热度始终要大于操作系统。随着计算框架的百花齐放，一些新的资源管理与调度系统问世，例如 Kubernets 和 Mesos，Hadoop 的存在感越来越低，在大数据平台中越来越底层，有些大数据平台甚至只采用 HDFS，其余都按照需求选取其他技术组件。

此外，一些计算框架本身就自带生态，如 Spark 的 BDAS，这就逐渐造成了一种现象：Hadoop 的热度越来越低，而分布式计算框架的热度越来越高，就像 Java 的热度肯定比 Linux 高，这也符合计算机的发展规律。

在现在的环境下，采用 HDFS+YARN 的方式作为自己底层大数据平台，仍然能满足绝大多数需求，也是最方便的解决方案。在十年前，Hadoop 就让大家享受到了阿姆达尔定律的红利，它的功劳还是需要被大家所铭记。在后面很长一段时间里，Hadoop 在大数据技术领域里仍然会占有一席之地。

总结

本节课主要讲解了 Hadoop 的架构及其一些关键组件等概念性的东西，但最后的比喻很有意思，作为集群的操作系统，Hadoop 短时间不会，未来也很难退出大数据的舞台。