Flink集群架构

在上一章节我们对flink有了一个基本的了解。从它的应用的场景以及它的一些基本的一些核心的一些概念。从本章节开始，我们对flink从它的一个集群的一个架构以及它的一个部署模式着手，去了解flink如何去部署在不同的这样的一个集群的一些资源管理器上面，以及相应的一些原理的一些解析。本节课开始我们了解一下flink的一个集群的一个基本的架构，了解里面核心的一些组件，比如说drop manager，task manager以及job graph等一系列的这样的一些集群的一些组件的一些架构。

我们首先来看一下flink整个的一个集群的架构的一个组成。我们flink的集群整个也是遵循了一个master worker的这样的一个集群的架构模式。有管理节点和worker节点、工作节点组成。我们管理节点的话主要叫做job，工作节点的话叫做task manager。管理节点来讲，job manager主要是负责整个集群的一个管理，包括一些集群资源的管理，以及job的的一些调度和执行，以及我们的point。后面会讲到check point的一些协调性的一些工作。

Task manager的话主要是负责整个集群资源的一个提供。包括每个task manager会部署在不同的这样的一个主机，或者不同的这样的一个计算节点上面。然后通过去提供相应的这样的一个计算资源，然后让job manager这边协调我们客户端这边提交那些任务，然后进行相应的一个执行。

对于我们客户端来讲的话，他是负责去接收我用户提交的这样的一个application的一个价。我们的application价最终会通过flink的一些命令行的方式去提交给我们的客户端。这个客户端的话会在自己的本地内部去产生一个job graph的一些对象。然后再通过job官费的一个提交到job manager上面，中间是通过RPC的形式，然后去提交到job manager上，面对job进行一个调度。此时如果成功提交了之后，会返回给我们的客户端一个job client。这个job client可以用作和job manager之间进行一个通信，然后获取我们job的一个执行的一个状态。

整个过程下来的话，其实就可以看到通过从用户这边提交作业，然后提交到客户端上面去生成job graph的一个对象。然后再提交我们的job manager，然后再拆分成不同的这样的一个运行在task manager中。这其实就是我们整个的一个flink的一个整个的一个集群的一个架构。

我们来看一下job manager。Job manager其实刚才已经讲到，他是负责整个集群的一个资源的一个管理，以及相应的一些调度的一些工作。它其实里面主要有几个部分的一个组成。第一个就是在整个job manager里面的话，它会负责我们的第一个check point的一个协调。Chat point对我们后面会讲到，对于我们在容错方面，它会通过文件检查点的方式去记录我们的一些状态性的一些数据。在job manager其实就是负责我们每个task manager里面的job check point的一些协调和一些执行。

另外一个的话，其实我们对于客户端提交的这样的一个job graph的一个对象。它会在job manager里面会生成对应的这样的一个SQ tion graphing。它其实是一种物理执行逻辑图。对于招花费来讲的话，它其实只是描写了这样的一个逻辑性的逻辑图。对于SQ tion graph，它其实会拆分成不同的这样的一个执行单元，去去提交到我们对应的这样的一个task manager上面。

另外一个的话就是我们在整个job manager里面的话，它会将对应的这样的一个task拆分成不同的task，去部署到我们的task manager上面去运行。这时候的话，其task manager跟draw manager进行交互的话，其实就是通过task这样的一个对象进行一个交互。OK另外一个的话就是对于RPC的这一块的一个通信的话，照manager跟task manager之间的通信，以及跟我们的客户端之间的一个通信。都是通过基于阿卡实现的这样的一个RPC通信的一个，远程近程的一个调用。这里面的话，阿卡里面最核心的其实就是一个actor system这样的一个组件。Actor system它其实负责和我们云端的这样的一个进程之间进行相互之间的一个通信。

另外一个的话，其实对于job的一个接收这一块，client端这边的话会提交不同的这样的一个job到job manager里面。Job manager后面我们会讲到，它其实里面还有一个叫job dispatcher的这样的一个组件。它会负责接收我们clients这边提交job graph的一个对象，然后去分拆成不同的这样的一个作业去提交到task manager。这个其实就会涉及到一个drop的一个分发的一个过程。

最重要的一点的话，其实对于job manager里面，它其实也提供了一个叫做resource management这样的一个组件的一个服务。Job management跟它的一个字面意义其实就是我们的一个资源管理器。对于不同的这样的一个resource manager，它其实是有相应的不同的一个实现。比如说如果我们是on stand a的集群，或on k8S或者on yard的集群的话。它不同的这样的一个集群部署模式。它其实有相应的这样的一个resource manager的一个实现。

另外一个的话，它会管理我们的一个task manager的一个注册。当我外围去启动一个task manager，他会主动会向我们的job manager进行一个RPC的一个远程的一个connection的一个注册。这个注册的这个过程，它会在job manager里面去将对应的task manager信息维系在自己的本地。然后并时刻不断的去进跟task manager之间进行一个heart beat的一个操作。整个过程其实就看下来，这是整个的一个job manager的一个主要的一个作用。

对于task manager来讲的话，他其实刚才已经提到对于负责我们具体的一个task的一些执行。它和job manager进行相应的这样的一个交互。当job manager去部署对应的这样的一个task到我们task manager上面去运行的时候，对于task的话，task manager里面的话，它会提供相应的这样的一个task的一个slot的一个资源卡槽。

对应的在我们通过一个计算机的模式去理解的话。我们task manager如果是GVM的一个进程的话，对于我们里面的这个task slot的一个资源池的话，它其实是一个thread poll，其实就是一个线程池。线程池里面的话，提供不同的这样的一个计算资源的一个线程。当我们用当job manager去提交相应的这样的一个task，到账task manager里面之后，它会在不同的这样的一个起不同的这样的一个task的一个线程。也就是我们的task slot，去将我们提交的这样的一个task运行起来。对应的这样的一个task，它其实会在后面我们会讲到，它其实就是不同的这样的一个，执行的一个Operator的一些节点的一些组合OK。

整个task的manager里面还有其他的一些模块。比如说对于我们的一个date exchange，就是我们的数据交互这一块。其实相当到我们在做做mapreduce或者做Spark程序的时候，它其实会涉及到一些shufu的一个过程。Shufu的这个过程的话，它其实就是一个数据在不同的这样的一个节点之间进行传输和交互的这样的一个过程。对于我们在flink内部也一样，如果数据比如说进行了一个group by key，或进行了这样的一个分组分区分组的一个操作。这个的过程的话，它其实就会涉及到我们的一个数据的一个交互。在task manager里面它会提供相应的shuffle environment，去提供我们的一个shufu的一些进行数据交互的一些组件OK另外一个的话其实是我们的一个也是一个RPC的一个通信。RPC里面的话也是通过基于阿卡system actor system进行相应的这样一个PC的一个远程的一个通信。

对于我们在刚才提到的这个数据交互这一块，它有对应的这样的一个network manager。也就是network manager这一块的一个网络的一个数据交互的话，是基于net去实现的这样的一个数据交互。所以对于我们节点和节点之间进行RPC通信是基于R卡实现。对于我们task manager和task manager节点和节点之间进行数据交互的话，是我们通过零也有一个network manager提供了基于net实现的这样的一个网络通信进站，也叫做net stack网络栈，去实现了这样的一个数据的一个网络传输OK另外一个的话，其实在task manager里面的话，它其实会实现一个management。这个地方其实也是我们后面会再去讲到内存管理这一块，就是会进行一些序列化和反序列化的一些操作。

当我们把相应的task提交进来了之后，势必就会接受外围传输进来的一些数据。这些数据会到我们的一个task manager去申请对应的这样的一个存储的一个内存的一个单元。这个内存的一个单元的一个管理的话，其实就是在我们task manager进行相应的这样一个管理操作。OK另外一个的话，其实对于刚才已经提到我们task manager启动完毕了之后，他会向我们的job manager进行一个注册的一个操作。另外一个的话比较重要的就是当我们用户作业提交完成了之后，照manager这边的话会向我们对应的这样的一个task manager去申请对应的smart的一个资源。当资源申请完毕了之后，对于task manager来讲的话，他会把我们申请的一个smart ts去提供给我们的一对应的job manager上面进行一个执行。这些其实就是整个我们task manager所提供的所有的一些功能。

对于我们client来讲的话，client其实就是我们的一个客户端。Client其实有很多，如果是没有接触过flink的同学来讲的话，可能我们大概介绍一下。比如说用户这边的话，我们自己去写了一个flink的一个程序。不管是你用java a还是scala或者说python写的，或者说用flink circle去写的这样的一个APP。它其实最终的话都会通过类似于flink比比比如说count jr然后后指一个host name等于于等于这种方式去提交到我们的一个集群上面去运行。

在用户去执行这样的一段命令的这个过程中话，其实会在我们的一个本地启动相应的这样一个client的一个进程。这个client的进程的话就负责会解析我们用户提交的这样一个what count的一个价。然后把word count架里面的may方法拿出来了之后，在自己的进程里面进行一个执行。这个执行的这个过程的主要的一个作用的话，其实就是生成这样的一个job graph的一个对象。Jump花费的对象，我们后面会进行相应的这样的一个介绍。它其实就是对于我这样的一个application里面的这样一个code的一个表达，一个deg方式的表达。也就是有像五环图的这种方式的一个表的。

在client里面的话，还有几个比较核心的一个概念。比如说对于contest environment。我们其实了解到在我们用户去编写相应的这样的一个flink程序的时候，它其实会首先第一步其实就是先要去创建对应的这样的一个execution environment。在clients里面的话，它其实有对应的这样一个contest environment。也就是说我们其实是在flink的client里面的话，也会去创建相应的这样的一个执行的一个环境，然后去调用我们对应的这样的一个应用的一些主方法。然后再去把它的一个程序进行一个执行，生成对应的这样的一个drop花费的一个对象OK。下一步的话，其实对于我job花费，如果一旦生成了之后，下面的话对于client的话，其实它它会进行一个drop mmt过程。

Drop some meat的过程的话，它会涉及到几个部分。第一个部分的话，其实就是对于我job挂费的一个提交。Drop话费提交到我们的一个jump manager上面去进行一个调度和执行。另外一个的话，其实对于我们client端的话，它会将我们提交的这样的一个作业所依赖的一些包。比如说一些价包，比如说用户提交的这样的一个work count的价的话，它其实会把这dependency的价包去说不到我们的一个drop manager上面。这期间话也是通过RPC的这种方式，把相应的这样的一个架包，以及相应的这样的一个drop grade的对象全部都传递到我们的job manager里面去。这个其实就是一个相当于说是一个静态编译的一个过程。

然后在drop manager上面其实就是一个动态执行的一个过程。所有的这样的一个作业的一些生成，包括一些tag的构建，以及我们的一些作业图的一些生成的话，都是在我们客户端里面一步进行完成。它其实跟我们job manager进行交互的话，都是通过统一的这样的一个标准的方式OK然后另外一个的话，对于我们客户端后面我们会讲到，在如果是在讲那个原理的时候会讲到，就是它其实也有一个叫做cluster deploy的一个过程。比如说我们启动要session或cobi ties session等类似于这样的一些集群的时候。它其实也是通过客户端端里面那些方法去进行对应的集群的一些部署的一些操作。所以说整个下来的话，其实这些都是一些客户端的一些主要的一些核心的功能点。

OK. 刚才其实提到了对应我们的应用程序里面会最终会生成一个drop graph，提交到我们drop manager里面。这个job graph y究竟是什么样的？我们再通过下面这样的一个图形给解释一下。对啊啊，那么我们通过下面这张图进行相应的这样的一个解释。

首先其实我们看到左边对于我不同的一这样的一个用户可能提交的不同的这样类行的一个作业。比如说我们可以通过data a stream API或data set API以及flink circle，以及推报API去写的相应的这样一个程序。它最终都会要去达成相应的这样的一个架包。当然这个也并不是唯一的方式。比如说我们还有后面讲到的circle client这种模式，可以直接去向我们的这样的一个客后端去提交相应的一些circle的一些脚本。但是大部分的情况下都是通过类似这种方式去达成一个可执行的一个架包。

在调用flink round的一个命令去执行，在客户端里面的话，其实我们会看到有几个主要的一个步骤。第一个步骤的话就是我们先通过反射的这种方式去调用我们对应的这个application里面的一个may方法。这个其实也如过去写过flink的程序的用户来讲的话，他其实是在提交作业的时候，需要去指定的我的一个main class。Main class里面的话，其实就必须得包含一个may方法。这个其实就是在这个地方会用到。这个其实就是我们整个application里面的一个code的一个执行。在我们的client里面的话，它其实有一个另外一个比较核心的一个组件叫做s cute or。Scuta的话其实就是我们的一个执行器。

执行器的话，它其实也会分为几种类型。比如说本地执行行器，远程执行器以及我们的on your的就有压的执行器。这个的话我们会在后面原理的这个章节里面会讲解它的一个执行器的一个组成。

然后这里面的话我们就讲到这个执行器的一个通用的一个功能。它就是第一步先执行我这样的一个应用的一个程序，把它拉起来。然后在自己的这样的一个进程里面，去通过这样的一种把应用程序进行在本地进行一个运行。

接下来的时候会调用我们整个应用程序里面的一个s cute or的一个方法。SQ的这个方法的话，它其实是把我们前面写到的这样的一个程序。如果比如说用data stream写的这样的一个APR写的话，它其实会产生一个streaming graph的这样的一个对象。也就是说把我们data stream中间转换的一些transformation去转换成对应的这样的一个stream graph出来。然后下面一步的话是把对应的stream graph转成job graph的一个对象。这个drop graph的一个对象转换成功了之后，再去进行一个submit到我们job manager里面的一个dispatcher的一个组件。这两个组件之间进行一个这样的一个通信。

对于我的一个stream graph和job graph之间的一个转换的话，我们可以通过这张图上面可以看得到。首先这个stream graph它其实仅是表述了我们的一个转换的一个大概的一个逻辑。比如说有source sink中间有transform，然后进行一个k bar的一个操作，然后再进行一个think的一个操作。它其实是一个dad flow的一个表述，但是它并没有相应的这样的一个并发的一些描述能比。

比如说我们在进行一个转换的一个过程中的话，它其实会进行一个比如说我们指定对于每一个算子的一个并行度。那么这个并行度它会拆解成，比如说我们的一个map的一个算子，可能会拆解成两个这样的一个执行的一个实例，或者说进行拆解成对应的这样的一个并行度出来。这个并行度最后的话是把这样的一个tag，也就是说我们这样的一个有向无环图，也就是我们的job graph的这样的一个对象去提交到我们的集群上面，进行对应的这样的一个调度与运行。这里面的话，每一个其实都是对应的这样的一些算子。这些算子的话如何去执行的话，都是通过我们的job manager的一个调度去调到我们的一个task manager上面去运行。整个来讲的话，其实我们的一个job gravy的话就是涵盖了这么多的一个步骤。

我们总结一下这个job graf的话，它其实是第一就是通过有向无框图，也就是dig的方式去表达我们的一个用户程序。另外一个的话，它其实是不同接口程序的一个抽象表达。我们提交不同的接口，比如说通过不同的一些data am APR或flink circle去提交的这样的一个程序。它最终都会转换成这样的一个统一的一个标准去提交到我的一个集群。这种做法的话，其实就可以去和我们的整个的一个客户端，以及我们的一个服务端进行相应的这样的一个功能上面的一个划分。另外一个的话就是对于我们在后面会讲到不同的集群的一个部主模式。

上面的话。我们会讲到我们在client端的时候，这个SQT的一个执行，以及我们的main方法的执行，会逐步的去移到我们的一个job manager里面去执行。就是我们的后面讲到的一个application model，这个地方我们就不再展开。

通过本节的学习，我们基本上了解了flink的集群的一些基本的一些架构。里面包含了一些像job manager、task manager以及climate的一些组成的一些部分。下一节我们讲flink在集群部署里面提供了不同的这样的一个集群的一个部署模式。