flink 设置消费者组 flink设计模式

一.架构设计

• 架构设计图
• 各层及相关术语说明

• 物理层

• 解决flink的部署模式的问题
• 支持多种部署模式:本地,集群,云及k8s
• 用户可以根据不同的场景选择不同的部署模式

• 核心层

• 是flink的核心实现层,负责为上层的接口提供服务
• Runtime

• flink的核心计算

• Optimizer

• 负责任务的优化

• Stream Buider

• 负责对任务进行DAG优化

• API层

• 面向用户,负责更好的用户开发体验
• 提供了流计算和批处理的接口,同时在这个基础上又开发了不同的组件库

• 基于流处理的CEP(Complex event process,复杂事件处理)
• Table和SQL
• 基于批处理的机器学习库flinkML
• 图处理库Gelly

• API层包括两部分

• 流处理应用的DataStream API
• 批处理应用的DataSet API
• 统一的API,包括直接操作状态和时间等底层数据

 二.运行模式

• 各个运行模式的区分点

• 集群的生命周期
• 资源的隔离保障

• 运行模式分类

• 本地
• standlone 独立flink集群,也就是集群中仅安装了flink
• 集群运行

• 经常是指flink on yarn
• 三种

• session
• pre-job
• application

• 本地

• 一个机器的单进程多线程模拟集群
• 一般用于测试

• standlone

• 完全独立的flink集群,纯flink完成各种工作

• 集群

• session

• 生命周期

• 集群首先创建了一个回话等待客户端连接,单个任务结束后并不会关闭会话,可以接受多个作业的提交.
• 一句话 : 保持会话通道,接受多个任务

• 资源隔离

• 由于所有作业共享同一个集群,所以如果一个TaskManager失败,它上所有的任务都将失败,一个JobManager失败,它将影响集群中运行的所有作业
• 一句话 : 管理者宕掉,任务全部GG

• 总结

• 速度快,但是有风险

• 工作模式

• 附加模式(默认)

• 特点

• 客户端与flink作业集群同步

• 细节

• 客户端将集群交给yarn,但是客户端保持运行,持续追踪集群状态
• 但是如果集群发生错误,客户端将显示,如果客户端关闭,对应也会通知集群关闭

• 一句话:session模式下的flink默认就是这个,客户端与集群一个关,都关

• 分离模式

• 特点

• 客户端与flink集群相互异步,客户端提交完成后就可以退出

• 细节

• yarn-session.sh客户端将集群提交给yarn,然后客户端返回
• 需要再次调用客户端或者yarn来停止集群

• 一句话:客户端提交了集群后就可以退出

• 工作流程

• 多个作业向同一个Session提交,由它统一管理
• 示意图

• pre-job

• 生命周期

• 集群管理器(yarn)为每个任务创建一个集群,该集群仅用于该作业.
• 客户端首先向集群管理器请求资源启动JobManager,然后将这个作业提交给Dispactcher.然后作业的资源请求惰性分配TaskManager.一旦作业完成,集群将被拆除

• 资源隔离

• JobManager中的错误仅会影响其中的一个作业

• 总结

• pre-job模式适合长期运行,具有高稳定性且对启动时长要求不高的大型作业

• 工作流程

• 多个不同的作业分别向自己的Session会话上提交作业
• 流程图

• application

• 生命周期

• main方法在集群上
• 提交作业的是一个单步骤过程

• jar包和资源上传hdfs
• jobManager去拉去对应的jar包和资源,如果存在HA,就选举出一个Active
• 由jobManager所在机器调用main方法提取JobGraph,作为客户端程序和集群进行交互,直到任务结束
• 如果main方法中有多个env.execute()/executeAsync()调用,在Application中,这些作业会被视为同一个应用,在同一个集群上执行
• application的寿命和对于作业的寿命有关

• 资源隔离

• 在 Flink Application 集群中，ResourceManager 和 Dispatcher 作用于单个的 Flink 应用程序，相比于 Flink Session 集群，它提供了更好的隔离。

• 总结

• 该模式为yarn session和yarn per-job模式的折中选择。

• 工作流程

• 将各个环节更进一步进行专用化处理，相当于每个FlinkJob都有一套专用的服务角色进程。

• 示意图

• 总结

• 各个模式应用场景

• session模式

• 集群资源充分、频繁任务提交、小作业居多、实时性要求高的场景。

• per-job模式

• 作业少、大作业、实时性要求低的场景。

• application模式

• 实时性要求不太高、安全性有一定要求均可以使用，普遍适用性最强。

• 生产环境中

• 一般建议用per-job或是application模式，提供了更好的资源隔离性和安全性。

三.运行流程

• 核心角色

• 一个JobManager
• 一到多个TaskManager

• 流程图
• -
• 角色剖析

• JobManager

• 主要作用就是协调和监控Task,Task的执行顺序,task的任务状态决策等
• 这个进程由三个不同的组件组成

• ResourcesManager

• ResourceManager 负责 Flink 集群中的资源提供、回收、分配 - 它管理 task slots，这是 Flink 集群中资源调度的最小单位。Flink 为不同的环境和资源提供者（例如 YARN、Mesos、Kubernetes 和 standalone 部署）实现了对应的 ResourceManager。在 standalone 设置中，ResourceManager 只能分配可用 TaskManager 的 slots，而不能自行启动新的 TaskManager。

• Dispatcher

• Dispatcher 提供了一个 REST 接口，用来提交 Flink 应用程序执行，并为每个提交的作业启动一个新的 JobMaster。它还运行 Flink WebUI 用来提供作业执行信息。

• JobMaster

• JobMaster 负责管理单个JobGraph的执行。Flink 集群中可以同时运行多个作业，每个作业都有自己的 JobMaster。
• 始终至少有一个 JobMaster。高可用（HA）设置中可能有多个 JobMaster，其中一个始终是 leader，其他的则是 standby。

• TaskManager

• TaskManager（也称为 worker）执行作业流的 task，并且缓存和交换数据流。
• 必须始终至少有一个 TaskManager。在 TaskManager 中资源调度的最小单位是 task slot。TaskManager 中 task slot 的数量表示并发处理 task 的数量。请注意一个 task slot 中可以执行多个算子。

• Yarn模式提交任务的工作流程

• flink-application运行模式