Spark与Flink对比

Spark缺点
无论是 Spark Streaming还是 Structured Streaming,
Spark流处理的实时性还不够,所以无法用在一些对实时性要求很高的流处理场景中。
这是因为 Spark的流处理是基于所谓微批处理( Micro- batch processing)的思想,即它把流
处理看作是批处理的一种特殊形式,每次接收到一个时间间隔的数据才会去处理,所以天生很难在实时性上有所提升。
虽然在 Spark2.3中提出了连续处理模型( Continuous Processing Model),但是现在只支持
很有限的功能,并不能在大的项目中使用。 Spark还需要做出很大的努力才能改进现有的流处理模型想要在流处理的实时性上提升,就不能継续用微批处理的模式,而要想办法实现真正的流处理即每当有一条数据输入就立刻处理,不做等待。
Flink
采用了基于操作符（Operator）的连续流模型，可以做到微秒级别的延迟。
Flink 核心模型简介
Flink最核心的数据结构是Stream，它代表一个运行在多分区上的并行流。
在 Stream 上同样可以进行各种转换操作（Transformation）。与 Spark 的 RDD 不同的是，Stream 代表一个数据流而不是静态数据的集合。所以，它包含的数据是随着时间增长而变化的。而且 Stream 上的转换操作都是逐条进行的，即每当有新的数据进来，整个流程都会被执行并更新结果。这样的基本处理模式决定了 Flink 会比 Spark Streaming 有更低的流处理延迟性。
当一个 Flink 程序被执行的时候，它会被映射为 Streaming Dataflow，下图就是一个Streaming Dataflow 的示意图。

在图中，你可以看出Streaming Dataflow 包括Strea