spark 和 flink 的对比

一、设计理念

        Spark 的数据模型是 弹性分布式数据集 RDD(Resilient Distributed Dattsets)，这个内存数据结构使得spark可以通过固定内存做大批量计算。初期的 Spark Streaming 是通过将数据流转成批 (micro-batches)，即收集一段时间(time-window)内到达的所有数据，并在其上进行常规批处理，所以严格意义上，还不能算作流式处理。但是 Spark 从 2.x 版本开始推出基于 Continuous Processing Mode 的 Structured Streaming，支持按事件时间处理和端到端的一致性，但是在功能上还有一些缺陷，比如对端到端的 exactly-once 语义的支持。

spark DAG示意图：

        Flink 是统一的流和批处理框架，基本数据模型是数据流，以及事件 (Event) 的序列，Flink 从设计之初秉持了一个观点：批是流的特例。每一条数据都可以出发计算逻辑，那么 Flink 的流特性已经在延迟方面占得天然优势。

一个典型的 Flink workflow 示意图：

 

        Flink 还提供了一个独特的概念叫做 有状态的计算，它被用来处理一种情况：数据的处理和之前处理过的数据或者事件有关联。比如，在做聚合操作的时候，一个批次的数据聚合的结果依赖于之前处理过的批次。早期的Spark用户会经常受此类问题所困扰，直到Structured Streaming的出现才得已解决。

总结：

1、Spark的技术理念是使用微批来模拟流的计算,基于Micro-batch,数据流以时间为单位被切分为一个个批次,通过分布式数据集RDD进行批量处理,是一种伪实时。

2、Flink是基于事件驱动的，是面向流的处理框架, Flink基于每个事件一行一行地流式处理，是真正的流式计算. 另外他也可以基于流来模拟批进行计算实现批处理。

二、架构方面

1、Spark在运行时的主要角色包括：Master、Worker、Driver、Executor。

 

2、Flink 在运行时主要包含：Jobmanager、Taskmanager和Slot。

三、任务调度

1、Spark Streaming 连续不断的生成微小的数据批次，构建有向无环图DAG，根据DAG中的action 操作形成 job ，每个job有根据窄宽依赖生成多个 stage 。

2、Flink 根据用户提交的代码生成 StreamGraph，经过优化生成 JobGraph，然后提交给 JobManager 进行处理，JobManager 会根据 JobGraph 生成 ExecutionGraph，ExecutionGraph 是 Flink 调度最核心的数据结构，JobManager 根据 ExecutionGraph 对 Job 进行调度。

四、时间机制

1、Spark Streaming 支持的时间机制有限，只支持处理时间。使用processing time模拟event time必然会有误差， 如果产生数据堆积的话，误差则更明显。

2、flink支持三种时间机制：事件时间，注入时间，处理时间，同时支持 watermark 机制处理迟到的数据,说明Flink在处理乱序大实时数据的时候,更有优势。

五、容错机制

1、SparkStreaming 的容错机制是基于RDD的容错机制，会将经常用的RDD或者对宽依赖加Checkpoint。利用 SparkStreaming 的 direct 方式与 Kafka 可以保证数据输入源的，处理过程，输出过程符合 exactly once 。

2、Flink 则使用两阶段提交协议来保证 exactly once 。

六、吞吐量和延迟

1、spark是基于微批的,而且流水线优化做的很好,所以说他的吞入量是最大的,但是付出了延迟的代价,它的延迟是秒级;

2、而Flink是基于事件的,消息逐条处理,而且他的容错机制很轻量级,所以他能在兼顾高吞吐量的同时又有很低的延迟,它的延迟能够达到毫秒级;