Flink On Yarn部署讲解

通过上节课的一些学习的话，我们了解了flink on standard low的这样的一种集群部署模式的一些原理，以及它的一些具体的实践的一些操作。从本节课开始的话，我们重点去了解一下flink on药的一些基本原理，以及它的一个实践的一个操作。首先我们先了解一下要的一个集群的一个架构的一个原理。对于做过大数据开发的这样的一些人员来讲的话，他其实对哈托普ER其实并不陌生。这个是作为我们整个大数据里面非常主流的这样的一个集群资源管理器。提供了这样的一套统一的一个资源管理和调度，以及我们的一个资源的一个操作。

我们在这样的一个过程里面的话，我们重点去了解一下这个杜比亚里面的话主要涵盖的几个核心的一些组件。这里面的话我们可以了解一下，首先哈多比亚里面的话有一个results manager的这样的一个组件。Resource manager其实也是我们整个一二集群里面的master的一个节点。它是主要是负责我整个集群资源的一个运维和一个调度。它是负责整个集群资源的一个管理和调度。与之相对应的有我们的一个node manager这样的一个进程节点。这个节点的话是负责每台机器上面的，就说每台具体的机器上面的这样的一个沃克的一些进程的一些管理，以及我们的一个运行资源的一个管理。整个的都比亚的集群的话也是属于master slave的这样的一种架构。

另外一个的话就是说在我们客户端这边的话，整个的话我们会把相应的这样的一个hadoop的一些APP去通过客户端的方式去提交到我们的resource manager上面去申请对应的这样的一个资源。这个资源一旦申请完毕了之后，他都会在node manager上面去。首先先启动我们的一个叫做application master的这样的一个组件。每一个应用的话，每一个提交一个这样的一个APP，它对应都会去启动一个application master，去负责管理每个任务内部的这样的一些资源的一些协调。对应的一个application master它本身也是会在我们的一个continue的这样的一个容器里面去启动。肯定的来讲的话，它其实是一个资源的一个抽象。分装了我们节点上的一个多维度的一个资源。比如说CPU内存和网络的一些资源。我们每肯定的比如说是1GB1核，或者说这样的一个内存的一个配置的话。它就会把对应的我们的这样的一个集群的一个服务去启动，在我们的node manager上面去提起来。

OK接下来的话，其实我们application master在这样的一个continuer启动完成了之后，我们就会在其他的节点上面，在continuer里面去启动对应的这样的一个task。然后去负责去完成我们application master交提交到对应的这样的一个具体的一个作业的一个执行。整个来讲的话都不一样话，其实就是按照这样的一个执行的一个流程上面去完成对应的这样的一个作业的一个一个执行，以及它的一个资源的一个分发。

OK我们来看一下我们在flink on your的这样的一种集群部署模式中。我们在session的这种部署模式里面的话，我们的flink如何去跟我们的都不要之间进行一个整合。我们可以看得到，对于我刚才在前面一小节里面提到的这样一个hadoop一个亚的一个架构里面，它涵盖了亚的一个resource manager，对应的是在我们的yr里面，如果去启动flink的这样的一个集群的时候，它也同样需要去申请我们的一个application master的一个管理界点。Application master一个管理节点其实就是跟我们flink的一个job manager本身是在一个进程里面去启动。整个的话这个application master跟我们的flink的job manager会绑定在一起。

然后当我们让我去提交的过程的话，我们可以看下。首先的话是我们客户端这边去通过flink session的这种模式的话，是提交我们对应的这样的一个APP。这个时候的话，通过session这种模式去连接到我们的亚的resource manager上面去。Resource manager这边接收到我们的客户端这边提交的这样的一个资源的一些申请的一些信息。这个时候的话，第二步的话是去启动我的一个hadoop r里面的application master。在这application master的话，他会把我job manager相关的一些这样的一个进程全部都提起来。这个启动的这个过程其实就是初始化我们flink的job manage的一个过程。当我的这个application master的节点启动完毕了之后，在这里面的话其实我们会在后面会重点去讲解。对于在欧亚的这种模式下面的时候，它有对应的这样的一个资源管理器和我们的这样的不同的这样的一个class management对应。

比如说在flink on yet的模式的话，我们在flink里面的话，它其实有一个叫做ER resource manager。它其实跟我们这样的一个不同的集群要的集群资源管理器其实是绑定的。比如说在K8S的时候，它有K8s resource manager。在standalone的时候，它有standalone的resource manager。这个地方的话，其实我们看到就是resource manager，就是yar resource manager OK另外一个就是dispatcher，他负责去接受我们客户端提交的一个任务。当我们整个的一个叫manager的进程全部启动完成了之后，下面一步的话其实就是接收我客户端这边提交的这样的一个job。Job提交到我们dispatch cher了之后，它会在内部去启动我们的一个具体作业对应的这样的一个job manager，也就是我们的job master。后面的话，他其实负责我们的一个具体的一个作业的一个管理。

当我们在application master的这样的一个节点的话，启动了所有的服务了之后，下一步的话，我接收到的这样的一个job，它就会拆分成不同的这样的一个task，去调度我的这样的一个task manager去运行。这个task manager其实我们前面也看到了。在昂亚的这种模式下，它其实就是我们的这样的一个不同的一个task。

对应的我们在flink on要的这种模式的application master的这样的一个管理节点，其实就是我们的一个job manager的一个节点。Task对的其实就是我们的一个task manager节点。整个下来的话，其实这样就是一个flink on娅的一个大概的一个集群部署的这样的一个架构。我们可以看得到在on亚的这种模式的话，它是支持native这样一种模式。Task manager它其实是一个动态的这样的一个启动的一个过程。也就是说当我job提交到我这个dispatcher了之后，我会根据我提交的这样的一个job再去启动我对应的这样的一个task manager。Task的manager启动完毕了之后，他才会去reject到我的这样的一个flink里面的一个叫manager这样的一个组件里面去。OK整个下来的话，其实就是我们的flink on yard这样session model的这样的一种集群的一个架构。

下面来看一下flink on Young里面poor job的这种模式。它最大的特点，前面我们其实已经讲到了，它整个的集群的话是独享job manager，以及独享我们的一个集群的一个wrong time。我们从图里面可以看得到，对于我客户端这边提交的这样的一个作业，去提交到我们的hato BR上面去申请资源的时候，那么resource manager这边的话首先先去启动对应的application master的这样的一个进场。Application master的话其实就是master节点里面，也就是我们的runtime所需要的一些组件的一些启动。里面同样也包含了flink的要resource manager进程，以及我们的job manager。

和session model不同的时候，我们可以看到对于application master里面的话，我们仅启动了一个drop manager的这样一个组件。对于我们在session model里面的话，其实启动了多个这样的一个job manager的一个组件。这个job manager其实根据我提交的这样的一个job的话，它其实是可以去比如说提交几个job。我们在这样的一个master节点，也就是我们整个的flink的管理节点的话，它其会启动多个这样的一个job my job manager的一个服务，然后去分别去管理我对应的这样的drop。对于application model的话，它其实只仅启动了一个这样的一个job manager去负责去管理它自己的一个作业。这也是我们做job模式的它的一个特点。

我们可以看得到的话，这里面的话，我们的这样的一个单个job manager，他其实独享了我们的flink里面的resource manager以及我们的其他的一些组件的一些服务。这样的话其实就是我们的一个pod rob的一个模式的一个特点。我们来总结一下，flink on your的一个优势与劣势。我们前面其实提到了两种部署的一个模式。我们来看一下它的一个主要优势，以及它的一个主要的一个劣势。

Flink on line的一个优势和劣势的话，我们可以总结一下。首先它的一个优势的话，我们认为它能够与现有的大数据平台进行无缝的一个对接。首先我们需要了解，我们在flink里面的话，目前能够支持的就是hadoop 2.4的以上的版本，包括2.4。对于2.4以下的版本，目前的话没有一个很好的一个支持。如果想将flink去部署在对应的一二的集群上面的话，首先需要去满足这样的一个版本的一个要求。也从另外一个方面上面去说到，就是说可以与现有的大数据平台进行一个无缝对接的话，就可以去避免去再重新去构建相应的这样的一个。资源管理器，也就是我们的class management，可以去利用现有的这样的一些平台去提供相应的一些计算资源。

另外一个优势的话是我们在部署的过程之中。我们后面在实践的课程里面会讲到，就是它的一个部署上面会非常的简单。任务的提交也相对比较简单。这也是它的一个优势和一个特点。OK. 

另外一个的话其实就是资源管理，资源管理就是它可以去统一的通过轧进行一个资源管理。我们在亚里面可以去提交不同类型的一些作业。比如说我们的以及比如说我们的storm等一系列的不同的这样的一些类型的作业，都可以通过统一的这样的一个要进行管理。这样的话其实可以提升我们整体的一个资源的一个利用的利用率OK。

另外一个的话就是基于native的这种方式。它其实task manager可以按需进行一个申请和启动。防止一个资源的一个浪费的一个情况。最后一点的话就是容错性的一个榜。后面我们其实会讲到在不同的这样的一个部署模式下面，如何去进行对flink的一个集群的一个高可用的一个保障。哈多布亚的话，它其实在这方面的话提供了相应的自动的一个firework的一个机制。它可以保证我的job manager，task manager它的一个异常恢复的一个市场。

我们讲完了这样的一个优势的话，我们来总结一下它它的一个主要的一个优势。劣势的话我们主要从几个方面。第一个的话就是说资源隔离的一个问题。首先我们hato BR里面其实如果是涉及到一些不同的一些作业。比如说离线的在线流式的作业的话，进行混合的一些调度的话。这个过程的话，其实对于网络这一块的话，其实没有进行一个非常充分的一个隔离。往往这种情况，比如说在夜间的话，我们会需要去跑一些离线的一些作业。这个离线的作业它可能会占用非常多的这样的一个带宽。

对于流式的这个作业的话，它可能是在需要去7乘24小时不断的降低去运行的。这个过程其实可能会有离线作业，会去干扰流式作业的这样一个治安的一个风险。这个的话其实我们需要去进行一些注意。

另外一个的话就是cobo s这一块，cobo s它其实有一个认证超期的一个问题。这个的话其实我们知道用hadoop平台的话，如果将一些copa s的认证打开了的话，你每次需要进行一个token的一个进行一个认证。这个认证的过程中的话，我们通常情况下通过写key type文件的方式进行认证。对于key type文件的话，它其实有一定的这样的一个认证的一个周期。这个周期的话可能会必须得时常进行一个review的一个过程。如果不进行review的这样的一个过程的话，这样的一个check point的它可能无法进行一个持久化的一个操作。就可能导致我的集群上面会有一些运行上的一些问题，这个其实也是一些劣势。讲完了前面的一些主要的一些理论上面的一些知识的话，我们来看一下我们在flink on on部署里面所涉及到的一些要点。

首先我们来看一下它的一个部署的几个主要的一个步骤。首先我们下载安装包，解压到单台的指令的一个节点。这个的话其实跟我们standard low的这样的一个集群部署，它其实是一样的。那么这个地方我们强调一点，就是说它只需要去在单台节点上去指定路径，也就是我们客户端去指定就可以了。这台节点有一个要求的话，就是说你杜比亚的这个版本的话，2.4以上同时在这台机器上面，你能够去操作HDFS的一些文件系统。另外一个的话，在节点上面，该节点的话需要去配置一个hadoop的一个config的这样的一个路径。这个路径的环境变量，这个环境变量的话需要去进行一个指定，同时我们在这个地方需要去强要一点，因为flink现在在自己的社区的1.1的版本以后的话就不再去支持。

我们在主版本里面去支持flink shed hadoop的相关的一些包。原来的话可以通过flink shit hadoop uber这样的一个包的话，可以获取到hadoop相关的一些依赖包。现在的话是需要用户这边自己去进行一个下载，以及我对应的或者说指定我们自己系统内部的一个hadoop class pass。获取我对应的hadoop相关的一些依赖包。这个地方我们把对应的下载的地址贴到这样的一个PPT里面。然后这样的话就可以通过这样的一个地址去下载相应的这样的一个hadoop依赖包。然后下载完成了这样的一个依赖包之后，需要去将对应的这样的一个依赖包放置在我们的一个安装路径里面的lib路径以下。这种情况的话，我们才能去操作hato p相关的一些包括HDFS。

然后哈杜比亚与哈杜比亚之间进行相应的这样的一个网络连接OK在flink on里面的话，我们再看一下，对于session集群启动的时候，我们通常使用到的是123上的这样的一个脚本。12 session启动的过程中，可以通过一些参数指令。比如说我们通过job manager去指定它的一个内存的一个大小。然后通过TM进行一个task manager的这样的一个内存的大小的一个指定。当然还有一些其他的很多的参数，我们可以通过执行一二三省点SH的这样的一个命令可以获取。

另外一个的话，对于我们的一个drop模式的一个启动，job集群模式的一个启动的话，我们通过flink run杠MER cluster，然后去指定它的一个YGM，以及我们的这样的一个需要去指定它的一个job manager的内存以及task manager的内存。同时在最后的话，我们需要去指定我们需要去提交的这样的一个作业的一个路径，以及我们可执行的这样的一个架包的一个路径。OK. 这个其实就是drop的模式的一个启动的一个过程。

另外一个的话就是我们的一个application model的这种启动。Application model的话，其实我们前面也介绍了它的一个特点，对应的是在药里面的话，我们也有相应的这样的一个启动的一个步骤。这个地方的话，我们是通过flink run application这样的一种参数然后去指定。如果是要的话，是它的一个杠T其实就是它的一个top去指定它的是一个样application OK下面的话其实它可以通过杠大地的这种方式，然后去指定它对应的具体在我们的应用里面的一些参数。比如说job manager的一些参数以及task manager的一些参数。

在这个里面的话，我们重点强调一点，就是说我们在application model的时候，在安亚的这种环境下面，它可以去直接通过从HDFS上面去拉取它的一个相应的一些集群的一些依赖包，以及我们的一些应用包。对于我集群的一个这样的一个依赖包的话，我们可以去直接去指定我们hadoop。我们可以把我们的下载的这样的一个安装包，直接传到我们的hadoop集群上面一个指路径里面来。然后我们去指定我们的flink的一个安装在HDFS上面的一个路径。这样的话，其实我们的flink相关的一些依赖包，就不需要再从我们的客户端去传到我们的一个服务器上面去，然后再去执行。另外一个，对于我们自己写的application的下包的话，我们可以通过本地的方式，也可以通过给定HDFS的方式，直接从HDFS分布式存储里面去获取。这个其实就是养application model。

总结一下，我们三种启动的模式的话，都有就是三种集群的一个启动。首先123上集群启动drop模式，application model的这样的一种集群的一个启动。OK通过本节课的学习的话，我们基本上了解了flink on your的政务集群部署模式的条件下的一些基本原理，以及相应的一些部署的一些流程和一些要点。下节课的话，我们将通过一些具体的实践的操作，来帮助你加深对flink on娅集群部署模式的一个了解。