这是我参与「第四届青训营 」笔记创作活动的第4天。

流式计算引擎发展历程

大数据诞生之初给使用者最大的疑惑在于：为何计算如此之慢？彼时使用数据库多数查询在亚秒级别返回，使用数仓多数查询在数秒级别返回，到 Hadoop 的大数据时代，大部分查询在数分钟、数小时、甚至于数天级别方才能够查询出结果。大数据、大数据，在一旦解决计算可处理的问题之后，时效性问题便摆上台面。

大数据领域下，时效性分为两个方面：

1. 数据从用户请求到最终呈现的实时性，这条路径强调的是请求响应的及时性。
2. 数据从发生到处理、并最终产生业务价值的全链路时效性，这条路径强调的是数据链路及时性。

前者我们称之为交互式计算领域，后者我们称之为实时（流）计算领域。交互式查询是技术方面的优化，是由于 MapReduce 计算模型太慢太落后进行的技术优化，和产品形态并无太大关联。而后者，则是整个大数据产品模型的变化，这是一种触发式计算，有点类似阿里云的 FunctionCompute，或者是 AWS 的 Lambda；或者更加准确地定义是：基于事件流的实时流计算。第一代计算引擎Mapreduce和第二代计算引擎Pig/Hive当前应用较少，我在这边不过多赘述，我们通常看到三个当前热门的流式计算引擎：

Storm

基本架构

Storm集群采用主从架构方式，主节点是Nimbus，从节点是Supervisor，有关调度相关的信息存储到ZooKeeper集群中。架构如下：

评价

Storm API 的 low-level 以及开发效率低下，这类基础大数据的 API 让业务人员参与编写业务逻辑好比登天。同时，Storm 的设计原则和其他系统大相径庭，Storm 更多考虑到实时流计算的处理时延而非数据的一致性保证。后者是其他大数据系统必备基础产品特征之一。Storm 针对每条流式数据进行计算处理，并提供至多一次或者至少一次的语义保证。我们可以理解为 Storm 不保证处理结果的正确性。

Spark Streaming

基本架构

Spark Streaming是将流式计算分解成一系列短小的批处理作业。这里的批处理引擎是Spark，也就是把Spark Streaming的输入数 据按照batch size（如1秒）分成一段一段的数据（Discretized Stream），每一段数据都转换成Spark中的RDD（Resilient Distributed Dataset ） ， 然 后 将 Spark Streaming 中 对 DStream 的 Transformation 操 作 变 为 针 对 Spark 中 对 RDD 的 Transformation操作，将RDD经 过操作变成中间结果保存在内存中。整个流式计算根据业务的需求可以对中间的结果进行叠加， 或者存储到外部设备。

简而言之，Spark Streaming把实时输入数据流以时间片Δt （如1秒）为单位切分成块，Spark Streaming会把每块数据作为一个 RDD，并使用RDD操作处理每一小块数据。每个块都会生成一个Spark Job处理，然后分批次提交job到集群中去运行，运行每个 job的过程和真正的spark 任务没有任何区别。

评价

相比于 Storm 的低阶 API 以及无法正确性语义保证，Spark 是流处理的分水岭：第一个广泛使用的大规模流处理引擎，既提供较为高阶的 API 抽象，同时提供流式处理正确性保证。

Flink

基本架构

下面我们介绍下Flink的基本架构，Flink系统的架构与Spark类似，是一个基于Master-Slave风格的架构。

当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager， JobManager 再调度任务到各个 TaskManager 去执行，然后 TaskManager 将心跳和统计信息汇报给 JobManager。 TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。

Client 为提交 Job 的客户端，可以是运行在任何机器上（与 JobManager 环境连通即可）。提交 Job 后，Client 可以结束进程 （Streaming的任务），也可以不结束并等待结果返回。

JobManager 主要负责调度 Job 并协调 Task 做 checkpoint，职责上很像 Storm 的 Nimbus。从 Client 处接收到 Job 和 JAR 包 等资源后，会生成优化后的执行计划，并以 Task 的单元调度到各个 TaskManager 去执行。

TaskManager 在启动的时候就设置好了槽位数（Slot），每个 slot 能启动一个 Task，Task 为线程。从 JobManager 处接收需要 部署的 Task，部署启动后，与自己的上游建立 Netty 连接，接收数据并处理。

评价

Flink 在 2015 年出现在大数据舞台，从产品技术来看，Flink 作为一个最新的实时计算引擎，具备如下流计算技术特征：

1. 完全一次保证：故障后应正确恢复有状态运算符中的状态
2. 低延迟：越低越好。许多应用程序需要亚秒级延迟
3. 高吞吐量：随着数据速率的增长，通过管道推送大量数据至关重要
4. 强大的计算模型：框架应该提供一种编程模型，该模型不限制用户并允许各种各样的应用程序在没有故障的情况下，容错机制的开销很低
5. 流量控制：来自慢速算子的反压应该由系统和数据源自然吸收，以避免因消费者缓慢而导致崩溃或降低性能
6. 乱序数据的支持：支持由于其他原因导致的数据乱序达到、延迟到达后，计算出正确的结果。
7. 完备的流式语义：支持窗口等现代流式处理语义抽象

你可以理解为整个实时计算产品技术也是时间发展而逐步成熟发展而来，而上述各个维度就是当前称之为成熟、商用的实时计算引擎所需要具备的各类典型产品技术特征。Flink 是当前能够完整支持上述各类产品特征参数的开源实时流处理系统。关于此，可以观看这篇文章《容错和高性能如何兼得: Flink 创始人谈流计算核心架构演化和现状》。

Flink、Storm和Spark Streaming三者综合比较

Flink的优势

从上面的对比可以看到Flink有如下的优势：

总结

宝剑锋从磨砺出，梅花香自苦寒来。