前言
本文隶属于专栏《1000个问题搞定大数据技术体系》,该专栏为笔者原创,引用请注明来源,不足和错误之处请在评论区帮忙指出,谢谢!
本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系
正文
使用场景受限
易于编程的 MapReduce 虽然具有很多的优势,但是它也有不擅长的地方。
这里的不擅长不代表它不能做,而是在有些场景下实现的效果差,并不适合 MapReduce 来处理,主要表现在以下几个方面。
- 实时计算:MapReduce 无法像 MySQL 一样,在毫秒或者秒级内返回结果。
- 流式计算:流式计算的输入数据是动态的,而 MapReduce 的输入数据集是静态的,不能动态变化。这是因为 MapReduce 自身的设计特点决定了数据源必须是静态的。
- DAG(有向无环图)计算:多个应用程序存在依赖关系,后一个应用程序的输入为前一个的输出。
在这种情况下, MapReduce 并不是不能做,而是使用后,每个 MapReduce 作业的输出结果都会写入到磁盘,会造成大量的磁盘IO,降低使用性能 - 交互式处理:MapReduce 不支持类似 Linux Shell 这样的交互式处理逻辑。
- 机器学习处理:MapReduce 不支持机器学习这种迭代式处理逻辑。
MapReduce 只适合不考虑时间性能的离线批处理场景。
部分框架比如 Sqoop 底层计算引擎就是 MapReduce,用户不感知也不会关心它底层是如何实现的,只要能达到数据转移的目标就好。
高昂的维护成本
使用 MapReduce,你需要严格地遵循分步的 Map 和 Reduce 步骤。
当你构造更为复杂的处理架构时,往往需要协调多个 Map 和多个 Reduce 任务。
然而,每一步的 MapReduce 都有可能出错。
为了这些异常处理,很多人开始设计自己的协调系统(orchestration)。
例如,做一个状态机(state machine)协调多个 MapReduce,这大大増加了整个系统的复杂度。
时间性能“达不到”用户的期待
除了高昂的维护成本, MapReduce 的时间性能也是个棘手的问题。
MapReduce 是一套如此精巧复杂的系统,如果使用得当,它是青龙偃月刀,如果使用不当,它就是一堆废铁。不幸的是并不是每个人都是关羽。