查看原文
其他

Flink Forward 2019 旧金山之行

vinoyang Flink 2022-09-09

题图:细雨朦胧中的金门大桥

上周,我同事Robbie(施晓罡)和我一起去旧金山参加了Flink Forward SF 2019。

在当地时间4月2日的正式会议上,Robbie代表腾讯分享了我们对Flink的改进、优化以及扩展并介绍了我们围绕Flink打造一体化实时流计算平台——Oceanus过程中的一些实践。另外我们也听了一些感兴趣的议题分享,了解了社区后续的发展方向,同时也跟Flink社区的几个主要负责人进行了交流。

先来聊聊会议吧。会议签到:

上午所有人都在主会场,现场大概两三百来号人参加了会议,看到不少华人面孔:

上午除了开场致辞外,总共有三个主题分享,比较值得一听的是《From Stream Processor to a Unified Data Processing System》(Stephan, Xiaowei Jiang, Robert):

这个议题主要介绍了Flink在通往统一的数据处理系统道路上的一些思考,以及社区后续实现这一目标的计划。

主会场的三个议题之后,其他的分享都拆分为四个分会场同时进行。一些实践性的案例分享,这里就不再多谈,社区后续也会有相关的演讲视频放出来。下午最值得一听的议题是:《Towards Flink 2.0: Rethinking the stack and APIs to unify Batch & Stream》(Aljoscha)。它也是上午主会场介绍统一数据处理系统的延伸与细化,虽然在分会场进行,但这个议题几乎吸引了绝大部分的听众。

它介绍了Flink 2.0将会迎来重大变动:Flink将会重构技术栈并在API上作出重大的调整。Flink目前为有界/批量(DataSet)和流(DataStream)处理程序提供不同的API。 虽然DataStream API可以处理批处理的场景,但与DataSet API相比,它的效率要低得多。Table API在两者之上构建了统一的API,并在引擎内将具体的实现委托给DataSet或DataStream。

这个演讲介绍了Flink社区重新设计API和堆栈以获得更好的统一批和流的体验。其中包含这些主题:

  • DataSet,DataStream和Table API的未来角色和相互作用

  • 新的Flink堆栈以及这些API将构建的抽象

  • 新的统一批/流的source

  • 批处理和流的优化在运行时的不同之处,以及未来批处理和流在运行时的相互作用可能是什么样子


接下来,谈谈我们此行的一些经历。Robbie在会上作了一次标题为《Developing and operating real-time applications with Oceanus》的分享,在演讲中主要介绍了腾讯为简化实时应用程序的开发,围绕社区版Flink进行了哪些功能定制与增强以及我们围绕Flink打造了一个一体化的实时流计算平台——Oceanus(更多关于Oceanus的介绍,请移步《Oceanus:基于Apache Flink的一站式实时计算平台》。 同时也介绍了典型的用户案例以及如何使用Oceanus开发、部署和监控应用程序。 除此之外,介绍了Oceanus对Flink Job的管理,以及我们在运营实践中获得的一些经验。 最后,讨论了我们为提高可靠性和性能所做的一些努力,例如: master failover以及locak keyed stream等。

在现场,Robbie还接受了Ververica市场部门的邀请,参与了一段视频问答访谈,视频的内容官方应该会在不久后放出。

由于没有演讲任务,我则在休息时段有机会找Flink的几个PMC聊了聊我们与社区后续的合作与贡献计划以及我们关心的一些话题。在去参会之前,Stephan(Co-founder, CTO)邮件我说希望能跟我们聊一下,他对于腾讯使用Flink的情况以及我们希望贡献哪些特性给社区非常有兴趣。于是在开会的间隙,我找他聊了会儿:

首先,我用极其糟糕而且很不流利的英语给他介绍了腾讯使用Flink的整个历程,然后介绍了我们的Oceanus平台所支撑的应用所属的业务类型。他主动提出希望介绍一下我们对于Flink的定制与改进情况,我阐述了我们内部对社区版Flink的一些比较大的改动,比如:对Flink Leadership模块ZK使用的增强、重构了Flink web UI、体验更好的日志文件拆分与展示、LocalKeyBy缓解数据倾斜、早于社区实现了JSON函数(Table/SQL)、检查点失败处理逻辑重构、比社区更细粒度的资源配置等等。此外我跟他提到我们今年加强了对Flink批处理的投入,包括我们正在打造的SuperSQL(漂移计算),它能够支持多源、跨DC(数据中心)的复杂SQL查询及优化,同时它还充当着SQL engine的角色,后续能够根据用户的SQL进行合理的执行优化以及引擎选择。Stephan表示他很高兴看到我们对Flink作出的改进并期待后续合适的特性能够反馈并贡献给社区。除此之外,他还给了我个人一些参与社区的建议。

另一个预约好要聊一下的是Fabian(Co-founder, software engineer),前不久我给他去了一份邮件,请求他帮我Review不少Flink批处理相关的issue以及PR。大会现场我找他聊的话题主要也与此有关。

我们发现Flink批处理有很多不完善的地方,尤其是Hadoop compatibility模块,很多问题甚至只看源码就能发现,这些问题也验证了Flink 批处理没有被广泛使用,对比Spark一些比较基本的功能都无法匹配。但是遗憾的是,目前Flink批处理没有得到社区的重视,Fabian之前是批处理的主要负责人,他自己也说由于工作方向的变动他已经不专注在这块。但我表达了我们的诉求,希望他能够抽出一些时间来帮忙review代码并评估相关issue的实现方案,他也承诺会尽力而为。

最后与Till(software engineer)也聊了聊,Till是我在社区中互动最多的一个人,因为我主要参与的模块,他都是负责人,所以有机会能跟他聊聊自然不会错过。

其实我同事Robbie在前一天晚上已经跟他聊过了一些我们所做的事情。那我跟他聊的话题主要是关于我们最近比较关注的声明式的资源管理与自动扩缩容的社区计划,他说目前还没有非常明确的计划一定会将它作为下个大版本的重点,社区还有一些前置任务需要先完成。然后,聊了聊我的几个设计文档以及我比较关心的几个issue,参与社区的一些方式等等。最后,我再次感谢了他在社区中帮助我们Review了很多PR,并提供了很多有意义的建议。Till的技术功底真的非常好,这一点在issue讨论以及PR review的过程中感受比较深。所以,现在无论是我们内部自己的需求还是社区认领的issue,我都会尝试着跟他聊聊方案,因为他总是会提出非常不错的建议。

当然,我也碰到了 Table/SQL 模块的主要负责人Timo,虽然Table/SQL不是我主要关注的领域,但前前后后也有不少PR以及在社区的互动。不幸的是他的右手似乎受伤了,挂着绷带,所以只是简单寒暄、问候了一下。

整体而言,旧金山之行还算比较愉快,听到了一些不错的分享,了解了社区的发展计划,有机会向社区当面表达了我们的诉求,见到了很长时间里只是在邮件中沟通的一些人。

有些比较有代表性的议题,后续有时间我会尝试单独分析一下。




您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存