10分钟入门Flink--架构和原理

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: 相信你读完上一节的[《10分钟入门Flink--了解Flink》](https://mp.weixin.qq.com/s?__biz=MzI3OTA2MDQyOQ==&mid=2247483800&idx=1&sn=bcba92c8bc5081ec481f0ec01926ce26&chksm=eb4ccb3adc3b422cbae3bc577525f8611bcbb76b5ac4e5d395d5ee85f26897e27846b68bc4b8&token=2145213332&lang=zh_CN#rd)对Flink已经有初步了解了。这是继第一节之后的Flink入门系列的第二篇,本篇主要内容是

相信你读完上一节的《10分钟入门Flink--了解Flink》对Flink已经有初步了解了。这是继第一节之后的Flink入门系列的第二篇,本篇主要内容是是:了解Flink运行模式、Flink调度原理、Flink分区、Flink安装。

1、运行模式

Flink有多种运行模式,可以运行在一台机器上,称为本地(单机)模式;也可以使用YARN作为底层资源调度系统以分布式的方式在集群中运行,称为Flink On YARN模式;还可以使用Flink自带的资源调度系统,不依赖其他系统,称为Flink Standalone模式。还有将Flink部署到Kubernetes的模式,称为Flink On Kubernetes模式。

1.1、单机(本地)模式

直接下载jar包后启动。

1.2、Flink Standalone模式

先一起看下这种模式运行架构图:

Flink Standalone模式为经典的主从(Master/Slave)架构,资源调度是Flink自己实现的。集群启动后,主节点上会启动一个JobManager进程,类似YARN集群的ResourceManager,因此主节点也称为JobManager节点;各个从节点上会启动一个TaskManager进程,类似YARN集群的NodeManager,因此从节点也称为TaskManager节点。

执行流程:Client接收到Flink应用程序后,将作业提交给JobManager。JobManager要做的第一件事就是分配Task(任务)所需的资源。完成资源分配后,Task将被JobManager提交给相应的TaskManager,TaskManager会启动线程开始执行。在执行过程中,TaskManager会持续向JobManager汇报状态信息,例如开始执行、进行中或完成等状态。作业执行完成后,结果将通过JobManager发送给Client。

各组件作用:

Client :Client是提交作业的客户端,虽然不是运行时和作业执行时的一部分,但它负责准备和提交作业到JobManager,它可以运行在任何机器上,只要与JobManager环境连通即可。

JobManager :JobManager根据客户端提交的应用将应用分解为子任务,从资源管理器(YARN等)申请所需的计算资源,然后分发任务到TaskManager执行,并跟踪作业的执行状态等。JobManager的主要作用是协调资源分配、任务调度、故障恢复等。整个集群有且仅有一个活跃的JobManager。

TaskManager :TaskManager是Flink集群的工作进程。Task被调度到TaskManager上执行。TaskManager相互通信,只为在后续的Task之间交换数据。TaskManager工作内容:

  1. 接收JobManager分配的任务,负责具体的任务执行。TaskManager会在同一个JVM进程内以多线程的方式执行任务
  2. 负责对应任务在每个节点上的资源申请,管理任务的启动、停止、销毁、异常恢复等生命周期。
  3. 负责对数据进行缓存。TaskManager之间采用数据流的形式进行数据交互。

Task :Flink中的每一个操作算子称为一个Task(任务)。Task是基本的工作单元,由Flink的Runtime来执行。每个Task在一个JVM线程中执行。多个Task可以在同一个JVM进程中共享TCP连接(通过多路复用技术)和心跳信息。它们还可能共享数据集和数据结构,从而降低每个Task的开销。

Task Slot :TaskManager为了控制执行的Task数量,将计算资源(内存)划分为多个Task Slot(任务槽),每个Task Slot代表TaskManager的一份固定内存资源,Task则在Task Slot中执行。

1.3、Flink On YARN模式

先来回顾下yarn的集群架构:

Flink On YARN模式遵循YARN的官方规范,YARN只负责资源的管理和调度,运行哪种应用程序由用户自己实现,因此可能在YARN上同时运行MapReduce程序、Spark程序、Flink程序等。

Flink On YARN模式下的运行架构:

1.4、Flink On Kubernetes模式

这种模式我没用过,不做介绍,感兴趣的朋友可以自行查阅。

2、调度原理

2.1、任务链

Flink中的每一个操作算子称为一个Task(任务),算子的每个具体实例则称为SubTask(子任务),SubTask是Flink中最小的处理单元,多个SubTask可能在不同的机器上执行。一个TaskManager进程包含一个或多个执行线程,用于执行SubTask。TaskManager中的一个Task Slot对应一个执行线程,一个执行线程可以执行一个或多个SubTask。他们的结构如下图所示:

由于每个SubTask只能在一个线程中执行,为了能够减少线程间切换和缓冲的开销,在降低延迟的同时提高整体吞吐量,Flink可以将多个连续的SubTask链接成一个Task在一个线程中执行。这种将多个SubTask连在一起的方式称为任务链。任务链的结构如下图所示:

2.2、并行度

Flink应用程序可以在分布式集群上并行运行,其中每个算子的各个并行实例会在单独的线程中独立运行,并且通常情况下会在不同的机器上运行。为了充分利用计算资源,提高计算效率,可以增加算子的实例数(SubTask数量)。一个特定算子的SubTask数量称为该算子的并行度,且任意两个算子的并行度之间是独立的,不同算子可能拥有不同的并行度。如下图所示,将Source算子、map()算子、keyby()/window()/apply()算子的并行度设置为2,Sink算子的并行度设置为1。运行效果如下图所示:

2.3、数据流

一个Flink应用程序会被映射成逻辑数据流(Dataflow),而Dataflow都是以一个或多个Source开始、以一个或多个Sink结束的,且始终包括Source、Transformation、Sink三部分。

Dataflow描述了数据如何在不同算子之间流动,将这些算子用带方向的直线连接起来会形成一个关于计算路径的有向无环图,称为DAG(Directed Acyclic Graph,有向无环图)或Dataflow图。各个算子的中间数据会被保存在内存中。

Flink算子组成的DAG,如下图所示:

程序的Dataflow图,如下图所示:

2.3、执行图

Flink应用程序执行时会根据数据流生成多种图,转成执行图,每种图对应了作业的不同阶段,根据不同图的生成顺序,主要分为4层:StreamGraph→JobGraph→ExecutionGraph→物理执行图。具体过程见下图:

  • StreamGraph:流图。使用DataStream API编写的应用程序生成的最初的图代表程序的拓扑结构,描述了程序的执行逻辑。StreamGraph在Flink客户端中生成,在客户端应用程序最后调用execute()方法时触发StreamGraph的构建。
  • JobGraph:作业图。所有高级别API都需要转换为JobGraph。StreamGraph经过优化(例如任务链)后生成了JobGraph,以提高执行效率。StreamGraph和JobGraph都是在本地客户端生成的数据结构,而JobGraph需要被提交给JobManager进行解析。
  • ExecutionGraph:执行图。JobManager对JobGraph进行解析后生成的并行化执行图是调度层最核心的数据结构。它包含对每个中间数据集或数据流、每个并行任务以及它们之间的通信的描述。
  • 物理执行图:JobManager根据ExecutionGraph对作业进行调度后,在各个TaskManager上部署Task后形成的“图”。物理执行图并不是一个具体的数据结构,而是各个Task分布在不同的节点上所形成的物理上的关系表示。

2.4、执行计划

Flink的优化器会根据数据量或集群机器数等的不同自动地为程序选择执行策略。

3、数据分区

3.1、分区概念

在Flink中,数据流或数据集被划分成多个独立的子集,这些子集分布到了不同的节点上,而每一个子集称为分区(Partition)。因此可以说,Flink中的数据流或数据集是由若干个分区组成的。

3.2、分区数量

在运行期间,每个数据记录将被分配给一个或多个分区,各个分区中的数据可以并行计算。我们已经知道,数据是由上游算子的某个实例(SubTask)发往下游算子的一个或多个实例,而一个算子实例只负责计算一个分区的数据。因此,分区的数量是由下游算子的实例数量(并行度)决定的,发往下游算子的数据分区数量等于下游算子的实例数量。

数据分区的一个原则是使得分区的数量尽量等于集群节点CPU的核心数量。

3.3、分区策略

Flink分区策略决定了一条数据如何发送给下游算子的不同实例。

  • 转发策略

  • 广播策略

  • 键值策略

  • 随机策略

  • 全局策略

  • 自定义策略
    如果内置的分区策略不能满足当前需求,则可以在程序中自定义分区策略。这块后续再介绍。

4、安装

具体安装步骤参见下一篇。文中会介绍Flink Standalone的集群安装。

感谢你的阅读,欢迎关注、点赞、收藏!!!

原文链接:https://mp.weixin.qq.com/s/GwNQNHTr0-NrrajCoRM6Ag

相关实践学习
基于Hologres轻松玩转一站式实时仓库
本场景介绍如何利用阿里云MaxCompute、实时计算Flink和交互式分析服务Hologres开发离线、实时数据融合分析的数据大屏应用。
Linux入门到精通
本套课程是从入门开始的Linux学习课程,适合初学者阅读。由浅入深案例丰富,通俗易懂。主要涉及基础的系统操作以及工作中常用的各种服务软件的应用、部署和优化。即使是零基础的学员,只要能够坚持把所有章节都学完,也一定会受益匪浅。
目录
打赏
0
0
0
0
140
分享
相关文章
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
196 21
RocketMQ原理—5.高可用+高并发+高性能架构
蚂蚁 Flink 实时计算编译任务 Koupleless 架构改造
本文介绍了对Flink实时计算编译任务的Koupleless架构改造。为解决进程模型带来的响应慢、资源消耗大等问题,团队将进程模型改为线程模型,并借助Koupleless的类加载隔离能力实现版本和包的隔离。通过动态装配Plugin及其Classpath,以及Biz运行时仅对依赖Plugin可见的设计,大幅优化了编译任务的性能。结果表明,新架构使编译耗时降低50%,吞吐量提升5倍以上。
蚂蚁 Flink 实时计算编译任务 Koupleless 架构改造
基于LlamaIndex实现CodeAct Agent:代码执行工作流的技术架构与原理
CodeAct是一种先进的AI辅助系统范式,深度融合自然语言处理与代码执行能力。通过自定义代码执行代理,开发者可精准控制代码生成、执行及管理流程。本文基于LlamaIndex框架构建CodeAct Agent,解析其技术架构,包括代码执行环境、工作流定义系统、提示工程机制和状态管理系统。同时探讨安全性考量及应用场景,如软件开发、数据科学和教育领域。未来发展方向涵盖更精细的代码生成、多语言支持及更强的安全隔离机制,推动AI辅助编程边界拓展。
60 3
基于LlamaIndex实现CodeAct Agent:代码执行工作流的技术架构与原理
深入解析Tiktokenizer:大语言模型中核心分词技术的原理与架构
Tiktokenizer 是一款现代分词工具,旨在高效、智能地将文本转换为机器可处理的离散单元(token)。它不仅超越了传统的空格分割和正则表达式匹配方法,还结合了上下文感知能力,适应复杂语言结构。Tiktokenizer 的核心特性包括自适应 token 分割、高效编码能力和出色的可扩展性,使其适用于从聊天机器人到大规模文本分析等多种应用场景。通过模块化设计,Tiktokenizer 确保了代码的可重用性和维护性,并在分词精度、处理效率和灵活性方面表现出色。此外,它支持多语言处理、表情符号识别和领域特定文本处理,能够应对各种复杂的文本输入需求。
167 6
深入解析Tiktokenizer:大语言模型中核心分词技术的原理与架构
Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
本文介绍了阿里云实时数仓Hologres负责人姜伟华在Flink Forward Asia 2024上的分享,涵盖实时数仓的发展历程、从实时数仓到实时湖仓的演进,以及总结。文章通过三代实时数仓架构的演变,详细解析了Lambda架构、Kafka实时数仓分层+OLAP、Hologres实时数仓分层复用等方案,并探讨了未来从实时数仓到实时湖仓的演进方向。最后,结合实际案例和Demo展示了Hologres + Flink + Paimon在实时湖仓中的应用,帮助用户根据业务需求选择合适的方案。
686 20
Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
​Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
​Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
MySQL原理简介—2.InnoDB架构原理和执行流程
本文介绍了MySQL中更新语句的执行流程及其背后的机制,主要包括: 1. **更新语句的执行流程**:从SQL解析到执行器调用InnoDB存储引擎接口。 2. **Buffer Pool缓冲池**:缓存磁盘数据,减少磁盘I/O。 3. **Undo日志**:记录更新前的数据,支持事务回滚。 4. **Redo日志**:确保事务持久性,防止宕机导致的数据丢失。 5. **Binlog日志**:记录逻辑操作,用于数据恢复和主从复制。 6. **事务提交机制**:包括redo日志和binlog日志的刷盘策略,确保数据一致性。 7. **后台IO线程**:将内存中的脏数据异步刷入磁盘。
164 12
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
95 12
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
124 3
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等