ToB企服应用市场:ToB评测及商务社交产业平台
标题:
Flink 架构学习总结
[打印本页]
作者:
泉缘泉
时间:
2023-9-11 19:04
标题:
Flink 架构学习总结
Flink是一个分布式系统,要求有效地分配和管理计算资源以执行流式应用程序。它集成了所有常见的集群资源管理器,如Hadoop YARN和Kubernetes,但也可以设置为作为standalone甚至库运行。
本节概述了Flink的体系结构,并描述了其主要组件如何交互以执行应用程序以及从故障中恢复。
Flink集群解析
Flink运行时由两种类型的进程组成:一个
JobManager
和一个或多个
TaskManager
。
Client
不是运行时和程序执行的一部分,而是用于准备数据流并将其发送到
JobManager
。之后,
Client
可以断开连接(分离模式),或者保持连接以接收进度报告(附加模式)。
Client
要么作为触发执行的Java/Scala程序的一部分运行,要么在命令行进程/bin/flink run ...中运行
JobManager
和
TaskManager
可以通过各种方式启动:直接在机器上作为
standalone
启动,在容器中启动,或者由
YARN
等资源框架管理。
TaskManager
连接到
JobManager
,宣布自己可用,并被分配工作。
JobManager
JobManager
有许多与协调Flink应用程序的分布式执行相关的职责:它决定何时安排下一个任务(或一组任务),对已完成或执行失败的任务做出反应,协调检查点,并协调故障恢复等。该进程由三个不同的组件组成:
ResourceManager
ResourceManager
负责Flink 集群中的资源分配和供应,管理任务槽(
task slots
) --是Flink集群的资源调度单元。Flink为不同的环境和资源提供商(如YARN、Kubernetes和独立部署)实现了多个
ResourceManager
。在
standalone
设置中,
ResourceManager
只能分配可用
TaskManager
的插槽,不能独立启动新的
TaskManager
。
Dispatcher
Dispatcher
提供了一个REST接口来提交Flink应用程序以供执行,并为每个提交的Job启动一个新的
JobMaster
。同时,
Dispatcher
还运行Flink WebUI提供job执行信息
JobMaster
JobMaster
负责管理单个
JobGraph
的执行。一个Flink cluster中可以同时运行多个
job
,每个
job
都有自己的
JobMaster
。
至少有一个
JobManager
。一个高可用性设置可能有多个
JobManager
,其中一个始终是
leader
,其他则是
备用(standby)
(请参阅
高可用性(HA)
)。
TaskManager
TaskManager
(也称为
worker
)执行数据流任务,缓冲和交换数据流。
必须始终至少有一个
TaskManager
。
TaskManager
中资源调度的最小单位是任务槽(task
slot
)。任务槽的数量表示并发处理任务的数量。请注意,可能在一个任务槽中执行多个
Operator
Task和算子(Operator)链
对于分布式执行,Flink 将算子的 subtasks
链接
成
tasks
。每个task由一个线程执行。将将
operator
链接成task是一种有用的优化:它减少了线程切换和缓冲的开销,并在降低延迟的同时提高了整体吞吐量。可以配置链接行为;请参阅
chaining docs
查看详细信息。
下图中的示例数据流由五个Subtask执行,因此由五个并行线程执行
Task Slot(任务槽)和资源
每个worker(
TaskManager
)都是一个JVM进程,可以在单独的线程中执行一个或多个子任务。为了控制单个
TaskManager
接受的任务数,就有了所谓的
task slot
(至少一个)。
每个
task slot
表示
TaskManager
的固定资源子集。例如,具有三个
slot
的
TaskManager
会将其托管内存的1/3专用于每个插槽。划分资源意味着
subtask
不会与其他作业的
subtask
争夺托管内存,而是有一定数量的保留托管内存。请注意,这里没有进行CPU隔离;当前
slot
仅隔离任务的托管内存。
通过调整
task slot
的数量,用户可以定义如何将
subtask
彼此隔离。
每个
TaskManager
有一个
slot
意味着每个任务组都在一个单独的JVM中运行
(例如,可以在一个独立的容器中启动)。
拥有多个
slot
意味着更多的
subtask
共享同一JVM
。同一JVM中的任务共享TCP连接(通过多路复用)和心跳消息。它们还可以共享数据集和数据结构,从而减少每个任务的开销。
默认情况下,Flink允许
subtask
共享
slot
,即使它们是不同
task
的
subtask
,只要来自同一
job
即可。结果就是,一个
slot
可以容纳
job
的整个管道。允许这种“
slot
共享”有两个主要好处:
Flink集群所需
task slot
与
job
使用的最大并行度保持一样。不需要计算一个程序总共包含多少任务(具有不同的并行度)。
更容易获得更好的资源利用率。如果没有“
slot
共享”,非密集型
subtask
(
source/map()
) 将阻塞与资源密集型
subtask
(
window
)一样多的资源。通过“
slot
共享”,将示例中的基本并行度从两个增加到六个,可以充分利用
slot
资源,同时确保繁重的
subtask
在
TaskManager
之间公平分配。
Flink 应用程序执行
集群生命周期
: Flink应用集群是一个专用的Flink集群,它只执行来自一个Flink应用的
job
,并且 main() 方法在集群上运行,而不是在
client
运行。
job
提交是一个一步到位的过程: 你不需要先启动Flink集群,然后向现有集群会话提交
job
,相反,你将应用程序逻辑和依赖项打包到一个可执行的作业JAR包中,集群入口点(ApplicationClusterEntryPoint) 负责调用main() 方法来提取
JobGraph
。这允许你像Kubernetes上的任何其他应用程序一样部署Flink应用程序。Flink应用程序集群的生命周期因此与Flink应用的生命周期绑定。
资源隔离
: 在Flink应用集群中,
ResourceManager
和
Dispatcher
的作用域为一个Flink应用,它提供了比Flink会话集群更好的隔离。
Flink Session集群
集群生命周期
: 在Flink会话集群中,客户端连接到一个预先存在的、长期运行的集群,该集群可以接受多个
job
提交。即使在所有
job
完成后,集群(和
JobManager
) 仍将继续运行,直到手动停止会话。因此,Flink会话集群的生存期不与任何Flink
job
的生存期绑定。
资源隔离
:
TaskManager
slot
由
ResourceManager
在提交
job
时分配,并在
job
完成后释放。因为所有作业都共享同一个集群,所以在提交
job
阶段存在一些集群资源竞争,比如网络带宽。这种共享设置的一个限制是,如果一个
TaskManager
崩溃,那么所有在该
TaskManager
上运行任务的
job
都将失败;类似的,如果
JobManager
上发生一些致命错误,它将影响集群中运行的所有
job
。
其他注意事项
: 拥有预先存在的集群可以节省大量申请资源和启动
TaskManager
的时间。在
job
的执行时间非常短,且启动时间过长会对端到端用户体验产生负面影响的情况下,这一点很重要——短查询的交互式分析就是这样,希望
job
可以使用现有资源快速执行计算。
以前,Flink会话集群也称为session mode下的Flink集群。
参考链接
https://nightlies.apache.org/flink/flink-docs-master/docs/concepts/flink-architecture/
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)
Powered by Discuz! X3.4