共计 7225 个字符，预计需要花费 19 分钟才能阅读完成。
本文整顿自 Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（莫问）在 Flink Forward Asia 2021 的分享。本篇内容次要分为四个局部：
- 2021: Apache Flink 社区继续凋敝
- Apache Flink 核心技术演进
- 流批一体演进与落地
- 机器学习场景反对
点击查看直播回放 & 演讲 PDF
一、2021: Apache Flink 社区继续凋敝
1.1 Flink 大版本迭代
2021 年，Flink 社区共公布两个大版本：Flink 1.13 和 Flink 1.14。
在 Flink 1.13 中，Flink 的部署架构朝着云原生架构进一步演进，使得 Flink 可能更加适应云原生环境下的运行；此外，Flink 在易用性方面也有显著晋升，使得用户能够十分便捷地对 Flink 工作进行调试、调优和监控等；在存储方面，Flink Checkpoint 格局失去对立，用户在不同的 State backend 之间无缝切换，不同的版本之间可进行晦涩降级。
Flink 1.14 中最大的变动是残缺地实现了 Flink 流批一体的架构和理念。在去年的 Flink Forward Asia 2020 会议上我重点分享了 Flink Unified SQL。往年，Flink 不仅在 SQL 和 Table API 上进行了流批一体的对立，在 Java API 自身、Data Stream，Data set API 上也进行了流批一体的对立。所有流批一体的语义都被对立到 Data stream API 之上，用户基于 Data stream 能够解决无限流和有限流从而实现流批一体的开发。此外 Flink 在资源层实现了细粒度的资源管理，令 Flink 工作在大规模场景下更高效；在网络流控方面 Flink 也进行了自适应流控的降级，通过自适应流控降级之后，用户能够更快地执行 Flink 的全局一致性快照。通过这些技术创新和技术演进之后，Flink 社区持续放弃疾速倒退和生态沉闷。
1.2 Apache Flink 社区层面体现继续亮眼
在 2021 年，Apache 软件基金会的财年报告中，Flink 社区的多项指标仍然放弃十分衰弱的倒退：在邮件列表中持续排名第一；Github 我的项目拜访流量排名第二；代码库的提交次数排名第二等。通过这些沉闷的指标能够看到 Flink 社区的活跃度在整个 Apache 软件基金会的社区中名落孙山。
Flink 社区的衰弱倒退离不开宽广代码贡献者对 Flink 我的项目的软件研发和技术利用的推动。截止目前，已有超过 1400 名开发者对 Apache Flink 我的项目进行过代码级的奉献。这些开发者别离来自于寰球 100 多家公司，其中不仅蕴含寰球出名的国际化公司，还有更多来自中国外乡的科技公司，中国因素在 Flink 社区施展着越来越大的作用。
阿里巴巴从 2018 年开始就踊跃建设 Apache Flink 中文社区，推动 Flink 在中国的疾速倒退。
从开明 Apache Flink 的公众号（Apache Flink）至今，已有 5 万名开发者订阅，仅去年一年，Apache Flink 公众号就公布了 140 多篇技术文章，次要围绕社区的动静、技术分享、以及各行业如何应用 Apache Flink 的用户案例。最近，Apache Flink 视频号也已正式开明，心愿借助更加新鲜的模式，从更多维度展现社区的倒退，对社区的技术和利用进行分享。
2021 年 7 月份，Flink 中文学习网站（https://flink-learning.org.cn）正式上线。咱们将网络中各种 Flink 的学习材料会集到一起，让更多 Flink 开发者、Flink 用户可能十分不便地学习 Flink 的常识技术、利用场景和利用案例。
尽管 2021 年是充斥疫情的一年，但社区经营流动没有进行。咱们在北京、上海等地仍然举办了 4 场 meetup。咱们也期待在新的一年中，越来越多的公司违心积极主动承当 Flink 社区的流动，推动 Flink 社区的倒退。
二、Apache Flink 核心技术演进
大数据和云原生是密不可分的两个场景，云上的环境和弹性能够给大数据计算更多空间，推动大数据更快遍及。Apache Flink 在云原生的趋势下对部署架构和资源管理形式做出进一步演进，使其齐全适应云原生模式：云上用户能够依据业务的流量变动随时动静扩缩容资源，做到按需应用，因而 Flink 也要适应云上按需应用的场景，依据云上资源动静扩缩容的变动在计算拓扑上以自适应模式调整并发，从而适应云上资源变动，具备更好的自动化运维和自适应运维能力。
除了云原生之外，Flink 最外围的技术理念是全局一致性快照。因为 Flink 最大的技术亮点就是它是有状态的实时计算引擎，通过 chandy Lamport 算法实现全局一致性快照，保证数据在齐全实时的状况下实现残缺的数据一致性保障和容错能力，所以全局一致性快照是 Flink 数据一致性保障和零碎容错的要害。如果咱们可能一直晋升全局一致性快照的品质和性能，Flink 外围的实时计算体验就会失去晋升，包含劫难复原也会变得更加平滑。
Flink 全局一致性快照的过程，总共分为四个步骤：
- 插入 checkpoint barrier：定期在 source 端插入非凡的 barrier，barrier 会顺着数据流向上游流动；
- 多输出 Barrier 对齐：每一个算子收到所有上游的 barrier 之后，做 barrier 对齐，而后做下一步 snapshot；
- Snapshot + Upload：在 snapshot 过程中须要将外部状态数据做长久化存储，比方存入 HDFS 之中；
- Checkpoint Complete：将 snapshot 做完之后同步 master，当所有的算子做完之后，全局分布式的一致性快照流程实现。
在这个过程中，真正可能晋升性能次要在第二点和第三点，即 barrier 对齐和将整个数据做一次 snapshot 并上传到 HDFS 上。
因而 2021 年，Flink 社区次要围绕第二步和第三步做 checkpoint 的优化。barrier 对齐看起来是一个简略的操作，但有时候也会卡很久，尤其是在反压的状况下，当上游算子的计算能力忽然降落，大量数据阻塞到网络层，使得 barrier 对齐耗时很久，将会导致工夫不可控。
如何解决这个问题呢？Flink 的网络流控机制是 credit-based 的流控机制，即上下游通过协商和管制上下游之间 buffer 的数量，起到高效的网络流控。但当上游呈现反压状况，计算能力急剧下降，这时不须要大量网络 buffer 进行数据缓冲，所以咱们提出在 credit-based 的根底上实现了 adaptive，即自适应的网络流控机制：不仅思考上下游协商时网络 buffer 的数量，还会思考网络 buffer 的大小，依据计算能力动静调整 buffer size，这样在上游反压计算能力降落的状况下，网络 buffer 的数据量就会变少，从而缓解反压时对 buffer 对齐的影响。
为了进一步晋升 checkpoint 的性能和速度，须要放慢每个算子做本地 take snapshot 的过程，为了扭转整个 take snapshot 和备份 snapshot 的机制，于是 Flink 引入了 log-based 的 checkpoint 机制，减速单算子执行 checkpoint 的性能。
有了这个机制之后，用户就能够在写 state 时，一方面写 state backend，一方面写 changelog。当在做 snapshot 时，能够在 changelog 中打一个 meta 数据，示意 check point 曾经做了，state 和 snapshot 数据就不仅是 state file，而且要加上 changelog。在这个过程中，能够把 state file 的数据向 HDFS 的拷贝作为定期法则化的过程，将它的频率和 checkpoint 的频率解耦，因而 check point 的速度就能够实现到秒级甚至毫秒级。这样不仅能够大幅度晋升容错体验，全局一致性体验和端到端的数据体验都失去大幅晋升。
Flink 不只有 SQL 的 API，也有 Java 的 API 去解决大数据的一些惯例计算，在机器学习和科学计算畛域被认为仍然具备很大的后劲 (实际上在机器学习畛域 Flink 确实曾经施展了巨大作用)。
PyFlink 在 2021 齐全追平了 table API 和 data stream API 的能力，同时在性能上做了很大的翻新：在 PyFlink 里将 Java 代码，C 代码和 Python 代码运行在一个过程中，不须要进行跨过程通信。通过 JNI 的技术，Java 框架能够调用 C 的代码，在 C 外面又调用 Python 解析器去执行 Python UDF，胜利去除跨过程通信的依赖，让整个 Python UDF 的性能能够达到靠近 java 的性能从而兼顾开发和运行效率。
三、流批一体演进与落地
在传统经典的 stream processing 之外，流批一体是 Flink 社区最近几年始终在提的翻新理念。接下来和大家分享流批一体在 Flink 的技术演进和理论落地场景。
在 API 层面，通过 unified SQL Flink 能够实现流批一体的开发。在去年天猫双十一我的项目中，阿里巴巴应用流批一体的 SQL 实现营销数据大屏实时和离线一体化的落地。往年，Flink 社区将 API stack 做得更加流批一体化，社区整合了 datastream 和 dataset 之后只保留了 datastream 的 API。在 datastream 的 API 上能够对接无限流和有限流，实现 java 层面流批一体的 API。
除此之外，Flink 的整个架构也彻底实现了流批一体的对立，能够同时解决无限数据集和有限数据集。用户能够开发一套代码同时对接两套数据源，因为 connector 框架岂但能够兼容流式存储，而且能够兼容批式存储，甚至能够在流式存储与批式存储间自在切换。Flink 的调度是一套 scheduling 调度器，能够调度各种各样的工作。在数据网络 shuffle 上，不仅有 Flink 善于的高性能流式 shuffle 框架，还引入了批式 shuffle 框架。阿里巴巴实时计算团队也奉献了第一版存算拆散的 remote shuffle service，并放到了 flink 开源生态项目组下：https://github.com/flink-exte…
有了这套流批一体对立架构，Flink 社区真正实现了一套从 API 到零碎架构的流批一体残缺理念。
流批一体是技术架构理念，须要在具体业务场景中落地能力看到价值，接下来给大家举一个 Flink CDC 的例子。Flink CDC + 流批一体架构能够实现全增量一体化的数据集成。传统数据集成的离线数据集成和实时数据集成基本上采纳两套技术栈，同时在两边进行简单配合能力实现残缺的数据集成计划。（PS：数据集成是刚需但同时又很简单。）
Flink 的流批一体能力联合 Flink CDC 的能力能够实现一站式数据集成：先全量同步历史数据，而后主动接到断点续传增量数据，实现一站式的数据同步。比方咱们能够应用 Flink CDC，用 1 个 job，一条 SQL 将 MySQL 全副数据同步到 Hudi 数据湖之中，并且主动进行增量的实时同步。
Flink CDC 曾经能够对接支流数据库，比方 MySQL、MariaDB、PGSQL、MongoDB、Oracle 等等。基于 Flink CDC 2.0 能够一站式将数据全库同步到其余数据库或者数仓数据湖中。
Flink CDC 如何实现全增量一体化的数据集成呢？
它利用了 Flink 流批一体的根底技术能力，联合 CDC 的 connector。在 Flink CDC 工作外部，第一步是全量读取数据库全表，基于 Flink 并行计算能力，疾速将全表数据进行同步；而后主动切换到 binlog 的增量数据源上，利用 Flink hybrid source 的能力，做外部流批数据源的切换；切换到增量之后实时同步 binlog，从而达到离线实时全增量一体化的数据集成。在这个过程中能人造保证数据的一致性，对用户来说没有任何额定的操作。
接下来，向大家着重介绍下实时离线一体化数仓场景。上图是十分经典支流的实时离线一体化数仓架构，绝大部分的用户场景都会应用 Flink 加 Kafka 做实时数据流解决，将剖析后果写入在线服务层对用户进行展现或进一步剖析，同时在后盾有一个异步离线数仓架构，对实时数据进行补充，每天定期大规模的批量运行 / 全量运行或对历史数据定期修改。
但这个架构存在着几个问题：
- 因为采纳不同的技术栈，所以实时链路跟离线链路有两套 API，岂但减少了开发成本，而且升高了开发效率；
- 实时数仓和离线数仓的数据口径难以放弃人造的一致性；
- 在整个实时流动的链路中，以 Kafka 为代表的音讯队列中的数据不便于实时摸索和剖析
在新的 Streaming Warehouse 的架构中，咱们引入了 Dynamic Table 的概念，即 Flink 的动静表，数仓的分层数据全副放到 Flink Dynamic Table 中，通过 Flink SQL 实时串联整个数仓的分层，数据在各个分层间进行实时流动，并能够对历史数据进行实现离线修改。与此同时，用户能够利用 Flink SQL 实时摸索和剖析 Dynamic Table 中流动的数据。这个架构真正做到了实时离线剖析一体化：对立的 SQL、对立的数据存储、对立的计算框架，并让数据在数仓中可能实时流动起来，因而咱们称其为：Streaming Warehouse 即流式数仓，该架构有三个劣势：
- 全链路数据实现秒级和毫秒级的实时流动；
- 所有流动中的数据皆可剖析，没有任何数据盲点；
- 实时离线剖析一体化，用一套 API 实现所有的数据分析。
流式数仓 Streaming Warehouse（简称 Streamhouse）将是 Flink 社区后续重点演进的方向。
在 Streamhouse 之中咱们引入了一个新的概念叫作动静表，能够把 Flink 动静表了解为一套流批一体的存储 (Flink SQL / datastream 等都是 flink 流批一体的计算，Dynamic Table 对应流批一体的存储)。Dynamic Table 具备流表二象性，因而其在数据结构上有两个存储属性：第一个是 File Store，第二个是 Log Store。
顾名思义，File Store 存储 Dynamic Table 的长久化数据，采纳经典的 LSM 架构，反对实时流式的更新、删除、减少等语义，同时采纳凋谢列存构造反对压缩等高性能，能够对接 Flink SQL 批模式进行历史数据分析。
Log Store 存储 Dynamic Table 的变动序列，是一个不可更改的序列，能够对接 Flink SQL 流模式，通过订阅 Dynamic Table 的增量变动，进行实时剖析。
接下来，咱们通过一段 demo 介绍如何利用 Flink CDC 和 Flink SQL、Flink Dynamic Table 构建一套残缺的流式数仓，实现实时离线一体化的体验。
demo 演示：https://www.bilibili.com/vide…
四、机器学习场景反对
接下来向大家介绍 Apache Flink 在机器学习生态的演进状况。Flink 的很多利用场景都与机器学习相干，比方互联网公司大量应用 Flink 做在线机器学习和离线机器学习，将 Flink 广泛应用于举荐，广告和搜寻等业务场景。
往年借力 Flink 流批一体技术的演进和降级咱们重构了 Flink ML 的根底框架降级为 Flink ML 2.0。基于新的流批一体 datastream API，构建新的迭代计算能力和 ML 算法，并将这个我的项目奉献到了 Flink 社区。与此同时，很多开发者或公司在 Flink 上奉献了很多机器学习生态的开源我的项目，比方阿里巴巴奉献的 deep learning on Flink，心愿将来有更多的公司积极参与奉献。
首先，机器学习架构是建设在流批一体的底层架构之上，因为新的 datastream 兼具流和批的解决能力，所以咱们在 datastream 上构建了一套全新的迭代计算能力，这套迭代计算能力是 Flink 引擎原生的迭代计算能力，能够同时实现同步迭代以及异步迭代，让迭代的效率更加高效。Flink 的流批一体能力能够对接不同的数据源，包含流式数据源、批式数据源、不同的计算能力等等，令特色工程和模型训练变得更加高效。此外，新的 Flink ML pipeline API 也参考了经典的 scikit-learn 格调，让传统机器学习的开发者更不便的上手。
基于 Flink 本身大数据计算能力的劣势，包含实时化、实时处理能力的劣势，在这个架构下能够将数据荡涤、数据预处理、特色计算、样本拼接和模型训练齐全串联，造成一套高效的大数据 +AI 一体化的计算流程，与此同时还能够兼容业界比拟成熟的深度学习算法。
Flink ML 最大的特点是其框架能够兼容流式和批式的数据源，实现在线机器学习流程和离线机器学习流程一体化。目前，阿里巴巴的机器学习团队在陆续推动算法的奉献，心愿当前有更多开发者或公司可能参加进来一起奉献。同时 Flink ML 能够嵌入支流的深度学习算法库，例如：tensorflow 和 PyTorch，创立全链路的深度学习流程。
整个机器学习流程中工作流的调度治理是大数据和 AI 的一个跨界问题。针对这个问题，阿里巴巴实时计算团队去年开源了一个我的项目叫 AI flow (https://github.com/flink-exte…)，这个我的项目能够围绕 Flink 实现从特色计算到模型训练、模型预测、模型验证全流程的治理调度零碎。目前，业界曾经有多家公司参加到这个我的项目的奉献和应用中，十分心愿有更多的公司和开发者参加进来，独特推动生态倒退。
Flink 社区通过最近几年的疾速倒退，技术创新仍在一直向前演进，从最后的流解决引擎向更加全面的流式数仓方向进化，并在数据湖、机器学习等大数据算力驱动的场景下施展更大的价值。期待将来有更多的公司和开发者参加到 Flink 社区，独特拓展 Flink 生态进一步倒退。
点击查看直播回放 & 演讲 PDF
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～
