一口气说完MR、Storm、Spark、SparkStreaming和Flink

这是彭文华的第92篇原创

一直想写一篇大数据计算引擎的综述，但是这个话题有点大。今天试试看能不能一口气写完。没想到一口气从7点写到了凌晨2点

大数据计算的起点是Hadoop的MapReduce。之前虽然有一些分布式计算的工具，但是公认的大数据计算引擎的始祖仍然是MapReduce，虽然现在已经逐渐被同是批处理的Spark替代了。如同MapReduce一样，Storm开启了流式数据处理的先河，现在也被如日中天的SparkStreaming完全替代。而Spark和SparkStreaming的前面，正有一颗冉冉升起的闪耀巨星-Flink。

创世!MapReduce!

我当年在做某市交通委项目的时候，用的是Oracle。数据就是从各个收费站、路网上Socket过来的每辆车辆监测数据，一天数据量好几百万。这个数据量现在看好像没啥，但是放在2013年就蒙圈了，那时候还在用Oracle。作为单体数据库管理系统，Oracle其承载能力是有限的，基本上一个月的数据就能撑爆了。单表2000万性能就明显下降，软件层面优化无望，只能寄希望于更好的硬件--小型机。当时的业界基本就是这个状态。

这个时候，Hadoop携MapReduce横空出世！google实验室发明了MapReduce和Google File System，Apache基金会的人大受启发，成功孵化了Hadoop项目。

单体数据库能力有限，最后只能期望硬件（CPU、内存）越来越强，相当于是追求个人武力值的不断超越。而Hadoop生态的核心是化整为零，分而治之。Hadoop可以将一个巨大的数据集进行切分，然后分发给N个机器上进行存储，执行计算任务时，Hadoop将MapReduce任务扔到存有数据的N台服务器上，各自执行Map和Reduce过程，最后汇聚成为最终结果。

单台机器的进化有极限，而且成本会越来越高。而Hadoop的“分而治之”的思路完全打破了原有的单兵作战的套路，实施蜂群战术，让算力和服务器资源的线性增加成为可能。需要提升算力，只需要投入基本等同的普通计算机即可。

当时我们就用Hadoop的早期版本成功解决了交通项目数据海量线性增长的问题。对的，那时候还不叫“大数据”，叫“海量数据”。

MapReduce为了提升效率、增强鲁棒性，做了大量的精巧设计。比如为了解决Java的Full GC的问题，设计了环形缓冲区，以减少大量的内存申请和废弃操作；为了提升速度，在Map阶段做了大量的排序，Reduce阶段获取的数据天然有序，计算速度得到极大的提升。

MapReduce扩展阅读：

点击阅读：架构师带你细细的捋一遍MapReduce全流程【附调优指南】