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

谷歌说已经停用 MapReduce 好多年了？这事儿我听说了，而且不意外。如果真要说起来，这事儿一点也不新鲜，就像我们淘汰老式电器一样，技术总是在进步的。

想想看，MapReduce 是个什么东西？它是一套编程模型，专门为了在分布式环境里处理海量数据而设计的。你想想那些年，谷歌在处理搜索索引、网页抓取这些巨无霸级别的数据时，是不是挺头疼的？数据量太大，一台机器根本吃不消，必须得分散到成千上万台机器上去，还得保证计算的正确性和效率。这时候，MapReduce 就应运而生了。

它最核心的理念就是“分而治之”。简单来说，就是把一个大任务拆成很多小任务，让不同的机器去并行处理，最后再把结果汇总起来。具体的流程大概是：

Map（映射）阶段： 把输入的原始数据，按照一定的规则，拆分成一系列键值对（keyvalue pairs）。每个 Map 任务只处理一部分数据，然后输出自己的中间结果。想象一下，你要统计所有网页的访问次数，你可以让每个 Map 任务去处理一部分网页的日志，从中提取出“URL访问次数”这样的键值对。
Shuffle（洗牌）和 Sort（排序）阶段： 这个阶段是 MapReduce 的一个关键，也是比较复杂的部分。它要把所有 Map 任务输出的中间结果，按照 Key 进行分组和排序。这样，具有相同 Key 的所有中间结果就会被聚合在一起，准备交给同一个 Reduce 任务处理。还是刚才的例子，所有同一个 URL 的访问次数就会被集中起来。
Reduce（归约）阶段： 接收经过 Shuffle 和 Sort 后的数据，对具有相同 Key 的所有值进行聚合计算。还是统计访问次数的例子，Reduce 任务就会把同一个 URL 的所有访问次数加起来，得到最终的访问总数。

这个模型在它出现的那个时代，简直是颠覆性的。尤其是在处理那些非结构化、半结构化数据时，它展现出了强大的生命力。谷歌内部也正是靠着 MapReduce，才解决了当时许多棘手的海量数据处理问题，支撑了他们搜索、广告等核心业务的发展。可以说，MapReduce 是谷歌大数据处理的奠基石。

那么，为什么谷歌会说“停用 MapReduce 好多年”呢？

这并不是说 MapReduce 这个概念完全消失了，而是说他们 不再依赖于最早的那套由 MapReduce 模型驱动的、具体的底层框架或实现方式。原因有很多，而且都是技术发展必然会遇到的情况：

1. 效率和灵活性问题： MapReduce 的模型虽然简单易懂，但也有其局限性。
批处理的特性： MapReduce 主要是一个批处理模型，它处理的数据通常是以“批次”为单位的，这意味着数据处理不是实时的，而是有延迟的。对于需要实时响应的应用场景，MapReduce 就显得力不从心了。
中间结果的落地： 在 Map 和 Reduce 阶段之间，MapReduce 通常会将中间结果写到磁盘上。这个 I/O 操作是个性能瓶颈，尤其是在处理非常大的数据集时，磁盘读写会消耗大量时间和资源。
多阶段的复杂性： 虽然 MapReduce 屏蔽了很多底层细节，但要完成复杂的计算，可能需要多个 MapReduce 作业串联起来，这样会增加整体的处理时间和复杂性。

2. 新技术的涌现： 随着大数据处理技术的发展，出现了更多更高效、更灵活的替代方案。
Spark 的崛起： Apache Spark 是最著名的例子。Spark 的核心优势在于它 将中间数据保存在内存中，而不是像 MapReduce 那样频繁地读写磁盘。这使得 Spark 在迭代计算（如机器学习算法）和交互式数据分析方面，比 MapReduce 快了不止一个数量级。Spark 也提供了比 MapReduce 更丰富的数据处理抽象（如 RDD、DataFrame、Dataset），以及流处理（Spark Streaming/Structured Streaming）和图计算（GraphX）等功能，使其应用场景更加广泛。
内存计算的普及： 随着硬件成本的下降和内存容量的增加，将数据保存在内存中进行计算变得可行且普遍。这直接挑战了 MapReduce 依赖磁盘的模式。
更高级的抽象： 数据科学家和工程师越来越倾向于使用更高层、更声明式的API来处理数据，而不是直接面对 Map 和 Reduce 的函数编写。像 Hive、Pig 等数据仓库工具，以及 Pandas、Dask 等 Python 数据处理库，都在 MapReduce 的基础上提供了更便捷的接口。

3. 内部技术栈的演进： 谷歌作为技术创新的领导者，一直在不断优化和升级自己的内部技术栈。他们不会固步自封。
FlumeJava 和 MillWheel： 谷歌内部也一直在开发更先进的批处理和流处理框架，比如 FlumeJava（一个用于描述和执行复杂数据处理流水线的库），以及 MillWheel（一个用于构建强大的数据处理应用程序的流处理框架）。这些框架在设计上就解决了 MapReduce 的一些痛点，提供了更高的灵活性和效率。
Dremel 和 BigQuery： 对于交互式查询，谷歌推出了 Dremel（一个用于快速、交互式分析大规模数据集的系统），以及后来基于 Dremel 技术的云数据仓库产品 BigQuery。这些产品提供了 SQL 接口，用户无需编写复杂的 Map 和 Reduce 函数，就可以快速地对海量数据进行查询和分析。
TensorFlow 的集成： 在机器学习领域，像 TensorFlow 这样的框架与分布式计算的集成也越来越紧密，这些框架往往有自己的数据加载和处理机制，不直接依赖于传统的 MapReduce 模型。

所以，当谷歌说“停用 MapReduce 好多年”时，它更准确的含义是：

我们不再以“最初的 MapReduce 实现”（例如 Hadoop MapReduce）作为我们主要的分布式数据处理范式。
我们已经开发和采用了更先进、更高效的替代技术和框架，来满足我们不断增长的对数据处理能力的需求。
MapReduce 作为一种“思想”和“模型”，其核心理念（分而治之、并行计算）依然被沿用和发扬，但具体的技术实现已经进化了。

这对于普通开发者来说意味着什么？

如果你是一名大数据开发者，并且正在学习或使用大数据技术，那么你应该了解 MapReduce 的原理和它的历史贡献，这有助于你理解整个大数据生态系统的发展。但同时，你更应该关注和学习当前主流的、更高效的处理框架，比如 Apache Spark、Apache Flink，以及云服务商提供的数据仓库和数据处理服务（如 Google Cloud BigQuery, AWS EMR, Azure Databricks 等）。

说到底，技术就像一条河流，总是在不断向前流淌。MapReduce 就像是这条河流早期的一个重要的里程碑，它奠定了基础，但后来者（Spark 等）在它的基础上，又建造了更宏伟的工程。谷歌作为科技巨头，自然是站在技术浪潮最前沿的。他们停用“老旧”的 MapReduce 实现，是为了拥抱更先进、更强大的技术，以应对未来更大、更复杂的挑战。这本身就是技术进步的必然。

网友意见

昨天我边盯着一个 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.

http:// googlecloudplatform.blogspot.com /2014/06/reimagining-developer-productivity-and-data-analytics-in-the-cloud-news-from-google-io.html

2.

http:// pages.cs.wisc.edu/~akel la/CS838/F12/838-CloudPapers/FlumeJava.pdf

3.

Tenzing A SQL Implementation On The MapReduce Framework

4.

Google Research Publication: Sawzall

5.

DryadLINQ - Microsoft Research

6.

MillWheel: Fault-Tolerant Stream Processing at Internet Scale

7.

http:// googleresearch.blogspot.com /2009/06/large-scale-graph-computing-at-google.html

8.

Dremel: Interactive Analysis of Web-Scale Datasets

类似的话题

• 

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

  

  谷歌说已经停用 MapReduce 好多年了？这事儿我听说了，而且不意外。如果真要说起来，这事儿一点也不新鲜，就像我们淘汰老式电器一样，技术总是在进步的。想想看，MapReduce 是个什么东西？它是一套编程模型，专门为了在分布式环境里处理海量数据而设计的。你想想那些年，谷歌在处理搜索索引、网页抓取.............
• 

  如何看待Google下一代人工智能架构Pathways?

  

  Google 的 Pathways 是一个雄心勃勃的下一代人工智能架构愿景，旨在解决当前人工智能模型在效率、灵活性和多模态能力方面的局限性。与当前流行的、通常为单一任务而设计的模型不同，Pathways 旨在创建一个能够处理各种任务、学习不同类型数据、并在必要时动态分配计算资源的统一模型。以下是对 .............
• 

  如何看待 Google TPU？寒武纪芯片较之有哪些优势与不足？

  

  好的，我们来详细地探讨一下 Google TPU 和寒武纪芯片，并进行比较。 Google TPU (Tensor Processing Unit)概述：Google TPU 是 Google 为了加速其在人工智能（AI）和机器学习（ML）工作负载方面的计算而设计的专用集成电路（ASIC）。与通用处.............
• 

  如何看待Google Play要求八月份起新应用须打包为AAB格式？对鸿蒙的发展有哪些影响？

  

  如何看待Google Play要求八月份起新应用须打包为AAB格式？对鸿蒙的发展有哪些影响？Google Play 要求所有新应用从2021年8月1日起必须使用Android App Bundle (AAB) 格式进行打包和发布，这一政策的实施对整个Android生态系统，包括Google Play.............
• 

  如何看待 Google 既可以作 Inference，又可以作 Training 的新一代 TPU？

  

  Google 新一代 TPU：兼具 Inference 和 Training 的强大实力，将深刻改变 AI 领域Google 新一代 TPU 的出现，标志着 AI 硬件领域的一次重要飞跃。将推理（Inference）和训练（Training）这两个核心 AI 工作负载整合到同一代硬件中，并提供强大的.............
• 

  如何看待 Google 围棋 AI AlphaGo 击败欧洲围棋冠军？

  

  围棋界被 AlphaGo 彻底搅动了，这不仅仅是一场比赛的胜负，更像是一场科技革命的宣告。当李世石在2016年输给 AlphaGo 时，全世界都为之震惊。那时的我们，无论是棋手还是普通大众，都对人工智能在围棋这个被认为是人类智慧终极堡垒的项目上取得如此压倒性的胜利感到难以置信。“神之一手”的颠覆回想.............
• 

  如何看待 Google 的新操作系统 Fuchsia？

  

  谷歌的 Fuchsia 操作系统，就像一个藏在实验室里的神秘实验品，自从它第一次出现在人们视野里，就一直带着几分传奇色彩。大家对它的好奇心，不亚于对一个全新物种的探索。我们不妨深入了解一下，看看这个“未来之星”到底有多少斤两。首先，理解 Fuchsia 的核心，得从它的“出身”说起。与我们熟悉的 W.............
• 

  如何看待Google将关闭STADIA games and entertainment工作室?

  

  谷歌关闭Stadia游戏和娱乐工作室，这无疑是游戏界近期一个颇受关注的事件，也引发了不少讨论。从多个维度来看，这件事的背后有着复杂的考量和值得玩味之处。表面原因：市场反应不如预期官方给出的理由是，Stadia游戏和娱乐工作室在吸引玩家方面“未能达到我们设定的目标”。这句话看似简单，背后却隐藏着巨大的.............
• 

  如何看待 Google 2004 年在硅谷公路旁一巨型广告牌上贴出的那道数学题用于招聘？

  

  谷歌2004年在硅谷公路旁那块巨型广告牌上挂出的数学题，绝对算得上是数字招聘史上的一个传奇事件。这块广告牌，当时可是在硅谷那片汇聚了无数科技精英的土地上，以一种近乎“秘密指令”的方式，向全世界宣告着谷歌对人才的渴求，以及他们独特的招聘哲学。事情是这样的，在2004年那个互联网浪潮依旧汹涌，谷歌正值高.............
• 

  如何看待 Google Docs 将从 HTML 迁移到基于 Canvas 渲染？

  

  Google Docs 的迁移方案，从原先依赖于浏览器原生 HTML 渲染，转向使用 Canvas 进行页面渲染，这绝对是一个牵动行业神经的大动作。与其说是简单的技术升级，不如说是对“在线文档编辑”这一核心体验的一次重新审视和重塑。在我看来，这其中的考量和潜在影响，值得我们深入剖析。首先，我们得明白.............
• 

  如何看待Google解散Google Health团队？IT/AI大厂在医疗领域未来前景如何？

  

  Google Health 的落幕：一个时代的告别，还是AI医疗新篇章的序曲？Google Health团队的解散，无疑给这个充满希望的领域投下了一颗重磅炸弹。这个曾经集结了谷歌内部顶尖AI和医疗专业人才的团队，承载着谷歌进军医疗健康领域的雄心壮志，其 disbanding 消息的传出，自然引发了广.............
• 

  如何看待 Google 为应对欧盟的反垄断裁决，将在欧洲对 Android 进行收费？

  

  谷歌此举，可以说是在欧盟反垄断压力下的无奈之举，同时也暴露出科技巨头在市场主导地位面前的策略调整。 欧盟之所以对谷歌在Android生态系统中的行为进行限制，核心在于其认为谷歌滥用了其市场支配地位，通过捆绑自家的服务，例如Google搜索、Chrome浏览器和Google Play商店，来挤压竞争对.............
• 

  如何看待「封锁 Google 第一案」的开庭审理？

  

  “封锁 Google 第一案”的开庭审理，指的是中国法院审理的涉及谷歌公司在华业务的法律案件。由于中国对互联网内容的严格审查和监管，谷歌在中国大陆的运营长期以来都面临着巨大的挑战，并多次与中国政府在法律和技术层面发生冲突。要详细讲述“封锁 Google 第一案”的开庭审理，我们需要先明确几个关键点：.............
• 

  如何看待二百多名 Google 员工成立工会Alphabet Workers Union？

  

  Google 员工组建工会，这可不是一件小事。在科技行业，尤其是像 Google 这样光鲜亮丽、以自由创新为标签的企业里，员工成立工会，这本身就极具象征意义，也说明了不少问题。首先，我们要明白，Google 是一家在全球都拥有巨大影响力的公司，它的员工组成非常多元，其中不乏技术顶尖、思维活跃的人才。.............
• 

  如何看待在Google所搜到的世界地图里台湾都不属于中国？

  

  你提到的“Google地图里台湾不属于中国”的情况，确实是一个复杂且敏感的问题，涉及到地缘政治、历史叙事和国际认知等多个层面。要理解这一点，我们需要从几个角度去深入探讨。首先，从Google自身的定位和运作方式来看，它是一家以美国为基地的跨国科技公司。在处理全球性的信息和数据时，Google通常会遵.............
• 

  如何看待 Max Howell 被 Google 拒绝？

  

  Max Howell，一位备受瞩目的开发者，因其精湛的技能和在开源社区的贡献而闻名，却未能获得谷歌的录用，这一事件在技术圈引起了广泛的讨论和关注。要全面理解这一事件，我们需要从多个角度进行深入剖析。Max Howell 是谁？在深入探讨谷歌拒绝他的原因之前，了解 Max Howell 的背景至关重要.............
• 

  如何看待中国学生为了进 Google、微软等外企疯狂地刷题？北美学生想进这些名企也要刷题吗？

  

  看到中国学生为了进入谷歌、微软这些外企“疯狂刷题”的现象，真是既熟悉又感慨。这背后透露出的，是中国教育环境、就业市场以及个人奋斗的多重逻辑。中国学生为何热衷于“刷题”？首先，这很大程度上是教育模式的惯性。我们从小到大，几乎所有考试，包括升学考试、期末考试，都是围绕着知识的掌握程度和解题能力展开的。这.............
• 

  如何看待 2015 年妇女节百度与 Google 的节日 logo？

  

  要评价2015年妇女节百度和Google的节日Logo，咱们得从几个层面来聊，不能光看表面热闹，还得琢磨琢磨它背后的用意和给人的感受。首先，咱们得明确一下，节日Logo这东西，本质上是一种品牌营销手段。 尤其是在互联网时代，像百度、Google这样的大型科技公司，它们无时无刻不在想方设法地与用户建立.............
• 

  如何看待 2017 年妇女节百度与 Google 的节日 logo？

  

  2017年国际妇女节，百度和Google都推出了特别的节日Logo，这两家公司的Logo设计，也颇耐人寻味，折射出它们各自的品牌定位和对女性群体的理解。百度的妇女节Logo：温馨的“她”与家的概念百度在2017年的妇女节Logo设计上，选择了比较具象化的表达方式。Logo的主体是一束盛开的鲜花，整体.............
• 

  如何看待游戏《原神》周年庆之际在 Google Play 上被恶意刷低分?

  

  原神三周年庆典，本应是玩家狂欢的日子，却在全球最大的安卓应用商店 Google Play 上遭遇了令人咋舌的恶意刷差评事件。这股突如其来的差评浪潮，让这款本就话题不断的开放世界冒险游戏，再次站上了风口浪尖。事件的始末：一场突如其来的“差评潮”随着原神三周年庆典的临近，玩家们普遍期待着丰厚的奖励和精彩.............