Flink Forward Asia 2024 - 总结和展望（附PPT下载链接）

最新推荐文章于 2024-09-06 11:21:04 发布

2401_85112269

最新推荐文章于 2024-09-06 11:21:04 发布

阅读量690

点赞数 23

分类专栏：作者\/ 文章标签： flink 大数据

本文链接：https://blog.csdn.net/2401_85112269/article/details/139292712

版权

作者\/ 专栏收录该内容

27 篇文章 0 订阅

订阅专栏

笔者总体的参会感受：引擎一体化和生态多元化是 Flink 一以贯之的发展策略。引擎一体化指的是**离线（batch），实时（streaming）和在线（application）**应用在执行层面的一体化。生态多元化指的是对 AI 生态环境的搭建和对更多生态的支持，包括 Hive，Python，Kubernetes 等。

接下来，笔者将根据自己参加的议题聊一聊参会的体验和一些自己的思考，希望能对感兴趣的同学有所助益。

主会场议题

在主议题之前有两个环节值得提一提。一是作为主场的阿里云智能请出阿里集团 CTO 兼阿里云智能总裁张建锋作为开场嘉宾进一步强化阿里集团以数据智能为驱动，All in Cloud 的决心以及开源的 Flink 在此过程中起到的关键性作用。下图很好地提炼了他的演讲。

二是由阿里云天池平台和 Intel 联合举办的 Apache Flink 极客挑战赛颁奖仪式。本次比赛吸引了全球超过 4000 名参赛者，经过四个月的四轮角逐最终产生共 10 个优胜队伍。值得一提的是获奖选手中有两位女将，未来也期待能有更多的妹子参与进来，放一张照片瞻仰一下。

下面言归正传，聊一聊几个主议题。

Stateful Function

照例，第一个主议题由 Flink 一哥 Stephan Ewen 执棒。作为对 Flink Forward 柏林站的延续，Stephan 继续推广他对 Flink 作为应用服务场景（Applications and Services）通用引擎的展望和规划。简而言之，他认为 Flink 除了能够做到批流一体，Flink 框架对于事件驱动的在线应用也可以有效甚至更好的支持，如下图所示：

我的理解是他所指的应用服务场景（Applications and Services）和传统意义上的 OLTP 类似。云上对此类问题的主流解决方案是现在很火的 FaaS (Function as a Service)，但通常会有以下四方面痛点：

Bottlenecked by state access & I/O
State Consistency Problem
Scalability of Database (storing the states)
Connections and Request rates

特别是在应用逻辑非常复杂的情况下，应用逻辑之间的组合调用会更加复杂，并且加剧上面四个痛点的复杂度。

同时你会发现上面的这些问题都和 State 的存储（storage），读写（access）以及一致性（consistency）相关，而 Flink 的 Stream Processing 框架可以很好的解决这些和状态相关的问题。所以 Stateful Function 在 Flink 现有的框架上拓展了对 Function Composition 和 Virtual Instance（轻量级的 Function 资源管理）的支持，以达到对应用服务场景（Application）的通用支持。

目前所有 Stateful Function 代码均已开源，在获得社区认可后也会 merge 回 Apache Flink，有兴趣的同学可以去官网自己实践一下：https://statefun.io/ 。在分议题 Apache Flink 核心技术中也有一场专门讲 Stateful Function 的实现，使用和 demo，小伙伴们也可以去感受一下，题目叫“Stateful Functions: Unlocking the next wave of applications with Stream Processing”。

看到这里可能还是会觉得不太直观，我结合自己的理解再多说两句，我们可以从两个维度理解 Stateful Function：

Stateful Function 到底要解决什么问题
为什么 Stateful Function 比现有的解决方案更好

设想如下的场景，我们使用 Lyft 打共享车。在乘客发起打车请求以后，Lyft 首先会根据乘客的定位，空闲司机的状态，目的地，交通状况和个人喜好给乘客推荐不同类型车辆的定价。在乘客选择定价以后，Lyft 会根据乘客的喜好（比如有些司机被乘客拉了黑名单），司机的喜好（乘客也有可能被司机拉了黑名单），司机和乘客的相对位置以及交通状况进行匹配，匹配完成后订单开始。在这个例子中，我们会发现：

**有很多 Function Composition：**乘客的喜好的计算，司机的喜好计算，司机和乘客相对位置计算，交通状况计算，以及最终匹配计算。
**状态的一致性的重要：**在匹配的过程中如果发生错误，在保持状态一致性的情况下回滚非常重要。我们不希望一个乘客匹配给两个司机，也不希望一个司机匹配给两个乘客，更不希望乘客或者司机因为一致性问题无法得到匹配。

Stateful Function 在 Flink 开源 Runtime 的基础上很好的解决了 Function Composition 和 State Consistency 的问题。

下面讨论一下第二个维度：为什么 Stateful Function 比现有的解决方案更好。我的理解是 Stateful Function 提供了更清晰的 abstraction。Stateful Function 把消息传输、状态管理从 Function 中隔离出来，使得用户只需要关注 Function 计算逻辑本身，而不需要关注 Function 的调度，组合等问题，这也使得 Stateful Function 框架能有更多的自由度为 Function 调度组合等问题做优化。当然这只是我个人的理解，抛砖引玉。

Flink Heading Towards a Unified Engine

第二场由阿里巴巴实时计算负责人王峰（阿里花名：莫问）接棒，主要总结了 2019 年 Apache Flink 在一体化引擎发展方面的成果和未来的方向。他认为未来 Flink 的发展趋势是一体化：包括离线（batch），实时（streaming）和在线（application）一体化。在此基础上，也需要把拥抱 AI 和云原生纳入到一体化中。后面的内容就是围绕这三方面来展开的。

对于批流融合，通过 1.9 和 1.10 两个版本的发布，Flink 在 SQL 和 Table API 的层面以及 Flink runtime 层面对批流模式已经做到统一。对于 Flink SQL，在 1.9 这个版本里面，已经可以实现完整的 DDL 功能，兼容 Hive 生态系统并且支持 Python UDF。

总体得到的讯息是：

Flink SQL 在批模式下经过多方验证已经达到生产可用的状态。
Flink SQL 可以在 Hive 生态上直接运行，没有迁移成本。
Flink SQL 可以做到批流在 SQL 优化，算子层以及分布式运行层的一体化。

另外这部分印象比较深刻的一点是：跑 TPC-DS benchmark，Flink 1.10 比 Hive-3.0 快 7 倍：

在 AI 部分，2019 Flink 重点主要在优化和铺垫 AI 的基础设施部分：

Flink 1.9 发布一套标准化的 Machine Learning Pipeline API (这个 pipeline 的概念最早在 Scikit-learn 中提出，在其他生态中也有广泛的采纳)。AI 的开发人员可以使用这套 API（Transformer，Estimator，Model）来实现机器学习算法。
更好的支持 Python 生态。Flink 1.10 在 Table API 中可以支持 Python UDF，复用了 Beam 的 Python 框架来进行 Java 和 Python 进程之间的通讯。
Alink 开源发布。Alink 是基于 Flink 的机器学习算法库，最大的亮点是对流式和在线学习的支持。以下为开源地址，感兴趣的同学可以研究一下。

https://github.com/alibaba/alink

在 AI 部分还有一个很值得期待的项目是 **Flink AI 明年的一个重点投入方向：AI Flow。**AI Flow 为 AI 链路定制了一套完整的解决方案：包括从 data acquisition，preprocessing，到 model training & validation & serving 以及 inference 的一整套链路。这个方案是针对解决现在 AI 链路里面数据预处理复杂，离线训练和在线预测脱钩等问题定制的，让我们拭目以待。

此外还有一个重要的方向是 Flink 对云原生生态的支持，具体来说就是与 Kubernetes 生态的深度融合。Kubernetes 环境可以在 multi-user 的场景下提供更好的隔离，对Flink在生产的稳定性方面会有所提升。Kubernetes 广泛应用在各种在线业务上，Flink 与 Kubernetes 的深度融合可以在更大范围内统一管理运维资源。Kubernetes 生态本身发展很快，可以给 Flink 在生产中提供更好的运维能力。后面 Lyft 和其他企业在分享中也提到希望 Flink 对 Kubernetes 可以原生地支持，也有以上这些方面的考虑。Flink 在 1.10 版本发布后可以原生地运行在 Kubernetes 之上。

阿里巴巴通过 1.9 和 1.10 两个版本历经 1 年左右将 Blink 中比较通用的部分悉数回馈给 Apache Flink 社区，回馈总代码数超过一百万行。阿里内部的 Blink 内核也逐步会由 Flink 内核替换，并且推出基于 Flink 内核的企业版 Ververica Platform，明年 1 月会正式商用。

另外这部分演讲中的两个 demo 让我眼前一亮。一个是基于 Flink + Hive + Zeppelin 的 Flink SQL demo，看完以后可以深刻感受到“可以在 Hive 生态上直接运行，没有迁移成本“，以及“一套 SQL，批流一体运行”的真正含义。还有一个是 Alink ML 基于 Jupyter 的 demo，看完以后我发现现在机器学习模型训练和使用可以如此简单，感兴趣的同学可以找来看看。

Storage Reimagined for a Streaming World

第三个议题是由戴尔科技集团带来的流式存储议题: Pravega。

他们的主要观点是随着流式计算在大企业用户中越来越广泛的应用，流式计算对存储也产生了新的需求：流式存储。需求来自两个方面：一是大型企业用户希望计算框架流程化繁为简，从而提出对流式计算存储一体化的需求；二是批流的计算一体化本身也对存储提出批流一体化需求。

在后面的分会场议题开源大数据生态中，Pravega 还有一场更偏技术的分享，包括整体的设计架构，如何保证 exactly once 语义，Stream Segment 如何更方便的提供 scaling up/down 等等，感兴趣的同学也可以看看，题目叫“Delivering stream data reliably with Pravega”。

这个议题本身也很有趣。不可避免的，我们会想到流式存储和通常意义上的消息队列系统（例如 Kafka）之间有什么区别，毕竟 infinite retention 的消息队列系统也可以被看成是一个 stream storage。另一个比较有趣的问题是一体化的抽象应该在哪个层面上来做，以及如何做。换言之，读写是否应该和存储分离，只提供统一的API？因为笔者对 storage 这块儿细节不是特别了解，这里就不班门弄斧了，感兴趣的小伙伴我们可以私下讨论。分议题中还有一场关于 Pulsar 的，也相关，题目叫“基于 Pulsar 和 Flink 进行批流一体的弹性数据处理”。