Flink知识散点

本文介绍了Apache Flink的执行原理,包括KeyBy操作的性能优化、执行环境的excute()方法的作用、FlinkRuntime层的整体架构及组件职责、作业提交流程、资源分配与任务调度机制,以及Flink支持的Per-job和Session两种作业执行模式。

1、KeyBy 操作后

只有当 Key 的数量大于算子的并发实例数才能获得较好的计算性能。
A.而若Key 的数量比实例数量少,就会导致部分实例收不到数据,这些实例就得不到执行,这些实例的计算能力得不到充分发挥。
B.当Key个数多余并行实例数时,由于同一个 Key 对应的所有数据都能发送到同一个计算实例上,同一个Key中所对应的数据都能分配到同一个实例中,这样Key内计算就免去了数据传递的序列化和网络IO等开销。

2、执行环境的excute()方法

前面我们调用的所有方法,都不是在实际处理数据,而是在构通表达计算逻辑的DAG图。只有当我们将整个图构建完成并显式调用 Execute 方法后,框架才会把计算图提交到集群中,接入数据并执行实际的逻辑。

3、Flink Runtime 层的整个架构主要是在 FLIP-6 中实现的,整体上采用了标准 master-slave 的结构。
其中master负责管理整个集群中的资源和作业;而TaskExecutor 则是 Slave,负责提供具体的资源并实际执行作业。

4、Master

部分又包含了三个组件,即 Dispatcher、ResourceManager 和 JobManager。
A.Dispatcher负责接收用户提供的作业,并且负责为这个新提交的作业拉起一个新的 JobManager 组件。
B.ResourceManager 负责资源的管理,在整个 Flink 集群中只有一个 ResourceManager。
C.JobManager 负责管理作业的执行,在一个 Flink 集群中可能有多个作业同时执行,每个作业都有自己的 JobManager 组件。
以上三个组件都包含在 AppMaster 进程中。

5、当用户提交作业时,提交脚本会先启动一个Client进程负责作业的编译与提交。

它先将用户编写的代码编译为一个 JobGraph,在这个过程,它还会进行一些检查或优化等工作,如判断哪些 Operator 可以 Chain 到同一个 Task 中。然后,Client 将产生的 JobGraph 提交到集群中执行。此时有两种情况,一种是类似于 Standalone 这种 Session 模式,AM 会预先启动,此时 Client 直接与 Dispatcher 建立连接并提交作业即可。另一种是 Per-Job 模式,AM 不会预先启动,此时 Client 将首先向资源管理系统 (如Yarn、K8S)申请资源来启动 AM,然后再向 AM 中的 Dispatcher 提交作业。

6、当作业到 Dispatcher 后

Dispatcher 会先启动一个 JobManager 组件,然后 JobManager 会向 ResourceManager 申请资源来启动作业中具体的任务。这时根据 Session 和 Per-Job 模式的区别, TaskExecutor 可能已经启动或者尚未启动。若是前者,此时 ResourceManager 中已有记录了 TaskExecutor 注册的资源,可以直接选取空闲资源进行分配。若是后者,ResourceManager 也需要先向外部资源管理系统申请资源来启动 TaskExecutor,然后等待 TaskExecutor 注册相应资源后再继续选择空闲资源进程分配。
目前 Flink 中 TaskExecutor 的资源是通过 Slot 来描述的,一个 Slot 一般可以执行一个具体的 Task,但在一些情况下也可以执行多个相关联的 Task。ResourceManager 选择到空闲的 Slot 之后,就会通知相应的 TM “将该 Slot 分配给 JobManager XX ”,然后 TaskExecutor 进行相应的记录后,会向 JobManager 进行注册。JobManager 收到 TaskExecutor 注册上来的 Slot 后,就可以实际提交 Task 了。TaskExecutor 收到 JobManager 提交的 Task 之后,会启动一个新的线程来执行该 Task。Task 启动后就会开始进行预先指定的计算,并通过数据 Shuffle 模块互相交换数据。

7、Flink 支持两种作业执行模式,即 Per-job 模式与 Session 模式。

7.1Per-job 模式下整个 Flink 集群只执行单个作业,即每个作业会独享 Dispatcher 和 ResourceManager 组件。此外,Per-job 模式下 AppMaster 和 TaskExecutor 都是按需申请的。因此,Per-job 模式更适合运行执行时间较长的大作业,这些作业对稳定性要求较高,并且对申请资源的时间不敏感。【一般配合yarn、mesose、k8s等外部资源管理器】
7.2与之对应,在 Session 模式下,Flink 预先启动 AppMaster 以及一组 TaskExecutor,然后在整个集群的生命周期中会执行多个作业。可以看出,Session 模式更适合规模小,执行时间短的作业。【一般在standalone模式下使用】

目录 01 事件驱动型应用 02 数据分析型应用 03 数据管道型应用 Flink的应用场景十分广泛,下面介绍3种常见的应用。 01 事件驱动型应用 在许多场景中,需要处理的数据往往来自事件。小到一些交互式的用户行为,大到一些复杂的业务操作,它们都会被转化成一条条数据,进而形成数据流(事件流)。事件驱动型应用的特在于,一些事件会触发特定的计算或其他外部行为,其典型场景有异常检测、反欺诈等。 在传统架构下,数据流通常会流入数据库,随后应用系统读取数据库中的数据,根据数据触发计算。在这种架构下,数据和计算分离,而且在存取数据时需要进行远程访问。与传统架构不同,Flink利用有状态的数据流来完成整个过程的处理,无须将数据先存入数据库再读取出来。数据流的状态数据在本地(local)维护,并且会周期性地持久化以实现容错。下图展示了传统事务型应用架构与Flink事件驱动型应用架构的区别。 传统事务型应用架构与Flink事件驱动型应用架构的区别 Flink事件驱动型应用架构的优势在于,它的状态数据在本地维护,不需要远程访问数据库,由此获得了更低的延迟、更高的吞吐量。同时,不像传统架构那样多个应用共享同一个数据库,任何对数据库的修改都需要谨慎协调,Flink事件驱动型应用架构中的每一个应用都独立地维护状态,可以灵活地进行扩/缩容。 从上面的介绍可以了解到,实现事件驱动型应用的关键在于支持“有状态的数据流”及容错机制。这是Flink最优秀的设计之一。这部分内容会在后文详细分析。 02 数据分析型应用 从历史发展的角度来看,企业要处理的数据量是由小到大变化的,因此不妨从传统企业的角度来看待数据分析型应用的演变。 过去,传统企业的数据分析型应用往往就是商务智能(business intelligence, BI)系统。一个成熟的BI产品是一套集数据清洗、数据分析、数据挖掘、报表展示等功能于一体的完整解决方案。不过,当数据量过大时传统的BI系统会出现性能瓶颈,而且它的底层是基于关系数据库的,处理非结构化数据时会十分乏力。因此,当今企业在进行技术选型和架构设计时,更倾向于选择Hadoop生态系统组件及其相关架构。 早期大数据场景下的数据分析型应用架构如图所示。 早期大数据场景下的数据分析型应用架构 上图充分体现了数据分析型应用的核心设计思想,即业务系统与分析系统分离。业务系统的数据周期性地转换并加载到数据仓库中,在数据仓库内部经过分层处理,最终标准化的数据被提供给其他应用使用。这种架构与BI系统的主要区别就是整个流程不再有完整的解决方案,而需要技术人员自己选择工具进行开发和组合。 流式架构 从传统的BI系统到早期大数据场景下的数据分析型应用架构,始终存在着一个问题,那就是整个过程中所有的抽取、转换、加载(Extract-Transform-Load, ETL)逻辑都是离线进行的,导致整个分析流程具有较高的延迟。由此,流式架构便应运而生。 流式架构的目的是在不丢失数据的前提下保证整个分析流程的低延迟,如上图图所示。 上图所示的整个流程少了ETL,直接将数据摄入流处理引擎,经过业务处理后输出给其他应用使用。在早期的技术储备条件下,想要保证低延迟,通常就难以保证结果的准确性,因此流式架构仅适用于那些对数据准确性要求不高,而对数据实时性要求极高的场景。 那么,在早期的技术储备条件下,能否通过架构的演进,既保证数据的实时性,又兼顾数据的准确性呢?开源框架Storm的创始人Nathan Marz提出了Lambda架构,有效地解决了这一问题。 Lambda架构的核心思想是实时处理和离线处理共存,实时处理如流处理一般保证数据的实时性,离线处理通过周期性地合并数据来保证数据的最终一致性。Lambda架构如图所示。 Lambda架构 在Lambda架构下,批处理层将准确结果写入批处理表,流处理层则将数据实时地写入速度表,批处理表的结果会定期与速度表中的数据合并以保证其准确性。数据应用则根据需求进行查询。 显而易见,虽然Lambda架构在一定程度上同时保证了数据的准确性与实时性,但它需要开发和维护两套系统,这实在是一笔不小的开销。由此,Kafka的核心成员之一Jay Kreps在Lambda架构的基础上提出了Kappa架构,解决了“两套代码实现一套业务逻辑”的问题。Kappa架构舍弃了批处理层,只保留了流处理层。与流式架构不同的是,Kappa架构需要让业务数据先进入支持数据重播的消息队列(如Kafka)。如果数据出现错误,那么再执行一个流处理作业,以对历史数据进行重新计算。当新启动的作业消费到最新的数据时,让外部应用访问新的服务数据库,完成服务的切换。Kappa架构如图所示。 Kappa架构 Kappa架构虽然不需要开发两套代码,但是仍然需要维护两套环境。而且,它所能处理的历史数据会受到消息队列存储策略的限制。 从Lambda架构和Kappa架构的提出者的技术背景可以了解到,他们提出的架构方案都是以他们熟悉的组件特性为基础的。Storm无法很好地保证数据的准确性,因此需要利用批处理层来保证数据的最终一致性。Kafka支持数据重播,因此可以只开发流处理层,在必要的时候对数据进行重播,从而保证数据的准确性。 Kappa架构之所以需要在两套环境中来回切换,主要是因为过去的流处理引擎无法保证数据的准确性,所以需要频繁地重新计算。如果流处理引擎能够像批处理引擎一样保证端到端的数据的最终一致性,从理论上来说就意味着一套环境可以解决所有问题。Flink完美地解决了这一问题。 以Flink作为流处理引擎,其架构如图所示。 link流式分析架构 Flink内部维护了数据流的状态,并以容错机制、窗口机制等特性作为支持,可以保证精确地实现端到端的数据的最终一致性。同时,Flink提供了从SQL到底层API的多层接口,使分析工作变得十分容易。因为Flink本身也能够进行批处理,所以Flink流式分析架构可以很容易地被转换成批处理架构。 对Kappa架构来说,可以直接选用Flink作为其中的流处理引擎,但此时设计两套环境的主要目的不再是保证数据的准确性,而是当Flink业务代码发生变动时可以执行新的作业,待数据消费到相同位置时及时完成服务的切换。 03 数据管道型应用 数据管道型应用也常常作为传统ETL流程的替代流程,与传统的ETL流程相比,其优势在于实时性高。Flink以流式的方式处理数据,无须像传统ETL流程一样进行周期性的离线处理。数据分析型应用实际上包含数据管道型应用,与数据分析型应用不同的是,数据管道型应用的侧重在于数据的流转。在数据管道型应用中,数据可能仅仅是从一个消息队列流转到另一个消息队列。 把这些知识都转化动画的方式用来讲解,使其更通俗易懂
07-16
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值