flink架构介绍

前言

flink作为基于流的大数据计算引擎，可以说在大数据领域的红人，下面对flink-1.7的架构进行逻辑上的分析并和spark做了一些关键点的对比。

架构

如图1，flink架构分为3个部分，client，JobManager（简称jm）和TaskManager（简称tm）。client负责提交用户的应用拓扑到jm，注意这和spark的driver用法不同，flink的client只是单纯的将用户提交的拓扑进行优化，然后提交到jm，不涉及任何的执行操作。jm负责task的调度，协调checkpoints，协调故障恢复等。tm负责管理和执行task。通过flink的架构我们可以了解到，flink把任务调度管理和真正执行的任务分离，这里的分离说的是物理分离。而对比spark的调度和执行任务是在一个jvm里的，也就是driver。分离的好处很明显，不同任务可以复用同一个任务管理（jm，tm），避免多次提交，缺点可能就是多了一个步骤，需要额外提交维护tm。

 

图1 架构

flink架构中另一个重要的概念是slot，在tm中有一个slot的概念，这个概念类似storm里的slot，用来控制并发度的，但不同于storm，flink的slot控制的是线程。首先1个tm对应1个jvm，然后并发度task对应一个线程，而slot就代表1个tm中可以执行的最大的task数。此外，task被tm管理，但是目前只会对内存进行管理，cpu是不做限制的。建议slot的数量和该节点的cpu数量保持一致。

部署策略

flink支持多种部署策略，独立部署模式或者基于其他资源容器yarn，mesos。

standalone

不依赖第三方资源容器进行部署，部署相对麻烦，需要将jm，tm分别部署到多个节点中，然后启动，一般不建议单独部署。

yarn

基于yarn的部署是比较常见的，flink提供了两种基于yarn的提交模式，attached和detached。无论是jb和tm的提交还是任务的提交都支持这两种模式。和spark基于yarn的两种模式不同，flink的这两种模式仅仅只是在client端阻塞和非阻塞的区别，attached模式会hold yarn的session直到任务执行结束，detached模式在提交完任务后就退出client，这个区别是很简单的。结合flink的架构来看，client不参与任何任务的执行，这点和spark是有很大区别的，不要搞混。

调度

flink同样采用了基于图的调度策略，client生成图然后提交给jm，jm解析后执行。但是flink的对task的执行思路和spark不同，spark是基于一个操作的并发，而flink是基于操作链的并发，这里先解释一下操作链，比如source(),map(),filter()这些都是操作，操作链就是多个连续的操作合并到一起，如图2，source(),map()形成一个操作链，keyBy(),window(),apply()[1]形成一个操作链。flink这样设计的目的在于，操作链中的所有操作可以使用一个线程来执行，这样可以避免多个操作在不同线程执行带来的上下文切换损失，并且可以直接在一个jvm中共享数据，这个思路可以说是一种新的优化思路。图3可以从一个任务的角度看到flink的并发思路。

 

图2

 

图3

总结

从架构上来看，flink也采用了常见的主从模型，不过不用担心flink已经支持了对jm的ha，很多地方可以看到其他大数据计算引擎的影子，在选择计算引擎的时候可以尝试一下。

参考

// flink官网对分布式执行环境的介绍

https://ci.apache.org/projects/flink/flink-docs-release-1.7/concepts/runtime.html

// flink官网对调度的介绍

https://ci.apache.org/projects/flink/flink-docs-release-1.7/internals/job_scheduling.html