Flink 的核心是一个分布式流数据引擎,能够以数据并行和流水线方式执行任意流数据程序。它的设计目标是提供高吞吐量、低延迟的流数据处理能力,同时支持对有界和无界数据流进行有状态的计算 。这里提到的有界数据流,就像是一个装满数据的固定大小的箱子,数据量是有限的,处理完这些数据任务就结束了,比如处理一份固定的历史订单数据报表。而无界数据流则如同一条源源不断流淌的河流,数据持续不断地产生,没有尽头,像网站的实时访问日志数据,新的访问记录随时都会添加进来。Flink 能够同时处理这两种类型的数据,展现出强大的通用性。
Flink 具备诸多显著特点,使其在大数据处理中脱颖而出。在性能方面,它拥有高吞吐和低延迟的特性,能够实现毫秒级延迟,这对于对实时性要求极高的场景,如金融交易监控、物联网设备数据处理等至关重要。例如在金融交易场景中,交易数据瞬息万变,Flink 能够实时处理股票、期货等金融产品的交易数据,实时监控交易风险,一旦发现异常交易行为,如短期内大量的异常订单,能够立即触发预警机制,保障金融交易的安全。
在时间处理上,Flink 内置了事件时间和处理时间,对于乱序的数据,也能提供准确的结果。在处理传感器数据时,由于数据传输可能存在延迟,导致数据到达顺序与实际产生顺序不一致,Flink 通过事件时间语义,能够准确地对这些乱序数据进行处理和分析。
Flink 还提供了精确一次的状态一致性保证,确保在分布式环境下数据处理的准确性和可靠性。在电商领域的实时数据处理中,当统计用户的累计购买金额时,即使在出现故障或数据重发的情况下,Flink 也能保证结果的一致性。并且,Flink 对于常用的外部系统都有 API 提供连接方式,如 Kafka、Hive、JDBC、HDFS、Redis、Doris 等,展现出强大的通用性。
正是由于 Flink 这些出色的特性,使得其在实时智能推荐、复杂事件处理、实时欺诈检测、实时数仓与 ETL 等众多场景中得以广泛应用。而在实际应用 Flink 时,了解其不同模式下的提交流程至关重要,这将直接影响到 Flink 作业的执行效率和稳定性。接下来,我们就深入探讨 Flink 几种模式下的提交流程。
Flink 提交流程关键组件介绍
在深入探讨 Flink 的提交流程之前,我们先来认识一下 Flink 提交流程中涉及的关键组件,它们各司其职,协同工作,共同确保 Flink 作业的顺利执行。
JobManager
JobManager 是 Flink 集群中的主进程,犹如一个交响乐团的指挥,在整个 Flink 作业执行过程中起着至关重要的协调和管理作用。当我们提交一个 Flink 作业时,JobManager 首先接收客户端提交的作业。这里的作业包含了作业图(JobGraph)、逻辑数据流图(logical dataflow graph)以及打包了所有类、库和其他资源的 JAR 包 。就好比收到了一份详细的建筑蓝图和建筑所需的各种材料清单。
随后,JobManager 将作业图转换成物理层面的执行图(ExecutionGraph),这个执行图详细规划了作业中各个任务的执行顺序和并行关系,就像将建筑蓝图细化为具体的施工步骤和人员分工安排。接着,JobManager 向 ResourceManager 请求执行任务所需的资源,也就是 TaskManager 上的插槽(slot) 。
在作业执行过程中,JobManager 持续监控任务的执行状态。一旦某个任务完成,它会及时知晓并进行相应的记录;若某个任务执行失败,JobManager 会迅速做出反应,决定是否重新调度该任务,或者调整整个作业的执行策略,就像在施工过程中,一旦某个施工环节出现问题,指挥者会立即采取措施进行调整。
JobManager 还负责协调 checkpoint 操作,定期触发检查点机制,将任务的状态持久化存储,以便在发生故障时能够从检查点恢复,保证作业的一致性和可靠性,这就如同在建筑过程中,定期对已完成的部分进行质量检查和记录,以便在出现问题时能够快速恢复到之前的正确状态。当作业出现故障时,JobManager 会利用 checkpoint 信息进行故障恢复,确保作业能够继续执行,而不会因为故障而中断。
TaskManager
TaskManager 是 Flink 集群中的工作节点,是真正执行任务的 "实干家"。每个 TaskManager 都是一个 JVM 进程,它包含了一定数量的插槽(task slot) ,插槽是 TaskManager 中资源调度的最小单位,就像是工厂里的生产工位,每个工位都有其固定的资源配置,如内存等。
TaskManager 从 JobManager 接收需要执行的任务。当收到任务后,它会根据任务的要求,利用自身的资源,在一个或多个线程中执行任务。在执行任务的过程中,TaskManager 负责处理数据流,对数据进行各种转换操作,比如过滤、映射、聚合等,就像工厂里的工人按照生产流程对原材料进行加工处理。
TaskManager 还负责缓存和交换数据流。当不同的 TaskManager 之间需要传递数据时,它会将数据进行缓存,并通过网络与其他 TaskManager 进行数据交换,确保数据能够准确、高效地在任务之间流动,这就如同工厂中不同工位之间的原材料传递和协作。并且,TaskManager 在启动时会向 ResourceManager 注册自己的资源信息,包括可用内存和插槽数量等,以便 ResourceManager 进行资源的统一管理和分配。
ResourceManager
ResourceManager 就像是一个资源管家,负责管理 Flink 集群中的计算资源,主要是 TaskManager 的插槽(task slot)。不同的环境和资源管理工具,如 YARN、Kubernetes 或独立部署,Flink 都提供了相应的 ResourceManager 实现。
当 JobManager 向 ResourceManager 申请插槽资源时,ResourceManager 会根据集群中各个 TaskManager 的资源使用情况,将有空闲插槽的 TaskManager 分配给 JobManager。比如,在一个拥有多个 TaskManager 的集群中,ResourceManager 会实时监控每个 TaskManager 的插槽使用状态,当 JobManager 提出资源请求时,它会精准地找到那些有空闲插槽的 TaskManager,并将其分配给 JobManager 。
如果当前集群中可用的插槽无法满足 JobManager 的请求,ResourceManager 还可以向资源提供平台发起会话,请求提供启动 TaskManager 进程的容器,以增加集群的资源供给。在任务完成后,ResourceManager 会回收和释放这些资源,以便它们能被其他任务再次利用,实现资源的高效循环利用。
Dispatcher
Dispatcher 是 Flink 集群的 "接待员" 和 "展示窗口"。当我们提交一个 Flink 应用程序时,Dispatcher 提供的 REST 接口就像是一扇门,接收客户端提交的应用程序执行请求。一旦收到请求,Dispatcher 会启动一个新的 JobMaster 来专门管理这个提交的作业,确保每个作业都有独立的管理机制,避免作业之间的相互干扰。
Dispatcher 还运行着 Flink WebUI,这是一个直观的可视化界面,就像一个展示板,方便用户提交应用程序后,随时查看作业的执行信息,包括作业的运行状态、任务的执行进度、资源的使用情况等。通过 WebUI,用户可以清晰地了解作业的实时情况,及时发现问题并进行调整。
Flink 提交流程
Flink 的提交流程主要分为客户端提交和集群模式提交两种方式,它们在作业执行和监控方式上有所不同。
客户端提交(同步提交)
客户端提交作业是 Flink 提交流程中较为基础的一种方式。在这种模式下,我们使用 Flink 提供的命令行工具来提交作业。其基本命令格式如下:
java
flink run -c <类名> <jar包路径> [运行参数]
其中,-c参数用于指定包含main方法的类名,<jar包路径>是我们编写的 Flink 作业的打包文件路径,[运行参数]则是作业运行时所需的一些自定义参数,这部分是可选的。例如,我们有一个简单的 Flink WordCount 作业,其主类为com.example.WordCount,打包后的jar包路径为/home/user/flink-jobs/wordcount.jar,如果我们希望指定作业的并行度为 4,那么提交命令可以写成:
java
flink run -c com.example.WordCount /home/user/flink-jobs/wordcount.jar -p 4
在客户端提交模式下,提交操作是同步进行的。这意味着客户端会一直等待作业执行完成或者出现异常终止。在作业执行过程中,客户端会持续跟踪作业的执行进度,并将作业执行过程中的控制台输出信息实时打印出来。就好像我们在指挥一场演出,客户端就像是站在舞台旁边的导演,时刻关注着演员(作业任务)的表演进度,一旦有任何情况,比如演员忘词(作业报错)或者表演顺利(作业正常执行),导演都能第一时间知晓并做出反应 。这种同步提交的方式,对于我们调试作业非常方便,因为我们可以实时看到作业的执行情况和输出结果,便于及时发现和解决问题。
集群模式提交(异步提交 - detached 模式)
集群模式提交作业为我们提供了一种更加灵活和高效的作业提交方式,特别是在生产环境中,它能够更好地满足大规模作业的管理需求。在集群模式下,我们通常使用-d或--detached参数来指定作业以分离模式提交,即异步提交。其命令格式如下:
java
flink run -d -c <类名> <jar包路径> [运行参数]
同样以刚才的 WordCount 作业为例,如果我们要以集群模式提交,命令可以是:
java
flink run -d -c com.example.WordCount /home/user/flink-jobs/wordcount.jar -p 4
当我们使用这种方式提交作业时,提交操作是异步的。客户端在提交作业后,会立即返回一个Future对象,然后不再继续跟踪作业的执行进度和控制台输出信息。这就好比我们把一场演出的筹备工作交给了专业的团队(集群),我们只是下达了任务(提交作业),然后就可以去做其他事情了,不再时刻盯着演出的每一个细节。这种异步提交的方式,对于那些长时间运行、不需要实时监控输出的作业非常适用,它可以释放客户端的资源,让客户端可以继续处理其他任务。同时,我们可以通过 Flink 提供的 WebUI 或者其他监控工具来查看作业的执行状态和相关信息 。
Flink 在不同环境下的提交流程
Standalone 模式
Standalone 模式是 Flink 自带的集群模式,它的部署和管理相对简单,不需要依赖外部的资源管理系统,非常适合用于开发和测试环境。在这种模式下,我们可以通过启动脚本来启动 JobManager 和 TaskManager,构建一个完整的 Flink 集群。接下来,我们详细了解 Standalone 模式下的会话模式和应用模式的提交流程。
会话模式
在 Standalone 模式的会话模式下,我们首先需要启动 Flink 集群,然后在这个集群会话中提交作业。启动集群的命令如下:
java
bin/start-cluster.sh
这条命令会启动 JobManager 和 TaskManager,JobManager 负责协调和管理整个集群的任务调度和资源分配,TaskManager 则是实际执行任务的工作节点。启动成功后,我们可以通过浏览器访问http://localhost:8081(假设本地部署,且未修改默认端口),打开 Flink 的 WebUI 界面,在这里可以查看集群的状态、资源使用情况等信息。
当集群启动并运行后,我们就可以提交作业了。提交作业的命令如下:
java
bin/flink run -m <JobManager地址:端口> -c <类名> <jar包路径> [运行参数]
其中,-m参数用于指定 JobManager 的地址和端口,<JobManager地址:端口>需要根据实际情况填写,如果是本地部署且使用默认端口,通常为localhost:8081;-c参数指定包含main方法的类名,这个类是我们编写的 Flink 作业的入口类;<jar包路径>是打包好的 Flink 作业的jar文件的路径;[运行参数]是作业运行时需要的一些自定义参数,这部分是可选的。例如,我们有一个 WordCount 作业,其入口类为com.example.WordCount,jar包路径为/home/user/flink-jobs/wordcount.jar,提交命令可以是:
bash
bin/flink run -m localhost:8081 -c com.example.WordCount /home/user/flink-jobs/wordcount.jar
下面为从客户端提交作业到作业执行完成的整个流程:
TypeScript
@startuml
actor Client
participant "JobManager (Dispatcher, JobMaster, ResourceManager)" as JobManager
participant "TaskManager (Slot)" as TaskManager
Client -> JobManager: 提交作业(包含JobGraph)
JobManager -> JobMaster: 分发作业给JobMaster
JobMaster -> ResourceManager: 请求资源(slots)
ResourceManager --> TaskManager: 判断是否有足够资源,有则通知提供slots
TaskManager --> JobMaster: 连接并提供slots
JobMaster --> TaskManager: 分发任务
TaskManager -> TaskManager: 任务执行,数据交换
TaskManager --> JobManager: 任务完成,释放资源
@enduml
- 客户端提交作业:客户端将包含作业图(JobGraph)、逻辑数据流图以及打包了所有类、库和其他资源的 JAR 包提交给 JobManager。这就像是我们把一份详细的项目计划和所需的所有材料交给了项目经理(JobManager) 。
- JobManager 分发作业:JobManager 内部的 Dispatcher 接收到作业后,将其分发给 JobMaster。Dispatcher 就像是一个邮件分拣员,将收到的作业准确地送到负责处理它的 JobMaster 手中 。
- JobMaster 请求资源:JobMaster 接收到作业后,根据作业的需求,向 ResourceManager 请求执行任务所需的资源,也就是 TaskManager 上的插槽(slot)。这一步就好比项目经理向资源管理员申请项目所需的人力和物资资源 。
- 资源分配:ResourceManager 检查集群中各个 TaskManager 的资源使用情况,如果有足够的空闲插槽,就通知对应的 TaskManager 为新的作业提供插槽。如果资源不足,它只能等待资源释放,而不会直接启动新的 TaskManager 。
- TaskManager 提供插槽:TaskManager 收到 ResourceManager 的通知后,连接到 JobMaster,并向其提供自己的插槽资源,表明自己可以承担任务的执行工作 。
- 任务分发与执行:JobMaster 将需要执行的任务分发给获得插槽的 TaskManager。TaskManager 开始执行任务,在执行过程中,不同的 TaskManager 之间可能会进行数据交换,以完成复杂的数据处理逻辑。就像项目中的各个团队成员按照项目经理的安排开始工作,并且在工作过程中相互协作,交换信息 。
- 任务完成与资源释放:当任务执行完毕后,TaskManager 会释放持有的资源,这些资源可以被其他作业再次使用,实现资源的循环利用 。
应用模式
在 Standalone 模式的应用模式下,提交作业和启动 TaskManager 的过程与会话模式有所不同。首先,我们提交作业并启动 JobManager,命令如下:
bash
bin/standalone-job.sh start --job-classname <类名> <jar包路径>
这里的--job-classname参数指定包含main方法的类名,<jar包路径>是作业的jar文件路径。例如,提交一个应用程序作业,命令可以是:
bash
bin/standalone-job.sh start --job-classname com.example.MyApp /home/user/flink-jobs/myapp.jar
提交作业后,会启动一个 JobManager,这个 JobManager 会运行 Flink WebUI,方便我们查看作业的执行信息。接下来,我们需要手动启动 TaskManager,命令如下:
bash
bin/taskmanager.sh start
当应用运行完毕后,我们可以手动关闭集群,停止 JobManager 和 TaskManager,停止 JobManager 的命令是:
bash
bin/standalone-job.sh stop
停止 TaskManager 的命令是:
bash
bin/taskmanager.sh stop
从客户端提交应用程序到应用运行完毕关闭集群的整个流程:
TypeScript
@startuml
actor Client
participant "JobManager (Dispatcher, ResourceManager)" as JobManager
participant "TaskManager (Slot)" as TaskManager
Client -> JobManager: 提交应用程序(包含JobGraph),应用在JobManager上运行
JobManager -> JobManager: 启动Dispatcher和ResourceManager
activate JobManager
Client -> TaskManager: 手动启动TaskManager
TaskManager -> ResourceManager: 注册资源
JobManager -> JobMaster: 由Dispatcher启动多个JobMaster,并分发作业给JobMaster
JobMaster -> ResourceManager: 请求资源(slots)
ResourceManager --> TaskManager: 判断资源足够,通知提供slots
TaskManager --> JobMaster: 连接并提供slots
JobMaster --> TaskManager: 分发任务
TaskManager -> TaskManager: 任务执行,数据交换
Client -> JobManager: 应用运行完毕,手动停止JobManager
Client -> TaskManager: 手动停止TaskManager
deactivate JobManager
@enduml
- 客户端提交应用程序:客户端通过分发器提供的 REST 接口,将应用程序提交给 JobManager,应用程序在 JobManager 上运行。与会话模式不同,此时 JobManager 内部只启动了 Dispatcher 和 ResourceManager,JobMaster 还没有启动 。
- 手动启动 TaskManager:客户端手动启动 TaskManager,TaskManager 启动后,会向 ResourceManager 注册自己的资源信息,包括可用内存和插槽数量等 。
- JobMaster 启动与作业分发:JobManager 内部的 Dispatcher 启动多个 JobMaster,并将作业(包含 JobGraph)提交给各自对应的 JobMaster。每个 JobMaster 负责管理和调度一个作业的执行 。
- 资源请求与分配:JobMaster 根据作业的需求,向 ResourceManager 请求执行任务所需的资源(slots)。ResourceManager 检查集群中各个 TaskManager 的资源使用情况,如果有足够的空闲插槽,就通知对应的 TaskManager 为作业提供插槽 。
- 任务分发与执行:TaskManager 收到 ResourceManager 的通知后,连接到对应的 JobMaster,并向其提供自己的插槽资源。JobMaster 将需要执行的任务分发给获得插槽的 TaskManager,TaskManager 开始执行任务,在执行过程中,不同的 TaskManager 之间可能会进行数据交换 。
- 应用运行完毕与集群关闭:当应用运行完毕后,客户端手动停止 JobManager 和 TaskManager,关闭整个集群,释放所有资源 。
Yarn 模式
Yarn 模式是 Flink 在 Yarn 资源管理框架上的部署方式,它充分利用了 Yarn 强大的资源管理和调度能力,使得 Flink 作业能够在大规模集群环境中高效运行。在 Yarn 模式下,我们可以根据不同的需求选择会话模式或单作业模式来提交作业。下面我们分别深入了解这两种模式的提交流程。
会话模式
在 Yarn 模式的会话模式下,我们首先需要开启一个 Yarn 会话,为 Flink 集群申请资源并启动相关服务。开启 Yarn 会话的命令如下:
bash
bin/yarn-session.sh [参数]
常见的参数有:
- -nm或--name:配置在 Yarn UI 界面上显示的任务名,方便我们在 Yarn 集群中识别和管理该会话 。
- -n或--container:指定需要的 Container 数量,也就是 TaskManager 的数量,每个 TaskManager 对应一个 Container 。
- -tm或--taskmanager_memory:设置每个 TaskManager 的内存大小,单位为 MB 。
- -s或--slots:指定每个 TaskManager 的插槽(slot)数量,插槽是 TaskManager 中资源调度的最小单位 。
例如,我们要开启一个 Yarn 会话,设置任务名为flink-session,使用 2 个 Container(即 2 个 TaskManager),每个 TaskManager 的内存为 2048MB,每个 TaskManager 有 4 个插槽,可以使用以下命令:
bash
bin/yarn-session.sh -nm flink-session -n 2 -tm 2048 -s 4
执行该命令后,Yarn 会根据我们的配置为 Flink 集群分配资源,并启动 JobManager。此时,JobManager 内部只有 ResourceManager 和 Dispatcher 在运行,因为还没有提交作业,所以 JobMaster 和 TaskManager 还未启动 。
当 Yarn 会话开启并启动了 JobManager 后,我们就可以提交作业了。提交作业的命令如下:
bash
bin/flink run -c <类名> <jar包路径> [运行参数]
这里的参数含义与 Standalone 模式下提交作业的参数类似,-c参数指定包含main方法的类名,<jar包路径>是作业的jar文件路径,[运行参数]是作业运行时需要的一些自定义参数。例如,提交一个 WordCount 作业,命令可以是:
bash
bin/flink run -c com.example.WordCount /home/user/flink-jobs/wordcount.jar
从开启 Yarn 会话到作业执行的整个流程:
TypeScript
@startuml
actor Client
participant "Yarn ResourceManager" as YarnRM
participant "Yarn NodeManager" as YarnNM
participant "JobManager (ResourceManager, Dispatcher)" as JobManager
participant "TaskManager (Slot)" as TaskManager
Client -> YarnRM: 提交yarn-session.sh请求
YarnRM -> YarnNM: 分配资源,启动JobManager
JobManager <-- YarnNM: JobManager启动成功
Client -> JobManager: 提交作业(包含JobGraph)
JobManager -> JobManager: Dispatcher启动JobMaster
JobMaster -> JobManager: 请求资源(slots)
JobManager -> YarnRM: 向Yarn RM请求container资源
YarnRM -> YarnNM: 分配container资源,启动TaskManager
TaskManager -> JobManager: 注册可用任务槽
JobManager -> TaskManager: 通知为新作业提供slots
TaskManager -> JobMaster: 连接并提供slots
JobMaster -> TaskManager: 分发任务
TaskManager -> TaskManager: 任务执行,数据交换
@enduml
- 开启 Yarn 会话 :客户端向 Yarn 的 ResourceManager 提交yarn-session.sh请求,请求开启一个 Yarn 会话,并指定相关的资源配置参数,如 TaskManager 的数量、内存、插槽数量等 。
- Yarn 分配资源并启动 JobManager:Yarn 的 ResourceManager 根据客户端的请求,在 NodeManager 上分配资源,并启动 Flink 的 JobManager。JobManager 启动后,其中的 ResourceManager 和 Dispatcher 开始运行,等待接收作业提交请求 。
- 客户端提交作业:客户端通过 REST 接口,将作业(包含 JobGraph)提交给 JobManager 中的 Dispatcher 。
- JobMaster 启动:Dispatcher 接收到作业后,启动 JobMaster,并将作业提交给 JobMaster。JobMaster 负责管理和调度作业的执行 。
- 资源请求:JobMaster 根据作业的需求,向 JobManager 中的 ResourceManager 请求执行任务所需的资源,也就是 TaskManager 上的插槽(slots) 。
- Yarn 分配 Container 资源并启动 TaskManager:JobManager 中的 ResourceManager 向 Yarn 的 ResourceManager 请求 container 资源,Yarn 的 ResourceManager 在 NodeManager 上分配 container 资源,并启动 TaskManager。TaskManager 启动后,会向 Flink 的 ResourceManager 注册自己的可用任务槽 。
- 资源分配与任务分发:Flink 的 ResourceManager 通知 TaskManager 为新的作业提供插槽,TaskManager 连接到对应的 JobMaster,并向其提供插槽资源。JobMaster 将需要执行的任务分发给获得插槽的 TaskManager 。
- 任务执行:TaskManager 开始执行任务,在执行过程中,不同的 TaskManager 之间可能会进行数据交换,以完成复杂的数据处理逻辑 。
单作业模式
在 Yarn 模式的单作业模式下,我们可以直接提交作业,Yarn 会为每个作业单独启动一个 Flink 集群。提交作业的命令如下:
bash
bin/flink run -d -t yarn-per-job -c <类名> <jar包路径> [运行参数]
其中,-d参数表示作业提交之后,任务的执行与客户端没有关系,客户端可以与 JobManager 断开连接;-t参数指定部署模式为单作业模式(yarn-per-job);-c参数指定包含main方法的类名;<jar包路径>是作业的jar文件路径;[运行参数]是作业运行时需要的一些自定义参数。例如,提交一个 WordCount 作业,命令可以是:
bash
bin/flink run -d -t yarn-per-job -c com.example.WordCount /home/user/flink-jobs/wordcount.jar
提交作业后,我们可以使用以下命令查看作业状态:
bash
bin/flink list -t yarn-per-job -Dyarn.application.id=<应用ID>
这里的-Dyarn.application.id=<应用ID>参数用于指定要查看的 Yarn 应用的 ID,通过这个 ID 可以准确地获取到对应的作业状态信息。例如,查看 ID 为application_1632547890123_0001的应用中的作业状态,命令可以是:
bash
bin/flink list -t yarn-per-job -Dyarn.application.id=application_1632547890123_0001
如果需要取消作业,可以使用以下命令:
bash
bin/flink cancel -t yarn-per-job -Dyarn.application.id=<应用ID>
同样,-Dyarn.application.id=<应用ID>参数用于指定要取消的 Yarn 应用的 ID。例如,取消 ID 为application_1632547890123_0001的应用中的作业,命令可以是:
bash
bin/flink cancel -t yarn-per-job -Dyarn.application.id=application_1632547890123_0001
在单作业模式下,作业提交后,客户端与 JobManager 的连接可以断开,作业的执行由 Yarn 集群和 Flink 集群负责。Yarn 会为每个作业启动一个独立的 Flink 集群,包括 JobManager 和 TaskManager,作业之间的资源相互隔离,互不影响 。其任务执行流程与会话模式类似,JobManager 接收到作业后,将作业分发给 JobMaster,JobMaster 请求资源,Yarn 分配资源并启动 TaskManager,TaskManager 执行任务 。这种模式非常适合那些对资源隔离要求较高,或者作业之间相互影响较大的场景 。
Kubernetes 模式
Kubernetes 模式是 Flink 在 Kubernetes 容器编排平台上的部署方式,它充分利用了 Kubernetes 强大的容器管理和编排能力,使得 Flink 作业能够在容器化环境中高效、灵活地运行。Kubernetes 模式为 Flink 带来了诸多优势,如快速的部署和扩展能力、资源的高效利用以及良好的弹性和容错性。
在 Kubernetes 模式下提交 Flink 作业,基本步骤如下:
- 配置 Kubernetes 集群和 Flink 环境:首先,需要确保 Kubernetes 集群已经搭建并正常运行。然后,配置 Flink 运行所需的环境,包括安装 Flink 的相关依赖、设置环境变量等。这一步就像是搭建一个舞台,为 Flink 作业的表演做好准备 。
- 创建集群资源:在 Kubernetes 中,我们需要创建各种资源来支持 Flink 作业的运行,包括 ConfigMap、Deployment、Service 等。ConfigMap 用于存储 Flink 的配置文件,如flink-conf.yaml,可以将一些通用的配置参数放在这里;Deployment 用于定义 Flink 作业的 Pod 的部署方式,包括 Pod 的数量、资源限制等;Service 则用于暴露 Flink 作业的服务,使得外部可以访问到 Flink 的 WebUI 和相关接口 。例如,创建
总结
Flink 作为一款强大的大数据处理框架,其在不同模式下的提交流程各具特点,适应了多样化的应用场景和需求。在 Standalone 模式下,会话模式适合开发和测试环境中快速提交和执行作业,其提交流程相对简单直接,资源分配和任务调度在本地集群内完成 。而应用模式则为应用程序的独立运行提供了支持,通过手动启动和管理 TaskManager,给予开发者更多的控制权限。
Yarn 模式充分利用了 Yarn 强大的资源管理能力,会话模式下先开启会话再提交作业,适用于需要共享集群资源、运行多个作业的场景 。单作业模式则为每个作业单独启动集群,实现了作业之间的资源隔离,特别适合对资源隔离要求高的生产环境 。
Kubernetes 模式借助 Kubernetes 的容器编排能力,为 Flink 作业的部署和管理带来了更高的灵活性和可扩展性,在云原生环境中具有显著优势。
回顾 Flink 提交流程,提交命令是我们与 Flink 交互的入口,不同模式下的提交命令虽有差异,但都围绕着指定作业类、JAR 包路径以及相关运行参数展开 。资源申请与分配是提交流程的关键环节,涉及到 JobManager、ResourceManager 和 TaskManager 之间的协作,它们根据作业需求合理分配资源,确保任务能够顺利执行 。任务执行阶段,TaskManager 作为实际的执行者,按照 JobMaster 的调度,对数据进行处理和转换。