Hadoop中的通用分布式计算框架

本文的内容是对本人近期学习hadoop系统过程的总结和思考，接触的通用计算框架有限，错误在所难免，欢迎指正和讨论

我接触的hadoop中的通用计算框架主要是mapreduce和spark。其中mapreduce在hadoop 2.0中被简化，将资源管理的功能抽象、独立出来，形成了yarn，一个通用的资源管理框架。而mapreduce则成为一个存粹的计算框架。随着spark的流行，mapreduce由于框架的限制、性能等原因被使用的越来越少了。

mapreduce于2006提出，由于其大大简化了分布式计算的程序的编写，而迅速流行起来。在我能读懂mapreduce的论文之后（论文发表N年后），让我惊讶的是mapreduce提出的运行方式与我工作中的程序运行方式有很大不同：

• mapreduce在一开始就将数据分成了多份，并将同一个程序复制到不同机器（节点）中执行，最后将结果聚合
• 一般互联网应用的开发方式（不考虑横向扩展的情况下）是将一个任务分成多个阶段（验证，业务执行，落库等），每个阶段由不同的机器（节点）执行。

由此也可以看出大数据系统与互联网应用的异同。而将数据分批分片执行的操作也是我之前看不懂mapreduce的主要原因（另一个原因是贫穷限制了我的想象力，当时不明白为什么需要那么多机器）。

mapreduce将计算过程分为map和reduce两个阶段，在当时能够满足大部分的需求，但随着人工智能和实时计算的兴起，mapreduce的局限越来越大。mapreduce主要有两个局限：

• 将计算过程抽象为map和reduce，现在看来过于简单。如果将分布式计算任务类比为面向对象编程中的interface，该interface将计算任务划分为任意个阶段（phase），那么mapreduce就是一个只有两个阶段的抽象类（abstract class），而继承了mapreduce的具体计算任务可发挥的余地就很小了。
• 缺少对数据的抽象。对于mapreduce框架，主要是提供了容错机制，将分布式计算的复杂性隐藏起来，而对于数据，则完全由具体的任务来解析。

由于mapreduce框架本身的缺陷，已经不能适应当前对大数据计算的需求，因此逐渐地被spark等框架取代。

spark作为新一代的通用计算平台，解决了mapreduce中存在的固有问题：

• 首先，spark没有再限制任务可以分为几个阶段，而是直接实现了分布式计算任务这个interface，考虑到易用性，任务该如何划分是由spark的引擎决定的，而不需要首先代码来控制。另外提供类sql语言来定义分布式计算任务，spark引擎再将sql转换为分布式任务。
• 对数据的抽象：spark使用rdd来表示数据，一个rdd中包含的数据可能分布在多个节点上。计算任务都是基于rdd来完成的。spark希望使用rdd来完成批处理，交互查询，迭代计算，流处理等需求，但在流处理方面，spark将流看作一段一段的数据，当对实时性要求越来越严格时，就有点力不从心。

据说apache flink使用了不同的数据抽象，更能满足对实时性的要求，不过我还没用过flink。有熟悉的欢迎指教。

未来，新的分布式计算平台主要还是看如何对数据进行抽象，以满足各种计算需求。对于使用大数据计算平台的公司，根据公司的规模以及开发的周期可以采取如下几种方式不断改进计算任务：

• 根据业务的需求，以及技术人员对于分布式计算的理解，开发自己的分布式计算平台。但这需要强大的财力支持，也需要深厚的技术储备，只适用于大公司，也是一个长期的规划。开发出新的计算平台是最难的，因为新的计算平台一定是要大大超越已有计算平台的，否则没必要重新发明轮子。而要超越已有的计算平台，就需要对分布式计算有新的、更高级的认识，需要质变，而不能仅仅是量变。
• 改进现有的通用计算平台，这种改进可能是在长期使用过程中积累的经验，也可能是根据最新的学术研究成果。这适合于大中型公司，是一个中长期规划。
• 优化现有的计算任务。这是一个短期的、适用于任何公司的计划。也是大部分公司都在做的。

这几种方式可以并行进行，也可能是层层递进的。比如在大量的短期优化计算任务后，将通用的部分提出来改进计算平台。多次改进计算平台后使用计算平台有了新的理解，开发出属于自己的分布式计算平台。

(广告，我正在学习Hadoop系统，包括读书和读源码，希望能和正在学习的小伙伴一起交流，如果你也有这样的想法，并且愿意经常分享你的所学，欢迎扫码进群)