关于flink:从-Flink-Forward-Asia-2021看-Flink-未来开启新篇章

作者：梅源（Yuan Mei）

FFA 2021 直播回放 & 演讲 PDF 下载

律回春晖渐，万象始更新，这句诗用来形容 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 社区，并携手其余开源我的项目造成更全面的联结解决方案，真正做到了开源凋谢，继续回馈，减速遍及。

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

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

Flink 部署的三种模式

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

Flink 最早的部署模式是经典的动态 (Static) Standalone 模式，这里的动态是指用户必须依据业务估算预留资源，资源少了作业就跑不起来，所以大部分状况下须要按最大资源量来预留。不言而喻这种模式对于用户来说既简单资源利用率也不高。
第二种模式咱们称为被动 (Active) 模式，这里的被动是指 Flink 会依据业务资源的应用状况被动的去向底层 Kubernetes 或者 Yarn 申请和开释资源。这种模式须要 Flink 和底层 Kubernetes 或者 Yarn 深度集成，实用于须要对资源深度把控的用户，对中小用户来讲太过简单。
这就引出了第三种模式咱们称为适应性 (Adaptive/Reactive) 模式。在这种模式下，Flink 能够像云上其余利用一样依据所给的资源 (减少或缩小资源 pod) 通过扭转本身拓扑构造来动静调整运行。

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

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

和 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)这个概念，这个概念提出的大背景是为了解决实时离线数仓一体化的问题。

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

实时流解决链路 (Flink + Kafka) 对数据进行分层 ODS，DWD，DWS，并实时写入在线服务层，提供在线服务 (实时 OLAP)；
同时会有一条离线链路定期对实时数据进行补充和历史修改。

这里除了常见的流批不对立带来的开发效率，保护老本，流批口径不对立等问题以外，其实还有一个更荫蔽同时也更难解决的问题：为了保障实时性，实时链路中的 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 区别于其余相似零碎的外围竞争力之一。如果大家对动静表的实现感兴趣的话能够看一看流批一体分论坛中“基于 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 中有几个新的亮点是值得看一看的：

Flink 基于 DataStream 引擎原生反对全新的迭代计算框架，反对更灵便的分布式同步和异步迭代；
公布了一套新版 Flink ML pipeline API，遵循机器学习用户更相熟 Scikit-Learn 格调 (Transformer，Estimator，Model)；
反对一体化的深度学习集成，Flink ML Estimator 能够将 Pytorch 和 Tensorflow 拉起；
流批一体能力使得 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 运行时介绍”有对这部分更具体的解释。

主议题第二场由字节跳动计算基础架构负责人师锐老师带来。字节跳动的产品业务场景次要都是以实时信息流举荐为主，因而以 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 在字节跳动外部如何演进应用感兴趣的同学能够去看看。

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

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

一是通过 Flink 实时 ETL 能够实现实时数据入湖；
二是将 Flink 的后果输入到 HBase 或者 ES 等联机数据库中提供面向利用的数据中台服务；
三是通过 Presto 或 CK 等剖析型引擎，提供面向分析师的 BI 剖析能力。

工行外部的高时效业务场景，基本上都能够蕴含在这条链路体系之中。

聪慧的小伙伴们可能曾经发现了，下面这条简单数据链路和 Flink 流式数仓 (Streaming Warehouse) 场景简直一摸一样。然而通过 Flink 的流式数仓，咱们能够把工行的这条两头贯通很多零碎和组件的链路简化成 Flink 单链路，通过 Flink 的动静表 (Dynamic Table) 提供的 流批实时剖析一体化的能力 来实现实时入湖，实时数据服务和实时剖析！

另一个比拟乏味的点是金融行业的数据中台在设计的时候会特地思考数据私密和平安的问题。他们采纳的办法有以下几种：

采纳全生命周期的数据监控审计，用于数据拜访的审计和追溯；
在数据产生挪动的时候给数据自身加水印能够不便溯源；
通过 SQL 实现自然人级别的动态数据拜访权限管制；
通过专家规定和 Machine Learning 来自动识别海量数据中的敏感数据。

这些思维和办法在数据安全，数据私密越来越受器重的明天很有借鉴意义。袁一老师还具体分享很多和金融行业相干的业务场景，置信对业务场景感兴趣的同学应该会有所启发。

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

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

雷同键值下能够保证数据有序；
能够依据数据流量动静扩缩存储单元；
反对事务性写入；
反对 Checkpointing 和一致性读写；
分层存储设计。

所有的这些个性都封装在 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-exte…）

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

[6] Apache Flink 不止于计算，数仓架构或衰亡新一轮改革（https://c.tb.cn/F3.0OfNLU）

[7]Flink-ML（https://github.com/apache/fli…）

[8]Clink（https://github.com/flink-exte…）

FFA 2021 直播回放 & 演讲 PDF 下载

更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～

关于flink:从-Flink-Forward-Asia-2021看-Flink-未来开启新篇章

主会场议题

Flink Next –– Beyond Stream Processing

云原生 –– 部署架构演进

Flink 容错 –– 稳固疾速的 Checkpoint

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

实时计算在字节跳动的倒退与瞻望

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

Deconstructing Stream Storage

圆桌会议

总结和感想