作者|王峰
本文由 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 交融的形式，在各行各业开释其价值。