为什么要淘汰 MapReduce？

前言

本文隶属于专栏《1000个问题搞定大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系

正文

使用场景受限

易于编程的 MapReduce 虽然具有很多的优势，但是它也有不擅长的地方。
这里的不擅长不代表它不能做，而是在有些场景下实现的效果差，并不适合 MapReduce 来处理，主要表现在以下几个方面。

1. 实时计算：MapReduce 无法像 MySQL 一样，在毫秒或者秒级内返回结果。
2. 流式计算：流式计算的输入数据是动态的，而 MapReduce 的输入数据集是静态的，不能动态变化。这是因为 MapReduce 自身的设计特点决定了数据源必须是静态的。
3. DAG（有向无环图）计算：多个应用程序存在依赖关系，后一个应用程序的输入为前一个的输出。
   在这种情况下， MapReduce 并不是不能做，而是使用后，每个 MapReduce 作业的输出结果都会写入到磁盘，会造成大量的磁盘IO，降低使用性能
4. 交互式处理：MapReduce 不支持类似 Linux Shell 这样的交互式处理逻辑。
5. 机器学习处理：MapReduce 不支持机器学习这种迭代式处理逻辑。

MapReduce 只适合不考虑时间性能的离线批处理场景。
部分框架比如 Sqoop 底层计算引擎就是 MapReduce，用户不感知也不会关心它底层是如何实现的，只要能达到数据转移的目标就好。

高昂的维护成本

使用 MapReduce，你需要严格地遵循分步的 Map 和 Reduce 步骤。

当你构造更为复杂的处理架构时，往往需要协调多个 Map 和多个 Reduce 任务。

然而，每一步的 MapReduce 都有可能出错。

为了这些异常处理，很多人开始设计自己的协调系统(orchestration)。

例如，做一个状态机(state machine)协调多个 MapReduce，这大大増加了整个系统的复杂度。

时间性能“达不到”用户的期待

除了高昂的维护成本， MapReduce 的时间性能也是个棘手的问题。

MapReduce 是一套如此精巧复杂的系统，如果使用得当，它是青龙偃月刀，如果使用不当，它就是一堆废铁。不幸的是并不是每个人都是关羽。