Flink

Apache Flink是一种为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架。

Storm（包括Storm Trident）和SparkStreaming（StructuredStreaming）也是两种著名的流处理框架。

Storm在设计之处是基于每条消息一次的模式的，因此提供了低延迟的流处理能力，但很难实现高吞吐，并且不能保证exactly-once的语义。

SparkStreaming/StructuredStreaming的设计则基于微批模式，因而可以实现较高的吞吐，

且可以保证exactly-once的语义，但通常在延迟性方面有所牺牲。Storm Trident的特性和SparkStreaming类似。

Flink的优势是，其在设计之初就是基于每条消息一次的流处理模式，将批处理视为特殊情况的流处理。

其可以在吞吐量、延迟、正确性方面都达到较高的标准。另外，其对事件时间/处理时间的处理能力也非常强大，

Spark的StructuredStreaming对时间的处理实际上是从Flink这里借鉴的。因此Flink是一门值得学习的技术。

在部署机制上，Flink支持单机版的Local模式，所有组件运行在单一JVM内。以及集群模式，

其中包括Flink自己管理各组件的Standalone模式，也可以跑在YARN等资源管理器上。另外也可以在云上运行。这些特性都和Spark高度一致。

Runtime层接收JobGraph并执行。JobGraph描述了并行执行的数据流，和Spark中的logical plan也很类似。

在API层面，Flink提供了DataStream和DataSet两类API，其中DataStream专门用于流处理，DataSet专门用于批处理，

但在底层执行逻辑上两者又复用了相同的代码。这两者可类比为Spark的SparkStreamingContext和SparkContext。

但需要注意和Spark的DataFrame/Dataset是不一样的，Spark的DataFrame/Dataset是高层/低层的两套数据结构API，并没有批/流上的区分。

最后，在Library层面，Flink的流API和批API都支持表和SQL，也提供了ML和图处理等能力，这和Spark也非常相似。

Flink中的执行资源是以任务槽位（Task Slots）定义的。每个TaskManager可执行一个工作流，具有1或多个task slots。

一个工作流包含多个前后相连的任务（task），例如MapFunction的n个并行实例，或ReduceFunction的n个并行实例。Flink通常会并行执行前后相连的tasks。

例如某程序有一个数据源、一个MapFunction、一个ReduceFunction，数据源和MapFunction的并行度为4，ReduceFunction的并行度为3。

一个工作流就由一条这样的Source-Map-Reduce组成。如集群有2个TaskManager，每个有3个slots。

在作业（job）执行过程中，由JobManager负责跟踪任务、决定何时调度任务、响应任务结束或执行失败的状态。

JobManager接收JobGraph，这可以理解为一种逻辑上的执行计划。

JobManager会将JobGraph翻译为ExecutionGraph，其是并行版本的JobGraph，决定了task最终以什么方式被并行执行。

在用户代码中，任何对操作符的调用都只生成JobGraph，而不会执行。只有显式调用execute方法后作业才会真正开始执行，这和Spark中遇到action才会执行的机制也是类似的。

Flink支持exactly-once的语义，这是通过对分布式数据流和操作符状态做一致性快照来实现的，也称为检查点机制（checkpointing，Spark中也有，但Flink的机制较为复杂）。

Flink分布式快照的核心概念是barriers。这些barriers被注入数据流并与记录一起作为数据流的一部分向下流动。barriers将数据流中的记录分为进入当前快照的记录和进入下一个快照的记录。

每个barriers都带有快照的ID，并且barriers之前的记录都进入了该快照。

barriers不会中断流的流动，非常轻量级。来自不同快照的多个barriers可以同时在流中出现，这意味着可以同时发生各种快照。