Flink系统架构

  原文链接:一文弄懂Flink基础理论

  Flink分布式程序包含2个主要的进程:JobManager和TaskManager.当程序运行时,不同的进程就会参与其中,包括Jobmanager、TaskManager和JobClient。

  当 Flink 集群启动后,首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager,JobManager 再调度任务到各个 TaskManager 去执行,然后 TaskManager 将心跳和统计信息汇报给 JobManager。TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。

JobManager

Master进程,负责Job的管理和资源的协调。包括任务调度,检查点管理,失败恢复等。

当然,对于集群HA模式,可以同时多个master进程,其中一个作为leader,其他作为standby。当leader失败时,会选出一个standby的master作为新的leader(通过zookeeper实现leader选举)。

JobManager包含了3个重要的组件:

###(1)Actor系统

Flink内部使用Akka模型作为JobManager和TaskManager之间的通信机制。

Actor系统是个容器,包含许多不同的Actor,这些Actor扮演者不同的角色。Actor系统提供类似于调度、配置、日志等服务,同时包含了所有actors初始化时的线程池。

所有的Actors存在着层级的关系。新加入的Actor会被分配一个父类的Actor。Actors之间的通信采用一个消息系统,每个Actor都有一个“邮箱”,用于读取消息。如果Actors是本地的,则消息在共享内存中共享;如果Actors是远程的,则消息通过RPC远程调用。

每个父类的Actor都负责监控其子类Actor,当子类Actor出现错误时,自己先尝试重启并修复错误;如果子类Actor不能修复,则将问题升级并由父类Actor处理。

在Flink中,actor是一个有状态和行为的容器。Actor的线程持续的处理从“邮箱”中接收到的消息。Actor中的状态和行为则由收到的消息决定。

###(2)调度
Flink中的Executors被定义为task slots(线程槽位)。每个Task Manager需要管理一个或多个task slots。
Flink通过SlotSharingGroup和CoLocationGroup来决定哪些task需要被共享,哪些task需要被单独的slot使用。
###(3)检查点

Flink的检查点机制是保证其一致性容错功能的骨架。它持续的为分布式的数据流和有状态的operator生成一致性的快照。Flink的容错机制持续的构建轻量级的分布式快照,因此负载非常低。通常这些有状态的快照都被放在HDFS中存储(state backend)。程序一旦失败,Flink将停止executor并从最近的完成了的检查点开始恢复(依赖可重发的数据源+快照)。

参考:三分钟掌握Flink基本概念和原理

运行架构

常用的类型和操作

参考:
Flink 原理与实现:数据流上的类型和操作:http://wuchong.me/blog/2016/05/20/flink-internals-streams-and-operations-on-streams
Flink Stream 算子:https://flink.sojb.cn/dev/stream/operators

程序结构介绍

Source,它是整个stream的入口。
Transformation,用于转换一个或多个DataStream从而形成一个新的DataStream对象。
Sink,它流的数据出口。

并行数据流

  Flink程序本质上是并行和分布式的。在程序执行期间,一个流会生成一个或者多个stream partition,并且一个operator会生成一个或者多个operator subtask。operator的 subtask 彼此之间是独立的,分别在不同的线程里去执行并且可能分布在不同的机器上或者containers上。
  operator的subtasks的数量等于该操作算子的并行度的数量。流的并行度有总是取决于产生它的操作算子的并行度决定的。同一个flink程序中的不同的operators可能有不同的并行度。

数据流在两个operators之间进行传递的方式有两种:one-to-one 模式 和 redistributing 模式

  • one-to-one 模式

两个operator用此模式传递的时候,会保持数据的分区数和数据的排序,比如:在下图中Source和map() operators之间的数据传递方式;

  • Redistributing 模式(重新分配模式)

这种模式会改变数据的分区数;每个一个operator subtask会根据选择transformation把数据发送到不同的目标subtasks,比如keyBy()会通过hashcode重新分区,broadcast()和rebalance()方法会随机重新分区,比如:在下图中map()和keyBy/window ,keyBy/window和Sink之间的数据传递方式;

Flink每个算子都可以设置并行度,然后就是也可以设置全局并行度。
api设置.map(new RollingAdditionMapper()).setParallelism(10)
全局配置在flink-conf.yaml文件中,parallelism.default,默认是1

Task and Operator Chains

为了更高效地分布式执行,Flink会尽可能地将operator的subtask链接(chain)在一起形成task。每个task在一个线程中执行。将operators链接成task是非常有效的优化:它能减少线程之间的切换,减少消息的序列化/反序列化,减少数据在缓冲区的交换,减少了延迟的同时提高整体的吞吐量。

可以进行Operator chains的条件
1、上下游的并行度一致
2、下游节点的入度为1 (也就是说下游节点没有来自其他节点的输入)
3、上下游节点都在同一个 slot group 中(下面会解释 slot group)
4、下游节点的 chain 策略为 ALWAYS(可以与上下游链接,map、flatmap、filter等默认是ALWAYS)
5、上游节点的 chain 策略为 ALWAYS 或 HEAD(只能与下游链接,不能与上游链接,Source默认是HEAD)
6、两个节点间数据分区方式是 forward(参考理解数据流的分区)
7、用户没有禁用 chain
————————————————

原文地址:https://www.cnblogs.com/jifengblog/p/12397309.html

时间: 2024-10-17 02:51:06

Flink系统架构的相关文章

系统架构师(java)和大数据架构师

架构师不是一个职业工种,而是一种能力,而且架构师也分很多种,不同领域的架构师是不一样的.比如互联网架构师和物联网架构师,没有什么可对比的.架构要考虑什么1.考虑系统能做什么,不能做什么,就是常说的系统边界2.确定架构内部的模块与模块之间的关系,以及module与外部是什么关系3.确定非功能性需要,架构的可扩展性,可用性,可维护性以及安全性4.架构确定以后要能够指导开发人员根据架构思想去设计和演化,确保开发出来的东西和架构的规划是一致的.Java系统架构师 系统的技术选型以及可行性评估 分布式技术

秒杀系统架构分析与实战

0 系列目录 秒杀系统架构 秒杀系统架构分析与实战 1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要面对的技术挑战有: 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,

大型网站系统架构的演化(转)

前言 一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线.所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就:不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索.下单.支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各

dubbo框架----探索-大型系统架构设计(图解)

对于高并发系统的架构要求: 1. 负载均衡 2.高并发 3.高可用 4.面向服务架构 (Dubbo框架使用) 5.分布式缓存 (redis分布式缓存) 6.分布式全文检索 (solr分分布式全文检索) 7.分布式数据库集群 (mycat 集群mysql数据库) dubbo  简介 系统架构 redis 集群 solr 集群 mysql 集群

ios系统架构及常用框架

1.iOS基于UNIX系统,因此从系统的稳定性上来说它要比其他操作系统的产品好很多 2.iOS的系统架构分为四层,由上到下一次为:可触摸层(Cocoa Touch layer).媒体层(Media layer).核心服务层(Core Services layer).核心操作系统层(Core OS layer)如图: (1) 触摸层:为应用程序开发提供了各种常用的框架并且大部分框架与界面有关,本质上来说它负责用户在iOS设备上的触摸交互操作.它包括以下这些组件: Multi-Touch Event

软件体系结构---安卓系统架构之应用程序框架层分析---1

本博客只介绍安卓系统架构中的应用程序框架层 什么是应用程序框架? 应用程序框架可以说是一个应用程序的核心,是所有参与开发的程序员共同使用和遵守的约定,大家在其约定上进行必要的扩展,但程序始终保持主体结构的一致性.其作用是让程序保持清晰和一目了然,在满足不同需求的同时又不互相影响. 而对于安卓来说:Android系统提供给应用开发者的本身就是一个框架,所有的应用开发都必须遵守这个框架的原则.我们在开发应用时就是在这个框架上进行扩展.在这个框架中我们可以完全访问核心应用程序所使用的API框架,即我们

企业内部IT一体化系列之一:系统架构

有个构想,将企业内部IT的日常运维,管理以及员工服务等日常全部集合和汇总到一起,说起来简单,其实相当复杂,因为自己在之前的公司曾经做过,虽然还未做完,但是构想有了,期待能有机会实施,现在先把可行的成果展示出来,主要是以前技术定级的时候写的ppt的图,凑合看看吧. 平台架构: 这图是微软给的私有云体系,我基本就是照着这个来做的. 下图是我目前整个系统所有的架构: 大概讲解一下: 1:首先整个企业IT统一管理平台需要一个登入的接口,或者说WEB的平台,那么我用SharePoint来做,WFE01,W

适应多场景应用的web系统架构探讨

背景: 虽然身处互联网时代,但还有很多信息系统仍运行在内部网络中,例如,企事业内部的OA系统,医院的HIS系统,银行的管理系统等.软件公司会针对系统应用环境,对信息系统进行逻辑业务上的修改.因此,本文主要介绍一种适应于多场景应用的web系统架构,供相关人员讨论研究. 1 系统框架图 2 分层的优势 (1)解耦:降低代码耦合度,允许前后端的分离,显示与业务的分离,前端开发与后台开发的分离. (2)复用:面向接口编程,面向接口实现,面向接口形成文档,提高接口函数的复用. (3)固化通用业务逻辑. (

Unity3D手游开发日记(2) - 技能系统架构设计

我想把技能做的比较牛逼,所以项目一开始我就在思考,是否需要一个灵活自由的技能系统架构设计,传统的技能设计,做法都是填excel表,技能需要什么,都填表里,很死板,比如有的技能只需要1个特效,有的要10个,那么表格也得预留10个特效的字段.在代码里面也是写死一些东西,要增加和修改,就得改核心代码,如果我要把核心部分做成库封装起来,就很麻烦了. 能不能做成数据驱动的方式呢? 改技能文件就行了,即使要增加功能,也只需要扩展外部代码,而不用改核心代码, 我是这么来抽象一个技能的,技能由一堆触发器组成,比