作者:杨克特(鲁尼)
前言
2019.10.7~9号,随着70周年国庆活动的顺利闭幕,Flink Forward 也照例在他们的发源地柏林举办了第五届大会。虽然还没有拿到具体的数据,不过从培训门票已经在会前销售一空的这样的现象来看,Flink Forward 大会还是继续保持了一个良好的势头。本届大会不管是从参会人数上,提交的议题,以及参加的公司数量来看都继续创了一个新高。当然,这要去掉去年 Flink Forward 北京站的数据 ;-)。阿里巴巴这次共派出了包括笔者在内的3名讲师,总共参加了4场分享和2个问答环节。在这里,我会根据自己参与的议题给大家做一下这次会议整体的一个介绍和个人在这次参会过程里面的感受和思考,希望对感兴趣的同学有所帮助。
Keynote
先说说这两天的 Keynote。第一天的开场 Keynote 还是继续由社区一哥 Stephan Ewen 来给出。他先总结了一下 Flink 项目目前的一些状态,包括:
-
Flink 在8月份的 Github star 数超过了1万
-
在所有 Apache 项目中,Flink 排在邮件列表活跃度的 Top 3,并且这个数字在接下来很有可能还会变小
这张图片很好的概括了 Flink 在过去大半年所侧重的工作:
对于 Flink 未来的一个可能的方向,Stephan 继续表达了他对 Application 这种偏在线服务的场景的兴趣。他先是将我们平时所说的批处理和流计算总结为 Data Processing,同时将消息驱动和数据库之类的应用总结为 Applications,而 Stream Processing 就是连接这两种看起来截然不同的场景的桥梁。我在一开始听到这个的时候也有点一头雾水,不明就里的感觉,经过这几天对这个问题的思考,有了一些自己的理解,我将在文末展开进行解释。提到 Application,就不得不提现在很流行的 FaaS(Function as a Service)。在这个领域,Stephan 觉得大家都忽视了 State 在这里面的重要性。比如一个典型的 Application 场景,一般都会具备以下这些特点:
-
整个 Application 会有一个或者多个入口,计算逻辑由消息来驱动
-
具体的业务逻辑被拆分成粒度较小的几个单元,每个逻辑单元使用一个 Function 来执行具体的逻辑
-
每个 Function 的计算逻辑可能会需要一些状态,比如可以使用数据库作为状态的存储
-
在完整的计算逻辑完成之后,我们会通过一个统一的出口返回处理的状态
在这个场景里,我们看到了至少三点需求:
这里面属第三点最难做。大家可以想象一下,假如现在我们的 Application 要处理类似电商场景下单这样的过程,同时我们依赖数据库作为这个应用的状态存储。我们有一个专门的库存管理逻辑和一个下单逻辑。在一个完整的购买逻辑里,我们需要先调用库存管理模块,检查下该商品是否有库存,然后将该商品的库存从数据库里减去1。这一步成功之后,我们的服务再继续调用下单逻辑,在数据库里面生成一个新的订单。在一切都正常的时候,这样的逻辑还是比较简单的,但一旦有错误出现就会相当麻烦。比如我们已经将库存减掉,但是在生成订单的过程中发生了错误,这样我们还得想办法让库存进行回滚。一旦类似的业务逻辑单元变多之后,你的应用代码将变得异常复杂。这个问题就是典型的 end-to-end exactly once,我们希望一个错综复杂的计算流程,要么全部一起成功,要么全部失败,就当它完全没发生过一样。
具体的实现逻辑,我就不再过多介绍,大家可以自行到官网进行查看和学习。
Cloudera
Stephan 给的第一个 Keynote 还是比较的偏技术化,这也符合他的个人风格。在之后的包括第二天的所有 Keynote,基本上都是知名的大公司来给 Flink 站台了。先从 Cloudera 说起,他们表示现在已经收到了越来越多的客户点名要 Flink 的情况,因此就”顺应民意“在他们的数据平台里加入了 Flink 的支持。能在这种商业开源软件提供商中占据一席之地,基本也算是标志在 Flink 已经进入了一个比较成熟的阶段。另外,Cloudera 是玩开源的老大哥级别人物了,当然不会只是简单的提供 Flink 软件这么简单。他们在会上宣布了他们已经组建了一支由两名 Flink PMC 带队的工程团队,并且打算后续在 Flink 社区也投入更多的资源,这无疑是给 Flink 社区的繁荣又注入了一股新鲜又强大的力量。
AWS
AWS 在第二天登场,由他们主管 EMR、Athena、DocumentDB以及区块链的老大 Rahul 给出。他先是回顾了一下流计算相关的产品在 AWS 的发展历程:
扯的有点远了,回到 Flink 上来。Rahul 最后总结了一下 Flink 是他们目前看到的会去消息队列里消费数据的产品中增长最快的系统,但从绝对体量上来看还是偏小。这也基本符合 Flink 目前的一个状态,热度高,增长也很快,但是绝对体量还偏小,不过这也预示着想象的空间还比较大。
Google
主议程
由于分身乏术,在主议程中我只挑选了一些个人比较感兴趣或者是不怎么了解的领域进行观摩和学习。但为了整篇报告的完整性,我还是尽量的简单介绍一下其他我没有参与但是还算熟悉的议题。后续主办方也会将所有的视频和 PPT 上传到网上供大家进行查看。接下来我就把议题按照个人理解分成几个不同的类别,分别抛砖引玉一下。大家如果对其中的某些议题的细节特别感兴趣的,可以再去仔细查看视频和 PPT。
平台化实践
议题2:《Building a Self-Service Streaming Platform at Pinterest》
Pinterest 算是 Flink 社区的新面孔,这次是他们第一次在 Flink 的大会上分享他们的经验。他们主要的应用场景主要是围绕广告来展开,使用 Flink 来给广告主们实时反馈广告的效果。这也算的上是 Flink 相当经典的一个使用场景了。至于为什么这么晚才用 Flink,他们上来就进行了说明。他们花了比较大的功夫去对比 Spark Streaming,Flink 以及 Kafka Stream 这3个引擎,权衡再三之后才选择了 Flink,也算是比较谨慎和心细了。同时他们的老的业务基本上都是使用 Spark 跑批处理作业,在切换成流之后,也是需要拿出点实实在在的成绩才有可能在公司内大规模推广。
接着,他们也分享了两个在平台化实践过程中填的坑。第一个是日志的查看,尤其是当所有的作业跑在 YARN 上的时候,当作业结束后怎么查看作业运行时的日志是一个比较头疼的问题。第二个是 Backfilling,在新的作业上线或者作业逻辑需要变更的时候,他们希望先追一部分存在 S3 上的历史数据,然后在基本追完的时候切换到 Kafka 这样的消息队列上继续进行处理。这个 Backfilling 是 Flink 流批一体最经典的场景,而且看起来确实是个很普遍的刚需。如果没记错的话,这次大会就有 3 个议题提到了这方面的问题,以及他们的解法。解法各有千秋,不过如果 Flink 在引擎上能够直接内置支持了这样的场景的话,相信体验会好不少(这也恰恰是 Flink 接下去一个比较重要的方向之一)。
其他议题推荐
-
《Flink for Everyone: Self-Service Data Analytics with StreamPipes》:一般来说,平台化建设都是公司内部项目,很少进行开源。这个叫做 FZI 的非盈利机构跳出来当了一把雷锋,提供了一套完全开源的平台化工程实现: streampipes。自带一整套托拉拽的作业构建流程,而且看起来界面也相当的不错,有需要的同学可以参考一下。
篇幅有限,还有其他相关的议题就不一一列出了。总体来说,基于 Flink 构建数据平台已经是一个相当成熟的实践,各行各业都有成功的案例进行参考。还没有上车的同学们,你们还在等什么?
应用场景类
议题1:《Making Sense of Streaming Sensor Data: How Uber Detects On-trip Car Crashes》
其他议题推荐
-
《Airbus makes more of the sky with Flink》:空客公司介绍了他们如何使用 Azure、Flink 来进行飞行数据的分析,旨在提供更好的飞行体验。
-
《Large Scale Real Time Ad Invalid Traffic Detection with Flink》:Criteo 这家法国的广告公司介绍了广告场景下进行实时的异常流量探测。
简单总结一下,在偏应用场景的方向上,已经越来越多的看到了 Flink 和机器学习结合使用的案例。基本上,一些稍微复杂点的问题很难通过规则逻辑,或者 sql 来进行简单的判定。这种情况下,机器学习就能够派上比较大的用场。目前看来,大家还是更多的先使用其他引擎训练好模型,然后让 Flink 加载模型之后进行预测操作。但是过程中也会碰到类似两个引擎对样本的处理逻辑不同等问题而影响最终的效果。这也算是 Flink 今后的一个机会,如果 Flink 在更加偏向批处理的模型训练上能提供比较好的支持,那么用户完全可以使用同一个引擎来进行诸如用本拼接,模型训练以及实时预测这一整套流程。整个的开发体验包括实际上线效果相信都会有较大的提升,让我们拭目以待 Flink 在这方面的动作。
生产实践
-
《How to configure your streaming jobs like a pro》:Cloudera 基于这些年他们在数百个流计算作业上总结下来的调参经验。针对不同类型的作业,哪些参数比较关键。
-
《Introspection of the Flink in production》:Criteo 分享的教大家如何观测 Flink 作业是否正常的经验,以及当作业出问题时,如何最快的定位 root cause。
-
《Kubernetes + Operator + PaaSTA = Flink @ Yelp》:当大部分人还是基于 Yarn 来运行 Flink的时候,Yelp 这个深度玩家已然走到了大家前面。这也是我在这次大会中看到的唯一使用 Flink + K8S 上线的组合。
虽然一个议题也没听,但是也从别的议题中零零星星的听到一些大家关于 Flink 生产的话题,其中比较突出的是 Flink 和 Kubernetes 的结合问题。K8S 的火热,让大家都有种不蹭一下热度就落伍了的想法。不少公司都有朝着这个方向进行尝试和探索的意愿。其中就属 Yelp 走的最快,已经拿这套架构上线了。个人觉得 Flink 和 K8S 的结合还是相当靠谱的,可以解锁更多 Application 和在线服务相关的姿势。当然,阿里巴巴实时计算团队在这方面也没有落伍,我们也已经和阿里云 K8S 合作了相当长一段时间,最近也推出了基于 K8S 容器化的全新一代实时计算产品 ververica platform。
研究型项目
前面的议题基本都是一些工程化的实践,这次大会还有不少研究型的项目吸引了我的兴趣。生态的繁荣发展,除了有各大公司的实践之外,偏理论化的研究型项目也不可缺少。听说这次大会收到了不少研究型的议题,但由于议题数量有限,只从里面挑选了一部分。
议题1:《Self-managed and automatically reconfigurable stream processing》
这是苏黎世联邦理工学院的一名博士后带来的自动配置流计算作业的一个研究型项目。他们的研究方向主要集中在如何让流计算作业能够自治,不需要人为干预而能够自动的调整到最佳的状态。这和 Google 在 keynote 里的分享不谋而合,都是希望系统本身具备足够强的动态调整能力。这个分享主要有两部分内容,第一部分是提出了一种新的性能瓶颈分析理论。一般来说,当我们想要优化一个流计算作业的吞吐和延迟时,我们往往采用比较传统的观测 cpu 热点的方式,找到作业中最耗 cpu 的部分然后进行优化。但往往我们忽略了一个事实是,影响系统 latency 或者吞吐往往还有各种等待的操作,比如算子在等待数据进行处理等。如果我们单独优化 cpu 热点,优化完之后可能只会让系统其它地方等待的时间变长,并不能真正带来延迟的下降和吞吐的上升。所以他们先提出了一种”关键路径“的理论,在判断性能瓶颈时是以链路为单元进行判断和测量。只有真正的降低整条关键路径的耗时,才能有有效的降低作业的延迟。
其他议题推荐
-
《Moving on from RocksDB to something FASTER》:这也是苏黎世联邦理工带来的关于状态存储相关的研究,寻找比 RocksDB 更快的解决方案。在 Statebackend 上,阿里巴巴实时计算团队也有所布局,我们正在探索一种完全基于 Java 的存储引擎。
深度技术剖析
这个部分主要介绍的都是 Flink 在过去1-2个版本内做的一些大的 feature 和重构。由于本人就是 Flink 的开发者,对这些工作都比较熟悉,因此就没有选择去听这些分享。借用 Stephan 在 Keynote 中的两张图,基本做了比较好的概括。
有同学对其中个别的技术点感兴趣的话,基本都能够找到对应的议题,在这里我就不展开一一介绍了。
总结和感想
这几年随着阿里巴巴持续对 Flink 的大力投资,Flink 的成熟度和活跃度均有了质的飞跃。社区生态也越发的繁荣,包括 cloudera 和 AWS 都已经开始积极的拥抱 Flink,也得到了不错的成果。各大公司的议题也从早年的抱着尝鲜的态度尝试 Flink,转变成了来分享使用 Flink 大规模上线后的一些成果和经验教训。在此基础之上,逐渐了形成了基于 Flink 的平台化实践、结合机器学习进行具体业务的问题解决和一些比较新颖的探索研究型项目等方向,让整个生态的发展更加的完整和壮实。不仅如此,Flink 也在积极的探索一些新的热门方向,比如和 K8S 的结合,和在线服务场景的结合等等,体现了这个生态的强大生命力。
在这里先解答一下常见的几个疑惑,因为这个看起来和大家平时接触到的数据比较不一样。常见的问题会有:
-
我平时的接触的数据都存在Database里,看起来这个不一样啊?Database 可以理解成为将这些 Stream 物化后的产物,一般是为了后续的频繁访问可以更快。而且大部分 Database 系统的实现里,其实也是用的 Log 来存储所有的增删改行为。
-
我平时接触的数据都放在数仓里,按照天做了分区。这种情况可以再往数据的源头想一下,数据刚产生的时候不会直接到你的数仓,一般也是需要经过一个 ETL 过程。一般的数仓可以理解成将过去的一段段有限流,转存成了更高效的格式。
当我们使用这样的方式来抽象数据之后,我们就可以考虑我们会在这样的数据上做什么样类型的计算了。先从有限流开始:
-
对过去的一部分数据做一下简单的清洗和处理,这基本上就是大部分经典的批处理 ETL 作业
-
对过去的一部分数据做一些稍微复杂点的关联和分析,这算是比 ETL 稍微复杂点的批处理作业
-
对过去的一部分数据进行深度的挖掘从而产生更深的洞察,这是机器学习训练模型的场景
对于无限流来说,我们需要时刻消费最新产生的数据,那么可能产生的计算类型会有:
-
和批处理类似的 ETL 和分析型的数据处理场景,只不过计算发生在最新实时产生的数据上
-
对于最新产生的数据进行特征分析和挖掘,这是机器学习实时训练模型的场景
-
将最新产生的数据样本化,然后套用机器学习模型进行判定,这是典型的实时预测场景
-
根据最新产生的数据,触发一系列后台业务逻辑,这就是典型的 Application 或者在线服务场景
特别值得注意的是,有限流的计算和无限流的计算并不是完全独立存在的,有时候我们的计算需要在两者之间进行切换,比如这些场景:
-
我们先根据历史数据进行样本生成然后训练模型,然后再消费最新的数据,将其转化为样本后开始做实时的预测和判定。这也是机器学习中很典型的做法,关键点在于需要保证训练模型时的样本逻辑和实时判定时的样本逻辑需要保持一致。
另外,我们也可以尝试从计算的延迟的角度对这些繁多的计算模式进行大致的分类:
列举了这么多例子和场景之后,大家应该也差不多能领悟到其中的道理了。当我们基于 Stream 来抽象所有的数据之后,在数据之上引发的计算模式是相当的多样化的。正如 Stephan 一开始在 keynote 中提到的,传统的 Data Processing 和消息驱动的 Application 场景,都不足以覆盖所有的计算模型。所有计算模型的本质是 Stream Processing,只不过有时候我们需要去处理有限的数据,有时候我们又需要去处理最新的实时数据。Flink 的愿景就是成为一个通用的 Stream Processing 引擎,并覆盖基于这个范式的所有可能的比较具体的计算场景。这样一来当用户有不同的计算需求时,不需要选择多个不同的系统(比如经典的 lambda 架构,我们需要选择一个专门的批处理引擎和专门的流计算引擎)。同时当我们需要在不同的计算模式间进行切换的时候(比如先处理历史数据再接上实时数据),使用相同的计算引擎也有利于我们保证行为的统一。
原文链接
本文为云栖社区原创内容,未经允许不得转载。