美文网首页
flink--架构、运行、调度原理

flink--架构、运行、调度原理

作者: tracy_668 | 来源:发表于2020-12-31 08:12 被阅读0次

    [TOC]

    flink是什么

    Flink主页在其顶部展示了该项目的理念:“Apache Flink是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架”。Apache Flink是一个框架和分布式处理引擎,用于对***和有界数据流进行有状态计算。Flink被设计在所有常见的集群环境中运行,以内存执行速度和任意规模来执行计算。

    flink基本框架

    批处理的特点是有界、持久、大量,批处理非常适合需要访问全套记录才能完成的计算工作,一般用于离线统计。流处理的特点是***、实时,流处理方式无需针对整个数据集执行操作,而是对通过系统传输的每个数据项执行操作,一般用于实时统计。

    在Spark生态体系中,对于批处理和流处理采用了不同的技术框架,批处理由SparkSQL实现,流处理由Spark Streaming实现,这也是大部分框架采用的策略,使用独立的处理器实现批处理和流处理,而Flink可以同时实现批处理和流处理。

    Flink是如何同时实现批处理与流处理的呢?答案是,Flink将批处理(即处理有限的静态数据)视作一种特殊的流处理。

    Flink的核心计算架构是下图中的Flink Runtime执行引擎,它是一个分布式系统,能够接受数据流程序并在一台或多台机器上以容错方式执行。

    Flink Runtime执行引擎可以作为YARN(Yet Another Resource Negotiator)的应用程序在集群上运行,也可以在Mesos集群上运行,还可以在单机上运行(这对于调试Flink应用程序来说非常有用)。

    image.png

    上图为Flink技术栈的核心组成部分,值得一提的是,Flink分别提供了面向流式处理的接口(DataStream API)和面向批处理的接口(DataSet API)。因此,Flink既可以完成流处理,也可以完成批处理。Flink支持的拓展库涉及机器学习(FlinkML)、复杂事件处理(CEP)、以及图计算(Gelly),还有分别针对流处理和批处理的Table API。

    能被Flink Runtime执行引擎接受的程序很强大,但是这样的程序有着冗长的代码,编写起来也很费力,基于这个原因,Flink提供了封装在Runtime执行引擎之上的API,以帮助用户方便地生成流式计算程序。Flink 提供了用于流处理的DataStream API和用于批处理的DataSet API。值得注意的是,尽管Flink Runtime执行引擎是基于流处理的,但是DataSet API先于DataStream API被开发出来,这是因为工业界对无限流处理的需求在Flink诞生之初并不大。

    DataStream API可以流畅地分析无限数据流,并且可以用Java或者Scala来实现。开发人员需要基于一个叫DataStream的数据结构来开发,这个数据结构用于表示永不停止的分布式数据流。

    Flink的分布式特点体现在它能够在成百上千台机器上运行,它将大型的计算任务分成许多小的部分,每个机器执行一部分。Flink能够自动地确保发生机器故障或者其他错误时计算能够持续进行,或者在修复bug或进行版本升级后有计划地再执行一次。这种能力使得开发人员不需要担心运行失败。Flink本质上使用容错性数据流,这使得开发人员可以分析持续生成且永远不结束的数据(即流处理)。

    1.4 无穷数据流和有限数据流

    无穷数据集:无穷的持续集合的数据集合
    有限数据集:有限不会改变的数据集合

    常见的无穷数据集合有:
    用户与客户端的实时交互数据
    应用实时产生的日志
    金融市场的实时交易记录

    1.6 flink特性

    1、高吞吐和低延迟性

    2、支持 Event Time 和乱序事件
    Flink 支持了流处理和 Event Time 语义的窗口机制。
    Event time 使得计算乱序到达的事件或可能延迟到达的事件更加简单。

    3、状态计算的 exactly-once 语义
    故障状态下,需要重启计算任务,这时候需要避免已经处理过的数据的重复处理。
    流程序可以在计算过程中维护自定义状态。
    Flink 的 checkpointing 机制保证了即时在故障发生下也能保障状态的 exactly once 语义。

    4、高度灵活的流式窗口
    Flink 支持在时间窗口,统计窗口,session 窗口,以及数据驱动的窗口
    窗口可以通过灵活的触发条件来定制,以支持复杂的流计算模式。

    5、带反压的连续流模型
    数据流应用执行的是不间断的(常驻)operators。
    Flink streaming 在运行时有着天然的流控:慢的数据 sink 节点会反压(backpressure)快的数据源(sources)。

    6、容错性
    Flink 的容错机制是基于 Chandy-Lamport distributed snapshots 来实现的。
    这种机制是非常轻量级的,允许系统拥有高吞吐率的同时还能提供强一致性的保障。

    7、Batch 和 Streaming 一个系统流处理和批处理共用一个引擎
    Flink 为流处理和批处理应用公用一个通用的引擎。批处理应用可以以一种特殊的流处理应用高效地运行。

    8、内存管理
    Flink 在 JVM 中实现了自己的内存管理。
    应用可以超出主内存的大小限制,并且承受更少的垃圾收集的开销。

    二、Flink基本架构

    2.1 flink中的角色

    Flink运行时包含了两种类型的处理器:

    JobManager处理器:也称之为Master,用于协调分布式执行,它们用来调度task,协调检查点,协调失败时恢复等。Flink运行时至少存在一个master处理器,如果配置高可用模式则会存在多个master处理器,它们其中有一个是leader,而其他的都是standby。

    TaskManager处理器:也称之为Worker,用于执行一个dataflow的task(或者特殊的subtask)、数据缓冲和data stream的交换,Flink运行时至少会存在一个worker处理器。

    image.png

    Master和Worker处理器可以直接在物理机上启动,或者通过像YARN这样的资源调度框架。Worker连接到Master,告知自身的可用性进而获得任务分配。

    2.2 ***数据流与有界数据流

    数据流:
    数据流有一个开始但是没有结束,它们不会在生成时终止并提供数据,必须连续处理流,也就是说必须在获取后立即处理event。对于
    数据流我们无法等待所有数据都到达,因为输入是的,并且在任何时间点都不会完成。处理数据通常要求以特定顺序(例如事件发生的顺序)获取event,以便能够推断结果完整性。

    有界数据流:
    有界数据流有明确定义的开始和结束,可以在执行任何计算之前通过获取所有数据来处理有界流,处理有界流不需要有序获取,因为可以始终对有界数据集进行排序,有界流的处理也称为批处理。

    Apache Flink是一个面向分布式数据流处理和批量数据处理的开源计算平台,它能够基于同一个Flink运行时(Flink Runtime),提供支持流处理和批处理两种类型应用的功能。现有的开源计算方案,会把流处理和批处理作为两种不同的应用类型,因为它们要实现的目标是完全不相同的:流处理一般需要支持低延迟、Exactly-once保证,而批处理需要支持高吞吐、高效处理,所以在实现的时候通常是分别给出两套实现方法,或者通过一个独立的开源框架来实现其中每一种处理方案。例如,实现批处理的开源方案有MapReduce、Tez、Crunch、Spark,实现流处理的开源方案有Samza、Storm。

    Flink在实现流处理和批处理时,与传统的一些方案完全不同,它从另一个视角看待流处理和批处理,将二者统一起来:Flink是完全支持流处理,也就是说作为流处理看待时输入数据流是***的;批处理被作为一种特殊的流处理,只是它的输入数据流被定义为有界的。基于同一个Flink运行时(Flink Runtime),分别提供了流处理和批处理API,而这两种API也是实现上层面向流处理、批处理类型应用框架的基础。

    2.3 flink数据流编程接口抽象

    Flink提供了不同级别的抽象,以开发流或批处理作业,如下图所示:


    image.png

    最底层级的抽象仅仅提供了有状态流,它将通过过程函数(Process Function)被嵌入到DataStream API中。底层过程函数(Process Function) 与 DataStream API 相集成,使其可以对某些特定的操作进行底层的抽象,它允许用户可以自由地处理来自一个或多个数据流的事件,并使用一致的容错的状态。除此之外,用户可以注册事件时间并处理时间回调,从而使程序可以处理复杂的计算。

    实际上,大多数应用并不需要上述的底层抽象,而是针对核心API(Core APIs) 进行编程,比如DataStream API(有界或***流数据)以及DataSet API(有界数据集)。这些API为数据处理提供了通用的构建模块,比如由用户定义的多种形式的转换(transformations),连接(joins),聚合(aggregations),窗口操作(windows)等等。DataSet API 为有界数据集提供了额外的支持,例如循环与迭代。这些API处理的数据类型以类(classes)的形式由各自的编程语言所表示。

    Table API 是以表为中心的声明式编程,其中表可能会动态变化(在表达流数据时)。Table API遵循(扩展的)关系模型:表有二维数据结构(schema)(类似于关系数据库中的表),同时API提供可比较的操作,例如select、project、join、group-by、aggregate等。Table API程序声明式地定义了什么逻辑操作应该执行,而不是准确地确定这些操作代码的看上去如何 。 尽管Table API可以通过多种类型的用户自定义函数(UDF)进行扩展,其仍不如核心API更具表达能力,但是使用起来却更加简洁(代码量更少)。除此之外,Table API程序在执行之前会经过内置优化器进行优化。

    你可以在表与 DataStream/DataSet 之间无缝切换,以允许程序将 Table API 与 DataStream 以及 DataSet 混合使用。

    Flink提供的最高层级的抽象是 SQL 。这一层抽象在语法与表达能力上与 Table API 类似,但是是以SQL查询表达式的形式表现程序。SQL抽象与Table API交互密切,同时SQL查询可以直接在Table API定义的表上执行。

    三、flink运行架构

    3.1 提交任务到yarn的流程

    flink在生产中,一般是使用yarn作为资源调度平台,比较少使用standalone的方式进行资源调度。所以这里以yarn为例,说明flink提交任务到yarn的流程。

    image.png

    Flink任务提交后,Client向HDFS上传Flink的Jar包和配置,之后向Yarn ResourceManager提交任务,ResourceManager分配Container资源并通知对应的NodeManager启动ApplicationMaster,ApplicationMaster启动后加载Flink的Jar包和配置构建环境,然后启动JobManager,之后ApplicationMaster向ResourceManager申请资源启动TaskManager,ResourceManager分配Container资源后,由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager,NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager,TaskManager启动后向JobManager发送心跳包,并等待JobManager向其分配任务。

    3.2 任务调度组件

    image.png

    1、 Program Code:我们编写的 Flink 应用程序代码

    2、 Job Client:Job Client 不是 Flink 程序执行的内部部分,但它是任务执行的起点。 Job Client 负责接受用户的程序代码,然后创建数据流,将数据流提交给 Job Manager 以便进一步执行。 执行完成后,Job Client 将结果返回给用户

    1. 3、 JobManager:主进程(也称为作业管理器)协调和管理程序的执行。 它的主要职责包括安排任务,管理checkpoint ,故障恢复等。机器集群中至少要有一个 master,master 负责调度 task,协调 checkpoints 和容灾,高可用设置的话可以有多个 master,但要保证一个是active, 其他是 standby; Job Manager 包含 Actor system(通信系统)、Scheduler(调度)、Check pointing 三个重要的组件

    4、 Task Manager:从 Job Manager 处接收需要部署的 Task。Task Manager 是在 JVM 中的一个或多个线程中执行任务的工作节点。 任务执行的并行性由每个 Task Manager 上可用的任务槽(task slot)决定。 每个任务代表分配给任务槽的一组资源。 例如,如果 Task Manager 有四个插槽,那么它将为每个插槽分配 25% 的内存。 可以在任务槽中运行一个或多个线程。 同一插槽中的线程共享相同的 JVM。 同一 JVM 中的任务共享 TCP 连接和心跳消息。Task Manager 的一个 Slot 代表一个可用线程,该线程具有固定的内存,注意 Slot 只对内存隔离,没有对 CPU 隔离。默认情况下,Flink 允许子任务共享 Slot,即使它们是不同 task 的 subtask,只要它们来自相同的 job。这种共享可以有更好的资源利用率。

    3.3 TaskManager和slots原理

    每一个worker(TaskManager)是一个JVM进程,它可能会在独立的线程上执行一个或多个subtask。为了控制一个worker能接收多少个task,worker通过task slot来进行控制(一个worker至少有一个task slot)。

    每个task slot表示TaskManager拥有资源的一个固定大小的子集。假如一个TaskManager有三个slot,那么它会将其管理的内存平均分成三份给各个slot。资源slot化意味着一个subtask将不需要跟来自其他job的subtask竞争被管理的内存,取而代之的是它将拥有一定数量的内存储备。需要注意的是,这里不会涉及到CPU的隔离,slot目前仅仅用来隔离task的受管理的内存。

    通过调整task slot的数量,允许用户定义subtask之间如何互相隔离。如果一个TaskManager一个slot,那将意味着每个task group运行在独立的JVM中(该JVM可能是通过一个特定的容器启动的),而一个TaskManager多个slot意味着更多的subtask可以共享同一个JVM。而在同一个JVM进程中的task将共享TCP连接(基于多路复用)和心跳消息。它们也可能共享数据集和数据结构,因此这减少了每个task的负载。

    image.png

    Task Slot是静态的概念,是指TaskManager具有的并发执行能力,可以通过参数taskmanager.numberOfTaskSlots进行配置,而并行度parallelism是动态概念,即TaskManager运行程序时实际使用的并发能力,可以通过参数parallelism.default进行配置。

    也就是说,假设一共有3个TaskManager,每一个TaskManager中的分配3个TaskSlot,也就是每个TaskManager可以接收3个task,一共9个TaskSlot,如果我们设置parallelism.default=1,即运行程序默认的并行度为1,9个TaskSlot只用了1个,有8个空闲,因此,设置合适的并行度才能提高效率。实际上slots限制的限制了该taskmanager在整个集群中能够并行运行task的数目,而parallelism.default则是限制单个job能够使用slot的数量,但是允许多个job同时运行,所以实际上是对单个job的并发限制。

    3.4 程序与数据流

    Flink程序的基础构建模块是 流(streams) 与 转换(transformations)(需要注意的是,Flink的DataSet API所使用的DataSets其内部也是stream)。一个stream可以看成一个中间结果,而一个transformations是以一个或多个stream作为输入的某种operation,该operation利用这些stream进行计算从而产生一个或多个result stream。

    在运行时,Flink上运行的程序会被映射成streaming dataflows,它包含了streams和transformations operators。每一个dataflow以一个或多个sources开始以一个或多个sinks结束。dataflow类似于任意的有向无环图(DAG),当然特定形式的环可以通过iteration构建。在大部分情况下,程序中的transformations跟dataflow中的operator是一一对应的关系,但有时候,一个transformation可能对应多个operator。

    image.png

    相关文章

      网友评论

          本文标题:flink--架构、运行、调度原理

          本文链接:https://www.haomeiwen.com/subject/arokoktx.html