flink1.16新特性列举

lifuyi2017

已于 2022-09-08 19:59:19 修改

阅读量2.5k

点赞数

分类专栏： flink 文章标签： flink

于 2022-08-29 10:56:29 首次发布

本文链接：https://blog.csdn.net/qq_34295546/article/details/126580556

版权

flink 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

一：Runtime、Checkpoint

1：异步io得重试api机制

FLIP-232: Add Retry Support For Async I/O In DataStream API - Apache Flink - Apache Software Foundation

重试是针对某一个异步function得重试，重试有两个超时时间。

现在重试暂时没有实现状态管理

重试中得retryQueue有可能会导致oom，现在暂时还没有解决，后续可能引入其他组件(e.g., Redission's RDelayedQueue, Rabbitmq and Kafka ...)来存这部分数据

2：在DataStream的批模式下，引入对DataStream进行缓存的支持：Support Cache in DataStream for Batch Processing

[FLINK-27521] FLIP-205: Support Cache in DataStream for Batch Processing - ASF JIRA

个人理解有点像spark的rdd 的cache操作

3：blocking shuffle的一些优化（批处理模式下的shuffle）

https://issues.apache.org/jira/browse/FLINK-28374

先了解下flink shuffle

Flink操作——Batch - Blocking Shuffle_京河小蚁的博客-CSDN博客

--1：flink在shuffle默认的buffer是32K的，这对于文件读来说太小了，但是sort shuffle时对于文件的io读写采用一套更大的CompositeBuffer，里面包含一个buffer集合，提升文件读写效率

--2：shuffle的reader线程池以前只考虑了读缓存和cpu核数，现在多考虑了slot数量和磁盘数

--3：降低了sort-shuffle每次请求的总的reader buffer大小8M--》4M，是为了reduce the time waiting for buffers，这一部分改造和第1点组合的

--4：对于shuffle中一个上游的数据有多个下游共用的情况，以前是上游vertex生成多个数据集，然后供下游使用，这导致了数据被序列化和持久化了多次。现在优化成了下游共用的情况，引入了一个NonChainedOutput的类作为上游的输出，在构造OperatorChain的时候，所有的network之间的output都改成NonChainedOutput，而不是之前的StreamEdge，只有chain内部还在使用StreamEdge

--5：shuffle压缩选项的增加，引入ZSTD主要是有些情况需要高压缩率，比如k8s环境

--6：HashBasedDataBuffer 和 SortBasedDataBuffer是blocking shuffle中两种DataBuffer，HashBasedDataBuffer性能要比SortBasedDataBuffer，以前选择使用哪一种是根据taskmanager.network.sort-shuffle.min-buffers参数来的，只有这个足够大，才会使用HashBasedDataBuffer，但是taskmanager.network.sort-shuffle.min-buffers太大会导致'Insufficient number of network buffers'报错，现在改为了根据每个ResultPartition（批处理模式下是SortMergeResultPartition ）所能获取的the number of network buffers can be allocated来确定DataBuffer类型，如果内存足够大，会使用HashBasedDataBuffer，如果要使用HashBasedDataBuffer，可以增大flink taskmanager的network内存

--7：移除SortMergeResultPartition的flush方法

--8：修改bug：SortMergeResultPartitionScheduler可能会出现读数据不连续的情况，这种情况发生是因为存在某个subpartition里面的所有数据总是最先被读取完

--9：移除了SortMergeSubpartitionReader中的一些没有使用的属性

--10：sort-shuffle的index文件以前存储的位置信息是当前数据分区的buffer数（the number of buffers in the current data region），这样不便于快速的定位目标数据的边界，现在改成了记录当前数据分区的bytes数，这样也便于做如下优化：为了连续性IO读取，读取大于一个buffer的数据

--11：解决在回收BatchShuffleReadBufferPool的buffer时，由于要回收的buffer数量可能大于numBuffersPerRequest导致对已经可用的buffer唤醒过于频繁的bug：

--12：对SortMergeResultPartitionReadScheduler中的reader进行排序以优化顺序读的效率

二：Deployment & Cluster Coordination

1：Hybrid Shuffle Mode（一种新的shuffle，不同于Pipelined Shuffle and Blocking Shuffle，通过execution.batch-shuffle-mode设置）

FLIP-235: Hybrid Shuffle Mode - Apache Flink - Apache Software Foundation

Configuration | Apache Flink

先看看之前两种shuffle的缺点：

pipelined shuffle：

shuffle的中间数据全部放在内存中的，这要求上下游流算子同时部署，会导致资源利用率低，更严重的是，如果多个作业每个都持有集群资源的一部分，并等待更多资源，则会发生死锁。这种可能性并不小，特别是对于并发作业提交频繁的OLAP等场景。

blocking shuffle：

shuffle的中间数据是写在本地磁盘的，下游是等上游任务执行完后执行的，即使现在有空余资源。会导致job的运行时间变长，同时频繁读写磁盘也会影响性能

新的shuffle应该满足2点：

一旦有空余资源就唤起挂起的任务，

尽量减少磁盘压力

引入一个特殊的ResultPartition：HybridResultPartition架构如下

MemoryDataManager 的架构如下：每个subResultPartition会有一个buffer队列，里面的buffer一旦消费完或者splling之后就会被bufferpool回收，bufferpool达到一个阈值会触发splling。

FileDataManager的架构如下：一个subResultPartition会有一个reader，默认写方式采用sort-shuffle方式

部署方面当前版本的Hybrid Shuffle 会禁用槽共享（first version of Hybrid Shuffle does not support slot sharing）

2：Speculative Execution（批模式下的推测执行）

FLIP-168: Speculative Execution for Batch Job - Apache Flink - Apache Software Foundation

这是一个新特性，需要和自适应批调度一起使用，相关配置与指标如下：

有几个重点类：

ExecutionTimeBasedSlowTaskDetector：延迟task的检测器

SpeculativeExecutionVertex：延迟执行节点，父类是ExecutionVertex，不同的是这种节点可以在同一时刻有多个executions，用于替代ExecutionGraph中原来的ExecutionVertex

SpeculativeScheduler：推测执行任务的调度器，父类是AdaptiveBatchScheduler

状态：

既然一个顶点可能会有多个execution，那么就会有多个状态，在恢复的时候会恢复状态比较优先的那个execution，任务的状态优先级排序如下：

3：State backend

--1：backend changelog 介绍

FLIP-158: Generalized incremental checkpoints - Apache Flink - Apache Software Foundation

状态不断的写入changelog，周期的写入state table。当 changelog达到一定大小，就会进行checkpoint。state table会周期的持久化（独立于checkpoint），这个操作叫materialization ，一旦一个materialization完成，changelog就会进行裁剪。目前只支持keyed state

Flink 1.15 新功能架构解析：高效稳定的通用增量 Checkpoint - SegmentFault 思否