共计 9381 个字符，预计需要花费 24 分钟才能阅读完成。
摘要： 本文整顿自 Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（莫问），在 Flink Forward Asia 2022 主会场的分享。本篇内容次要分为四个局部：
- 实时流计算寰球范畴事实标准
- 2022 数据实时化技术创新不止
- Streaming Data Warehouse
- 流式数仓 Demo
点击查看直播回放 & 演讲 PPT
一、实时流计算寰球范畴事实标准
Apache Flink 社区从 2014 年诞生到 2022 年曾经通过了间断八年的疾速倒退。从晚期的互联网行业逐渐扩大到更多的传统行业，比方金融、电信、交通、物流、以及能源制作等等。
Apache Flink 诞生于欧洲，暴发于中国。最近几年席卷寰球，在北美、东南亚等寰球各地开始被大量应用。能够说在寰球的各个行业，只有大家想到实时流计算，基本上都会抉择 Apache Flink。因而咱们就能够认定 Apache Flink 社区曾经成为了寰球范畴内实时流计算的事实标准。从 2022 年社区的各项指标中，也进一步失去印证。
Flink 社区通过八年的疾速倒退，在 Github Star 上也始终继续稳固的快速增长。目前为止，Flink 的 Github Star 曾经超过了 20000，这在 Apache 支流的大数据我的项目中仍然是名落孙山的。
在开发者生态方面，咱们也曾经积攒了超过 1600 名的开发者，为 Flink 社区做奉献，2022 年又新减少了 200 多名开发者。从下载量上也能够看到，Flink 在 2022 年再创新高，月度峰值的下载量最高曾经冲破 1400 万次。
在整个 Flink 国际化生态一直凋敝倒退的过程中，咱们能够十分骄傲的看到，中国开发者在外面承当了十分大的外围推动力。
通过 OSS Insight 网站的数据统计能够看到，Flink 社区在 Github 上产生的 Pull Request 有 45% 是来自于中国的开发者。由此可见，整个社区的技术演进和技术开发的推动力次要都是由中国开发者带来的。
Apache Flink 中文社区这几年也在继续稳固的倒退中。去年十分多国内的开发者在 Apache Flink 社区公众号上公布了文章，数量达 100 多篇。Apache Flink 社区公众号的订阅人数也曾经超过了 60000 名。往年咱们还推出了 Apache Flink 官网的视频号，目前订阅人数也曾经将近 4000 名。
Flink 通过多年继续的衰弱倒退，造成了一个凋敝的生态，它的外围竞争力是什么呢？其实十分明确的能够看到，就是 Flink 的技术当先性，实时化的大数据计算能力。
Flink 社区最近几年其实也和其余的支流的开源社区和生态进行了单干，造成了一系列丰富多彩的实时化大数据场景解决方案，例如：
- 和 HBase 社区联结起来造成实时大屏剖析的解决方案。
- 和一些生态数仓我的项目，比方 Hudi、Iceberg、ClickHouse、StarRocks、Doris、TiDB 等开源湖仓产品，造成全链路实时湖仓剖析解决方案。
- 和支流的深度学习框架，比方 TensorFlow，PyTorch 我的项目进行联结应用，提供实时化、个性化举荐的解决方案。
- 和 Prometheus 造成实时监控报警的解决方案。
从以上内容咱们能够看到，Flink 社区的心态是十分凋谢的，能够和很多支流的开源社区造成联结解决方案。让丰富多彩的实时化场景解决方案，推动各个行业大数据实时化技术的降级。
二、2022 数据实时化技术创新不止
接下来我将为大家介绍一下，2022 年中 Flink 社区在实时化技术路线上的一些重要技术成绩和翻新成绩。
Apache Flink 社区在 2022 年公布了两个大的版本，Flink 1.15 和 Flink 1.16。在 1.15 中，Flink 解决了很多以前历史存在的一些难题，比方初步反对了跨版本流 SQL 作业降级，在 1.15 中能够检测到新老版本不兼容的状况并对用户进行提醒，也能够去兼容老版本的 plan 进行降级。
此外 1.15 也解决了 Flink 在多 Source 对齐状况下的挑战。因为 Flink 的一个流工作能够有时候会有多个数据源或者日志流。不同的日志流的数据停顿是不一样的，所以就有可能导致他们的数据进度差别较大。在 1.15 中提出了新的计划，更加不便的实现了多 Source 的 Watermark 对齐。
在 Flink 核心理念中，比方 Checkpoint 和 Savepoint 这两个概念用户就始终不是很分明，常常会使用不当。因而在 1.15 中也对这两个概念从新进行了梳理和定义。同时也将 Checkpoint 和 Savepoint 进行存储格局的对立，让 Savepoint 也能够像 Checkpoint 一样高效的被应用。
此外对批处理技术也进行了更多的欠缺，包含批算子的主动并发设置，让批处理更加易用，流批一体更加实用。
在 1.16 中，咱们做了更多的技术创新和新的技术的尝试。比方咱们对整个 Flink 分布式一致性快照技术架构，进行了很大水平的降级，落地了 Unaligned CP + Log-Based CP 新组合。在 Flink Streaming 方面引进了异步化的技术和缓存能力，使得 Streaming 维表 Join 有更强的能力。
在流批一体畛域提出了流批自适应 Hybrid Shuffle，通过更加正当的利用集群资源，来晋升网络 Shuffle 的性能。
在生态方面，对 Hive 生态进行了更好的兼容和拥抱。不仅可能无缝对接 Hive 的 HMS，也齐全兼容了 HiveServer2 协定。在 Hive SQL 的兼容性上，Flink SQL 也达到了 94% 以上的兼容度，也就是原来用户在 Hive 生态上写的 Hive SQL 绝大部分都能够不通过批改间接运行在 Flink 引擎之上，利用 Flink 实时化计算高性能的能力，去减速 Hive 离线数仓的性能。
在 Python API 方面，PyFlink 也失去了彻底的欠缺。在 1.16 中曾经根本笼罩了所有 Flink 的要害算子。这样对 Python 程序员来说，也能够通过 Python 语言应用 Flink 所有个性了。
方才介绍的 Flink 1.15 和 Flink 1.16 的诸多个性，也只是冰山一角。其实整个 1.15 和 1.16，还推出了十分多的个性和改良。接下来我会抉择一些比拟有代表性和创新性的技术点进行深度解读。
首先来看一下新一代分布式一致性快照的架构。咱们晓得分布式一致性快照技术在整个 Flink 社区里是十分外围的理念。Flink 作为一款有状态的流计算引擎，分布式快照是它的十分外围的特点。
比方 Flink 在不停做流计算的过程中，会定期 Take Snapshot 或者 Checkpoint 将流计算的状态进行长久化。就算流工作出现异常，它也能够从上一个邻近的状态进行复原，保障业务的连续性。因而 Flink 的用户都有一个人造的诉求，就是心愿 Flink 的分布式一致性快照能够更加低成本、高频的做进去，从而让业务更加晦涩。
然而在实在的生产环境中，尤其是大规模、简单的生产环境中，分布式一致性快照是面临十分多挑战的。尤其是在反压的状况下，挑战尤为突出。因为在反压的过程中，整个流计算的网络 buffer 会被打满，也就是网络拥塞。
用来做 Checkpoint 的 Barrier 没有方法胜利的在流外面传输，所以各个流计算的算子也没有方法收集到这些 Barrier，并且让 Barrier 对齐，也就没有方法触发 Checkpoint。即便可能触发 Checkpoint，在执行 Checkpoint 动作的时候，也须要把本地的状态数据上传到近程的云存储之上，数据量的大小也是不可控的。如果在状态数据的变动比拟大的状况下，Checkpoint 仍然会继续很久，并变得不可控。
所以 Flink 在最近几个版本中对整个分布式一致性快照架构做的很多的技术点的降级。比方咱们间断做了多个版本的 Unaligned Checkpoint，推出了 Buffer Debloating 技术。在 Flink 1.16 中落地了 Log-based Checkpoint 来做架构降级和革新。
通过 Buffer Debloating 能够让整个网络 buffer 应用更加高效；通过 Unaligned Checkpoint 去除对 Barrier 对齐的依赖；通过 Log-based Checkpoint 大幅升高执行 Checkpoint 的老本。
接下来分享一下 State 状态存储体系。在云原生时代，咱们须要对 Flink 的状态存储体系进行了更大范畴的降级。置信各个开源软件或者根底软件都须要去思考如何去适应 Cloud Native 时代，如何去进行相应的降级和转型。
云原生时代给咱们带来了的最显著的特点就是资源的弹性更强了，越来越 Serverless 了，这对 Flink 架构提出了更高的弹性扩缩容需要。Flink 作业的并发会随着资源弹性和业务负载一直扭转，因而 Flink 的状态存储也须要进行相应的适配，即状态数据的决裂和合并。
如果状态存储依据并发的变动而进行决裂合并的性能变差，整个 Flink 的弹性扩缩容就会受到重大的影响。因而在 Flink 1.16 中，对 RocksDB State Backend 的状态重建算法进行了大量优化，使之有 2-10 倍的晋升。
但这还不是咱们的终极计划，后续 Flink 将会对整个状态存储管理体系进行更大的降级，变成一个彻底的存算拆散架构来适应云原生环境。咱们心愿所有的状态数据全副都原生在 HDFS 或者云存储之上，本地磁盘和内存只是状态数据的缓存减速层，构建一套体系化的 Tiered State Backend 零碎。
接下来分享一下流批一体上的技术创新。流批一体是 Flink 中一个十分有特色的技术理念，Shuffle 是整个分布式计算里十分外围的一个性能相干的技术。在 Flink 的 Shuffle 中，有两种经典的 Shuffle，别离是流式的 Pipeline Shuffle 和批式的 Blocking Shuffle。
流式的 Pipeline Shuffle 是工作的上下游，通过网络的形式间接连贯进行数据传输。批式的 Blocking Shuffle 是上游将两头数据写到磁盘或者存储服务上，上游通过磁盘或者存储服务下载两头数据。因而在惯例的理念中，流执行模式都会用流式 Shuffle，批工作都会用批式 Shuffle。
但咱们也能够显著的看出，流式 Shuffle 的性能比拟高，因为它不通过磁盘 Io，而批式 Shuffle 通过一次磁盘 Io 性能会更差一点。所以咱们能不能将流式 Shuffle 也利用在批执行模式或者批工作场景下，减速批式 Shuffle 呢？
从技术自身来说是能够的，但在真正生产环境下执行的时候，会发现有一个很大的束缚或者不确定性。因为流式 Shuffle 有个前提条件是，上下游或者说一个联通的连通图须要同时拉起。但这就须要更多的资源，而真正在生产环境下是否能有这么多资源是不可保障的，所以就可能有死锁的状况产生。
因而是否能够在资源绝对短缺的状况下，把连通图一起拉起进行流式 Shuffle 减速。而资源不够的状况下，退回到经典的批式 Blocking Shuffle，这样就能够正当的利用资源来进行 Shuffle 减速了。答案必定是能够的。这也是在 1.16 中推出 Hybrid Shuffle 的背景和思路起因。
接下来分享一下最近一两年新提出的概念 Flink CDC，即基于 Flink 的全增量一体数据同步技术。首先介绍一下做 Flink CDC 的起因。
Flink 实质上是一款流式的分布式执行引擎或者计算引擎，它在大家心目中曾经是连贯各种不同存储的数据管道或者数据通道了。Flink 自身具备十分多的技术特色，比方有丰盛的 Connector 生态，可能连贯各种各样的支流存储系统；有优良的分布式架构，包含反对 Checkpoint 机制，流批交融机制。这些都是一款全增量一体数据集成引擎所须要的个性。所以咱们认为，在 Flink 的肩膀下来构建一款全增量数据同步引擎是特地容易胜利的，因而就启动了 Flink CDC 我的项目。
其实在去年 Flink-CDC 1.0 的试水中，整个开发者生态对它都是一个十分正向的反馈。所以往年加大了对 Flink CDC 的投入，推出了更加欠缺和成熟的 Flink CDC 2.0 大版本和框架。在 2.0 中，咱们形象出了通用的增量快照一致性读取算法。有了它之后，就能够升高接入数据源的老本，减速接入更多的数据源。
同时联合整个分布式框架的诸多劣势，Flink CDC 曾经具备了十分强的能力。比方反对高性能的并行读取，借助 Flink Checkpoint 劣势，实现数据断点续传。并通过增量一致性快照读取算法，能够全程对数据库无锁，这样咱们在整个全增量一体数据同步的过程中不会对在线业务有任何的影响。
从下图中能够看到，Flink-CDC 2.0 曾经接入了很多支流的数据源，比方 MySQL 家族，PolarDB，Oracle，MariaDB 等，接入中有 PG，TiDB 和 Ocean Base 等，置信日后会有更多的数据源接入到 Flink CDC 数据同步框架中。
在最初一项技术创新中，我分享一下 Flink 在机器学习场景中的子项目 – Flink ML 2.0。大家都晓得在老版的 Flink 中有一个模块叫 Flink ML，即 Flink 机器学习算法库。老的 Flink ML 模块是基于 Flink DataSet API 来构建的，但 DataSet API 曾经被废除了。在最近几个版本中，Flink 曾经将根底的 API 层全副对立到流批一体的 DataStream API 之上，不再应用 DataSet，所以老版 Flink ML 也相当于被废除了。
去年其实曾经预报了要从新建设 Flink ML 成为一个新的 Flink 子项目。往年咱们通过致力曾经将这件事进行了从 0-1 的孵化和落地，并公布了两个版本，第三个版本也在进行之中。
咱们都晓得机器学习的算法库，它的运算外围是迭代计算框架，因而咱们在 Flink ML 2.0 我的项目中，基于 Flink Data Stream 流批一体的 API，重建了一套流批一体的迭代计算框架。它不仅反对传统的同步迭代训练，也反对异步的迭代训练模型。
Flink 不只反对无限数据集的训练，也反对有限流数据集上的在线迭代训练。同时借助 Flink Checkpoint 分布式框架的劣势，也反对整个分布式训练断点的异样复原。这对一些须要长时间运行的训练任务还是有很好的生产意义的。
通过一年的致力，在社区版曾经对 Flink ML 的算法进行了第一步的欠缺。阿里云实时计算和机器学习团队独特奉献了 30 多个经典的机器学习算法，笼罩了常见的特色工程场景，明年将会实现所有支流经典 ML 算法库的欠缺。
三、Streaming Data Warehouse
Flink 下一步外围演进的方向是 Streaming Data Warehouse。在这之前，为了更好了解，先来回顾一下历史上核心理念的演进的过程。
Flink 在诞生的时候，它为什么能击败了上一代流式计算引擎 Storm，受到开发者的青眼，成为新的一代流计算的计算引擎的呢？我感觉要害的外围点是 Flink 是一款有状态的流计算，而 Storm 是一个无状态的流计算引擎。
Flink 将 Streaming 计算和状态存储进行有机交融，这样就能够在框架层反对整个流计算状态的精准数据一致性。不仅放弃低提早、高吞吐的流计算能力，还保障了数据一致性，而且是在框架层面放弃的，这是 Storm 做不到的。所以 Flink 凭借技术架构上的翻新成为了新一代流计算的霸主。
但在 Flink 诞生之后的几年，就遇到了一个瓶颈，推广门槛过高。因为大家在晚期开发 Flink 的时候，都要写 Java 程序，通过 DataStream 的 API 写 Java 代码，这对很多数据分析师来说门槛还是很高的。因为在整个数据分析师的世界里，规范的语言是 SQL，这也是 Flink 很难推广的一个起因。
2019 年，阿里巴巴将本人外部积攒的 Blink SQL 奉献给了 Flink 社区，从此 Flink 社区也有了一套十分易用的 Stream SQL。有了 SQL 后大幅升高了开发门槛，所以之后 Flink 的利用失去了爆炸式的增长，这也是为什么大家看到最近这两三年 Flink 呈现了一个减速遍及的过程。
然而 SQL 只可能解决计算层的一些体验问题。即便 Flink 具备流批一体 SQL 的能力，可能实现全量增量开发一体化的体验，但它仍然没有方法解决存储层割裂的问题。
下一阶段 Flink 社区新的机会点就是持续晋升一体化的体验，来实现一套实时数据链路。因而咱们能够通过 Flink 的流批一体的 SQL 和流批一体的存储，构建一套真正一体化体验的流式数仓 - Streaming Data Warehouse。
在 Streaming Data Warehouse 新的理念和状态中，能够保障所有的数据端到端都能够实时流动；整个全链路的开发过程中，用户都能够有全增量一体化的开发体验，并且有对立的数据存储和管理体系。
因而如果要去做下一代的 Streaming Data Warehouse 架构。第一步要欠缺的就是流批一体存储。目前在开源生态中还没有一款真正可能实现，高性能流读流写、批读批写的流批一体存储。
因而 Flink 社区去年推出了全新子项目 Table Store，它的定位就是实现流批一体的存储能力。它的特点是能实现高性能的流读流写、批读批写，所以咱们把 Table Store 的数据表称为动静表。
Table Store 的设计齐全遵循当初新一代存算拆散的理念，能够把数据存储在 HDFS 或者支流云存储上。它的外围存储格局是由 Lake Store 和 Log Store 两局部组成。
在 Lake Store 中，利用了很多经典的数据结构，比方 LSM 和 ORC，以及一系列索引技术。LSM 技术比拟适宜大规模数据更新，ORC 的列存技术配合一些索引，适宜高性能的数据读取。在 Log Store 中，提供了残缺 CDC 语义的 Changelog，这样配合 Flink 的 SQL 就能够增量订阅 Table Store，进行流式的数据分析了。
整个 Table Store 的数据体系是齐全凋谢的，它除了能够默认对接 Flink 之外，它也能对接 Spark、Hive、Trino 等这些支流的开源计算引擎。
Table Store 在 Flink 社区曾经公布了两个版本，0.1 和 0.2。目前除了阿里巴巴以外，字节跳动等一些公司也参加了我的项目的共建。接下来看一下通过两个版本公布，Table Store 在真正场景下的流读、流写、批读、批写的性能怎么样。咱们做了一个性能测试，将 Table Store 和目前最支流的数据湖存储 Hudi 进行了比照。
整个性能测试的业务场景来自经典的 TPC-H，利用 TPC-H 的工具产生 6000 万条订单数据，写入到 MySQL 的订单表中，模仿一个实在的业务行为。而后利用 Flink CDC 做数据同步，将 MySQL 的数据同步到数据湖仓表中。一条链路将它写入到 Apache Hudi 里，一条链路写入到 Table Store。而后去测试、比照一下，两个不同技术数据更新的性能差别，同时咱们再用 Flink SQL 对这两张数据表进行查问。
在测试后果中，咱们能够看到 Table Store 的更新性能十分优良，显著当先了 Hudi 的更新能力。在数据查问的性能上显著当先了 Hudi 的 MOR 模式，比拟靠近 COW 模式，综合性能上能够看出 Table Store 流批一体的读写性能还是十分优良的。
四、流式数仓 Demo
为了让大家更好的了解 Streaming Data Warehouse 这个新理念，制作了一个 demo 供大家观看。
首先通过 Flink SQL 实时同步到 Table Store，而后构建 ODS, DWD，ADS 层。数据及元数据存储在云上 OSS。demo 应用 TPC-H 数据集，蕴含两张事实表，主订单 orders，子订单 lineitem，和两张维度表，别离是用户维表 customer、国家维表 nation。
主订单表关联用户维表能够失去用户所在国家标识，关联子订单表能够失去订单价格，关联国家维表可失去国家字段。被打宽后的明细表，按年和国家进行聚合即可失去年度国家 GMV 散布。
首先创立 MySQL 数据库到 Table Store 的同步工作。第一张是订单明细表 line item。在 Table Store 中，为了更好的辨别不同数据层，咱们给它加上 ods 前缀。在 with 参数中，咱们指定了表的 OSS 存储地址，并设置 auto-create 属性为 true，即主动创立以后表的所在目录。
相似的形式申明其余三张表的 DDL，将主订单表、用户维表、国家维表进行同步。在提交工作时，咱们应用 statement set 语法，将四张表放在一个工作里进行同步。上面咱们开始操作；
从模板核心创立同步工作，点击提交筹备上线作业。
切换到运维界面，筹备启动。
在同步工作启动后，咱们能够开始生成订单明细数据，接下来的动画会演示生成明细数据的过程。
首先应用主订单中的 o_orderkey 关联子订单中的 l_orderkey，能够看到主订单中只有 o_orderkey 等于 1 的记录，满足等值条件。
这里应用 interval join 让主订单表的下单日期 o_order_date 与子订单表的发货日期 l_shipdate 在 14 天内，能够看到子订单表中只有一条记录满足 interval 条件。
同时咱们用子订单中的金额字段和折扣字段计算出 GMV 字段 l_revenue。
紧接着，咱们应用 customer key 与用户维表进行 look up join，失去了用户所在国家的标识 c_nation_key。
最初咱们与国家维表进行关联，失去了用户所在国家字段。
通过一次 interval join 和两次 look up join 订单明细表就构建实现了。
接下来咱们就能够对明细表按年和国家进行汇总，计算出 GMV 金额。咱们同样应用 statement set 语法将明细层和汇总层的计算放在同一个工作里。
上面开始生成作业：点击提交，筹备上线作业。
切换到运维界面筹备启动。
当初所有工作都在运行中，咱们创立长期查问来预览汇总表的数据。随机选取 1993 年，各个国家的 GMV 数据曾经展现进去了。
在上一步中，咱们曾经计算并查问了汇总之后的国家 GMV 数据。假如咱们接到一个新的需要，要将国家维表中的国家字段从英文转换为中文，进行数据勘误。此时咱们能够创立 batch 作业，对维表和它所产生的上游表进行 overwrite。
从模板核心创立为表勘误工作。点击提交筹备上线作业，切换到运维界面筹备启动。
期待作业启动并执行结束后，依照同样形式对 DWD 和 ADS 表进行 overwrite。在上游数据勘误工作都执行实现后，咱们从新查问汇总表的数据，能够看出在勘误后汇总表的国家曾经转化为中文。
以上就是本次 demo 的全部内容。
点击查看直播回放 & 演讲 PPT
更多内容
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…
