Flink部署集群整体架构源码分析

目录
  • 概览
  • 部署模式
    • Application mode
      • 客户端提交请求
      • 服务端启动&提交Application
    • session mode
  • Cluster架构
    • Cluster的启动流程
    • DispatcherResourceManagerComponent
      • Runner代码
      • HA代码框架
  • 总结

概览

本篇我们来了解Flink的部署模式和Flink集群的整体架构

部署模式

Flink支持如下三种运行模式

运行模式 描述
Application Mode Flink Cluster只执行提交的整个job,然后退出;main方法在cluster中执行;支持yarn和k8s;官方建议yarn和k8s上的运行方式
pre-job mode Flink Cluster只执行提交的整个job,然后退出;main方法在client中执行;支持yarn;官方建议yarn上运行方式, 该模式在Flink 1.15中被废弃了,建议用application mode
session mode 支持在一个Flink Cluster中提交多个任务;main方法在client中执行;支持yarn和k8s

Flink的部署步骤分为如下2步:

  • 部署启动一个Flink Cluster,负责接收job提交请求和管理job信息;
  • 向Flink Cluster提交job; 根据Flink Cluster可以运行的任务的数量(1个或多个)和提交job请求的地点(远端或Cluster端)的不同,从而有了不同的运行模式。由于pre-job模式已经被废弃了,下面我们主要来学习下Application mode和session mode

Application mode

Application mode是Flink Cluster运行1个job,提交任务的地点为Cluster端。其提交方式如下

./bin/flink run-application -t yarn-application ./examples/streaming/TopSpeedWindowing.jar

其处理流程为,客户端提交部署请求,服务端启动Flink Cluster, 服务端运行Flink Application提交Job到Cluster。下面我们分析下具体实现细节。

客户端提交请求

通过flink命令提交请求,其运行的类为CliFrontend。为支持部署到不同的资源管理平台,所以有和对应资源管理系统交互的类,具体如下:

  • CliFrontend:flink命令对应的类,发起提交请求,后面session mode的提交Flink Application也是由该类负责
  • ClusterClientFactory:集群客户端工厂类,负责生成不同资源管理平台的客户端
  • ClusterDescriptor:负责和对应的资源管理平台交互,申请资源和提交请求
  • ClusterEntrypoint:在资源管理平台运行的类,启动Flink Cluster。 针对不同资源管理平台的对应实现类如下:
接口类 yarn kubernates
ClusterClientFactory YarnClusterClientFactory KubernetesClusterClientFactory
ClusterDescriptor YarnClusterDescriptor KubernetesClusterDescriptor
ClusterEntrypoint YarnApplicationClusterEntryPoint KubernetesApplicationClusterEntrypoint

服务端启动&提交Application

服务端启动对应的ClusterEntrypoint,其中会启动一个REST Server来接受提交Flink Application,另外有个Dispatcher负责作业的调度,其他部分后面我们分析运行流程时再展开介绍。作业的提交请求是在Dispatcher中的DispatcherBootstrap属性实例化的时候触发。 Flink Application运行时,是在StreamExecutionEnvironment.execute()方法来触发实际提交,提交相关的调用链如下:

这几个都是接口类,在Application模式下对应的实现类如下

接口类 实现类
PipelineExecutorServiceLoader EmbeddedExecutorServiceLoader
PipelineExecutorFactory EmbeddedExecutorFactory
PipelineExecutor EmbeddedExecutor

session mode

session mode是一个Flink Cluster可以来运行多个Flink job。那这里的提交会分为2个步骤

// 提交启动session cluster
// yarn session
./bin/yarn-session.sh --detached
// kubernates session
./bin/kubernetes-session.sh -Dkubernetes.cluster-id=my-first-flink-cluster
// 提交job
./bin/flink run ./examples/streaming/TopSpeedWindowing.jar
  • 通过yarn-session.sh (或kubernates-session.sh) 来提交部署Flink Cluster,这块和前面application mode类似,以yarn模式为例,底层也是调用了YarnClusterDescriptor来提交相应的请求,提交到服务器的是YarnSessionClusterEntrypoint类。
  • 提交Job,这块是在client端来单独提交的,直接提交信息到服务器的REST Server,根据提交的目标资源管理系统的不同,使用了不同的实现类
接口类 实现类yarn 实现类kubernates
PipelineExecutorServiceLoader DefaultExecutorServiceLoader DefaultExecutorServiceLoader
PipelineExecutorFactory YarnSessionClusterExecutorFactory YarnSessionClusterExecutorFactory
PipelineExecutor YarnSessionClusterExecutor KubernetesSessionClusterExecutor

Cluster架构

Flink是一个Master/Worker的架构,Master节点负责整个任务的管理,Worker节点负责执行对应的任务。其整体结构如下:

* JobManager: Master节点的统称,目前版本没有该类,其中有几个重点的服务,如上图所示,目前的代码中对应的组合了这些服务的类为:

Dispatcher

ResourceManager

Component。

* Dispatcher: Job调度器,负责接收Job的提交,保存Job和管理JobMaster来执行作业。前面我们提到的提交作业到Cluster,实际上是提交给了Dispatcher的。

* ResourceManager: 负责和不同的资源调度系统交互,管理资源申请。

* WebMonitorEndpoint: 负责web界面的Rest请求处理

* JobMaster: 负责运行单个JobGraph,包括TaskManager的管理,任务的调度等。

* TaskManager: 负责任务的执行,也没有TaskManager的类,对应的类为TaskExecutor,来执行多个Task

说明:JobManager可能是原来的JobMaster,具体通过Dispatcher.java的如下代码可以看出,重点在对其具体结构的理解,这个变化的逻辑我们就不考究了。

 private JobManagerRunner createJobMasterRunner(JobGraph jobGraph) throws Exception

Cluster的启动流程

上面介绍了Cluster的整体架构,接下来我们看看Cluster的启动流程。以Application mode部署到Yarn为例(其他模式的启动类似,只是启动的主类不同)。该方式下的主类为:YarnApplicationClusterEntryPoint,其内部调用了ClusterEntrypoint的方法,最终是通过ClusterEntrypoint类的runCluster()方法来创建DispatcherResourceManagerComponent对象。

DispatcherResourceManagerComponent

接下来我们看看DispatcherResourceManagerComponent中的具体属性信息

    @Nonnull private final DispatcherRunner dispatcherRunner;
    @Nonnull private final ResourceManagerService resourceManagerService;
    @Nonnull private final RestService webMonitorEndpoint;
    @Nonnull private final LeaderRetrievalService dispatcherLeaderRetrievalService;
    @Nonnull private final LeaderRetrievalService resourceManagerRetrievalService;

Runner代码

这里我们并没有看到Dispatcher,而是一个类似名字的DispatcherRunner.DispatcherRunner是来管理Dispatcher如何运行的。类似ResourceManagerService是来管理ResourceManager的生命周期的。

HA代码框架

另外由于这些服务都有双机容错机制(HA), 所以这里在看相关代码的时候会产生一定的干扰,本篇的最后我们来介绍下这块HA的相关的机制,这样对大家来梳理相关的流程会更清晰。 Leader的选举,是通过LeaderElectionService(选举服务,实现类为DefaultLeaderElectionService)和LeaderContender(竞选者)共同来完成的。具体过程为LeaderElectionService.start(LeaderContender),启动选举服务,传入LeaderContender信息,等选举成功后,会回调LeaderContender的grantLeadership()方法,Flink中相关的服务都实现了LeaderContender接口。所以理清这个逻辑后,我们在看到相关服务的start()方法中只调用了leaderElectionService.start方法时也不用懵了,直接看该服务的grantLeadership方法来梳理逻辑。 LeaderElectionDriver:进行Leader的选举和保存Leader的信息,具体的实现有ZooKeeperLeaderElectionDriver和KubernetesLeaderElectionDriver

那如何获取Leader的地址呢,也提供了相应的接口LeaderRetrievalService和LeaderRetrievalLister,启动一个对Leader地址的监听,leader有变化时会得到通知。

总结

本篇我们了解了Flink的部署模式,按Job提交方式和一个集群可同时运行任务的数量的不同,分为ApplicationMode和SessionMode2种模式。接着介绍了Cluster的整体架构和启动流程,主要包括Dispatcher、ResourceManager和WebMonitorEndpoint。最后介绍了HA处理的整体框架,便于大家更好的梳理核心流程。

以上就是Flink部署集群整体架构源码分析的详细内容,更多关于Flink部署集群架构的资料请关注我们其它相关文章!

(0)

相关推荐

  • 详解Flink同步Kafka数据到ClickHouse分布式表

    目录 引言 什么是ClickHouse? 创建复制表 通过jdbc写入 引言 业务需要一种OLAP引擎,可以做到实时写入存储和查询计算功能,提供高效.稳健的实时数据服务,最终决定ClickHouse 什么是ClickHouse? ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS). 列式数据库更适合于OLAP场景(对于大多数查询而言,处理速度至少提高了100倍),下面详细解释了原因(通过图片更有利于直观理解),图片来源于ClickHouse中文官方文档. 行式 列

  • Flink DataStream基础框架源码分析

    目录 引言 概览 深入DataStream DataStream 属性和方法 类体系 Transformation 属性和方法 类体系 StreamOperator 属性和方法 类体系 Function DataStream生成提交执行的Graph StreamGraph 属性和方法 StreamGraph生成 JobGraph 属性和方法 总结 引言 希望通过对Flink底层源码的学习来更深入了解Flink的相关实现逻辑.这里新开一个Flink源码解析的系列来深入介绍底层源码逻辑.说明:这里默

  • Flink状态和容错源码解析

    目录 引言 概述 State Keyed State 状态实例管理及数据存储 HeapKeyedStateBackend RocksDBKeyedStateBackend OperatorState 上层封装 总结 引言 计算模型 DataStream基础框架 事件时间和窗口 状态和容错 部署&调度 存储体系 底层支撑 Flink中提供了State(状态)这个概念来保存中间计算结果和缓存数据,按照不同的场景,Flink提供了多种不同类型的State,同时为了实现Exactly once的语义,F

  • Flink时间和窗口逻辑处理源码分析

    目录 概览 时间 重要类 WatermarkStrategy WatermarkGenerator TimerService 处理逻辑 窗口 重要类 Window WindowAssigner Triger Evictor WindowOperator InternalAppendingState 处理逻辑 总结 概览 计算模型 DataStream基础框架 事件时间和窗口 部署&调度 存储体系 底层支撑 在实时计算处理时,需要跟时间来打交道,如实时风控场景的时间行为序列,实时分析场景下的时间窗

  • Flink作业Task运行源码解析

    目录 引言 概览 调度框架 JobMaster ScheduleNG TaskExecutor Task 计算框架 算子计算处理 总结 引言 上一篇我们分析了Flink部署集群的过程和作业提交的方式,本篇我们来分析下,具体作业是如何被调度和计算的.具体分为2个部分来介绍 作业运行的整体框架,对相关的重要角色有深入了解 计算流程,重点是如何调度具体的operator机制 概览 首先我们来了解下整体的框架 JobMaster: 计算框架的主节点,负责运行单个JobGraph,包括任务的调度,资源申请

  • Apache Hudi结合Flink的亿级数据入湖实践解析

    目录 1. 实时数据落地需求演进 2. 基于Spark+Hudi的实时数据落地应用实践 3. 基于Flink自定义实时数据落地实践 4. 基于Flink + Hudi的落地数据实践 5. 后续应用规划及展望 5.1 取代离线报表,提高报表实时性及稳定性 5.2 完善监控体系,提升落数据任务稳定性 5.3 落数据中间过程可视化探索 本次分享分为5个部分介绍Apache Hudi的应用与实践 1. 实时数据落地需求演进 实时平台上线后,主要需求是开发实时报表,即抽取各类数据源做实时etl后,吐出实时

  • Flink JobGraph生成源码解析

    目录 引言 概念 JobGraph生成 生成hash值 生成chain 总结 引言 在DataStream基础中,由于其中的内容较多,只是介绍了JobGraph的结果,而没有涉及到StreamGraph到JobGraph的转换过程.本篇我们来介绍下JobGraph的生成的详情,重点是Operator可以串联成Chain的条件 概念 首先我们来回顾下JobGraph中的相关概念 JobVertex:job的顶点,即对应的计算逻辑(这里用的是Vertex, 而前面用的是Node,有点差异),通过in

  • Flink部署集群整体架构源码分析

    目录 概览 部署模式 Application mode 客户端提交请求 服务端启动&提交Application session mode Cluster架构 Cluster的启动流程 DispatcherResourceManagerComponent Runner代码 HA代码框架 总结 概览 本篇我们来了解Flink的部署模式和Flink集群的整体架构 部署模式 Flink支持如下三种运行模式 运行模式 描述 Application Mode Flink Cluster只执行提交的整个job

  • Nacos配置中心集群原理及源码分析

    目录 Nacos集群工作原理 配置变更同步入口 AsyncNotifyService AsyncTask 目标节点接收请求 NacosDelayTaskExecuteEngine ProcessRunnable processTasks DumpProcessor.process Nacos作为配置中心,必然需要保证服务节点的高可用性,那么Nacos是如何实现集群的呢? 下面这个图,表示Nacos集群的部署图. Nacos集群工作原理 Nacos作为配置中心的集群结构中,是一种无中心化节点的设计

  • openstack云计算keystone架构源码分析

    目录 keystone架构 Keystone API Router Services (1) Identity Service (2) Resource Service (3) Assignment Service (4) Token Service (5) Catalog Service (6) Policy ServicePolicy Service Backend Driver keystone管理这些概念的方法 keystone-10.0.0代码结构展示 keystone服务启动 key

  • Hadoop源码分析一架构关系简介

    1. 简介 Hadoop是一个由Apache基金会所开发的分布式系统基础架构 Hadoop起源于谷歌发布的三篇论文:GFS.MapReduce.BigTable.其中GFS是谷歌的分布式文件存储系统,MapReduce是基于这个分布式文件存储系统的一个计算框架,BigTable是一个分布式的数据库.hadoop实现了论文GFS和MapReduce中的内容,Hbase的实现了参考了论文BigTable. 2. hadoop架构 hadoop主要有三个组件 HDFS.YARN和MapReduce.其

  • Hadoop源码分析五hdfs架构原理剖析

    目录 1. hdfs架构 如果在hadoop配置时写的配置文件不同,启动的服务也有所区别 namenode的下方是三台datanode. namenode左右两边的是两个zkfc. namenode的上方是三台journalnode集群. 2. namenode介绍 namenode作为hdfs的核心,它主要的作用是管理文件的元数据 文件与块的对应关系中的块 namenode负责管理hdfs的元数据 namenode的数据持久化,采用了一种日志加快照的方式 最后还会有一个程序读取这个快照文件和日

  • Redis7.0部署集群的实现步骤

    目录 Redis7.0部署集群详细版 1.Redis集群内部结构设计 2.cluster集群内部结构搭建 3.主从下线和主从切换 Redis7.0部署集群详细版 集群的架构:集群就是使用网络将若干台计算机联通起来,并提供统一的管理方式,使其对外呈现单机的服务效果 集群的作用: 分散单台服务器的访问压力,实现负载均衡 分散单台服务器的存储压力,实现可扩展性 降低单台服务器宕机带来业务灾难 1.Redis集群内部结构设计 数据存储设计 通过算法设计,计算出key应该保存的位置 将所有的存储空间计划切

  • 合成大西瓜开发源码手把手教你运行和部署大西瓜游戏项目(附源码)

    最近合成大西瓜非常火,很多编程爱好者将大西瓜改成了各种版本,非常魔性,哈哈. 如果你也想魔改大西瓜,或者想研究一下项目怎么玩的,下面的教程从下载到游戏项目部署一条龙搞定. 步骤一:下载大西瓜源代码 贴心的我已经将各种版本的代码整理到百度网盘了,大家可以按需下载: 链接: https://pan.baidu.com/s/1DfRdj2s2yGW_XbQhhjSM1w 提取码: 4t3d 步骤二:尝试运行大西瓜游戏项目 下载的源码结构如下图 如果你双击打开 index.html 文件可能卡在98%或

  • docker网络及部署集群和打包镜像问题

    目录 Docker 网络 理解Docker –-link 自定义网络 网络连通 实战:部署Redis集群 SpringBoot微服务打包Docker镜像 Docker 网络 理解Docker 清空下前面的docker 镜像.容器 # 删除全部容器 $ docker rm -f $(docker ps -aq) # 删除全部镜像 $ docker rmi -f $(docker images -aq) 测试 三个网络 问题: docker 是如果处理容器网络访问的? # 测试 运行一个tomcat

  • RateLimiter 源码分析

    俗话说得好,缓存,限流和降级是系统的三把利剑.刚好项目中每天早上导出数据时因调订单接口频率过高,订单系统担心会对用户侧的使用造成影响,让我们对调用限速一下,所以就正好用上了. 常用的限流算法有2种:漏桶算法和令牌桶算法. 漏桶算法 漏桶算法:请求先进入"桶"中,然后桶以一定的速率处理请求.如果请求的速率过快会导致桶溢出.根据描述可以知道,漏桶算法会强制限制请求处理的速度.任你请求的再快还是再慢,我都是以这种速率来处理. 但是对于很多情况下,除了要求能够限制平均处理速度外,还要求能允许一

  • Hadoop源码分析三启动及脚本剖析

    1. 启动 hadoop的启动是通过其sbin目录下的脚本来启动的.与启动相关的叫脚本有以下几个: start-all.sh.start-dfs.sh.start-yarn.sh.hadoop-daemon.sh.yarn-daemon.sh. hadoop-daemon.sh是用来启动与hdfs相关的服务的 yarn-daemon.sh是用来启动和yarn相关的服务 start-dfs.sh是用来启动hdfs集群的 start-yarn.sh是用来启动yarn集群 start-all.sh是用

随机推荐