作者 |Stephan Ewen & Johannes Moser
翻译 |宋辛童
在 Apache 在软件基金会最近发布的年度报告中，Apache Flink 再次进入最活跃的项目 5 名字！项目最新发布的！ 1.14.0 版本也反映了它非凡的活动，包括超越 200 名贡献者的 1000 其余的贡献。全社区为推进项目付出了持之以恒的努力，我们引以为豪。
新版本在 SQL API、更多的连接器支持，Checkpoint 机制、PyFlink 许多方面带来了许多新的特点和改进。主要改进之一是流批一体化的使用体验。我们相信，在实践中，无限数据流的处理与有限批数据的处理处理，因为许多场景需要处理来自各种数据源的历史数据，同时处理实时数据流。例如，数据探索、新应用状态初始化、流式应用训练模型、升级或修复后的数据重处理等。
在 Flink 1.14 我们终于可以了：Flink 支持部分运行和部分结束的应用程序（部分算子已处理到有界输入数据流的末端） Checkpoint。此外，Flink 在，确保所有计算结果顺利提交 Sink。
(以前只支持单独使用 DataStream API 或 SQL/Table API）。
我们更新了统一 Source 和 Sink API，并已开始。我们新增了 它可以在多个存储系统之间过渡。你现在可以实现，比如先从 Amazon S3 在无缝切换到 Apache Kafka 这种处理。
此外，这一版本朝着我们将 Flink 另一步是创造一个更自调、更容易使用、更容易处理特定知识的目标。作为迈出这一目标的第一步，我们在上一个版本中介绍了它 [1]。现在，我们又添加了它(即缓冲区扩大)。这一特性可以在不增加的情况下保持高吞吐量 Checkpoint 在大小的前提下，加速高负荷Checkpoint。该机制可以通过不断调整网络缓冲区的大小，以最小的缓冲数据达到最佳的吞吐效率。详情请参考章节。
新版本中有许多来自每个组件的新特性和改进，我们将在下面介绍它们。与此同时，我们也告别了一些在最新版本中逐渐被替换和废弃的组件和功能。最具代表性的是新版本。
我们希望你喜欢这个新版本，并渴望了解你的使用经验：这个版本解决了以前没有解决的问题，以及什么新场景？
Flink 其对流和批处理的统一之处在于使用同一套 API、在支持多种执行范式的种执行范式。
正如前面提到的，我们相信流处理和批处理是分不开的。以下段落来自一份 [2]，很好地呼应了这一观点。
流处理和批处理不是非此即彼的选择。Facebook 所有数据仓库的处理都是批处理。我们在大约 5 年前开始研发 Puma 和 Swift。正如我们在 […] 如章所示，混合使用流处理和批处理可节省较长的处理过程数小时。
同一引擎实时处理和历史数据也可以保证语义的一致性，使结果具有更好的可比性。这里有一篇文章 [3]。
以前的版本可以实现流批数据处理。新版本增加了更多使用场景的新特性和一系列使用体验的改进。
Flink 的 Checkpoint 机制原本只支持在应用 DAG 在运行状态下创建所有任务 Checkpoint。这意味着不可能同时读取有界和无界数据源。此外，在数据即将完成和部分任务结束时，用流式(而不是批式)处理有界输入数据的应用程序将不再完成 Checkpoint。这使得最后一部分输出数据无法被提交到要求精确一次语义的 Sink 业务延迟。
通过 [4]，Flink 支持在部分任务结束后创建 Checkpoint，在有界流处理结束后触发 Checkpoint 确保在操作结束时提交所有输出结果 Sink（与 stop-with-savepoint 类似）。
这个特性可以添加到配置中 execution.checkpointing.checkpoints-after-tasks-finish.enabled: true 启用。为了让用户独立选择和尝试重大新特征的传统，这一特征是 Flink 1.14 没有默认启用。我们希望在下一个版本中使用它作为默认模式。
背景：处理有界数据时，尽管人们通常倾向于使用批处理模式，仍有一些情况需要用到流处理模式。例如，Sink 也许只支持流模式(也就是说) Kafka Sink），或者应用希望充分发挥流处理固有的近时间排序特性(例如 [5]）。
SQL 和 Table API 它正成为新项目的默认起点，其自然的声明特征和丰富的内置类型和操作使应用程序开发变得简单和快速。然而，开发人员遇到了一些具体的事件驱动的业务逻辑，SQL 的表达能力无法满足（或不适合强行用 SQL 表达)并不少见。
此时，自然的做法是插入一段状态 DataStream API 描述的逻辑，然后切换回来 SQL。
在 Flink 1.14 在中国，有界的批执行模式 SQL/Table 通过通过 DataStream API 定义算子处理，然后转换回数据表。其内部原理是，Flink 构建了一个优化的声明 SQL执行和 DataStream 由批准执行混合而成的数据流 DAG。详见 [6]。
全新的 [7] 它可以依次从多个数据源读取数据，在不同的数据源之间无缝切换，产生由多个数据源组成的数据流。
混合 Source 对于从分层存储中读取数据的场景，相当于从跨越所有层次的数据流中读取数据。例如，注入新数据 Kafka，并最终迁移到 S3(考虑到成本和效率，这通常是压缩列存格式)。混合 Source 就像读取连续的逻辑数据流一样，从 S3 读取历史数据，然后转换为 Kafka 读取最新数据。
我们相信这是为了实现日志和 Kappa 结构完整前景令人兴奋的一步。即使事件日志的旧部分在物理上迁移到不同的存储（出于成本、压缩效率、读取速度等原因），您仍然可以将其视为连续日志。
Flink 1.14 加入了混合 Source 核心功能。在后续版本中，我们希望为典型的切换策略添加更多的工具和模式。
统一新流批 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 的补充，甚至是替代选择。关于如何启用该特性，请参考 [8]。
细粒度资源管理是一项新的高级功能，用于提高大型共享集群的资源利用率。
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 的平台已经应用这种机制有一段时间了，在实践中集群资源利用率有着显著的提高。
关于如何使用细粒度资源管理的更多细节，请参考 [9]。
此版本对连接器的指标进行了标准化（详见 [10]）。在接下来的几个版本中，社区将在围绕新的统一 API 逐步翻新所有连接器的同时，同步实现标准化指标对所有连接器的覆盖。在 Flink 1.14 中，我们覆盖了 Kafka 连接器和（部分的）文件系统连接器。
连接器在 Flink 作业中是数据的出入口。如果作业未按预期运行，连接器的指标是首先要检查的部分之一。我们相信对于 Flink 应用的生产运维而言，这将是一个很好的改进。
此版本新增了 [11] 连接器。Pulsar 连接器支持以流和批两种执行模式从 Pulsar 主题读取数据。在 Pulsar 事务功能（自 Pulsar 2.8.0 引入）的支持下，Pulsar 连接器可以支持精确一次的数据传递语义，即使在生产者尝试重传消息时也能确保消息仅被传递给消费者一次。
为了满足不同场景下对消息顺序和规模的需求，Pulsar Source 连接器支持四种订阅类型： [12]、 [13]、 [14]、 [15]。
该连接器目前支持 DataStream API。SQL / Table API 预计将在后续版本中提供。关于如何使用 Pulsar 连接器，请参考 [16]。
与 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 归档文件等。更多详情请参考 [17]。
维护一个开源项目也意味着有时要告别一些受人喜爱的功能特性。
在两年前我们将 Blink SQL 引擎加入到 Flink 时，就已明确它终将取代原本的 SQL 引擎。Blink 速度更快，功能也更加完整。最近一年，Blink 已成为默认的 SQL 引擎。在 Flink 1.14，我们终于将旧版 SQL 引擎的所有代码移除了。这让我们得以移除许多过时的接口，避免用户在实现自定义连接器和函数时产生不知该用哪个接口的困惑。这还有助于我们今后更加快速的迭代 SQL 引擎。
此版本还移除了对 Apache Mesos 的集成，因为我们发现几乎没有用户仍对这一特性感兴趣，同时也缺少足够的贡献者愿意帮助维护这部分系统。Flink 1.14 将不再能够在不依赖于像 Marathon 这样的辅助项目的情况下运行在 Mesos 上，同时 Flink 的 ResourceManager 也不再支持根据工作负载的资源需求从 Mesos 动态申请、释放资源。
我们已努力让版本升级变得尽可能顺利，但仍有一些改动需要用户在升级 Flink 版本时对应用的一些部分做出调整。有关升级过程中可能需要做出的调整及确认，请参阅 [18]。
原文连接：
https://flink.apache.org/news/2021/09/29/release-1.14.0.html
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, 子扬, 莫辞
[1] https://flink.apache.org/news/2021/05/03/release-1.13.0.html#reactive-scaling
[2] https://research.fb.com/wp-content/uploads/2016/11/realtime_data_processing_at_facebook.pdf
[3] https://www.ververica.com/blog/apache-flinks-stream-batch-unification-powers-alibabas-11.11-in-2020
[4] https://cwiki.apache.org/confluence/display/FLINK/FLIP-147%3A+Support+Checkpoints+After+Tasks+Finished
[5] https://www.youtube.com/watch?v=4qSlsYogALo&t=666s
[6] https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/dev/table/data_stream_api/
[7] https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/connectors/datastream/hybridsource/
[8] https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/deployment/memory/network_mem_tuning/#the-buffer-debloating-mechanism
[9] https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/deployment/finegrained_resource/
[10] https://cwiki.apache.org/confluence/display/FLINK/FLIP-33%3A+Standardize+Connector+Metrics
[11] https://pulsar.apache.org/
[12] https://pulsar.apache.org/docs/zh-CN/concepts-messaging/#exclusive
[13] https://pulsar.apache.org/docs/zh-CN/concepts-messaging/#shared%E5%85%B1%E4%BA%AB
[14] https://pulsar.apache.org/docs/zh-CN/concepts-messaging/#failover%E7%81%BE%E5%A4%87
[15] https://pulsar.apache.org/docs/zh-CN/concepts-messaging/#key_shared
[16] https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/connectors/datastream/pulsar/
[17] https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/dev/python/overview/
[18] https://nightlies.apache.org/flink/flink-docs-release-1.14/release-notes/flink-1.14/
---------- END ----------
往期推荐
推荐 | 颜值与功能双在线的 Zookeeper 可视化工具：PrettyZoo
Impala在腾讯金融大数据场景中的应用
Flink实时计算topN热榜
hadoop之yarn命令详解
HBase原理（一）：架构理解
分享一下我对 ambari 二次开发的一些理解~
公开课：Amabri自定义服务集成之前要做的规划或步骤有哪些
最后说一句(求关注，别白嫖我)
扫一扫，我们的故事就开始了。
动动小手，让更多需要的人看到~