当前位置： 首页 > news >正文

Flink部署与应用——部署方式介绍

news 2025/4/26 4:25:55

引入

通过前面的梳理，我们通过Flink相关论文的介绍，对于Flink已经有了初步理解，这里简单的梳理一下Flink常见的部署与监控。

Flink 的部署方式 

StandAlone模式

介绍

StandAlone模式是Flink框架自带的分布式部署模式，不依赖其他的资源调度框架，特点：

  • 分布式多台物理主机部署
  • 依赖于Java8或Java11JDk环境
  • 仅支持Session模式提交Job
  • 支持高可用配置

但是有以下缺点：

  • 资源利用弹性不够（资源总量是定死的；job退出后也不能立刻回收资源）
  • 资源隔离度不够（所有job共享集群的资源）
  • 所有job共用一个jobmanager，负载过大
  • 只能运行Flink程序，不能能运行其他的编程模型

OnYarn模式

介绍

YARN是一个通用的资源调度框架，特点是：

  • 可以运行多种编程模型，例如MR、Storm、Spark、Flink等
  • 性能稳定，运维经验丰富
  • 灵活的资源分配和资源隔离
  • 每提交一个application都会有一个专门的ApplicationMater（JobManager）

ResouManager(NM)：

  • 负责处理客户端请求
  • 监控NodeManager
  • 启动和监控APPlicationMaster
  • 资源的分配和调度

NodeManager：

  • 管理单个Worker节点上的资源
  • 处理来自ResourceManager的命令
  • 处理来自ApplicationMaster的命令
  • 汇报资源状态

ApplicationMaster：

  • 负责数据的切分
  • 为应用申请计算资源，并分配给Task
  • 任务的监控与容错
  • 运行在Worker节点上 

Container：

  • 资源抽象，封装了节点上的多维度资源，如CPU，内存，网络资源等

Flink On Yarn 的三种模式

Flink程序可以运行为以下3种模式:

  • Application Mode【生产中建议使用的模式】：每个job独享一个集群，job退出集群则退出，用户类的main方法在集群上运行
  • Per-Job Mode：每个job独享一个集群，job退出集群则退出，用户类的main方法在client端运行；（大job，运行时长很长，比较合适；因为每起一个job，都要去向yarn申请容器启动jm,tm，比较耗时）
  • Yarn Session Mode：多个job共享同一个集群<jobmanager/taskmanager>、job退出集群也不会退出，用户类的main方法在client端运行；（需要频繁提交大量小job的场景比较适用；因为每次提交一个新job的时候，不需要去向yarn注册应用）

上述3种模式的区别点在:
集群的生命周期和资源的隔离保证
用户类的main方法是运行在client端，还是在集群端

yarn application模式提交
bin/flink run-application -t yarn-application \
-yjm 1024 -yqu default -ys 2 \
-ytm 1024 -p 4 \
-c com.chaos.flink.java.KafkaSinkYarn /root/flink_test-1.0.jar
  • bin/flink run-application ：这是用于运行 Flink 应用程序的命令入口。
  • -t yarn-application ：指定在 YARN 集群上运行应用程序。
  • -yjm 1024 ：设置 JobManager 的内存大小为 1024 MB。
  • -yqu default ：指定 YARN 队列的名称为 default。
  • -ys 2 ：设置 YARN 服务，这里可能是指 YARN 的一些特定配置，比如在 YARN 上运行的实例数量。
  • -ytm 1024 ：设置 TaskManager 的内存大小为 1024 MB。
  • -p 4 ：设置 Flink 作业的并行度为 4。
  • -c com.chaos.flink.java.KafkaSinkYarn ：指定主类的完整类名为 com.chaos.flink.java.KafkaSinkYarn，这是应用程序的入口类。
  • /root/flink_test-1.0.jar ：指定要运行的 Flink 应用程序的 JAR 包路径。 
yarn perJob模式提交

Yarn-Per-Job 模式：每个作业单独启动集群，隔离性好，JM(JobManager) 负载均衡，main 方法在客户端执行。在 per-job 模式下，每个 Job 都有一个 JobManager，每个TaskManager 只有单个 Job。  

特点： 一个任务会对应一个 Job，每提交一个作业会根据自身的情况，都会单独向 yarn申请资源，直到作业执行完成，一个作业的失败与否并不会影响下一个作业的正常提交和运行。独享 Dispatcher 和 ResourceManager，按需接受资源申请；适合规模大长时间运行的作业。

提交命令 (申请容器启动flink集群以及提交job，是合二为一的)

bin/flink run -m yarn-cluster -yjm 1024 \
-ytm 1024 -yqu default -ys 2   -p 4 \
-c com.chaos.TaskDemo  /root/flink_test-1.0.jar
  • -m：master的运行模式
  • -yjm：JobManager的所在Yarn容器的内存大小
  • -ytm：TaskManager的所在Yarn容器额内存大小
  • -yqu：Yarn任务队列的名称
  • -ys：每个TaskManager的slot数量
  • -p：并行度
  • -c：main方法全类名
yarn session模式提交

Yarn-Session 模式：所有作业共享集群资源，隔离性差，JM 负载瓶颈，main 方法在客户端执行。适合执行时间短，频繁执行的短任务，集群中的所有作业 只有一个 JobManager，另外，Job 被随机分配给 TaskManager  

特点： Session-Cluster 模式需要先启动集群，然后再提交作业，接着会向 yarn 申请一块空间后，资源永远保持不变。如果资源满了，下一个作业就无法提交，只能等到 yarn 中的其中一个作业执行完成后，释放了资源，下个作业才会正常提交。所有作业共享 Dispatcher 和 ResourceManager；共享资源；适合规模小执行时间短的作业。

  1. 基本操作命令 
    # 提交命令：
bin/yarn-session.sh –help# 停止命令：
yarn application -kill application_1550836652097_0002
  2. 具体操作步骤
    1. 先开辟资源启动session模式集群 
      # 老版本： 
bin/yarn-session.sh -n 3 -jm 1024 -tm 1024
# -n --> 指定需要启动多少个Taskmanager# 新版本： 
bin/yarn-session.sh -jm 1024  -tm 1024  -s 2  -m yarn-cluster -ynm hello -qu default -jm：jobmanager memory  
-tm：taskmanager memory
-m yarn-cluster：集群模式（yarn集群模式）
-s：规定每个taskmanager上的taskSlot数（槽位数）
-nm：自定义appliction名称
-qu：指定要提交到的yarn队列
    2. 启动的服务进程
      YarnSessionClusterEntrypoint（AppMaster，即JobManager）
      注意：此刻并没有taskmanager，也就是说，taskmanager是在后续提交job时根据资源需求动态申请容器启动的。
    3. 向已运行的session模式集群提交job 
      bin/flink run -d -yid application_1550579025929_62420 -p 4 -c com.chaos.flink.java.TaskDemo /root/flink_test-1.0.jar

Flink On Yarn 的优劣势

优势：

  • 与现有大数据平台无缝对接（Hadoop2.4+）
  • 部署集群与任务提交都非常简单
  • 资源管理统一通过Yarn管理，提升整体资源利用率类
  • 基于Native方式，TaskManager资源按需申请和启动，防止资源浪费
  • 容错保证：借助于Hadoop Yarn提供的自动failover机制，能保证JobManager，TaskManager节点异常恢复

劣势：

  • 资源隔离问题，尤其是网络资源的隔离，Yarn做的还不够完善
  • 离线和实时作业同时运行相互干扰等问题需要重视
  • Kerberos认证超期问题导致Checkpoint无法持久化

On Kubernetes模式

介绍

Flink on Kubernetes 是将 Apache Flink 部署在 Kubernetes 集群上的一种方式，使用户能够利用 Kubernetes 的强大功能进行资源管理、弹性伸缩和高可用性管理。

Master节点：

  • 负责整个集群的管理，资源管理
  • 运行APIServer，ControllerManager，Scheduler服务
  • 提供Etcd高可用键值存储服务，用来保存Kubernetes集群所有对象的状态信息和网络信息

Node：

  • 集群操作的单元，Pod运行宿主机
  • 运行业务负载，业务负载会以Pod的形式运行

Kubelet：

  • 运行在Node节点上，维护和管理该Node上的容器

Container Runtime：

  • Docker容器运行环境，负责容器的创建和管理

Pod：

  • 运行在Node节点上，多个相关Container的组合
  • Kubunetes创建和管理的最小单位

核心概念

  • ReplicationController（RC)：RC是K8s集群中最早的保证Pod高可用的API对象，通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。
  • Service：Service是对一组提供相同功能的Pods的抽象，并为它们提供一个统一的入口。
  • PersistentVolume(PV)：容器的数据都是非持久化的，在容器消亡以后数据也跟着丢失，所以Docker提供了Volume机制以便将数据持久化存储。
  • ConfigMap：ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。

Flink On Kubunetes的三种模式

Session 模式：启动一个长期运行的 Flink 集群，所有作业共享该集群资源。适合多个作业需要共享资源的场景。

Application 模式：为每个作业启动一个独立的 Flink 集群，作业之间资源隔离，互不影响。

Native Kubernetes 模式：Flink 原生支持 Kubernetes，通过 Kubernetes API 进行资源管理和调度，能够动态分配和释放 TaskManager。

Flink On Kubunetes的优缺点

优点：

  • 强大的资源管理与弹性伸缩：Kubernetes 可根据作业负载动态分配和释放资源，实现 Flink 集群的弹性伸缩。这提高了资源利用率，降低了成本，尤其在业务波动时可快速调整资源以满足需求。

  • 高可用性与容错能力：Kubernetes 能自动重启故障 Pod 并重新调度 TaskManager，确保 Flink 作业持续运行，保障数据处理的可靠性和稳定性。

  • 深度云原生集成：Flink on Kubernetes 与云原生生态系统深度融合，可与云服务（如对象存储、消息队列）无缝协作，便于构建完整的云原生数据处理解决方案。

  • 简化的部署与运维：通过 Flink Kubernetes Operator 提供的抽象接口，用户可以更高效地部署和管理 Flink 集群，减少手动操作，降低运维负担。

  • 多租户支持：Kubernetes 的命名空间功能可实现多租户隔离，为多团队或项目共用集群提供了便利，提高了资源的隔离性和安全性。

缺点：

  • 部署复杂度增加：与在专用集群上部署 Flink 相比，Flink on Kubernetes 需要熟悉 Kubernetes 的概念和工具（如 Pod、Deployment、Service 等），增加了学习曲线和部署前的准备工作。

  • 资源管理的潜在挑战：Kubernetes 的资源调度策略可能与 Flink 的需求不完全匹配，导致资源分配效率降低。例如，在某些情况下，Kubernetes 的默认调度算法可能无法满足 Flink 对数据本地性的要求，影响作业性能。

  • 性能开销：在 Kubernetes 上运行 Flink 会引入额外的性能开销，包括容器的启动时间和 Kubernetes 的调度延迟。此外，如果 Kubernetes 集群的资源紧张，可能导致 Flink 作业的性能下降。

  • 网络配置复杂性：在 Kubernetes 集群中，网络配置可能较为复杂，需要确保 Flink 的各个组件之间能够正确通信。

  • 长期运行作业的资源管理：对于长期运行的 Flink 作业，需要持续监控和管理资源使用情况。Kubernetes 的资源配额和限制机制可以帮助控制资源使用，但需要合理配置以避免对作业的性能产生负面影响。


http://www.mrgr.cn/news/100159.html

相关文章：

  • Python Cookbook-6.9 快速复制对象
  • 数据结构0基础学习堆
  • 【视频时刻检索】Text-Video Retrieval via Multi-Modal Hypergraph Networks 论文阅读
  • 五一去荣昌吃卤鹅？基于Java和天地图的寻找荣昌卤鹅店实践
  • 【每天一个知识点】IPv4（互联网协议版本4）和IPv6（互联网协议版本6）
  • JDBC 批处理与事务处理：提升数据操作效率与一致性的密钥
  • Web漏洞--XSS之订单系统和Shell箱子
  • 架构师面试（三十六）：广播消息
  • Python数据分析案例73——基于多种异常值监测算法探查内幕交易信息
  • Safety Estimands与Efficacy Estimands的差异剖析
  • 【金仓数据库征文】金仓数据库：国产化浪潮下的技术突破与行业实践
  • VRRP与防火墙双机热备实验
  • python pymysql如何保证数据库更新成功
  • 考研英一学习笔记
  • 传感器模块有助于加速嵌入式视觉开发
  • Spring AI 快速入门：从环境搭建到核心组件集成
  • 脚本批量启动Node服务器
  • 电子设备的“记忆大脑”：NAND、NOR、EEPROM谁在掌控你的数据？
  • 算法训练营 Day1
  • 软测面经（私）