从 Flink Forward Asia 2021，看 Flink 未来开启新篇章

律回春晖渐，万象始更新，这句诗用来形容 2021 年的大数据领域再合适不过，而 Flink 在 2021 年也开启了新的篇章。

2022 年 1 月 8-9 号，Flink Forward Asia (FFA) 线上峰会成功举行。Flink Forward Asia 是由 Apache 官方授权，Apache Flink 中文社区主持举办的会议。目前，Flink Forward Asia 已成为国内最大的 Apache 顶级项目会议之一，是 Flink 开发者和使用者的年度盛会。由于疫情原因，本届峰会仍采用线上直播的形式，峰会首日流量峰值 PV 20W+、UV 10W+；实时观看量峰值 4.5W+。直播页累计 PV 100W+、UV 30W+。在线上峰会的同时，FFA 还举办了首届以实时计算为主题的 Flink Hackathon，共有 267 支参赛队伍，最终 27 支队伍入围参与线下决赛。未来 Flink Hackathon 也会常态化举办，集思广益。

FFA 大会从社区发展，业界影响力以及生态技术演进这三方面总结了 Flink 在过去一年的发展。社区方面，根据 Apache 软件基金会 2021 财年报告公布的各项核心指标，Flink 已连续三年位列 Apache 社区最活跃的项目之一。而作为社区的最小原子，Flink 的社区代码开发者 (Contributor) 已超过 1400 名，年增长率超过 20%。其中尤其值得一提的是 Flink 中文社区的蓬勃发展：Flink 的官方公众号订阅数超过 5 万人，全年推送超过 140 篇和 Flink 技术，生态以及行业实践相关的最新资讯。最近，Flink 社区开通了 Flink 官方视频号，希望通过更加丰富新颖的形式从更多纬度让大家对 Flink 有更全面的了解。此外，Flink 社区重构和改版了去年开通的 Flink 官方学习网站 Flink Learning[1]，希望通过这个学习网站，汇总沉淀和 Flink 相关的学习资料，场景案例以及活动信息，使 Flink Learning 真正成为大家学习研究探索 Flink 的好帮手。

业界方面影响力方面，Flink 已成为业界实时计算的事实标准。越来越多的公司不仅使用 Flink，也积极参与 Flink 的发展与建设，共同完善 Flink。目前，Flink 的代码开发者来自全球超过 100+ 公司。去年举办的 4 场的线下 meet up，阿里巴巴、字节跳动，携程和 360 都提供了大力支持。而今年 FFA 大会有来自互联网，金融，能源，制造业，电信等各个行业的 40+ 知名公司共 87 个主题演讲。从生态技术演进来看，Flink 在云原生，高可用性，流批一体和 AI 四个主打方向上都取得了不错的成绩。特别值得一提的是 Flink 新推出了流批一体的进阶版，流式数仓 (Streaming Warehouse) 这个概念，实现流批实时分析一体化，真正意义上完成流批一体计算和流批一体存储的融合，让整个数仓的数据流动起来。流式数仓将是 Flink 未来最重要的方向之一，在 Flink 社区也会同步推广。

本文将对 Keynote 议题作一些简单的归纳总结，感兴趣的小伙伴们可以在官网[2] 找到相关主题视频观看直播回放。

主会场议题

在主议题之前，阿里巴巴集团副总裁，阿里巴巴开源技术委员会负责人，阿里云智能计算平台负责人贾扬清老师作为开场嘉宾，分享了他对开源在云计算的大背景下的思考：开源，无论是从技术贡献还是生态发展来看，已从最初的替代和补充逐步发展成为创新和引领的角色。阿里巴巴到目前为止已经开源了 2700 多个项目，是国内互联网技术企业中的先锋。而 Flink 作为阿里巴巴最具影响力的开源项目之一，无论是在技术先进性还是生态丰富性上都无可争议。不仅如此，阿里巴巴在过去几年中积极拓展 Flink 的适用场景，通过自身大规模业务打磨迭代开源技术，进而将这些技术回馈 Flink 社区，并携手其他开源项目形成更全面的联合解决方案，真正做到了开源开放，持续回馈，加速普及。

下面来重点聊一聊几个主议题。

1. Flink Next –– Beyond Stream Processing

主议题照例由 Apache Flink 中文社区发起人，阿里巴巴开源大数据平台负责人王峰（花名莫问）老师开启，主要介绍 Flink 社区在 2021 年取得的成果以及未来的发展方向，包括云原生，Flink 容错，流批一体和机器学习四个部分。

■ 云原生 –– 部署架构演进

Flink 部署的三种模式

说起开源大数据的发展，绕不开云原生，两者相依相生相辅相成。作为开源大数据的引擎课代表 Flink 的部署模式是如何在云原生大背景下演进的是个很有趣的话题。

• Flink 最早的部署模式是经典的静态 (Static) Standalone模式，这里的静态是指用户必须根据业务估算预留资源，资源少了作业就跑不起来，所以大部分情况下需要按最大资源量来预留。显而易见这种模式对于用户来说既复杂资源利用率也不高。

• 第二种模式我们称为主动 (Active) 模式，这里的主动是指 Flink 会根据业务资源的使用情况主动的去向底层 Kubernetes 或者 Yarn 申请和释放资源。这种模式需要 Flink 和底层 Kubernetes 或者 Yarn 深度集成，适用于需要对资源深度把控的用户，对中小用户来讲太过复杂。

• 这就引出了第三种模式我们称为适应性 (Adaptive/Reactive) 模式。在这种模式下，Flink 可以像云上其他应用一样根据所给的资源 (增加或减少资源 pod) 通过改变自身拓扑结构来动态调整运行。

从用户的角度来看，他并不需要了解资源是如何分配的，所以第三种模式对于用户的门槛相对较低。

还有一个值得思考的问题是云原生到底给 Flink 带来了什么，除了弹性资源管理，自带的数据多备份，自适应运维管理，标准化的工具和操作，笔者觉得更重要的是降低用户的使用门槛，用更小的成本给用户提供更简单，稳定和丰富的使用体验。

■ Flink 容错 –– 稳定快速的 Checkpoint 

和 Checkpointing 相关的讨论几乎贯穿了 Flink 的整个发展历程，它是整个 Flink 容错架构的核心。Flink 会定期给所有的算子状态做快照检查点 (Checkpoint），如果 Flink 作业失败，作业会从上一个完整的 Checkpoint 恢复。在实际工作中，我们发现引擎这一层很大部分的 Oncall 的问题都跟做 Checkpoint 相关，所以如何能够高频稳定的完成 Checkpoint 是提升 Flink 高可用性 (容错) 的重点。造成做 Checkpoint 失败 (超时) 的主要原因来自两方面：

• 一是中间数据流动缓慢造成 Checkpoint Barrier 流动缓慢；

• 二是算子状态过大造成状态数据上传超时。

Flink 针对这两个方面都有重点项目在跟进：Buffer Debloating 和 Generalized Log-Based Checkpoint。

Buffer Debloating 是在不影响吞吐和延迟的前提下缩减上下游需要缓存的数据到刚好算子不空转，目前上游会动态缓存下游 1 秒钟能处理的数据 (这个时间是可以配置的)。Buffer Debloating 在 Flink-1.14 版本已经发布。Generalized Log-Based Checkpoint 是一种基于 log 打点的方式来做 Checkpoint 的方法，类似传统 DB 的 write ahead log，好处是能快速，高频且稳定的做 Checkpoint，代价是需要额外多写/存一份 log。我们知道 Flink 做 Checkpoint 由同步和异步两个过程组成，同步的过程通常很快，主要的耗时在异步上传状态文件这个过程中。Generalized Log-Based Checkpoint 的原理就是将 Checkpointing 这个过程和耗时的异步上传文件这个过程剥离开，也同时和底层状态存储的物化过程解耦。Generalized Log-Based Checkpoint 预计会在 Flink-1.15 版本发布。

分论坛核心技术专场 talk “Flink 新一代流计算和容错 (Flink Fault Tolerance 2.0)” 对这个部分有更为详细的阐述，感兴趣的同学可以找来看看。

■ 流批一体 –– 架构演进和落地

流批一体是近些年 Flink 一直在力推的创新性理念，从最早提出这个理念到当前被广泛接受，莫问老师分享了流批一体在 Flink 的系统架构各个层面演进的过程及其落地场景，如下图所示。

1）架构演进

API 层面，去年流批统一的 SQL/Table API (Declarative API) 首次在阿里巴巴双十一最核心的天猫营销活动分析大屏场景中落地[3]，今年更近一步，完成了 Imperative API 的整合，形成流批统一的 DataStream API，而陈旧的 DataSet API 将逐步被淘汰。架构层面，同一个作业可以同时处理有限数据集和无限数据集；并且 connector 框架可以同时对接流式存储和批式存储，做到一套代码可以处理两套数据源。运行层面，一套调度框架可以同时适用于流和批的作业；流批 shuffle 是 pluggable 的，复用一套 shuffle 接口。阿里巴巴实时计算团队在今年开源了存算分离的 Remote Shuffle Service[4]，放在 Flink 开源项目的 Flink-extended 这个子项目组里面。Flink-extended[5] 里面包含很多其他 Flink 生态项目，有兴趣的同学可以去看一看。

继去年在天猫双十一核心大屏业务上线后，流批一体今年逐步在阿里巴巴更多核心业务上推广。除了阿里巴巴，有越来越多的公司认可流批一体这个理念。今年FFA有个专门的流批一体分论坛，由字节跳动，美团，京东以及小米等公司分享流批一体在其业务中的实践。此外在核心技术专场中有专门针对流批一体架构演进的专场 talk “面向流批一体的 Flink Runtime 新进展”，对这个话题感兴趣的同学可以了解一下。对新版 connector 框架原理感兴趣的同学可以参考核心技术专场中的 “Flink Connector 社区新动向与 Hybrid Source 原理实践”。

2）场景落地

莫问老师指出，流批一体这一技术理念落地需要具体的场景支撑来体现其真正价值，基于此，他分享了流批一体最为典型的两个应用场景。

场景1  Flink CDC：全增量一体化数据集成

在传统的数据集成中，离线和实时数据集成是两套不同的技术栈，需要全量和增量定时合并，时效性也比较差。Flink的流批一体能力结合 Flink CDC 的能力可以实现一体化数据集成：先全量的同步完历史数据后自动接到断点，实时的续传增量数据，实现一站式数据同步（读取数据库全量数据后自动切换，通过 binlog 增量同步）。这里的自动切换的实现基于新版流批一体 Source 框架。

Flink CDC 目前已可以支持大部分主流数据库包括 MySQL、Postgres、Oracle、MongoDB、MariaDB，其他的如 TiDB，DB2，SQL Server 也在积极开发中。对 Flink CDC 如何能够实现一站式数据集成感兴趣的同学可以参考分论坛实时数据湖专场中的talk “Flink CDC 如何简化实时数据入湖入仓”。

场景2  Streaming Warehouse：流式数仓

前面提到，今年的一大亮点是莫问老师提出的流式数仓 (Streaming Warehouse) 这个概念，这个概念提出的大背景是为了解决实时离线数仓一体化的问题。

实时离线数仓一体化这个问题目前比较常用的解决方案是用实时和离线两条链路来实现：

1. 实时流处理链路 (Flink + Kafka) 对数据进行分层ODS，DWD，DWS，并实时写入在线服务层，提供在线服务 (实时 OLAP)；

2. 同时会有一条离线链路定期对实时数据进行补充和历史修正。

这里除了常见的流批不统一带来的开发效率，维护成本，流批口径不统一等问题以外，其实还有一个更隐蔽同时也更难解决的问题：为了保证实时性，实时链路中的 ODS，DWD，DWS 这些分层数据是存在消息队列 (比如 Kafka) 中的，但是消息队列中的数据是没办法有效进行实时分析的，如果引入其他的 OLAP 系统会增加系统复杂度同时也不能保证数据一致性。

为了解决消息队列无法有效率的进行实时分析的问题，Flink 引入了 Dynamic Table 动态表来存放实时链路产生的分层数据，如上图所示。这样一来，Flink 可以通过 Flink SQL 的流批一体能力实时的串联起整个分层数仓；通过 Flink SQL 对 Dynamic Table 的 OLAP 查询提供实时分析的能力。我们可以把这个理解成流批一体的进阶版本流批实时分析一体化，也就是莫问老师这里提出的流式数仓 (StreamHouse = Streaming + Warehouse) 这个概念，真正做到在一套方法论的大框架下实现一套API，一套计算，一套中间存储的全链路一体化。

Dynamic Table (动态表) 不同于一般意义上的 Source和Sink，是 Flink 的内置表。之所以称为动态表是因为此表具有流表二象性。流表二象性通过列存 LSM Tree 和 Log 两种不同的存储形式来支持，分别对应于 Flink SQL 的批 (全量分析) 和流 (增量处理) 两种模式。Dynamic Table 通过 Flink 自身的 Checkpointing 一致性语义机制保证流表二象性在两种存储形式下的一致性语义。这里需要注意的是，流表二象存储的数据一致性问题是混拼系统 (引入其他 OLAP 和消息队列) 无法轻易规避和解决的问题 (因为中间涉及多系统间的一致性读写同步)。如果大家对动态表的实现感兴趣的话可以看一看流批一体分论坛中 “基于 Flink Dynamic Table 构建流批一体数仓” 这个 talk，里面有对 Dynamic Table 更详细的介绍。

这个部分的最后有一个流式数仓的 demo，用上述一体化的方法论展示了流作业在实时 OLAP 分析发现业务逻辑有错后，如何批式做订正并实时支持 OLAP 查询更正的一个流批实时分析一体化的典型场景，还是很受启发的，大家可以看一看。想对流式数仓有更详细了解的同学可以参考莫问老师关于流式数仓的专访[6]。

■ 机器学习 –– Apache Flink ML 2.0 全新架构

机器学习作为 Apache Flink 的另一大重要场景，在今年 Flink 流批一体 API 和架构进一步完善的基础上，基于流批一体 DataStream API 完成重构，全面升级到 Flink ML 2.0。Flink ML 最大的特点是实时离线一体化，以及与之相配套的实时离线一体化管理调度 (Flink AI Flow) 和执行。在 Flink ML 2.0 中有几个新的亮点是值得看一看的：

1. Flink 基于 DataStream 引擎原生支持全新的迭代计算框架，支持更灵活的分布式同步和异步迭代；

2. 发布了一套新版 Flink ML pipeline API，遵循机器学习用户更熟悉 Scikit-Learn 风格 (Transformer，Estimator，Model)；

3. 支持一体化的深度学习集成，Flink ML Estimator 可以将 Pytorch 和 Tensorflow 拉起；

4. 流批一体能力使得 Flink ML 2.0 可以同时对接流和批的数据集。

Flink ML 2.0 目前已经由阿里巴巴实时计算团队和机器学习团队共同完成，贡献给 Flink 社区，成为 Flink 的一个子项目 Flink-ML[7]。值得一提的是除了阿里巴巴，现在还有很多其他公司也在共同建设 Flink ML 的生态，比如 360 贡献了 Clink[8]。核心技术专场中 “为实时机器学习设计的算法接口与迭代引擎” 这个 talk 详细介绍了 Flink ML 2.0 的架构演进，此外今年 FFA 还有一个机器学习专场，感兴趣的同学可以看一看。

PyFlink 方面，Flink 对 AI 的主流开发语言 Python 的支持更加完备：PyFlink 在功能上完全追平了 Table API 和 Data Stream API 的能力，在性能上创新性的通过 JNI 调用 C，再在 C 里面调用 Python 解析器的方法消除了 Python UDF 和 Java 跨进程通信，使得 Python UDF 性能接近 Java UDF，兼顾开发和运行的效率。分论坛核心技术专场 “基于 FFI 的 PyFlink 下一代 Python 运行时介绍” 有对这部分更详细的解释。

2. 实时计算在字节跳动的发展与展望

主议题第二场由字节跳动计算基础架构负责人师锐老师带来。字节跳动的产品业务场景主要都是以实时信息流推荐为主，因此以 Flink 为支撑的实时计算广泛应用在字节跳动的各个产品中。字节跳动旗下全线产品总 MAU 目前已超过 19 亿，由于其业务特性，其数据量 (EB 级别，1EB = 2^60 Bytes) 和实时推荐的请求量 (百万 QPS) 都是巨大的。我们可以看到在师锐老师分享的字节跳动引擎资源使用的对比图中，Flink 和 Spark 基本持平，这在一般的公司是不太常见的，从这个方面也可以看出字节跳动整个业务线对以 Flink 为基础的流计算的依赖。

字节跳动主要计算引擎资源对比图

字节跳动从 2017 年开始调研并逐步使用 Flink 流式计算，到 2019 年初，所有流式作业已完成从 JStorm 迁移到 Flink。2019 年开始，随着 Flink SQL 和 Flink 批式计算的成熟，Flink Batch 也在字节跳动数据同步等场景相继落地，现在每天大概有 10w+ Flink Batch 作业运行。师锐老师特别提到，从去年开始，流批一体也逐步在字节跳动公司内部推广应用。目前字节跳动全球 Flink 流式作业达到 4w 个，其中 SQL 作业占 30%，使用的 CPU 核数超过 400 万核，晚高峰 Flink 作业处理消息的 QPS 达到 90 亿，Checkpoint 高峰流量吞吐达到 600GB/s，还是很惊人的！

Flink 在字节跳动发展图

在字节跳动的分享中，基于存算分离架构的流批一体消息队列 BMQ 值得提一提 (BMQ 目前承接了字节 90% 的消息队列流量)。在 BMQ 之前，字节使用 Kafka 作为消息队列，集群升级扩缩容需要大量拷贝数据，所以完成一个集群的升级差不多需要一周的时间。为了解决这个问题，字节团队基于存算分离的架构重新设计实现了消息队列，BMQ。在 BMQ 的架构之下，数据存放在分布式文件系统 HDFS 中，Meta 存放在 K-V 存储中。由于 BMQ 的计算层 Proxy 无状态所以非常容易做扩缩容，迁移时间可在分钟级完成。另一方面，BMQ 可以同时提供 Stream API 和 Batch API，所以可以同时支持流和批的消费，实现存储层的流批一体。有些小伙伴可能有疑问，这和上面提到的动态表 (Dynamic Table) 一样吗？笔者觉得还是很不一样的，因为要解决的问题不一样：动态表要解决流批实时分析一体化的问题，所以它的流批存储格式是完全不一样的 (为了分别加速流处理和批查询)；而 BMQ 所有数据只写一份在 HDFS 上，主要还是为支持高效的大规模消息传输和读写服务的。

师锐老师提到他们下一步计划是推进 Flink OLAP 的落地。他指出，Flink 拥有丰富的 connector 生态可以实现跨数据源查询，Flink OLAP 能力在字节内部测试过可以媲美 Presto，甚至在有些情况下更优，现在有关 Flink OLAP 的改进和优化也在积极推进 Flink 社区中。本次 FFA 字节跳动有 7 个分会场 talk，从核心技术提升到行业实践涵盖了方方面面，对 Flink 在字节跳动内部如何演进使用感兴趣的同学可以去看看。

3. 工商银行实时大数据平台建设历程及展望

主议题第三场由中国工商银行大数据平台负责人袁一老师带来，他从金融行业的视角分享了有关工行实时大数据平台建设的历程和思路。

首先我们来看一张描述工行数据流向的示意图，如上图所示。应用产生的数据会写入到 MySQL 或 Oracle 等关系型数据库，之后将数据库产生的日志复制到 Kafka 消息队列中作为实时处理平台的数据源。实时处理平台有三个数据出口：

• 一是通过 Flink 实时 ETL 可以实现实时数据入湖；

• 二是将 Flink 的结果输出到 HBase 或者 ES 等联机数据库中提供面向应用的数据中台服务；

• 三是通过 Presto 或 CK 等分析型引擎，提供面向分析师的 BI 分析能力。

工行内部的高时效业务场景，基本上都可以包含在这条链路体系之中。

聪明的小伙伴们可能已经发现了，上面这条复杂数据链路和 Flink 流式数仓 (Streaming Warehouse) 场景几乎一摸一样。但是通过 Flink 的流式数仓，我们可以把工行的这条中间贯穿很多系统和组件的链路简化成 Flink 单链路，通过 Flink 的动态表 (Dynamic Table) 提供的流批实时分析一体化的能力来完成实时入湖，实时数据服务和实时分析！

另一个比较有趣的点是金融行业的数据中台在设计的时候会特别考虑数据私密和安全的问题。他们采用的方法有以下几种：

1. 采用全生命周期的数据监控审计，用于数据访问的审计和追溯；

2. 在数据发生移动的时候给数据本身加水印可以方便溯源；

3. 通过 SQL 实现自然人级别的动态数据访问权限控制；

4. 通过专家规则和 Machine Learning 来自动识别海量数据中的敏感数据。

这些思想和方法在数据安全，数据私密越来越受重视的今天很有借鉴意义。袁一老师还详细分享很多和金融行业相关的业务场景，相信对业务场景感兴趣的同学应该会有所启发。

4. Deconstructing Stream Storage

主议题的最后一场由 Pravega 中国社区创始人，戴尔科技集团 OSA 软件开发总监滕昱老师压轴：解构流存储。

Pravega 是提供流批统一能力的开源分布式流存储，有如下特点：

1. 相同键值下可以保证数据有序；

2. 可以根据数据流量动态扩缩存储单元；

3. 支持事务性写入；

4. 支持 Checkpointing 和一致性读写；

5. 分层存储设计。

所有的这些特性都封装在 Stream 抽象的设计理念之下，也给流式计算屏蔽了很多流存储端的复杂性。在这次分享中，滕昱老师着重介绍了 Pravega 的分层存储架构 (Tiered Storage)：其底层是一个基于分布式文件/对象存储的持久性主存储，中间是基于内存的全局 Cache 层，最上层是分布式 Log 抽象层。滕昱老师还同时分享了 Pravega 的分层存储架构与 Kafka 和 Pulsar 这两个消息系统在架构上的区别以及对性能的影响，感兴趣的同学可以去详细了解一下。

在 Pravega 的分享中有几个比较有趣的点：

• 一是 Pravega 针对现在比较火热的物联网边缘计算的定制优化，比如 Pravega 针对多客户端的两阶段数据聚合，在 Writer 进行第一阶段聚合，在 Segment Store 进行第二阶段聚合，极大的提高了吞吐量。这种数据聚合优化非常适用于有大量客户端但每个客户端产生的数据量比较小的情况，而这就是物联网的典型特点。

• 二是 Pravega 和 Flink 联动的端到端的 auto-scaling。弹性扩缩容是云原生大背景下非常重要的问题，前面提到 Pravega 的一大特点就是可以自动扩缩容，调整 Segment 数目，而这个数目可以很好的作为 Flink Reactive Scaling 的指标，两者相结合后可以做到从计算到存储端到端的 auto-scaling，目前这项工作已在两边社区合作规划中。滕昱老师的分享中还有一个 Demo 展示了 Pravega 和 Flink 联动 scaling 的效果。

滕昱老师表示未来存储和计算，流和表的界限逐渐模糊，Pravega 流批一体的存储设计也暗合了 Flink 未来很重要的一个发展方向。Pravega 社区会积极与包括 Flink 在内的数据湖仓相关的开源社区通力合作，构建解决方案。今年 Pravega 和 Flink 社区共同发布了白皮书，未来也期望和 Flink 社区有更多合作，将 Flink 计算推向数据的产生端，通过 Pravega 能实现数据从端到云的流动。

圆桌会议

今年 FFA 主会场新增加了一个环节圆桌会议 (分北京和上海两场)，邀请了业界来自阿里巴巴，字节跳动，美团，快手，小米，工商银行，戴尔科技集团和小红书在内的多位大数据专家负责人，共同探讨 Flink 以及实时计算的未来。各位大佬友好真诚并且很接地气讨论了很多大家都比较关心的问题，由于篇幅关系，这里仅列出了讨论的部分相关话题，大家可以找视频感受一下：

• 如何看待 Flink 在实时计算方面已趋于成熟这个话题，目前大家都用实时计算做什么？

• 实时计算的未来是怎样的 (技术和业务层面)？基于此，Flink 需要探索哪些新的领域，解决哪些关键问题？

• 有人认为实时计算的门槛和代价比较高，相对偏小众；也有很多人认为实时计算是未来的方向，大数据和 AI 都会向实时化方向演进；大家怎么看这个问题？

• Flink 在整个开源大数据生态中应该如何定位，如何保持差异化？

• 如何看待公司内部技术实践，技术创新与开源社区之间的关系，大家使用和回馈社区的策略又是什么？

• 使用和贡献开源项目有哪些优势？在公司内部在做 Flink 哪方面的探索？过程中又遇到过哪些挑战？

• Flink 在内部使用的未来规划，以及接下来有哪些打算贡献社区的创新技术？

• 如何看待 Flink 与生态项目之间的 (合作、竞争) 关系？

• 什么样的开源社区是对大家有帮助的开源社区？同时又是一个可持续发展的社区？

总结和感想

过去的 2021 年是大数据领域的风口年，对于 Apache Flink，实时计算的领跑者，能否抓住这个风口也是很关键的一年。在 Flink SQL 趋于成熟，流批一体在业内逐步接受落地的当口，我们需要思考未来 Flink 何去何从，这也是我们正在做的事情。在此基础上，Flink推出了流批一体的进阶版，流式数仓 (Streaming Warehouse) 这个概念，希望能实现流批实时分析一体化，真正意义上完成流批一体计算和流批一体存储的融合，做到在一套方法论的大框架下实现一套 API，一套计算，一套中间存储的全链路一体化。流式数仓将是 Flink 未来最重要的方向，道阻且长，行则将至，行而不辍，未来可期！

注释

[1] Flink 官方学习网站 Flink Learning（https://flink-learning.org.cn/）

[2] https://flink-forward.org.cn/

[3] 40亿条/秒！Flink流批一体在阿里双11首次落地的背后

[4] Remote Shuffle Service（https://github.com/flink-extended/flink-remote-shuffle）

[5] Flink-extended（https://github.com/flink-extended/）

[6] Apache Flink 不止于计算，数仓架构或兴起新一轮变革

[7] Flink-ML（https://github.com/apache/flink-ml）

[8] Clink（https://github.com/flink-extended/clink）

---

更多 Flink 相关技术问题，可扫码加入社区钉钉交流群～