作者｜王峰
本文由 Apache Flink 中文社区发起人，阿里云计算平台事业部实时计算与开放平台部门负责人王峰分享，主要介绍 Flink 作为一款统一的流批一体引擎其发展现状及未来规划。大纲如下：
- 2020：Apache Flink 社区生态加速繁荣的一年
- 技术创新：Apache Flink 社区发展的核心驱动力
- Flink 在阿里巴巴的现状和未来
2020：Apache Flink 社区生态加速繁荣的一年
1.Flink 蝉联 Apache 社区最活跃项目
我们先来介绍一下在 2020 年 Flink 社区生态发展的态势。整体来说，社区处在一个非常健康和高速的发展过程中，尤其是在 2020 年，我们取得了非常好的成果。从 Apache 软件基金会 2020 财年的报告中，可以看到一些很关键的数据：
- Flink 用户和开发者邮件列表活跃度 Top1
- Github 上 Flink 代码提交次数 Top2
- Github 上 Flink 的用户访问量 Top2
综合这几个数据来看，可以认为 Flink 在 Apache 众多的开源项目中名列前茅，是 Apache 最活跃的项目之一。我们在 Github 上 Star 的数量，以及 Flink 贡献者数量的增长趋势也是非常喜人的。最近几年来，我们一直处在一个加速上涨的过程，每年都是平均 30% 以上的数据增长，可以看出 Flink 整个生态的繁荣和高速发展。
2.Apache Flink 年度发布总结
我们再回顾一下 2020 年整个社区在技术上取得的成果。Flink 社区在 2020 年发布了三个大的版本， Flink-1.10，Flink-1.11，以及 12 月最新发布的 Flink-1.12 三大版本。这三个版本相对于去年收官的版本 Flink-1.9 有非常大的进步。
在 Flink-1.9 中，我们完成了将 Blink 代码贡献合并进入 Flink 社区，使得 Flink 流批一体架构正式启动。今年我们又通过 1.10、1.11、1.12 这三个版本对 Flink 流批一体架构做了重要的升级和落地。同时在 Flink SQL 的开发场景下，我们不仅支持了流批一体的 SQL，同时也支持读取数据库 binlog 的 CDC，并且对接了新一代数据湖的架构。Flink 在 AI 场景下的应用也越来越广泛，所以我们在 Python 语言上也提供了大量支持，PyFlink 已经可以完整的支持 Flink 的开发。在 K8s 的生态上，我们也做了很多的工作。
Flink 经过今年三个版本的迭代以后，已经可以完整的以云原生的方式运行在 K8s 的生态之上，去除了对 Hadoop 的依赖。以后在 K8s 生态之上也可以使 Flink 的部署与其他的在线业务进行更好的混布。
3.Apache Flink 中文社区持续火热
在此也跟大家分享一下 Flink 中文社区的发展。
首先，从邮件列表来看，Flink 项目可能是 Apache 顶级项目中唯一一个开通中文用户邮件列表的项目。Apache 作为一个国际化的软件基金会，基本上以英文交流的方式为主，由于 Flink 在中国的活跃度空前，所以我们也开通了中文邮件列表。目前中文邮件列表的活跃度甚至已经超过英文邮件列表，成为全球 Flink 最活跃的地区。
其次，社区也开通了 Flink 的中文社区公众号（上图左侧），每周推送社区资讯、活动信息、最佳实践等内容为开发者提供了解社区进展的窗口，目前超过 3 万名活跃的开发者订阅我们，全年推送超过 200 篇与 Flink 技术，生态以及实践相关的最新资讯。
前段时间，我们还推出了 Flink 社区官方中文学习网站（https://flink-learning.org.cn/），希望帮助更多的开发者方便的学习 Flink 技术，了解 Flink 的行业实践，同时我们的 Flink 社区的钉钉大群也为大家提供了技术交流的平台，欢迎大家加入，进行技术的交流。
4.Apache Flink 成为实时计算事实标准
现在 Flink 已经成为了实时计算事实上的标准，我相信目前国内外各种主流的 IT 或科技驱动的公司，都已采用 Flink 做实时计算。Flink Forward Asia 2020 也邀请到了 40 多家国内外一流公司分享他们的 Flink 的技术和实践，非常感谢这些公司的讲师们、专家们来分享。我相信未来各行各业会有更多的公司采用 Flink 去解决实时数据的问题。
技术创新：Apache Flink社区发展的核心驱动力
1. 流计算引擎的内核技术创新
接下来主要跟大家介绍技术方面 Flink 社区在 2020 年的发展。我们相信技术创新是开源项目、开源社区持续发展的核心驱动力。这部分将分为三个方向来分享，首先介绍一下 Flink 在流计算引擎内核的一些技术创新。
Unaligned Checkpoint - 优化加速
第一个例子是非对齐式的 Checkpoint。Checkpoint 技术需要不断的在实时的数据流中插入 barrier，做定期的 snapshot，这是 Flink 最基本的理念之一。在现有的 Checkpoint 模式下，因为需要对齐 barrier，所以在反压或者数据计算压力非常大的情况下，Checkpoint 有可能是做不出来的。所以我们今年在 Flink 社区里做了一个非对齐的 Checkpoint，使得在反压的情况下，Checkpoint 也能够比较快速的做出来。
非对齐的 Checkpoint 和现有的对齐的 Checkpoint 可以通过设置 alignment timeout 进行自动切换：正常情况下做对齐式 Checkpoint，而在反压的时候切换到非对齐的 Checkpoint。
Approximate Failover – 更加灵活的容错模式
第二个技术创新是在容错方面。众所周知，Flink 的数据是支持强一致性（exactly-once）的。但是为了保证强一致性，其实在整个系统的可用性上有一些 trade off。为了保证数据强一致性，任何一个 Flink 节点的失败都会导致 Flink 全部节点回滚到上一次的 Checkpoint，在这个过程中需要进行整个 DAG 图的重启。在重启的过程中业务会有一个短时间的中断和回滚。其实很多场景对数据的强一致性不是必须的，对于少量数据的损失是可以接受的。对于一些采样数据的统计或者机器学习场景下特征计算，并不是说一条数据都不能丢，这些应用场景反而对数据的可用性有更高的要求。
所以我们在社区里创新做一种新的容错模式，Approximate Failover，一个更加灵活的容错模式，使得任何一个节点失败，只对这个节点本身进行重启和恢复，这样的话整个图不用重启，也就是说整个的数据流程不会中断。
Nexmark - Streaming Benchmark
同时，我们在流计算方向发现缺乏一个比较标准的 Benchmark 工具。在传统的批计算中，有各种 TPC Benchmark 可以比较完善的覆盖传统批计算的场景。而在实时流计算场景下则缺乏标准的 Benchmark。基于 Nexmark 的一篇论文，我们推出了第一版包含 16 个 SQL Query 的 benchmark 工具 Nexmark。Nexmark 有三个特点：
第一， 覆盖场景更全面
- 基于在线拍卖系统业务模型设计
- 16 个 Query，全面覆盖常用流计算场景
- ANSI SQL，标准化，更容易扩展
第二， 更加方便易用
- 纯内存数据源生成器，灵活调控负载
- 无外部系统依赖
- 性能指标采集自动化
第三，开源，开放
Nexmark 已经开源 https://github.com/nexmark/ne...，大家如果希望比对不同 Flink 版本之间流引擎的差异，或者对比不同的流计算引擎之间的差异，都可以采用这个工具。
2.Flink 架构的演进
全新的流批一体架构
再介绍一下 Flink 架构的演进，Flink 是一个流计算驱动的引擎，它的核心是 Streaming。但是它可以基于 Streaming 的内核，实现流批一体更全能的架构。
2020 年，Flink 在流批一体上走出了坚实的一步，可以抽象的总结为 Flink 1.10 和 1.11 这两个大的版本，主要是完成 SQL 层的流批一体化和实现生产可用性。我们实现了统一的流批一体的 SQL 和 Table 的表达能力，以及统一的 Query Processor，统一的 Runtime。
在刚发布的 1.12 版本中，我们也对 DataStream API 进行了流批一体化。在 DataStream 原生的流的算子上增加批的算子，也就是说 DataStream 也可以有两种执行模式，批模式和流模式里面也可以混合批算子和流算子。
正在规划的 1.13 的版本中，会彻底实现 DataStream 流批一体化的算子，整个的计算框架和 SQL 一样，完全都是流批一体化的计算能力。这样一来，原来 Flink 中的 DataSet 这套老的 API 就可以去掉，完全实现真正的流批一体的架构。
在全新的流批一体的架构之下，整个 Flink 的机制也更加清晰。我们有两种 API，一个是 Table 或者 SQL 的关系型 API，还有 DataStream 这种可以更灵活控制物理执行的 API。无论是高层的 API（Table 或者 SQL），还是低级的 API（DataStream），都可以实现流批一体的统一表达。我们还可以将用户的需求表达的图转换为一套统一的执行 DAG 图。这套执行 DAG 图中，可以使用 Bounded Stream，也可以使用 Unbounded Stream，也就是有限流和无限流两种模式。我们的 Unified Connector 的框架也是流批一体的统一框架：可以读流式的存储，也可以读批式的存储，整个架构将会把流和批真正融为一体。
在核心的 Runtime 层也实现了流批一体。调度和 Shuffle 是 Runtime 层最核心的两部分。在调度层支持 Pluggable 的插件机制，可以实现不同的调度策略应对流、批、甚至流批混合的场景。在 Shuffle Service 层面，也支持流式和批式的 Shuffle。
同时我们正在做更新一代的 Shuffle Service 的框架：Remote Shuffle Service。Remote Shuffle Service 可以部署到 K8s 里面，实现存储计算的分离。就是说，Flink 的计算层和 Shuffle 类似于一个存储服务层，完全解耦的部署，让 Flink 的运行更加具有灵活性。
TPC-DS Benchmark
批的性能究竟如何是大家比较关心的一个问题。经过三个版本的努力之后，Flink-1.12 比 Flink-1.9（去年的版本）已经有三倍的提升。可以看到，在 10TB 数据量，20 台机器的情况下，我们的 TPC-DS 的运行时间已经收敛到 1 万秒以内了。所以 Flink 的批处理性能已经完全达到生产标准，不亚于任何一个业界目前主流的批处理引擎。
流批一体数据集成
流批一体不只是一个技术上的问题，我想更详细的解释一下流批一体架构到底怎么去改变在不同典型场景下的数据处理的方式和数据分析的架构。
我们先看第一个，在大数据场景下经常需要数据同步或者数据集成，也就是将数据库中的数据同步到大数据的数仓或者其他存储中。上图中的左边是传统的经典数据集成的模式之一，全量的同步和增量的同步实际上是两套技术，我们需要定期将全量同步的数据跟增量同步数据做 merge，不断的迭代来把数据库的数据同步到数据仓库中。
但基于 Flink 流批一体的话，整个数据集成的架构将截然不同。因为 Flink SQL 也支持数据库（像 MySQL 和 PG）的 CDC 语义，所以可以用 Flink SQL 一键同步数据库的数据到 Hive、ClickHouse、TiDB 等开源的数据库或开源的 KV 存储中。在 Flink 流批一体架构的基础上，Flink 的 connector 也是流批混合的，它可以先读取数据库全量数据同步到数仓中，然后自动切换到增量模式，通过 CDC 读 Binlog 进行增量和全量的同步，Flink 内部都可以自动的去协调好，这就是流批一体的价值。
基于 Flink 的流批一体数仓架构
第二个变化，数仓架构。目前主流数仓架构都是一套典型的离线数仓和一套新的实时数仓，但这两套技术栈是分开的。在离线数仓里，大家还是习惯用 Hive 或者 Spark，在实时数仓中用 Flink 加 Kafka。但是这个方案总结下来有三个问题需要解决：
- 两套开发流程，成本高。
- 数据链路冗余。数仓的经典架构大家都知道，ODS 层，DWD 层，DWS 层。在 DWD 的明细层可以看到实时数仓和离线数仓经常做的是一模一样的事情，如数据清洗、数据补齐、数据过滤等，两套链路将上面的事情做了两遍。
- 数据口径的一致性难以保证。实时报表需要实时观看，同时每天晚上会再做一次离线报表用于第二天分析。但是这两份报表的数据在时间的维度上可能是不一致的，因为它是由两套引擎算出来的，可能有两套用户代码，两套 UDF，两套 SQL，两套数仓的构建模型，在业务上造成了巨大的困惑，很难通过资源或人力来弥补。
如果用新的流批一体架构来解决，以上难题将极大降低。
- 首先，Flink 是一套 Flink SQL 开发，不存在两套开发成本。一个开发团队，一套技术栈，就可以做所有的离线和实时业务统计的问题。
- 第二，数据链路也不存在冗余，明细层的计算一次即可，不需要离线再算一遍。
- 第三，数据口径天然一致。无论是离线的流程，还是实时的流程，都是一套引擎，一套 SQL，一套 UDF，一套开发人员，所以它天然是一致的，不存在实时和离线数据口径不一致的问题。
基于 Flink 的流批一体数据湖架构
再往前走一步，我们通常会把数据落到 Hive 存储层，但是当数据规模逐渐的增大，也存在一些瓶颈。比如说数据文件规模增大以后，元数据的管理可能是瓶颈。还有一个很重要的问题，Hive 不支持数据的实时更新。Hive 没有办法实时，或者准实时化地提供数仓能力。现在比较新的数据湖架构，在一定程度上可以解决 Hive 作为数仓的问题。数据湖可以解决这种更具扩展性的元数据的问题，而且数据湖的存储支持数据的更新，是一个流批一体的存储。数据湖存储与 Flink 结合，就可以将实时离线一体化的数仓架构演变成实时离线一体化的数据湖架构。比如：
Flink + Iceberg：
- 通用化设计，解耦计算引擎，开放数据格式
- 提供基础 ACID 保证以及 Snapshot 功能
- 存储流批统一，支持批量和细粒度更新
- 低成本的元数据管理
- 0.10 已发布 Flink 实时写入和批量读取分析功能
- 0.11 规划自动小文件合并和 Upsert 支持。
另外，Flink 跟 Hudi 的整合，我们也在跟 Hudi 社区做比较密切的合作，未来的几个月我们将会推出 Flink 加 Hudi 的完整的解决方案。
Flink + Hudi：
- Upsert 功能支持较为成熟
- Table 组织方式灵活（根据场景选择 copy on write 还是 merge on read）
- Flink 与 Hudi 的集成正在积极对接中
3.大数据与AI一体化
最后一个主流技术方向就是 AI，现在 AI 是非常火的一个场景，同时 AI 对大数据存在着很强的算力需求。接下来跟大家分享 Flink 在 AI 场景下，社区做的一些事情，以及未来的规划。
PyFlink 逐步走向成熟
首先我们看一下语言层，因为 AI 的开发者很喜欢用 Python，所以 Flink 提供了 Python 语言的支持，在 2020 年社区做了很多的工作，我们的 PyFlink 项目也取得了很多的成果。
Python 版本的 Table 和 DataStream API：
- Python UDX 支持 logging、metrics 等功能，方便作业调试及监控
- 用户可以用纯 Python 语言开发 Flink 程序
SQL 中支持 Python UDX：
- 包括 Python UDF、Python UDTF 以及 Python UDAF
- SQL 开发人员也可以直接使用 Python 库
增加 Pandas 类库支持：
- 支持 Pandas UDF、Pandas UDAF 等功能
- 支持 Python Table 与 Pandas DataFrame 的互转
- 用户可以在 Flink 程序中使用 Pandas 类库。
Alink 新增数十个开源算法
在算法层面，阿里巴巴去年（2019）开源了 Alink，一套在 Flink 上的流批一体的传统机器学习算法。今年阿里巴巴的机器学习团队也在 Alink 上继续开源数 10 种新的算法，去解决更多场景下的算法组件的问题，进一步提升机器学习的开发体验。我们希望未来随着 Flink 新的 DataStream 的 API 也支持流批一体的迭代能力，我们会将 Alink 基于新的 DataStream 上面的迭代能力贡献到 Flink 的机器学习中，让标准的 Flink 机器学习能有一个比较大的突破。
大数据与 AI 一体化流程管理
大数据与 AI 一体化是最近很值得探讨的问题之一。大数据和 AI 技术是水乳交融的。通过大数据加 AI 的很多核心技术一体化，去解决整个在线的，比如实时推荐，或者其他的在线机器学习的一套完整流程。在这个过程中，大数据侧重的是数据处理、数据验证、数据分析，而 AI 的技术更侧重于模型的训练、模型的预测等等。
但这一整套的过程，其实要大家合力才能去真正解决业务的问题。阿里巴巴有很强的基因来做这件事情，Flink 最早诞生于搜索推荐场景，所以我们的在线搜索、在线推荐就是用 Flink 加 TensorFlow 的技术来实现的后台机器学习流程。我们也将阿里积累的这套流程做了一个抽象，把业务属性的东西全部去掉，只把开源的纯技术体系留下，它抽象成一套标准的模板，标准的解决方案，并开源出来，叫 Flink AI Extended。这个项目主要由两个部分来组成。
第一，Deep Learning on Flink: Flink 计算引擎和深度学习引擎集成
- Tensorflow / PyTorch on Flink
- 大数据计算任务和机器学习任务无缝对接。
第二， Flink AI Flow: 基于 Flink 的实时机器学习工作流
- 基于事件的流批混合工作流
- 大数据与机器学习全链路一体化。
我们希望通过开源主流的大数据加 AI 的技术体系，大家都可以快速的应用到业务场景中，做出来一套在线机器学习业务，比如实时推荐等。这个项目目前也是非常灵活，它可以运行 Standalone 单机版，也可以运行在 Hadoop YARN，或者 Kubernetes 上。
Flink Native on K8S
K8s 是现在标准化的一个行为，云原生。我们相信 K8s 的未来会更加的广阔，起码 Flink 一定要支持在 K8s 之下原生的运行，实现云原生的部署模式。经过今年三个版本的努力，我们已经支持原生的将 Flink 部署到 K8s 里面。Flink 的 job manager 可以跟 K8s 的 master 进行直接通信，动态的申请资源，根据运行的负载动态扩缩容。同时我们完全对接了 K8s 的 HA 方案，也支持 GPU 的调度和 CPU 的调度。所以现在 Flink Native on K8S 这个方案已经非常成熟，如果企业对 Flink 在 K8s 部署上有诉求，可以使用 Flink-1.12 这个版本。
Flink 在阿里巴巴的现状和未来
技术的创新和技术的价值一定要靠业务去检验，业务价值是最终的判定标准。阿里巴巴不仅是 Apache Flink 最大的推动者和支持者，同时也是最大的用户。下面介绍 Flink 在阿里应用的现状以及后续规划。
1.Flink 在阿里巴巴的发展历程
首先看一下 Flink 在阿里巴巴的成长路线，还是非常有节奏的。
- 2016 年，我们将 Flink 大规模运行在双 11 场景，最早的是在搜索推荐的落地，支持了搜索推荐的全链路实时化，以及在线学习的实时化。
- 2017 年，我们认定 Flink 作为一个全集团级别的实时数据处理引擎，支持整个阿里巴巴集团的业务。
- 2018 年，我们开始上云，第一次通过将 Flink 推到云上，去积累技术，服务更多中小企业。
- 2019 年，我们向国际化迈进了一步，收购了 Flink 的创始公司，阿里巴巴投入了更多的资源和人力去推动 Flink 社区的发展。
到今年，我们已经看到 Flink 成为了一个实时计算事实上的国际的标准。在全球，许多云厂商和大数据的软件厂商都已经将 Flink 内置到他们的产品里，成为标准云产品的形态之一。
2.双十一全链路数据实时化
今年双 11，基于 Flink 的实时计算平台在阿里内部已经完整的支持了所有场景的实时数据的业务。在数据规模上，已经有超过数百万的 CPU Core 在运行。今年在资源基本上没有增加的情况下，计算能力相对去年有一倍的增长。同时，通过技术优化，实现了整个阿里经济体的全链路数据实时化。
3.“全链路数据实时化” to ”实时离线一体化”
全链路数据实时化不是我们的终点，下一步是实现实时离线一体化的诉求。在电商大促的场景下，需要对实时数据与离线数据做对比，如果实时和离线的数据不一致，或者不知道是不是一致的，那就会对业务造成很大的干扰，业务没有办法判断到底是技术上的误差导致的结果不符合预期，还是业务效果真的不符合预期。所以今年双 11，阿里巴巴第一次大规模落地流批一体的场景以及实时离线一体化业务场景。
今年双 11 流批一体的落地场景是天猫的双11营销大屏分析。通过大屏数据分析，可以看到不同的维度的数据，对比双11当天用户的交易量和一个月前、甚至去年双 11，它的增长是否符合预期。我们能确保流批结果是一致的。
此外，我们结合了阿里巴巴自研的 Hologres 流批一体的存储能力，加上 Flink 流批一体的计算能力，实现了全链路的流批一体的数据架构，以及整个业务架构。在此架构下，我们不仅保持数据天然的一致性，业务上没有了干扰，同时我们使淘宝的小二开发数据报表的开发效率提升了 4~10 倍。
另一方面，Flink 的流任务和批任务运行在一个集群里，双11当天巨大的流量到了晚上可能会变成一个波谷，这时我们会运行大量离线的批的分析任务，为第二天的报表做准备。所以削峰填谷的应用使我们的资源节省了一倍，这是一个非常可观的数据。
目前，除了阿里巴巴外，社区上也有诸多合作密切的伙伴如字节跳动、小米、网易、知乎等在探索使用 Flink 做流批一体统一架构的方案。我相信 2020 年是 Flink 新一代数据架构落地的元年，从全链路数据实时化走向实时离线一体化的元年，并且阿里巴巴已经在最核心的双 11 业务场景下进行了落地。
明年，会有更多的企业尝试，并贡献社区完善新架构，推动社区朝着新方向：流批一体化、离线实时一体化、大数据与 AI 一体化演进。真正让技术创新服务好业务，改变大数据处理架构、大数据与 AI 融合的方式，在各行各业释放其价值。