如何看待 Google 说已经停用 Map Reduce 好多年？ 第1页

昨天我边盯着一个 MapReduce job 边听 Google I/O, 听到 Urs 说我们都不用 MapReduce 了好桑心，虽然 Google 内部系统通常只有 deprecated 和 experimental 两种状态，但真不带拿 MapReduce 这么玩儿的不是。

官方 blog[1] 有个简单解释，相关论文其实早就出来了。

Today at Google I/O, we are demonstrating Google Cloud Dataflow for the first time. Cloud Dataflow is a fully managed service for creating data pipelines that ingest, transform and analyze data in both batch and streaming modes. Cloud Dataflow is a successor to MapReduce, and is based on our internal technologies like Flume andMillWheel.

我感觉题主链接的新闻重点抓错了，MapReduce 这套分布式计算框架实现的主要局限在于 1. 用 MapReduce 写复杂的分析 pipeline 太麻烦；2. 它怎么改进都还是一个基于 batch mode 的框架。

MapReduce 的计算模型特别简单，只要分析任务稍微复杂一点，你就会发现一趟 MapReduce 是没法把事情做完了，你就得设计多个互相依赖的 MapReduce 任务，这就是所谓 pipeline.在数据流复杂的分析任务中，设计好的 pipeline 达到最高运行效率很困难，至于给 pipeline 调错就真是让人想死。这时就需要用到 Flume[2] 了 —— 演示中的代码其实就是运用 Flume 框架的 Java 代码。Flume 提供了一个抽象层次更高的 API，然后一个 planner 把 Flume 程序转换成若干个 MapReduce 任务去跑。Google 还有很多这种基于 MapReduce 的封装，有一个叫 Tenzing[3] 的项目，是把复杂的 SQL 查询转换（编译）成 MapReduce, 还有 Sawzall[4] 这样的直接基于 MapReduce 模型的专用语言。所以没错，裸奔 MapReduce API 的时候确实少了，但数据中心里每天仍有无数的 MapReduce job 甚至在工程师自己都不知道的情况下，默默地低调地跑着 —— 当然这个 MapReduce 经过多年改进，估计 2003 年出论文时的代码现在已经一行不剩了。如果哪天所有人都不裸奔 MapReduce API 了（总有我这样的顽固分子），Urs 要偷偷把 MapReduce 换成什么别的我们可能还真都不知道。

另外插播一句 Flume 的思路没有多独特，它的编程模型跟微软的 LINQ 很相象，DryadLINQ[5] 的计划算法也跟 Flume 异曲同工。它们所依赖的理论基础可就老了去了。

MillWheel[6] 则是解决流计算的问题了。

我觉得必须在概念上把 MapReduce 计算模型，和 Google 内部基于这套计算模型做出的分布式计算框架实现分开。MapReduce 这个计算模型其实很古老，是函数式程序设计里的一个基本思路，它的名字就源于 LISP 类函数式语言里的 map 和 reduce 操作。Google MapReduce 论文的主要贡献是在于它让这个非常常用的计算模型跑在了一大堆会随时崩溃的 PC 上，而不在计算模型本身。

把 MapReduce 看成基本的函数式编程模型而不是具体实现，理解 Flume 和 MillWheel 会简单很多，Flume 做的工作其实就是一个编译器，把一个复杂的分析程序编译成一堆基本的 MapReduce 执行单元。至于 MillWheel 的所谓流计算则跟函数式编程里的懒惰求值大有渊源，比如计算

       (map (fn [x] (* x 2)) (map (fn [x] (+ x 1)) data-list))      

最笨的做法就是先把 data-list 每项加 1，输出一个列表作为每项乘 2 的 map 任务的输入，然后再输出另一个列表，这就是传统 MapReduce 实现干的事情。Clojure 利用 LazySeq 实现了对 map 的懒惰求值，可以做到「要一个算一个」：当要取上述结果的第一项时，它才去取 data-list 中的第一项，作加 1 和乘 2 操作然后输出，如此类推，就不是做完一个 map 再做另一个 map 了。MillWheel 做的则是方向正好反过来的「来一个算一个」，data-list 里来一个输入就输出一个结果，每一步都不需要等上一步全部完成（数据流往往是无限的，没有「全部完成」的概念）。例如计算：

       (reduce + 0 (map (fn [x] (* x 2)) data-stream))     

（注意这不是一个典型的 MapReduce，虽然里面有 map 和 reduce）在 MillWheel 里，就可以随着 data-stream 数据的涌入，实时显示当前的数据总和，而不是到 data-stream 结束时才输出一个结果，而且这样 x * 2 的中间结果也压根用不着存储下来。

可以看到，具体怎么实现上述运算，是个具体实现的底层优化的问题，在概念上计算模型还是基本的 map 和 reduce，就好比同一条 SQL 查询语句可用于不同的执行引擎 —— 在 I/O 上工程师也演示了一段分析代码是怎么可以不加修改同时适应 batch 模式和流模式的。作为常用计算模型的 MapReduce 并没有什么被淘汰的可能。

再补充一句，MapReduce 当然不是唯一可用的计算模型，MillWheel 可以很方便的实现其他计算模型，Google 还有基于图的计算框架 Pregel[7] 等。另外其实自从有了 Dremel[8], 很多分析任务都可以直接用交互式查询来完成，写分析 pipeline 的时候也少了很多。

1.

2.

3.

4.

5.

6.

7.

8.