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