实时计算——聊一聊我所经历的计算框架

在聊实时计算之前，先说一下我对离线和批量、实时和流式的一些看法。

我们首先来简单看一下计算任务的大致流程：

首先先说下批量计算和流式计算：

图中显示了一个计算的基本流程，receiver处负责从数据源接收数据，并发送给下游的task，数据由task处理后由sink端输出。

以图为例，批量和流式处理数据粒度不一样，批量每次处理一定大小的数据块（输入一般采用文件系统），一个task处理完一个数据块之后，才将处理好的中间数据发送给下游。流式计算则是以record为单位，task在处理完一条记录之后，立马发送给下游。

假如我们是对一些固定大小的数据做统计，那么采用批量和流式效果基本相同，但是流式有一个好处就是可以实时得到计算中的结果，这对某些应用很有帮助，比如每1分钟统计一下请求server的request次数。

那问题来了，既然流式系统也可以做批量系统的事情，而且还提供了更多的功能，那为什么还需要批量系统呢？因为早期的流式系统并不成熟，存在如下问题：

1.流式系统的吞吐不如批量系统

2.流式系统无法提供精准的计算

后面的介绍Storm、Spark streaming、Flink主要根据这两点来进行介绍。

批量和流式的区别：

1.数据处理单位：

批量计算按数据块来处理数据，每一个task接收一定大小的数据块，比如MR，map任务在处理完一个完整的数据块后（比如128M），然后将中间数据发送给reduce任务。

流式计算的上游算子处理完一条数据后，会立马发送给下游算子，所以一条数据从进入流式系统到输出结果的时间间隔较短（当然有的流式系统为了保证吞吐，也会对数据做buffer）。

这样的结果就是：批量计算往往得等任务全部跑完之后才能得到结果，而流式计算则可以实时获取最新的计算结果。

2.数据源：

批量计算通常处理的是有限数据（bound data），数据源一般采用文件系统，而流式计算通常处理无限数据（unbound data），一般采用消息队列作为数据源。

3.任务类型：

批量计算中的每个任务都是短任务，任务在处理完其负责的数据后关闭，而流式计算往往是长任务，每个work一直运行，持续接受数据源传过来的数据。

离线=批量？实时=流式？

习惯上我们认为离线和批量等价；实时和流式等价，但其实这种观点并不完全正确。

假设一种情况：当我们拥有一个非常强大的硬件系统，可以毫秒级的处理Gb级别的数据，那么批量计算也可以毫秒级得到统计结果（当然这种情况非常极端，目前不可能），那我们还能说它是离线计算吗？

所以说离线和实时应该指的是：数据处理的延迟；批量和流式指的是：数据处理的方式。两者并没有必然的关系。事实上Spark streaming就是采用小批量（batch）的方式来实现实时计算。

可以参考下面链接：https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101。

整理了一份适合2018年学习的大数据资料需要的加群QQ群：834325294 注明CSDN既可免费获取作者是Google实时计算的负责人，里面阐述了他对批量和实时的理解，并且作者认为批量计算只是流式计算的子集，一个设计良好的流式系统完全可以替代批量系统。本人也从中受到了很多启发。

介绍完这些概念后，下面我们就来简单看看目前流行的实时计算框架的实现和区别。

Storm

Storm做为最早的一个实时计算框架，早期应用于各大互联网公司，这里我们依然使用work count举例：

 

spout：负责从数据源接收数据

bolt：负责数据处理，最下游的bolt负责数据输出

spout不断从数据源接收数据，然后按一定规则发送给下游的bolt进行计算，最下游的bolt将最终结果输出到外部系统中（这里假设输出到DB），这样我们在DB中就可以看到最新的数据统计结果。Storm每一层的算子都可以配置多个，这样保证的水平扩展性。因为往往处理的是unbound data，所以storm中的算子都是长任务。

容灾是所有系统都需要考虑的一个问题，考虑一下：假如运行过程中，一个算子（bolt）因某种原因挂了，Storm如何恢复这个任务呢？