01 为什么 MapReduce 会被淘汰

为什么 MR 会被淘汰

过去十几年，分布式系统的发展非常迅速，计算框架是其中非常耀眼的一个方向，业内比较流行的计算框架如下图所示（图片来自该专栏）：

大数据框架

大规模数据技术的发展，可以分为三个阶段：

1. 石器时代：MR 诞生之前，当时已经有了相应的需求，但还没有抽象提炼出一个系统的方法；
2. 青铜时代：MR 的诞生，标志是 Jeff 的那篇论文；
3. 蒸汽机时代：2016 Google 内部已经废弃 MR，开始全面 FlumeJava，新的时代开启；

15 年暑假，当时还在研一，在学习 storm、spark 这些框架，当时跟一个在 Google 师兄交流，记得他说他们用的是 FlumeJava，而那时的自己对未来技术的趋势没有任何敏感，根本没有想到 Google 的 DataFlow 后来会完全改写了整个流计算框架的发展。

MR 为什么会被取代？

1. 高昂的维护成本：MR 需要严格按照 Map/Reduce 拆分，复杂的流程需要协调多个 Map 和 Reduce 任务（而且任务的任何一步都有可能出错）；
2. 时间性能达不到用户的期待：MR 的调优会让你怀疑人生（配置太多，比如分片问题，后来 Google 提出了动态分片的功能）；

MR 后谁主沉浮：怎样设计下一代数据处理技术？

包括 Google 在内的一线大厂，对于内部技术的选择非常重要，一个能成为默认技术方案，至少满足以下条件：

1. 经受众多产品线、超大规模数据量的考验；
2. 自发地被众多开发者采用，简单易用而受开发者青睐；
3. 能通过内部领域专家的评审；
4. 比上一代技术有 10%的提升不是远远不够的，比如要显著地有 70%的提升，才能说服整个公司进行相应的迁移；

怎么设计下一代数据处理技术

如果现在回到 2008 年，已经清楚知道 MR 问题的情况，你会怎么设计下一代数据处理技术？

1. 首先为了解决‘复杂处理在 MR 中维护成本高的问题’，我们可以先使用有向无环图（DAG）来抽象表达，因为它可以为多步骤的数据处理建立模型（节点抽象为数据集，边抽象为数据变换，DAG 还相当于把数据处理描述语言跟计算引擎解耦开来）；
2. 自动地性能优化 + 计算资源的弹性分配；
3. 统一批处理+流处理的编程模型：统一的数据结构和统一的 API，现在有越来越多的任务可能既有流又有批（也可能会有更复杂的计算，比如：图计算）；
4. 架构层面提供异常处理和数据监控能力：数据监控特别是中间过程数据是否丢失等情况的监控；

按照我们的想法如果我们重新设计一个计算系统，整体的框架大概是这样这个样子（图片来自该专栏）。

我们设计的一个计算系统雏形

作者个人的经验分享：

我经常说服别人不要先去看有没什么开源技术可以用，而是从自己面对的问题出发独立思考，忘掉 MapReduce，忘掉 Apache Spark，忘掉 Apache Beam；

如果这个世界一无所有，你会设计一个怎样的大规模数据处理框架？你要经常做一些思维实验，试试带领一下技术的发展，而不是永远跟随别人的技术方向。

这个或许就是硅谷顶级大厂或者牛逼团队跟一般公司或团队的区别吧，他们本身能力就很强、技术氛围好、又经常做这些深入的思考，而我们更多的是在被动地完成手中的活，随着时间，这差距可想而知。

有兴趣的同学，可以通过下面的链接购买，会有一些优惠

二维码扫描购买有一定优惠