共计 8535 个字符，预计需要花费 22 分钟才能阅读完成。
在 Apache 软件基金会近期公布的年度报告中，Apache Flink 再次跻身最沉闷我的项目前 5 名！该我的项目最新公布的 1.14.0 版本同样体现了其不凡的沉闷力，囊括了来自超过 200 名贡献者的 1000 余项奉献。整个社区为我的项目的推动付出了坚持不懈的致力，咱们引以为傲。
新版本在 SQL API、更多连接器反对、Checkpoint 机制、PyFlink 等多个方面带来了大量的新个性与改良。其中一个次要的改良是针对流批一体的应用体验。咱们置信，在实践中，对无界的数据流的解决与对有界的批数据的解决是密不可分的，因为很多场景都须要在解决实时数据流的同时解决来自各种数据源的历史数据。例如开发新利用时的数据摸索、新利用的状态初始化、用于流式利用的训练模型、降级或修复后的数据重解决等。
在 Flink 1.14 中，咱们终于能够 在同一个利用当中混合应用有界流和无界流 ：Flink 当初反对对局部运行、局部完结的利用（局部算子已解决到有界输出数据流的末端）做 Checkpoint。此外，Flink 在 解决到有界数据流末端时会触发最终 Checkpoint，以确保所有计算结果顺利提交到 Sink。
批执行模式当初反对在同一利用中混合应用 DataStream API 和 SQL/Table API（此前仅反对独自应用 DataStream API 或 SQL/Table API）。
咱们更新了对立的 Source 和 Sink API，并已开始 围绕对立的 API 整合连接器生态 。咱们新增了 混合 Source 可在多个存储系统间过渡。你当初能够实现诸如先从 Amazon S3 中读取旧的数据再无缝切换到 Apache Kafka 这样的解决。
此外，这一版本朝着咱们将 Flink 打造得更加自调易用、无需大量流解决特定常识的指标又迈进了一步。作为向此指标迈出的第一步，咱们在上个版本中引入了 被动弹性伸缩模式 。当初，咱们又新增了 对网络内存的主动调整 （即缓冲区去收缩）。这一个性能在放弃高吞吐、不减少 Checkpoint 大小的前提下，减速高负载时的 Checkpoint。该机制通过一直调整网络缓冲区的大小，可能以起码的缓冲数据达到最佳的吞吐效率。更多详情请参考 缓冲区去收缩 章节。
新版本中有许多来自各个组件的新个性与改良，咱们将在下文介绍。与此同时，咱们也辞别了一些在最近的版本中逐步被取代、废除的组件和性能。最具代表性的是，新版本中 移除了旧版 SQL 查问引擎和对 Apache Mesos 的集成。
咱们心愿你喜爱这个新版本，同时迫切地想理解你的应用体验：这一版本解决了哪些此前尚未解决的问题，满足了哪些新场景？
一、流批一体的解决体验
Flink 的一个独特之处是其对流和批处理的对立：应用同一套 API、同一个可反对多种执行范式的运行时。
正如在前文中提到的，咱们置信流解决和批处理是密不可分的。上面这段话来自一份 对于 Facebook 流式数据处理的报告，很好地响应了这一观点。
流解决与批处理并不是非此即彼的抉择。最后，Facebook 所有数据仓库的解决都是批处理。咱们在大概 5 年前开始研发 Puma 和 Swift。正如咱们在 […] 章节所展现的，混合应用流解决和批处理可能为较长的解决流程节约数个小时。
利用同一引擎解决实时和历史数据还能够确保语义的一致性，使后果具备更好的可比性。这里有一篇 对于阿里巴巴应用 Apache Flink 生成对立的、统一的业务报告的文章。
此前的版本曾经能够实现流批一体的数据处理。新版本在这方面减少了针对更多应用场景的新个性，以及一系列应用体验的改良。
有界流 Checkpoint 机制
Flink 的 Checkpoint 机制本来只反对在利用 DAG 中的所有工作都处于运行状态时创立 Checkpoint。这意味着让利用同时读取有界和无界数据源在本质上是不可能的。此外，以流式（而非批式）解决有界输出数据的利用，在数据将要解决完、局部工作完结时将不再做 Checkpoint。这使得最初一部分输入数据无奈被提交到要求准确一次语义的 Sink 中，造成业务提早。
通过 FLIP-147，Flink 反对在局部工作完结后创立 Checkpoint，以及在有界流解决完结后触发最终 Checkpoint 以确保在作业完结时将所有输入后果提交到 Sink（与 stop-with-savepoint 相似）。
该个性可通过在配置中增加 execution.checkpointing.checkpoints-after-tasks-finish.enabled: true 启用。出于让用户自主抉择并试用重大新个性的传统，这一个性在 Flink 1.14 中没有默认启用。咱们心愿在下个版本中将其作为默认模式。
背景：解决有界数据时，只管人们通常偏向于应用批处理模式，仍有一些状况须要用到流解决模式。例如，Sink 可能只反对流模式（即 Kafka Sink），或者利用心愿尽量施展流解决固有的近工夫排序个性（例如 Kappa+ 架构）。
DataStream 和 Table/SQL 混合利用的批执行模式
SQL 和 Table API 正在成为新我的项目的默认终点，其人造的申明式特点和丰盛的内置类型与操作使利用开发变得简略疾速。然而，开发人员遇到一些特定的、事件驱动的业务逻辑，SQL 的表达能力无奈满足（或不适宜强行用 SQL 来表白）的状况也并不常见。
此时，天然的做法是插入一段有状态的 DataStream API 形容的逻辑，再切换回 SQL。
在 Flink 1.14 中，有界的批执行模式的 SQL/Table 利用可将其中间数据表转换成数据流，通过由 DataStream API 定义的算子解决，再转换回数据表。其外部原理是，Flink 构建了一个由优化的申明式 SQL 执行和 DataStream 批执行混合而成的数据流 DAG。详见 相干文档。
混合 Source
全新的 混合 Source 可能顺次地从多个数据源读取数据，在不同数据源之间无缝切换，产出一条由来自多个数据源的数据合并而成的数据流。
混合 Source 针对的是从分层存储中读取数据的场景，相当于从一条逾越所有层级的数据流读取数据。例如，将新数据灌入 Kafka，并最终迁徙至 S3（出于老本与效率的考量这通常是压缩的列存格局）。混合 Source 能够像读取一条间断的逻辑数据流一样，先从 S3 读取历史数据，而后转换到 Kafka 读取最新的数据。
咱们置信这是向着实现日志与 Kappa 架构 残缺前景的令人兴奋的一步。即便事件日志的古老局部在物理上被迁徙到了不同的存储（出于老本、压缩效率、读取速度等起因），你仍能够将其视作间断的日志解决。
Flink 1.14 退出了混合 Source 的外围性能。在后续的版本中，咱们心愿退出更多针对典型切换策略的工具与模式。
整合 Source 和 Sink
随着新的流批对立的 Source 和 Sink API 变得稳固，咱们开始了围绕这些 API 整合所有连接器的微小致力。与此同时，咱们也会让 DataStream 和 SQL / Table API 上的连接器更好地对齐，首先是 DataStream API 上的 Kafka 和 文件 Source、Sink。
随同着这一致力（预计仍将继续 1-2 个版本），Flink 用户在连贯内部零碎时将取得更加晦涩、统一的体验。
二、运维改良
缓冲区去收缩
缓冲区去收缩 是 Flink 中的一项新技术，能够最小化 Checkpoint 的提早和开销。它通过主动调整网络内存的用量，在确保高吞吐的同时最小化缓冲区中的数据量。
Apache Flink 在其网络栈中缓冲了一定量的数据，以便无效利用疾速网络的高带宽。Flink 利用以高吞吐运行时，会应用局部（或全副）网络缓冲内存。对齐的 Checkpoint 随着数据在毫秒级的工夫内流过网络缓冲区。
当 Flink 利用呈现（临时的）反压时（例如内部零碎反压或遇到数据歪斜），往往会导致网络缓冲区中寄存了绝对利用以后吞吐（因反压而升高）所需的带宽过多的数据。更加不利的是，缓冲的数据越多意味着 Checkpoint 机制须要做越多的工作。对齐的 Checkpoint 须要期待更多的数据失去解决，非对齐的 Checkpoint 则须要长久化更多排队中的数据。
这就轮到 缓冲区去收缩 退场了。它将网络栈从持有最多 X 字节的数据改为持有须要接收端 X 毫秒计算工夫解决的数据。默认值是 1000 毫秒，意味着网络栈会缓冲上游工作 1000 毫秒所能解决的数据量。通过继续的测量和调整，零碎可能在一直变动的状况下放弃这一个性。因而，Flink 对齐式 Checkpoint 具备了稳固的、可预测的对齐工夫，反压时寄存在非对齐式 Checkpoint 中的数据量也极大水平缩小了。
缓冲区去收缩能够作为非对齐式 Checkpoint 的补充，甚至是替代选择。对于如何启用该个性，请参考 文档。
细粒度资源管理
细粒度资源管理 是一项新的高级性能，用于进步大型共享集群的资源利用率。
Flink 集群执行多种多样的数据处理工作负载。不同的数据处理步骤通常须要不同的资源，如计算资源、内存等。例如，大多数映射函数都比拟轻量，而较大的、保留工夫较长的窗口函数往往受害于大量内存。默认状况下，Flink 以粗粒度的 Slot 治理资源，一个 Slot 代表 TaskManager 的一个资源切片。一个 Slot 能够寄存流式解决流程中每个算子的一个并发子工作实例，即一个 Slot 可持有一整条解决流程的并发子工作实例。通过 Slot Sharing Group，用户能够影响子工作在 Slot 上的散布。
有了细粒度资源管理，TaskManager 上的 Slot 能够动静扭转大小。转换和算子指定所需的资源配置（CPU、内存、磁盘等），由 Flink 的 ResourceManager 和 TaskManager 负责从 TaskManager 的总资源中划分出指定大小的资源切片。你能够将这看做是 Flink 中的一层最小化、轻量化的资源编排。下图展现了细粒度资源管理与目前默认的共享固定大小 Slot 资源管理形式的区别。
你可能会问，Flink 曾经集成了 Kubernetes、Yarn 等成熟的资源编排框架，为什么还要减少这样一个新个性？有几种状况，在 Flink 外部减少一层资源管理能够显著进步资源利用率：
- 当 Slot 比拟小时，为每个 Slot 专门申请 TaskManager 的代价是十分高的（JVM 开销、Flink 框架开销等）。Slot Sharing 通过让不同类型的算子共享 Slot，即在轻量的算子（须要较小的 Slot）和分量的算子（须要较大的 Slot）间共享资源，在肯定水平上解决了这个问题。然而，这仅在所有算子的并发度雷同时有较好的成果，并非总是最优的。此外，有些算子更适宜独自运行（例如机器学习中负责训练的算子须要专用的 GPU 资源）。
- Kubernetes 和 Yarn 往往须要破费一段时间来满足资源申请，特地是在集群负载较高时。对于一些批处理作业，期待资源的工夫会升高作业的执行效率。
那么什么时候应该启用这一个性呢？默认的资源管理机制实用于大多数流解决和批处理作业。如果你的作业是长时间运行的流作业或疾速的批作业，其不同解决阶段须要的资源差别显著，且你曾经为不同算子设置了不同的并发度，那么你能够尝试用细粒度资源管理进步资源效率。
阿里巴巴外部基于 Flink 的平台曾经利用这种机制有一段时间了，在实践中集群资源利用率有着显著的进步。
对于如何应用细粒度资源管理的更多细节，请参考 文档。
三、连接器
连接器指标
此版本对连接器的指标进行了标准化（详见 FLIP-33）。在接下来的几个版本中，社区将在围绕新的对立 API 逐渐翻新所有连接器的同时，同步实现标准化指标对所有连接器的笼罩。在 Flink 1.14 中，咱们笼罩了 Kafka 连接器和（局部的）文件系统连接器。
连接器在 Flink 作业中是数据的出入口。如果作业未按预期运行，连接器的指标是首先要查看的局部之一。咱们置信对于 Flink 利用的生产运维而言，这将是一个很好的改良。
Pulsar 连接器
此版本新增了 Apache Pulsar 连接器。Pulsar 连接器反对以流和批两种执行模式从 Pulsar 主题读取数据。在 Pulsar 事务性能（自 Pulsar 2.8.0 引入）的反对下，Pulsar 连接器能够反对准确一次的数据传递语义，即便在生产者尝试重传音讯时也能确保音讯仅被传递给消费者一次。
为了满足不同场景下对音讯程序和规模的需要，Pulsar Source 连接器反对四种订阅类型：独占 、 共享 、 灾备 、 键共享。
该连接器目前反对 DataStream API。SQL / Table API 预计将在后续版本中提供。对于如何应用 Pulsar 连接器，请参考 文档。
四、PyFlink
基于链接的性能晋升
与 Java API 将工作中的转换函数、算子链接起来以防止序列化开销相似，PyFlink 当初也会将 Python 函数链接起来。对于 PyFlink，链接不仅能打消序列化开销，还能缩小 Java 和 Python 过程间的 RPC 通信。这大幅提高了 PyFlink 的整体性能。
此前版本中，SQL / Table API 曾经能够将 Python 函数链接起来。在 Flink 1.14 中，这一优化进一步笼罩了 Python DataStream API 中的 cPython 函数。
环回调试模式
通常状况下，Python 函数是由独立于 Flink JVM 之外的 Python 过程执行的。这一架构导致对 Python 代码的调试比拟艰难。
PyFlink 1.14 引入了环回模式，在本地部署模式下主动启用。该模式下，用户自定义 Python 函数将由运行客户端的 Python 过程执行，该过程是启动 PyFlink 利用的入口，负责执行用于构建数据流 DAG 的所有 DataStream API 和 Table API 代码。用户当初本地运行 PyFlink 作业时，能够通过在 IDE 中设置断点的形式不便地调试 Python 函数。
其余改良
PyFlink 还有很多其余改良，例如反对用 Yarn Application 模式执行作业、反对应用 tgz 压缩格局的 Python 归档文件等。更多详情请参考 Python API 文档。
五、辞别旧版 SQL 引擎和 Mesos 反对
保护一个开源我的项目也意味着有时要辞别一些受人青睐的性能个性。
在两年前咱们将 Blink SQL 引擎退出到 Flink 时，就已明确它终将取代本来的 SQL 引擎。Blink 速度更快，性能也更加残缺。最近一年，Blink 已成为默认的 SQL 引擎。在 Flink 1.14，咱们终于将旧版 SQL 引擎的所有代码移除了。这让咱们得以移除许多过期的接口，防止用户在实现自定义连接器和函数时产生不知该用哪个接口的困惑。这还有助于咱们今后更加疾速的迭代 SQL 引擎。
此版本还移除了对 Apache Mesos 的集成，因为咱们发现简直没有用户仍对这一个性感兴趣，同时也短少足够的贡献者违心帮忙保护这部分零碎。Flink 1.14 将不再可能在不依赖于像 Marathon 这样的辅助我的项目的状况下运行在 Mesos 上，同时 Flink 的 ResourceManager 也不再反对依据工作负载的资源需要从 Mesos 动静申请、开释资源。
六、降级阐明
咱们已致力让版本升级变得尽可能顺利，但仍有一些改变须要用户在降级 Flink 版本时对利用的一些局部做出调整。无关降级过程中可能须要做出的调整及确认，请参阅 发版布告。
原文连贯：https://flink.apache.org/news…
贡献者列表
Apache Flink 社区感激对此版本做出奉献的每一位贡献者：
adavis9592, Ada Wong, aidenma, Aitozi, Ankush Khanna, anton, Anton Kalashnikov, Arvid Heise, Ashwin Kolhatkar, Authuir, bgeng777, Brian Zhou, camile.sing, caoyingjie, Cemre Mengu, chennuo, Chesnay Schepler, chuixue, CodeCooker17, comsir, Daisy T, Danny Cranmer, David Anderson, David Moravek, Dawid Wysakowicz, dbgp2021, Dian Fu, Dong Lin, Edmondsky, Elphas Toringepi, Emre Kartoglu, ericliuk, Eron Wright, est08zw, Etienne Chauchot, Fabian Paul, fangliang, fangyue1, fengli, Francesco Guardiani, FuyaoLi2017, fuyli, Gabor Somogyi, gaoyajun02, Gen Luo, gentlewangyu, GitHub, godfrey he, godfreyhe, gongzhongqiang, Guokuai Huang, GuoWei Ma, Gyula Fora, hackergin, hameizi, Hang Ruan, Han Wei, hapihu, hehuiyuan, hstdream, Huachao Mao, HuangXiao, huangxingbo, huxixiang, Ingo Bürk, Jacklee, Jan Brusch, Jane, Jane Chan, Jark Wu, JasonLee, Jiajie Zhong, Jiangjie (Becket) Qin, Jianzhang Chen, Jiayi Liao, Jing, Jingsong Lee, JingsongLi, Jing Zhang, jinxing64, junfan.zhang, Jun Qin, Jun Zhang, kanata163, Kevin Bohinski, kevin.cyj, Kevin Fan, Kurt Young, kylewang, Lars Bachmann, lbb, LB Yu, LB-Yu, LeeJiangchuan, Leeviiii, leiyanfei, Leonard Xu, LightGHLi, Lijie Wang, liliwei, lincoln lee, Linyu, liuyanpunk, lixiaobao14, luoyuxia, Lyn Zhang, lys0716, MaChengLong, mans2singh, Marios Trivyzas, martijnvisser, Matthias Pohl, Mayi, mayue.fight, Michael Li, Michal Ciesielczyk, Mika, Mika Naylor, MikuSugar, movesan, Mulan, Nico Kruber, Nicolas Raga, Nicolaus Weidner, paul8263, Paul Lin, pierre xiong, Piotr Nowojski, Qingsheng Ren, Rainie Li, Robert Metzger, Roc Marshal, Roman, Roman Khachatryan, Rui Li, sammieliu, sasukerui, Senbin Lin, Senhong Liu, Serhat Soydan, Seth Wiesman, sharkdtu, Shengkai, Shen Zhu, shizhengchao, Shuo Cheng, shuo.cs, simenliuxing, sjwiesman, Srinivasulu Punuru, Stefan Gloutnikov, SteNicholas, Stephan Ewen, sujun, sv3ndk, Svend Vanderveken, syhily, Tartarus0zm, Terry Wang, Thesharing, Thomas Weise, tiegen, Till Rohrmann, Timo Walther, tison, Tony Wei, trushev, tsreaper, TsReaper, Tzu-Li (Gordon) Tai, wangfeifan, wangwei1025, wangxianghu, wangyang0918, weizheng92, Wenhao Ji, Wenlong Lyu, wenqiao, WilliamSong11, wuren, wysstartgo, Xintong Song, yanchenyun, yangminghua, yangqu, Yang Wang, Yangyang ZHANG, Yangze Guo, Yao Zhang, yfhanfei, yiksanchan, Yik San Chan, Yi Tang, yljee, Youngwoo Kim, Yuan Mei, Yubin Li, Yufan Sheng, yulei0824, Yun Gao, Yun Tang, yuxia Luo, Zakelly, zhang chaoming, zhangjunfan, zhangmang, zhangzhengqi3, zhao_wei_nan, zhaown, zhaoxing, ZhiJie Yang, Zhilong Hong, Zhiwen Sun, Zhu Zhu, zlzhang0122, zoran, Zor X. LIU, zoucao, Zsombor Chikan, 子扬, 莫辞
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群；
第一工夫获取最新技术文章和社区动静，请关注公众号～
