作者 | 阿里巴巴高级技术专家、Apache Flink Committer 贺小令（晓令）
Apache Flink 继续保持高速倒退，是 Apache 最沉闷的社区之一。Flink 1.16 共有 240 多个 Contributor 激情参加，共实现了 19 个 FLIP [1]和 1100 多个 issue，给社区带来十分多振奋人心的性能。
Flink 曾经是流计算畛域的领跑者，流批一体的概念逐步失去大家的认可，并在越来越多的公司胜利落地。之前的流批一体更强调对立的 API 和对立的计算框架。往年，在此基础上，Flink 推出了 Streaming Warehouse[2]，进一步降级了流批一体的概念：真正实现了流批一体的计算和流批一体的存储的交融，从而实现流批一体的实时化剖析。
在 1.16 版本里，Flink 社区对流、批都实现了泛滥改良：
- 在批处理方面，实现了易用性、稳定性、性能全方位的改良，1.16 是 Fink 批处理的里程碑式的版本，是走向成熟的重要一步。
- 易用性：引入 SQL Gateway 并齐全兼容 HiveServer2，用户能够十分不便的提交 Flink SQL 作业和 Hive SQL 作业，同时也很容易连贯到原有的 Hive 生态。
- 性能：Flink SQL 用户反对通过 Join Hint 指定 Join 策略，防止不合理的执行打算；Hive SQL 的兼容性曾经达到 94%，用户能够以极低的老本实现 Hive 到 Flink 的迁徙。
- 稳定性：通过预测执行缩小作业长尾以进步作业整体运行稳定性；反对自适应 HashJoin，通过失败回滚机制防止作业失败。
- 性能：对多分区表进行动静分区裁剪以进步解决效率，TPC-DS 在 10TB 规模数据集下性能晋升了 30%；反对混合 Shuffle 模式，进步资源使用率和解决性能。
- 在流解决方面，也实现了很多重大改良：
- Changelog State Backend 能够为用户提供秒级甚至毫秒级 Checkpoint，从而大幅晋升容错体验，同时为事务性 Sink 作业提供更小的端到端提早体验。
- 维表关联在流解决中宽泛被应用，引入了通用的缓存机制放慢维表查问速度，引入了可配置的异步模式晋升维表查问吞吐，引入可重试查问机制解决维表提早更新问题。这些性能都十分实用，解决了用户常常埋怨的痛点，反对了更丰盛的场景。
- 从 Flink SQL 诞生第一天就存在一些非确定性操作可能导致用户作业呈现谬误后果或作业运行异样，这给用户带来了极大的困扰。1.16 里咱们花了很多大精力解决了大部分问题，将来还会继续改良。
随着流批一体的进一步欠缺和 Flink Table Store 的一直迭代（0.2 版本已公布[3]），Flink 社区正一步一步推动 Streaming Warehouse 从概念变为事实并走向成熟。
了解 Streaming Warehouse
流式数仓（Streaming Warehouse）更精确地说，其实是“make data warehouse streaming”，就是让整个数仓所有分层的数据全副实时地流动起来，从而实现一个具备端到端实时性的纯流服务（Streaming Service），并且用一套对立 API 和计算框架来解决和剖析所有流动中的数据。想理解更多内容请参阅文章[4]。
批处理
得益于咱们在流解决的长期投资，流解决曾经成为流计算畛域的领导者。在批处理上，咱们也投入更多的精力，使其成为一个优良的批处理引擎。流批处理对立的整体体验也将会更加顺畅。
SQL Gateway
从各个渠道反馈中理解到，SQL Gateway[5] 始终是用户十分期待的性能，尤其是对批用户。1.16 里，该性能终于实现（设计见 FLIP-91[6]）。SQL Gateway 是对 SQL Client 的扩大和加强，反对多租户和插件式 API 协定（Endpoint），解决了 SQL Client 只能服务单用户并且不能对接内部服务或组件的问题。以后 SQL Gateway 已反对 REST API 和 HiveServer2 协定，用户能够通过 cURL，Postman，各种编程语言的 HTTP 客户端链接到 SQL Gateway 提交换作业、批作业，甚至 OLAP 作业。对于 HiveServer2 协定，请参考“Hive 语法兼容”章节。
Hive 语法兼容
为了升高从 Hive 到 Flink 的迁徙老本，这个版本里咱们引入了 HiveServer2 协定并持续改良 Hive 语法的兼容性。
HiveServer2 协定 [7] 容许用户应用 Hive JDBC/Beeline 和 SQL Gateway 进行交互，Hive 生态（DBeaver, Apache Superset, Apache DolphinScheduler, and Apache Zeppelin）也因而很容易迁徙到 Flink。当用户应用 HiveServer2 协定连贯 SQL Gateway，SQL Gateway 会主动注册 Hive Catalog，主动切换到 Hive 方言，主动应用批处理模式提交作业，用户能够失去和间接应用 HiveServer2 一样的体验。
Hive 语法 [8] 曾经是大数据处理的事实标准，Flink 欠缺了对 Hive 语法的兼容，减少了对 Hive 若干生产中罕用语法的反对。通过对 Hive 语法的兼容，能够帮忙用户将已有的 Hive SQL 工作迁徙到 Flink，并且不便相熟 Hive 语法的用户应用 Hive 语法编写 SQL 以查问注册进 Flink 中的表。到目前为止，基于 Hive qtest 测试集（蕴含 12K 个 SQL 案例），Hive 2.3 版本的查问兼容性已达到 94.1%，如果排除 ACID 的查问语句，则已达到 97.3%。
Join Hint
Hint 始终是业界用来干涉执行打算以改善优化器毛病的通用解决方案。Join 作为批作业中最宽泛应用的算子，Flink 反对多种 Join 策略。统计信息缺失或优化器的代价模型不欠缺都会导致选出谬误 Join 策略，从而导致作业运行慢甚至有运行失败的危险。用户通过指定 Join Hint[9]，让优化器尽可能抉择用户指定的 Join 策略，从而防止优化器的各种有余，以确保批作业的生产可用性。
自适应 Hash Join
对于批作业而言，数据歪斜是十分常见的，而此时应用 HashJoin 可能运行失败，这是十分蹩脚的体验。为了解决该问题，咱们引入了自适应的 HashJoin：Join 算子运行时一旦 HashJoin 运行失败，能够主动回退到 SortMergeJoin，并且是 Task 粒度。通过该机制可确保 HashJoin 算子始终胜利，从而进步了作业的稳定性。
批处理的预测执行
为了解决问题机器导致批作业解决慢的问题，Flink 1.16 引入了预测执行。问题机器是指存在硬件问题、突发 I/O 忙碌或 CPU 负载低等问题的机器，这些问题可能会使得运行在该机器上的工作比其余机器上的工作要慢得多，从而影响批处理作业的整体执行工夫。
当启用预测执行时，Flink 将继续检测慢工作。一旦检测到慢工作，该工作所在的机器将被辨认为问题机器，并通过黑名单机制（FLIP-224[10]）被加黑。调度器将为慢工作创立新的执行实例并将它们部署到未被加黑的节点，同时现有执行实例也将持续运行。新的执行实例和老的执行实例将解决雷同的输出数据并产出雷同的后果数据。一旦任何执行实例率先实现，它将被视为该工作的惟一实现执行实例，并且该工作的其余执行实例都将被勾销。
大多数现有 Source 都能够应用预测执行 (FLIP-245[11])。只有当一个 Source 应用了 SourceEvent 时，它必须额定实现 SupportsHandleExecutionAttemptSourceEvent 接口以反对预测执行。目前 Sink 尚不反对预测执行，因而预测执行不会在 Sink 上产生。
咱们也改良了 Web UI 和 REST API (FLIP-249[12])，以显示工作的多个执行实例和被加黑的 TaskManager。
混合 Shuffle 模式
咱们为批处理引入了一种新的混合 Shuffle[13] 模式。它联合了 Blocking Shuffle 和 Pipeline Shuffle（次要用于流式解决）的长处：
- 与 Blocking Shuffle 一样，它不要求上下游工作同时运行，这容许应用很少的资源执行作业。
- 与 Pipeline Shuffle 一样，它不要求上游工作实现后才执行上游工作，这在给定足够资源状况下缩小了作业的整体执行工夫。
- 用户能够抉择不同的落盘策略，以满足缩小数据落盘或是升高工作重启代价的不同需要。
留神：该性能为实验性的，并且默认敞开。
Blocking shuffle 进一步改良
在这个版本中，咱们进一步改良了 Blocking Shuffle 的可用性和性能，包含自适应网络缓冲区调配、程序 IO 优化和后果分区重用，容许多个消费者节点重用同一个物理后果分区，以缩小磁盘 IO 和存储空间。在 TPC-DS 10TB 规模的测试中，这些优化能够实现 7% 的整体性能晋升。此外，还引入了两种压缩率更高的压缩算法（LZO 和 ZSTD）。与默认的 LZ4 压缩算法相比，能够进一步缩小存储空间，但要付出一些 CPU 老本。
动静分区裁剪
对于批作业，生产环境中分区表比非分区表应用更为宽泛。以后 Flink 曾经反对动态分区裁剪，即在优化阶段，优化器将 Filter 中的 Partition 相干的过滤条件下推到 Source Connector 中从而缩小不必要的分区读取。星形模型 [14] 是数据集市模式中最简略且应用最宽泛的模式，咱们发现很多用户的作业没法应用动态分区裁剪，因为分区裁剪信息在执行时能力确定，这就须要动静分区裁剪技术[15]，即运行时依据其余相干表的数据确定分区裁剪信息从而缩小对分区表中有效分区的读取。通过 TPC-DS 10TB 规模数据集的验证，该性能可晋升 30% 的性能。
流解决
在 1.1 6 中，咱们在 Checkpoint、SQL、Connector 和其余畛域都进行了改良，从而确保 Flink 在流计算畛域持续当先。
Generalized Incremental Checkpoint
Changelog State Backend 旨在令 Checkpoint 的距离更短、更加可预测。这个版本在本身易用性上和与其余 State Backend 兼容性上做了诸多改良，使其达到生产可用。
- 反对状态迁徙
- 反对 Failover 时从本地复原
- 引入文件缓存优化复原过程的性能
- 反对从 Checkpoint 进行切换
- 优化监控体验：
- 裁减了 Changelog 的监控指标
- 在 Flink WebUI 上显示 Changelog 相干的配置
<u><p style=”text-align:center”> 表 1: Value State 上 Changelog Enabled / Changelog Disabled 比照 (具体配置请参考文档[16])</p></u>
RocksDB Rescaling 改良及性能测试
对于应用 Flink 构建的云服务利用来说，Rescaling 是一种十分频繁的操作。这个版本应用了 RocksDB 的区间删除 [17] 来优化增量 RocksDB State Backend 的 Rescaling 性能。区间删除被用来防止在 Rescaling 过程中大量的扫描和单点删除操作，对有大量的状态须要删除的扩并发来说，单个并发上的复原速度能够进步 2~10 倍[18]。
改善 State Backend 的监测体验和可用性
这个版本还改善了状态后盾的监控体验和可用性。之前，RocksDB 的日志位于它本人的 DB 目录中，这使得调试 RocksDB 没那么容易。这个版本让 RocksDB 的日志默认留在 Flink 的日志目录中。新增了 RocksDB 相干的统计指标，以帮忙调试 DB 级别的性能，例如，在 DB 内的总块缓存命中 / 失败计数。
反对透支缓冲区
透支缓冲区 [19]（Overdraft Buffers）旨在缓解反压状况下 Subtask 被阻塞的概率，能够通过设置 taskmanager.network.memory.max-overdraft-buffers-per-gate [20] 开启。
从 1.16 开始，一个 Flink 的 Subtask 能够申请 5 个（默认）额定的透支缓冲区。透支缓冲区会轻微地减少作业的内存使用量，但能够极大地缩小 Checkpoint 的距离，特地是在开启 Unaligned Checkpoint 状况下。只有以后 Subtask 被上游 Subtasks 反压且以后 Subtask 须要申请超过 1 个网络缓冲区（Network Buffer）能力实现以后的操作时，透支缓冲区才会被应用。更多细节能够参考文档[21]。
对齐 Checkpoint 超时
这个版本更新了从 Aligned Checkpoint（AC）切换到 Unaligned Checkpoint（UC）的工夫点。在开启 UC 的状况下，如果配置了 execution.checkpointing.aligned-checkpoint-timeout[22], 在启动时每个 Checkpoint 依然是 AC，但当全局 Checkpoint 持续时间超过 aligned-checkpoint-timeout 时，如果 AC 还没实现，那么 Checkpoint 将会转换为 UC。
以前，对一个 Substask 来说，AC 到 UC 的切换须要等所有上游的 Barriers 达到后能力开始，在反压重大的状况下，在 checkpointing-timeout[23] 过期之前，上游的 Substask 可能无奈齐全地收到所有 Barriers，从而导致 Checkpoint 失败。
在这个版本中，如果上游 Subtask 中的 Barrier 无奈在 execution.checkpointing.aligned-checkpoint-timeout[24] 内发送到上游，Flink 会让上游的 Subtask 先切换成 UC，以把 Barrier 发送到上游，从而缩小反压状况下 Checkpoint 超时的概率。更多细节能够参考文档[25]。
流计算的非确定性
Flink SQL 用户常常埋怨了解流解决的老本太高，其中一个痛点是流解决中的非确定性（而且通常不直观），它可能会导致谬误的后果或异样。而这些痛点在 Flink SQL 的晚期就曾经存在了。
对于简单的流作业，当初能够在运行前检测并解决潜在的正确性问题。如果问题不能齐全解决，一个具体的音讯能够提醒用户如何调整 SQL，以防止引入非确定性问题。更多细节能够参考文档[26]。
维表加强
维表关联在流解决中被宽泛应用，在 1.16 中咱们为此退出了多项优化和加强：
- 反对了通用的缓存机制和相干指标[27]，能够减速维表查问。
- 通过作业配置 [28] 或查问提醒 [29] 反对可配置的异步模式（ALLOW_UNORDERED），在不影响正确性的前提下大大晋升查问吞吐。
- 可重试的查问机制 [30] 让用户解决维表数据更新提早问题有了更多的伎俩。
异步 I/O 反对重试
为异步 I/O [31]引入了内置的重试机制，它对用户现有代码是通明的，能够灵便地满足用户的重试和异样解决需要。
PyFlink
在 Flink 1.15 中，咱们引入了一种新的执行模式：“线程”模式。在该模式下，用户自定义的 Python 函数将通过 JNI 在 JVM 中执行，而不是在独立的 Python 过程中执行。然而，在 Flink 1.15 中，仅在 Table API 和 SQL 上的 Python 标量函数的执行上反对了该性能。在该版本中，咱们对该性能提供了更全面的反对，在 Python DataStream API 中以及在 Table API 和 SQL 的 Python 表值函数中，也反对了该性能。
除此之外，咱们还在继续补全 Python API 所缺失的最初几处性能。在这个版本中，咱们对 Python DataStream API 提供了更全面的反对：反对了旁路输入、Broadcast State 等性能，并欠缺了对于窗口性能的反对。咱们还在 Python DataStream API 中，增加了对于更多的 Connector 以及 Format 的反对，例如增加了对于 Elasticsearch、Kinesis、Pulsar、Hybrid Source 等 Connector 的反对以及对于 Orc、Parquet 等 Format 的反对。有了这些性能之后，Python API 曾经根本对齐了 Java 和 Scala API 中绝大部分的重要性能，用户曾经能够应用 Python 语言实现大多数类型 Flink 作业的开发。
其余
新语法
1.16 扩大了多个 DDL 语法以帮忙用户更好的应用 SQL：
- USING JAR [32]反对动静加载 UDF jar 包，不便平台开发者轻松实现 UDF 的治理和相干作业的提交。
- CREATE TABLE AS SELECT [33](CTAS) 不便用户基于已有的表和查问创立新的表。
- ANALYZE TABLE [34]反对用户手工为原表生成统计信息，以便优化器能够生成更优的执行打算。
DataStream 中的缓存
反对通过 DataStream#cache 缓存 Transformation 的执行后果。缓存的两头后果在首次计算两头后果时才生成，以便当前的作业能够重用该后果。如果缓存失落，原始的 Transformation 将会被从新计算以失去后果。目前该性能只在批处理模式下反对。这个性能对于 Python 中的 ML 和交互式编程十分有用。
History Server 及已实现作业的信息加强
在这个版本中，咱们增强了查看已实现作业的信息的体验。
- JobManager / HistoryServer WebUI 提供了具体的执行工夫指标，包含工作在每个执行状态下的耗时，以及在运行过程中忙碌 / 闲暇 / 反压总工夫。
- JobManager / HistoryServer WebUI 提供了按 Task 或者 TaskManager 维度分组的次要子工作指标的聚合。
- JobManager / HistoryServer WebUI 提供了更多的环境信息，包含环境变量，JVM 选项和 Classpath。
- HistoryServer 当初反对从内部日志归档服务中浏览日志，更多细节能够参考文档[35]。
Protobuf 格局
Flink 当初反对 Protocol Buffers[36] (Protobuf) 格局，这容许您间接在 Table API 或 SQL 应用程序中应用这种格局。
为异步 Sink 引入可配置的 RateLimitingStrategy
1.15 中实现了异步 Sink，容许用户轻松实现自定义异步 Sink。这个版本里，咱们对此进行扩大以反对可配置的 RateLimitingStrategy。这意味着 Sink 的实现者当初能够自定义其异步 Sink 在申请失败时的行为形式，具体行为取决于特定的 Sink。如果没有指定 RateLimitingStrategy，它将默认应用 AIMDScalingStrategy。
降级阐明
咱们尽力的让每次版本升级都安稳，但仍有一些改变须要用户降级到 1.16 时对现有应用程序做出一些调整。请参考 Release Notes 获取更多的降级时须要的改变与可能的问题列表细节。
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群～
贡献者列表
Apache Flink 社区感激对此版本做出奉献的每一位贡献者：
1996fanrui, Ada Wang, Ada Wong, Ahmed Hamdy, Aitozi, Alexander Fedulov, Alexander Preuß, Alexander Trushev, Andriy Redko, Anton Kalashnikov, Arvid Heise, Ben Augarten, Benchao Li, BiGsuw, Biao Geng, Bobby Richard, Brayno, CPS794, Cheng Pan, Chengkai Yang, Chesnay Schepler, Danny Cranmer, David N Perkins, Dawid Wysakowicz, Dian Fu, DingGeGe, EchoLee5, Etienne Chauchot, Fabian Paul, Ferenc Csaky, Francesco Guardiani, Gabor Somogyi, Gen Luo, Gyula Fora, Haizhou Zhao, Hangxiang Yu, Hao Wang, Hong Liang Teoh, Hong Teoh, Hongbo Miao, HuangXingBo, Ingo Bürk, Jacky Lau, Jane Chan, Jark Wu, Jay Li, Jia Liu, Jie Wang, Jin, Jing Ge, Jing Zhang, Jingsong Lee, Jinhu Wu, Joe Moser, Joey Pereira, Jun He, JunRuiLee, Juntao Hu, JustDoDT, Kai Chen, Krzysztof Chmielewski, Krzysztof Dziolak, Kyle Dong, LeoZhang, Levani Kokhreidze, Lihe Ma, Lijie Wang, Liu Jiangang, Luning Wang, Marios Trivyzas, Martijn Visser, MartijnVisser, Mason Chen, Matthias Pohl, Metehan Yıldırım, Michael, Mingde Peng, Mingliang Liu, Mulavar, Márton Balassi, Nie yingping, Niklas Semmler, Paul Lam, Paul Lin, Paul Zhang, PengYuan, Piotr Nowojski, Qingsheng Ren, Qishang Zhong, Ran Tao, Robert Metzger, Roc Marshal, Roman Boyko, Roman Khachatryan, Ron, Ron Cohen, Ruanshubin, Rudi Kershaw, Rufus Refactor, Ryan Skraba, Sebastian Mattheis, Sergey, Sergey Nuyanzin, Shengkai, Shubham Bansal, SmirAlex, Smirnov Alexander, SteNicholas, Steven van Rossum, Suhan Mao, Tan Yuxin, Tartarus0zm, TennyZhuang, Terry Wang, Thesharing, Thomas Weise, Timo Walther, Tom, Tony Wei, Weijie Guo, Wencong Liu, WencongLiu, Xintong Song, Xuyang, Yangze Guo, Yi Tang, Yu Chen, Yuan Huang, Yubin Li, Yufan Sheng, Yufei Zhang, Yun Gao, Yun Tang, Yuxin Tan, Zakelly, Zhanghao Chen, Zhu Zhu, Zichen Liu, Zili Sun, acquachen, bgeng777, billyrrr, bzhao, caoyu, chenlei677, chenzihao, chenzihao5, coderap, cphe, davidliu, dependabot[bot], dkkb, dusukang, empcl, eyys, fanrui, fengjiankun, fengli, fredia, gabor.g.somogyi, godfreyhe, gongzhongqiang, harker2015, hongli, huangxingbo, huweihua, jayce, jaydonzhou, jiabao.sun, kevin.cyj, kurt, lidefu, lijiewang.wlj, liliwei, lincoln lee, lincoln.lil, littleeleventhwolf, liufangqi, liujia10, liujiangang, liujingmao, liuyongvs, liuzhuang2017, longwang, lovewin99, luoyuxia, mans2singh, maosuhan, mayue.fight, mayuehappy, nieyingping, pengmide, pengmingde, polaris6, pvary, qinjunjerry, realdengziqi, root, shammon, shihong90, shuiqiangchen, slinkydeveloper, snailHumming, snuyanzin, suxinglee, sxnan, tison, trushev, tsreaper, unknown, wangfeifan, wangyang0918, wangzhiwu, wenbingshen, xiangqiao123, xuyang, yangjf2019, yangjunhan, yangsanity, yangxin, ylchou, yuchengxin, yunfengzhou-hub, yuxia Luo, yuzelin, zhangchaoming, zhangjingcun, zhangmang, zhangzhengqi3, zhaoweinan, zhengyunhong.zyh, zhenyu xing, zhouli, zhuanshenbsj1, zhuzhu.zz, zoucao, zp, 周磊, 饶紫轩,, 鲍健昕 愚鲤, 帝国阿三
参考链接
[1] https://cwiki.apache.org/conf…
[2] https://developer.aliyun.com/…
[3] https://flink.apache.org/news…
[4] https://developer.aliyun.com/…
[5] https://nightlies.apache.org/…
[6] https://cwiki.apache.org/conf…
[7] https://nightlies.apache.org/…
[8] https://nightlies.apache.org/…
[9] https://nightlies.apache.org/…
[10] https://cwiki.apache.org/conf…
[11] https://cwiki.apache.org/conf…
[12] https://cwiki.apache.org/conf…
[13] https://nightlies.apache.org/…
[14] https://en.wikipedia.org/wiki…
[15] https://cwiki.apache.org/conf…
[16] https://flink-learning.org.cn…
[17] https://rocksdb.org/blog/2018…
[18] https://github.com/apache/fli…
[19] https://nightlies.apache.org/…
[20] https://nightlies.apache.org/…
[21] https://nightlies.apache.org/…
[22] https://nightlies.apache.org/…
[23] https://nightlies.apache.org/…
[24] https://nightlies.apache.org/…
[25] https://nightlies.apache.org/…
[26] https://nightlies.apache.org/…
[27] https://cwiki.apache.org/conf…
[28] https://nightlies.apache.org/…
[29] https://nightlies.apache.org/…
[30] https://nightlies.apache.org/…
[31] https://nightlies.apache.org/…
[32] https://nightlies.apache.org/…
[33] https://nightlies.apache.org/…
[34] https://nightlies.apache.org/…
[35] https://nightlies.apache.org/…
[36] https://developers.google.com…
更多内容
Flink Forward Asia 2022
本届 Flink Forward Asia 更多精彩内容，可点击浏览原文或扫描图片二维码观看全副议题的视频回放及获取 FFA 2022 峰会材料！
PC 端观看：https://flink-forward.org.cn/「倡议返回 FFA 2022 大会官网观看全副议题的视频回放」
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/produc…