Flink的计算方式

首先看一张来自官网的Flink运行时架构图

管理抽象：
JobManager (Master) ：负责调度任务执行、负责指挥进行检查点、负责任务失败容错恢复等。
TaskManager (Worker) ：负责具体任务的执行、缓存和交换数据流等。
每个管理者都对应着独立的JVM进程。

执行抽象：
Task，本质上都回归到线程执行具体的task。

我们先不论资源管理框架。可以看到，资源被划分为细粒度的Slot。Flink Job也跟Spark Job一样，均以Task为计算单元。

每一个task均由一个线程来运行。在默认的情况下，Slot的数量是和分配的cpu核数相对应。

然后再看下一张图

虚线框内，Flink会（可以）将source/map/flatMap/filter等操作，组合成操作符链，作为一个task。同一操作符链内的算子其实很像Spark里边窄依赖的概念。

由这两张图，其实就可以总结出Flink的计算模式是长运行的连续运算符的计算模式。

之前接触的比较多的是Spark，对Flink很少了解，但越了解越感觉到Flink的强大，也可能是了解的不是很多，到现在也没发现Flink实时处理哪个地方比Spark流处理弱。

这里边我们应该很自然地提出一个问题，既然操作符operator会组成链条（我们可以称之为连续运算符），为什么不所有算子组成统一的一个链条？

我认为这个问题的答案应该基于以下几点
第一：就此图来讲，我们可以看到chain的分界，不同chain之间存在着数据依赖，更准确地说是下游算子依赖上游算子。chain的划分和Spark stage的划分精髓神似。
第二：状态管理，Flink具有强大的内置状态管理能力，每个chain的结果都是一个State，这个State跟分布式快照、容错、exactly-once能力息息相关。
第三：总结来说，这样一来方便了分布式的数据交换、管理，正好也为检查点、容错提供了状态数据基础。

就任务执行这一层面，我们来看看和Spark的不同：
第一：Spark面向stage调度，将stage之间构成DAG，stage之间存在这明显的宽依赖关系。Flink可以说是面向运算符链条chain的调度，chain之间也存在这数据依赖关系。这一点如果我们从本质上去看的话，他们大致是相同的。
第二：对于Spark微批模型，每个批次都对应着各stage中任务启动开销，简单来讲就是每个批次的数据过来，任务都需要重新启动。而Flink并没有这个额外开销，这也是Flink在延迟方面战胜Spark微批处理的关键点。

Spark和Flink接触了任意一个，再去学另一个，是很有意思并很容易懂的。大数据计算的本质就是分治，无论哪个框架都脱离不了这个核心。

本文及之后的文章更多的倾向于个人总结的观点了，如有问题，还请看到的小伙伴指正。