简介：本文将对FFA Keynote议题作一些简略的演绎总结，感兴趣的小伙伴们能够在FFA官网[2]找到相干主题视频观看直播回放。

作者 | 梅源（Yuan Mei）
起源 | 阿里技术公众号

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

2022年1月8-9号，Flink Forward Asia（FFA）线上峰会胜利举办。Flink Forward Asia 是由 Apache 官网受权，Apache Flink中文社区主持举办的会议。目前，Flink Forward Asia 已成为国内最大的 Apache 顶级我的项目会议之一，是 Flink 开发者和使用者的年度盛会。在线上峰会的同时，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+出名公司共83个主题演讲。从生态技术演进来看，Flink在云原生，高可用性，流批一体和AI四个主打方向上都获得了不错的问题。特地值得一提的是Flink新推出了流批一体的进阶版，流式数仓（Streaming Warehouse）这个概念，实现流批实时剖析一体化，真正意义上实现流批一体计算和流批一体存储的交融，让整个数仓的数据流动起来。流式数仓将是Flink将来最重要的方向之一，在Flink社区也会同步推广。

本文将对FFA Keynote议题作一些简略的演绎总结，感兴趣的小伙伴们能够在FFA官网[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是在不影响吞吐和提早的前提下缩减上下游须要缓存的数据到刚好算子不空转，目前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区别于其余相似零碎的外围竞争力之一。如果大家对动静表的实现感兴趣的话能够看一看流批一体分论坛中“基于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 运行时介绍”有对这部分更具体的解释。

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

主议题第二场由字节跳动计算基础架构负责人师锐老师带来。字节跳动的产品业务场景次要都是以实时信息流举荐为主，因而以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作业运行。师锐老师特地提到，从去年开始，流批一体也逐渐在字节跳动公司外部推广应用，感兴趣的小伙伴能够参考流批一体分论坛专场中的talk“流批一体在字节跳动特色平台的实际”。目前字节跳动寰球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）提供的流批实时剖析一体化的能力来实现实时入湖，实时数据服务和实时剖析！

另一个比拟乏味的点是金融行业的数据中台在设计的时候会特地思考数据私密和平安的问题。他们采纳的办法有以下几种：1）采纳全生命周期的数据监控审计，用于数据拜访的审计和追溯；2）在数据产生挪动的时候给数据自身加水印能够不便溯源；3）通过SQL实现自然人级别的动态数据拜访权限管制；4）通过专家规定和Machine Learning来自动识别海量数据中的敏感数据。这些思维和办法在数据安全，数据私密越来越受器重的明天很有借鉴意义。袁一老师还具体分享了很多和金融行业相干的业务场景，置信会对业务场景感兴趣的同学有所启发。

四 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-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...）

原文链接
本文为阿里云原创内容，未经容许不得转载。