盗版小说网站怎么赚钱,Wordpress 转发后查看,ie显示wordpress网页不完整,郑州最新通告一、基本组件栈 在Flink整个软件架构体系中#xff0c;同样遵循着分层的架构设计理念#xff0c;在降低系统耦合度的同时#xff0c;也为上层用户构建Flink应用提供了丰富且友好的接口。从下图中可以看出整个Flink的架构体系基本上可以分为三层#xff0c;由上往下依次是 …一、基本组件栈 在Flink整个软件架构体系中同样遵循着分层的架构设计理念在降低系统耦合度的同时也为上层用户构建Flink应用提供了丰富且友好的接口。从下图中可以看出整个Flink的架构体系基本上可以分为三层由上往下依次是 API Libraries层、Runtime核心层以及物理部署层。 【1】APILibraries层 作为分布式数据处理框架Flink同时提供了支撑流计算和批计算的接口同时在此基础之上抽象出不同的应用类型的组件库如基于流处理的CEP复杂事件处理库、SQLTable库和基于批处理的FlinkML机器学习库等、Gelly图处理库等。API层包括构建流计算应用的DataStream API和批计算应用的DataSet API两者都提供给用户丰富的数据处理高级API例如Map、FlatMap操作等同时也提供比较低级的Process Function API用户可以直接操作状态和时间等底层数据。 【2】Runtime核心层 该层主要负责对上层不同接口提供基础服务也是Flink分布式计算框架的核心实现层支持分布式Stream作业的执行、JobGraph到ExecutionGraph的映射转换、任务调度等。将DataSteam流作业和DataSet批作业转成统一的可执行的Task Operator达到在流式引擎下同时处理批量计算和流式计算的目的。其中Runtime层对不同的执行环境提供了一套统一的分布式作业执行引擎。 【3】物理部署层 该层主要涉及Flink的部署模式目前Flink支持多种部署模式本地、集群Standalone/YARN、云GCE/EC2、Kubenetes。Flink能够通过该层能够支持不同平台的部署用户可以根据需要选择使用对应的部署模式。 二、Runtime层总体架构 Flink采用了非常经典的Master-Slave结构Master就对应白线框起来的Dispatcher(负责接收用户提供的作业并且负责为这个新提交的作业拉起一个新的JobManager组件在整个Flink集群中只有一个Dispatcher)ResourceManager(负责资源的管理在整个Flink集群中只有一个ResourceManager)JobManager(负责管理作业的执行在一个Flink集群中可能有多个作业同时执行每个作业都有自己的JobManager 组件)这三个组件都包含在AppMaster进程中。Slave就对应TaskManager负责作业的实际执行。 【1】Client 基于上述结构当用户提交作业的时候提交脚本会首先启动一个Client进程负责作业的编译与提交。它首先将用户编写的流式处理代码编译为一个JobGraph在这个过程它还会进行一些检查或优化等工作例如判断哪些Operator可以 Chain到同一个Task中合并。然后Client将产生的JobGraph提交到集群中执行。此时有两种情况一种是类似于Standalone这种Session模式AM(Flink Master白框中的组件)会预先启动此时Client直接与Dispatcher建立连接并提交作业即可。另一种是Per-Job模式AM不会预先启动此时Client将首先向资源管理系统 如Yarn、K8S申请资源来启动AM然后再向AM中的 Dispatcher提交作业。 【2】AM 当作业到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模块互相交换数据。 以上就是Flink Runtime层执行作业的基本流程。可以看出Flink 支持两种不同的模式即Per-job模式与Session模式。如下图所示Per-job模式下整个Flink集群只执行单个作业即每个作业会独享Dispatcher和ResourceManager组件。此外Per-job模式下AppMaster 和TaskExecutor都是按需申请的。因此Per-job模式更适合运行执行时间较长的大作业这些作业对稳定性要求较高并且对申请资源的时间不敏感。与之对应在Session模式下Flink预先启动AppMaster以及一组TaskExecutor然后在整个集群的生命周期中会执行多个作业。可以看出Session模式更适合规模小执行时间短的作业。 三、资源管理与作业调度 作业调度可以看做是对资源和任务进行匹配的过程。如上所述在Flink中资源是通过Slot来表示的每个Slot可以用来执行不同的Task。而在另一端任务即Job中实际的Task它包含了待执行的用户逻辑。调度的主要目的就是为了给Task 找到匹配的Slot。逻辑上来说每个Slot都应该有一个向量来描述它所能提供的各种资源的量每个Task也需要相应的说明它所需要的各种资源的量。但是实际上在1.9之前Flink是不支持细粒度的资源描述的而是统一的认为每个Slot提供的资源和Task需要的资源都是相同的。从1.9开始Flink 开始增加对细粒度的资源匹配的支持的实现但这部分功能目前仍在完善中。 作业调度的基础是首先提供对资源的管理因此我们首先来看下Flink中资源管理的实现。Flink中的资源是由TaskExecutor上的Slot来表示的。如下图所示在ResourceManager中有一个子组件叫做SlotManager它维护了当前集群中所有TaskExecutor上的 Slot 的信息与状态如该Slot在哪个TaskExecutor中该Slot当前是否空闲等。当JobManger来为特定Task申请资源的时候根据当前是Per-job还是Session模式ResourceManager可能会去申请资源来启动新的TaskExecutor。当TaskExecutor启动之后它会通过服务发现找到当前活跃的ResourceManager 并进行注册。在注册信息中会包含该TaskExecutor中所有Slot的信息。 ResourceManager收到注册信息后其中的SlotManager就会记录下相应的Slot信息。当JobManager为某个Task来申请资源时SlotManager就会从当前空闲的Slot中按一定规则选择一个空闲的Slot进行分配。当分配完成后RM会首先向TaskManager发送RPC要求将选定的Slot 分配给特定的JobManager。TaskManager如果还没有执行过该JobManager的Task的话它需要首先向相应的JobManager建立连接然后发送提供 Slot的RPC请求。在JobManager中所有Task的请求会缓存到SlotPool中。当有Slot被提供之后SlotPool会从缓存的请求中选择相应的请求并结束相应的请求过程。 当Task结束之后无论是正常结束还是异常结束都会通知JobManager相应的结束状态然后在TaskManager端将Slot标记为已占用但未执行任务的状态。JobManager会首先将相应的Slot缓存到SlotPool中但不会立即释放。这种方式避免了如果将Slot直接还给ResourceManager在任务异常结束之后需要重启时需要立刻重新申请Slot的问题。通过延时释放Failover的Task可以尽快调度回原来的TaskManager从而加快Failover的速度。当SlotPool中缓存的Slot超过指定的时间仍未使用时SlotPool就会发起释放该 Slot的过程。与申请Slot的过程对应SlotPool会首先通知TaskManager来释放该Slot然后TaskExecutor通知ResourceManager该Slot已经被释放从而最终完成释放的逻辑。 除了正常的通信逻辑外在ResourceManager和TaskExecutor之间还存在定时的心跳消息来同步Slot的状态。在分布式系统中消息的丢失、错乱不可避免这些问题会在分布式系统的组件中引入不一致状态如果没有定时消息那么组件无法从这些不一致状态中恢复。此外当组件之间长时间未收到对方的心跳时就会认为对应的组件已经失效并进入到Failover的流程。在Slot管理基础上Flink可以将Task调度到相应的Slot当中。如上所述Flink尚未完全引入细粒度的资源匹配默认情况下每个Slot可以分配给一个Task。但是这种方式在某些情况下会导致资源利用率不高。如图5所示假如 A、B、C依次执行计算逻辑那么给 A、B、C分配分配单独的Slot就会导致资源利用率不高。为了解决这一问题Flink提供了Share Slot的机制。如图下图所示基于Share Slot每个Slot中可以部署来自不同JobVertex的多个任务但是不能部署来自同一个JobVertex的Task。如图下图所示每个Slot中最多可以部署同一个A、B或C的Task但是可以同时部署A、B和C的各一个Task。当单个Task占用资源较少时Share Slot可以提高资源利用率。 此外Share Slot也提供了一种简单的保持负载均衡的方式。 基于上述Slot管理和分配的逻辑JobManager负责维护作业中Task执行的状态。如上所述Client端会向JobManager提交一个JobGraph它代表了作业的逻辑结构。JobManager会根据JobGraph按并发展开从而得到JobManager中关键的ExecutionGraph。ExecutionGraph的结构如下图所示与JobGraph相比ExecutionGraph中对于每个Task与中间结果等均创建了对应的对象从而可以维护这些实体的信息与状态。 Flink中的ExecutionGraph是JobGraph 按并发展开所形成的它是JobMaster中的核心数据结构 在一个Flink Job中是包含多个Task的因此另一个关键的问题是在Flink中按什么顺序来调度Task。如下图所示目前Flink提供了两种基本的调度逻辑即Eager调度与Lazy From Source。Eager调度如其名所示它会在作业启动时申请资源将所有的Task调度起来。这种调度算法主要用来调度可能没有终止的流作业。与之对应Lazy From Source则是从Source开始按拓扑顺序来进行调度。简单来说Lazy From Source 会先调度没有上游任务的Source任务当这些任务执行完成时它会将输出数据缓存到内存或者写入到磁盘中。然后对于后续的任务当它的前驱任务全部执行完成后Flink就会将这些任务调度起来。这些任务会从读取上游缓存的输出数据进行自己的计算。这一过程继续进行直到所有的任务完成计算。 四、错误恢复 在Flink作业的执行过程中除正常执行的流程外还有可能由于环境等原因导致各种类型的错误。整体上来说错误可能分为两大类Task执行出现错误或Flink集群的Master出现错误。由于错误不可避免为了提高可用性Flink需要提供自动错误恢复机制来进行重试。 Task执行错误Flink提供了多种不同的错误恢复策略。如下图所示第一种策略是 Restart-all即直接重启所有的Task。对于Flink的流任务由于Flink提供了Checkpoint机制因此当任务重启后可以直接从上次的Checkpoint 开始继续执行。因此这种方式更适合于流作业。 第二类错误恢复策略是Restart-individual它只适用于 Task之间没有数据传输的情况。这种情况下我们可以直接重启出错的任务。 由于Flink的批作业没有Checkpoint机制因此对于需要数据传输的作业直接重启所有Task会导致作业从头计算从而导致一定的性能问题。为了增强对Batch作业Flink在1.9中引入了一种新的Region-Based 的 Failover策略。在一个Flink的Batch作业中Task之间存在两种数据传输方式一种是Pipeline类型的方式这种方式上下游Task之间直接通过网络传输数据因此需要上下游同时运行另外一种是Blocking类型如上节所述这种方式下上游的Task会首先将数据进行缓存因此上下游的Task可以单独执行。基于这两种类型的传输Flink将ExecutionGraph中使用Pipeline方式传输数据的Task的子图叫做Region从而将整个 ExecutionGraph划分为多个子图。可以看出Region内的Task必须同时重启而不同Region的Task由于在Region边界存在 Blocking的边因此可以单独重启下游 Region中的Task。基于这一思路 , 如果某个Region中的某个Task执行出现错误可以分两种情况进行考虑。如下图所示如果是由于Task本身的问题发生错误那么可以只重启该Task所属的Region中的Task这些 Task重启之后可以直接拉取上游Region缓存的输出结果继续进行计算。 另一方面如图如果错误是由于读取上游结果出现问题如网络连接中断、缓存上游输出数据的TaskExecutor异常退出等那么还需要重启上游Region来重新产生相应的数据。在这种情况下如果上游Region输出的数据分发方式不是确定性的如KeyBy、Broadcast是确定性的分发方式而Rebalance、Random则不是因为每次执行会产生不同的分发结果为保证结果正确性还需要同时重启上游Region所有的下游Region。 如果是由于上游失败导致的错误那么需要同时重启上游的Region和下游的Region。实际上如果下游的输出使用了非确定的数据分割方式为了保持数据一致性还需要同时重启所有上游Region和下游Region。 除了Task本身执行的异常外另一类异常是Flink集群的Master进行发生异常。目前Flink支持启动多个Master作为备份这些Master可以通过ZK来进行选主从而保证某一时刻只有一个Master在运行。当前活路的Master发生异常时 , 某个备份的Master 可以接管协调的工作。为了保证Master可以准确维护作业的状态Flink目前采用了一种最简单的实现方式即直接重启整个作业。实际上由于作业本身可能仍在正常运行因此这种方式存在一定的改进空间。 ● 更完善的资源管理 从1.9开始Flink开始了对细粒度资源匹配的支持。基于细粒度的资源匹配用户可以为TaskExecutor和 Task设置实际提供和使用的CPU、内存等资源的数量Flink可以按照资源的使用情况进行调度。这一机制允许用户更大范围的控制作业的调度从而为进一步提高资源利用率提供了基础。 ● 统一的 Stream 与 Batch Flink目前为流和批分别提供了DataStream和DataSet两套接口在一些场景下会导致重复实现逻辑的问题。未来Flink会将流和批的接口都统一到DataStream之上。 ● 更灵活的调度策略 Flink 从1.9开始引入调度插件的支持从而允许用户来扩展实现自己的调度逻辑。未来Flink也会提供更高性能的调度策略的实现。 ● Master Failover 的优化 如上节所述目前Flink在Master Failover时需要重启整个作业而实际上重启作业并不是必须的逻辑。Flink未来会对Master failover进行进一步的优化来避免不必要的作业重启。