数据后台处理系统——数据计算

前言

在上两篇文章中分别描述了数据源接入方式、数据源落地方案选择，那么接下来该轮到如何对数据源进行计算处理了。对于数据的计算形式可以多种多样，如果从数据处理的历史进程来划分，可以分为：大数据时代之前的集中式数据计算和大数据时代的分布式数据计算。

先来给数据计算下个定义：将特定数据集处理成业务需要的样子即数据计算。

集中式计算

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

集中式计算流程简图

在以前，传统的SQL数据库可以解决任何问题。然而，随着互联网时代的到来，尤其是移动互联网的爆发式发展，数据规模呈指数级增长，之前的那套方案显然不再适用，此时急需一套能够计算海量数据的技术。就在这个时候，Google发表了对行业具有极其重要意义的3篇论文，分别是分布式文件系统GFS、分布式计算引擎MapReduce、分布式数据库BigTable。就是这几篇论文，才诞生了后来伟大的Hadoop生态（HDFS、MapReduce、Hbase），随着该生态的持续发展，后续很快又加入了很多其他的技术组件，比如hive、solr等。很快，MapReduce（更早的MPI就不说了，大部分人都没有接触过）就成为了分布式计算引擎的事实标准，各行各业争相使用。

分布式计算

分布式计算引擎的出现就像一颗救星，让超大数据集的计算成为可能（要知道集中式计算会面临各种OOM）。虽然MapReduce存在各种各样的缺陷，但是作为大数据时代分布式计算的开山鼻祖，具有划时代意义，它带给我们最核心的思想就是：分而治之。也就是原来一台机器我搞不定，那我就多台机器一起帮忙，每台机器计算一部分，然后将每台机器计算的结果再传到其中的一台或者几台机器进行汇总，最终得出计算结果。而后续出现的所有优秀的分布式计算框架，都继承了该核心思想。

分布式计算流程简图

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

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

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

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

计算框架的总结如何选择计算框架

计算框架毫无疑问是用来计算数据的，那如何选择呢？首先看业务场景，一切脱离业务场景的技术选型都是耍流氓。而业务场景中，第一个要看的就是数据量，这里面有个指导原则就是：在满足业务需求的前提下，能用简单的技术就一定不要用复杂的。

因为简单就意味着稳定、高效率。对于计算框架选型来说，如果基于你项目目前的数据体量，用集中式的计算框架就能搞定的事情（比如一天的数据增量都不到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住哪个技术，对哪个技术栈更加熟悉。有人说我难道不能都选吗？如果是在实验环境下作为技术尝试，没有问题，但是如果在生产环境，还是不建议了，增加了系统复杂度不说，还增加了运维管理难度和开发难度，纯属自找麻烦，把一种技术用好不香吗？

以上，是我对数据计算的一点感受和理解，希望对你有所帮助。

因为篇幅所限，关于计算引擎的更多细节内容将在后续文章中陆续展开探讨，欢迎持续关注。

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!