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

11 月 28 - 30 日，北京迎来了入冬以来的第一场雪，2019 Flink Forward Asia（FFA）也在初雪的召唤下顺利拉开帷幕。尽管天气寒冷，FFA 实际到会人次超过 2000，同比去年增长近 100%。

Flink Forward 是由 Apache 官方受权举办的会议，每一年在欧洲、北美洲、亚洲各举办一场。经过参会不只能够了解到 Flink 社区的最新动态和发展计划，还能够了解到业界围绕 Flink 生态的生产实践经验，是 Flink 开发者和使用者的盛会。去年 12 月 Flink Forward 首次在中国举办，是规模最大、参与人数最多的 Flink Forward 大会。今年 Flink Forward China 正式升级为 Flink Forward Asia，吸引到更多的关注，并于 11 月 28 日在北京开幕。

除了参会人数的迅速增长，多元化也是今年 FFA 的一大闪光点。笔者根据大会纲要数了一下，大约有超过 25 家来自北美，欧洲和亚洲的公司，高校以及科研机构参与分享了超过 45 个议题。国内外一线大牌互联网公司齐聚一堂，其乐融融。这也说明愈来愈多的业界公司更加看好 Flink，而且深度参与 Flink 的规划与发展，这不管是对 Flink 的将来仍是 Flink 社区的发展都有很是积极的意义。

通过几年的发展，Flink 已经成为 Apache 最活跃的社区和在 Github 上访问量前三的项目。Github 的星数（表明项目受欢迎程度）在 2019 一年以内翻了一番。Apache Flink 在中国本土也更加的普及，下图列出了一些使用 Flink 做为实时计算解决方案的中国公司 logo。

笔者整体的参会感觉：引擎一体化和生态多元化是 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.10 这个版本里面，已经能够实现完整的 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 进行批流一体的弹性数据处理”。

基于 Apache Flink 的大规模准实时数据分析平台

主议题的最后一场是 Flink 实践，是由 Lyft 带来的大规模准实时数据分析平台的分享。这里所说的准实时，指端到端数据延迟不超过 5 分钟，在 Lyft 内部主要用于数据交互式查询，下图是 Lyft 准实时平台架构图。

Flink 在整个架构中是用来作流数据注入的，Flink 向 AWS S3 以 Parquet 的格式持久化数据，并以这些原始数据为基础，进行多级 non-blocking 的 ETL 加工（压缩去重），创建实时数仓，用于交互式数据查询。

在这个分享中印象深入的几点：

• Flink 的高效性。据 Lyft 的大佬们讲，这个新的平台相较于先前基于 Kinesis Client 的 ingestion 相比较，仅数据注入部分的集群就缩减了 10%，因此他们对 Flink 的高效性是很是承认的。
• Lyft 也提到，他们花了蛮多精力基于 Flink 的 StreamingFileSink 来解决 Flink 和 ETL 之间 watermark 的同步问题。其实我很但愿他们能分享一下为什么压缩去重（ETL）部分不也用 Flink 来作。若是是技术上的问题能够帮助 Flink 更好的完善本身。
• Lyft 提到 Flink 的重启和部署会对 SLO 形成延迟影响，subtask 停滞会形成整个 pipeline 的停滞以及指望 Flink 可以有一套在 Kubernetes 环境下运行的方案。其实这里提到的几点也在其余的几场企业实践分享中被提到，这些也是当前 Flink 亟待解决的几大痛点。社区对这几点都有规划，分议题中有一场“Pluggable Shuffle Service and Unaligned Checkpoints”有针对 Flink 重启和停滞的讨论；“Optimize Apache Flink on Kubernetes with YuniKorn Scheduler”讨论了一些和 Kubernetes 应用相关的问题。

除了 Lyft，在分会场中也有不少企业参与分享了本身使用和深度参与 Flink 开发的经验和教训。Flink 不只在国内公司中深受欢迎，不少北美欧洲的公司好比 Netflix，Uber 和 Yelp 也愈来愈多的使用和开发 Flink，感兴趣的同窗能够关注一下分会场议题中的“企业实践”和“实时数仓”专场。

分会场议题

分会场议题主要围绕着上面四个主议题展开，分为五个专场：

• Apache Flink 核心技术：主要针对 Flink 1.9 和 1.10 中比较核心的技术更新
• 人工智能：除了主议题已经包括的，Flink+TensorFlow 的实践分享也颇有趣
• 企业实践：字节跳动，快手，滴滴，网易，爱奇艺，Bilibili，360 等分享的实践经验
• 实时数仓：Netflix，美团，小米等分享的基于 Flink 的数仓平台
• 开源大数据生态：和 Flink 生态相关的内容，主要包括 Zeppelin，Kubernetes，Hive 等等

因为篇幅关系，这里就不做展开了，贴个清单连接，方便你们查阅，全部PPT资料也会连接在文末。

总结和感想

三天的 FFA，感触颇深。Flink 创始人之一 Ververica CEO Kostas Tzoumas 感慨说，五年前当他们 5 个初创刚刚开始 Flink 这个项目的时候没法想象今天 Flink 能有如此大的生态和如此广的应用。虽然我没法深切体会到他的感觉，可是当前 Flink 社区的繁荣和 Flink 的应用广度是有目共睹的，但更重要的问题是：将来咱们如何延续这种繁荣。Flink 在经历了高性能流式引擎，批流一体两代发展后，咱们确实须要思考一下将来的 Flink 是什么样的。

在这届 FFA 中一直强调一体化和多元化的概念，也就是开篇讲的引擎一体化和生态多元化，具象化来讲有三点：Stateful Function，拥抱AI，云原生。再到下一个层面也给 Flink 引擎自己提出更多的要求，这是挑战固然也是机遇。古语云瑞雪兆丰年， FFA 在北京的初雪中圆满落下帷幕，也让咱们共同努力，把握好机遇一块儿迎接挑战，共创美好的 Flink 2020。最后，分享一张一哥 Stephan 在 FFA 的 cool 照做为全篇的收尾，你们一块儿感觉一下。

附录：
2019 Flink Forward Asia 主会场视频回顾
2019 Flink Forward Berlin 柏林站分享

PPT下载连接

点击「PPT下载」便可至Flink社区官网下载大会各会场PPT。

Tips：极少数嘉宾 PPT 仍在审核中，完成后会第一时间更新在连接里，你们记得及时刷新～

---

本文做者：梅源（Yuan Mei）

原文连接

本文为云栖社区原创内容，未经容许不得转载。