0. 前言

在上两篇文章中分别描述了数据源接入方式、数据源落地方案选择，那么接下来该轮到如何对数据源进行计算处理了。

对于数据的计算形式可以多种多样，如果从数据处理的历史进程来划分，可以分为：大数据时代之前的集中式数据计算和大数据时代的分布式数据计算。

先来给数据计算下个定义：将目标数据集通过转换、抽取、清洗、分析、挖掘，最终处理成业务需要的样子, 即数据计算。

1. 集中式计算

在大数据时代之前的数据计算，可以称之为【集中式计算】，所谓集中式，意思就是单个进程内部或者单机内部对数据进行计算。最大的瓶颈是只能利用单台服务器的资源，因此其计算规模很容易达到极限。

在以前，传统的SQL数据库可以解决任何问题。

然而，随着互联网时代的到来，尤其是移动互联网的爆发式发展，数据规模呈指数级增长，之前的那套方案显然不再适用，此时急需一套能够计算海量数据的技术。就在这个时候，Google发表了对行业具有极其重要意义的3篇论文，分别是分布式文件系统GFS、分布式计算引擎MapReduce、分布式数据库BigTable。就是这几篇论文，才诞生了后来伟大的Hadoop生态（HDFS、MapReduce、Hbase），随着该生态的持续发展，后续很快又加入了很多其他的技术组件，比如hive、solr、yarn等。

很快，MapReduce就成为了分布式计算引擎的事实标准，各行各业争相使用，虽然该计算引擎早已经淘汰，但其指导思想却一直影响至今。

2. 分布式计算

分布式计算引擎的出现就像一颗救星，让令人头疼的超大数据集的计算成为可能（集中式计算在生产中会面临各种OOM）。

虽然MapReduce存在各种各样的缺陷（根本原因在于配置复杂和效率低下），但是作为大数据时代分布式计算的开山鼻祖，具有划时代意义，它带给我们最核心的思想就是：分治和规约。

也就是原来一台机器搞不定，现在可以多台机器一起帮忙，每台机器计算一部分，然后将每台机器计算的结果再传到其中的一台或者几台机器进行规约汇总，最终得出计算结果。

而后续出现的所有优秀的分布式计算框架，都继承了该核心思想。

根据我对计算引擎的理解，给它下一个定义：在针对一类数据进行计算过程中，将共性部分进行抽象形成的软件框架叫做计算引擎。

而对于大数据时代而言，其数据计算的共性部分就是map跟reduce，即分治与规约。注意，这里的map跟reduce是广义的，不是仅仅指具体的map算子跟reduce算子本身（比如spark的distinct、aggregate等算子全是map或者reduce的变种）。

虽然说分布式计算引擎给大数据时代带来了福音，但是也同样给使用者拔高了使用门槛。因为是分布式计算，所以这里就涉及到多个机器间任务的调度、通信、分布式事务管理等诸多技术挑战，关于这部分内容，后续文章会讲到。

结合我的个人经验，给这两类常用计算框架做一个概括性总结，如下图所示：

3. 如何选择计算框架

计算框架毫无疑问是用来计算数据的，那如何选择呢？

首先看业务场景，一切脱离业务场景的技术选型都是耍流氓。而业务场景中，第一个要看的就是数据量，这里面有个指导原则就是：在满足业务需求的前提下，能用简单的技术就一定不要用复杂的。

因为简单，通常意味着稳定、高效率。对于计算框架选型来说，如果基于你项目目前的数据体量，用集中式的计算框架就能搞定的事情（比如一天的数据增量都不到100MB），就一定不要为了跟风赶时髦而去用分布式的计算引擎，

因为只有把单机的效率利用到极致了，再考虑用分布式才有意义，否则如果你技术储备不够，只会是自讨苦吃。

见过很多团队中，明明一个MySQL就可以搞定的项目（数据量小的可怜），非得引入Hadoop技术栈，最后各种不稳定，各种bug频出，把自己搞的狼狈不堪，实在是没有必要，其实那些大数据的技术组件的核心原理一点都不高大上，技术的使用目标是解决工程上的实际问题，而不是追求所谓的高大上。

那如果数据量大的场景下（每天怎么着也得有几百MB的数据增量吧，否则不好意思上分布式啊），该怎么办呢？上分布式计算框架喽。因为分布式计算框架中又分为流式计算跟批处理计算，具体用哪个，还是两个都用，这个在你的业务场景中其实很好判断，且上面的总结中已经说的比较清楚，不再赘述。

接下来，聊一下在确定完使用流式计算还是批处理计算之后，如何对计算引擎选择的问题。这里面大概涉及到7种不同技术实现（strom、sparkstreaming、structured streaming、flink streaming、MapReduce、spark batch、flink batch），和4大不同类型的技术栈（strom、MapReduce、spark、flink）。

如果在你的项目中，既有流式计算又需要批处理计算，最好选择spark或者flink，因为这两种模式它们都支持。

Strom：关于它的一些基本概念，网络上有很多，不再赘述。如果你的应用场景只有流式计算，且对实时性要求高，且你对该计算框架很熟悉（这点至关重要），可以用。但是其缺点是社区热度在逐年下降，生态不不够完整，可能出现跟一些对新的大数据组件支持不友好的情况，所以在选择前还是要慎重。

MapReduce：同样略过基本概念。虽然现在该计算引擎还没有完全淘汰(在作为某些框架内嵌的计算引擎使用)，但是已经不再推荐使用了。一者编程模型过于僵化，开发起来很难受；二者计算效率也低下，跟不上业务对数据处理速度的要求。现在已经没有人用这个框架编写业务处理代码了。

spark VS flink：都是当今流批一体处理的王者，选哪个？其实都可以。

有人说flink的流式处理思想更加先进，延迟更低，那麻烦structured streaming了解一下，同样一点也不弱的（不要只看官网的宣传，要看实际使用效果）。这两种框架都有着强大的社区支持，不存在谁比谁要高出一截来。至于如何选择，最重要的一点是你能hold住哪个技术，对哪个技术栈更加熟悉。有人说我难道不能都选吗？如果是在实验环境下作为技术尝试，没有问题，但是如果在生产环境，还是不建议了，增加了系统复杂度不说，还增加了运维管理难度和开发难度，纯属自找麻烦，把其中的一种技术用好不香吗？

4. 总结

计算引擎可以说是大数据时代最为伟大的发明之一，它将原本只能跟数据结构耦合在一起的状态，进行了剥离。

让数据源和计算引擎完全分割开，且对数据源不再是必须符合某种索引要求，大大提高了数据源的利用率；

此外，因为计算引擎是对数据处理过程共性的抽象，提供了很多实用的脚手架和语法糖功能，开发人员可以根据业务需要，极其灵活的编写自己的业务处理逻辑；

当然，计算引擎的缺点也非常明显，因为数据处理必须经过【分治与规约】的过程，就注定了这个过程是离线的，是有时间延迟的。

如果你有任何疑问，欢迎找我探讨。

大家有任何关于大数据相关的技术问题，欢迎找我咨询。