一文带你了解 Flink Forward 柏林站全部重点内容

**作者：杨克特（鲁尼）**

前言
==

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，并且这个数字在接下来很有可能还会变小
*   8月份发布的 1.9.0 版本是 Flink 目前为止发布的功能最多，修改量最大的一个版本

这张图片很好的概括了 Flink 在过去大半年所侧重的工作： 

对于 Flink 未来的一个可能的方向，Stephan 继续表达了他对 Application 这种偏在线服务的场景的兴趣。他先是将我们平时所说的批处理和流计算总结为 Data Processing，同时将消息驱动和数据库之类的应用总结为 Applications，而 Stream Processing 就是连接这两种看起来截然不同的场景的桥梁。我在一开始听到这个的时候也有点一头雾水，不明就里的感觉，经过这几天对这个问题的思考，有了一些自己的理解，我将在文末展开进行解释。提到 Application，就不得不提现在很流行的 FaaS（Function as a Service）。在这个领域，Stephan 觉得大家都忽视了 State 在这里面的重要性。比如一个典型的 Application 场景，一般都会具备以下这些特点：

*   整个 Application 会有一个或者多个入口，计算逻辑由消息来驱动
*   具体的业务逻辑被拆分成粒度较小的几个单元，每个逻辑单元使用一个 Function 来执行具体的逻辑
*   Function 之间会互相调用，一般来说我们也会将这些调用设计为异步的模式
*   每个 Function 的计算逻辑可能会需要一些状态，比如可以使用数据库作为状态的存储
*   在完整的计算逻辑完成之后，我们会通过一个统一的出口返回处理的状态

在这个场景里，我们看到了至少三点需求：

*   计算逻辑由消息驱动
*   计算逻辑和互相调用的关系必须可以比较灵活的进行组织
*   计算逻辑需要状态的支持，并且在某些情况下，需要保证 exactly once 的处理语义

这里面属第三点最难做。大家可以想象一下，假如现在我们的 Application 要处理类似电商场景下单这样的过程，同时我们依赖数据库作为这个应用的状态存储。我们有一个专门的库存管理逻辑和一个下单逻辑。在一个完整的购买逻辑里，我们需要先调用库存管理模块，检查下该商品是否有库存，然后将该商品的库存从数据库里减去1。这一步成功之后，我们的服务再继续调用下单逻辑，在数据库里面生成一个新的订单。在一切都正常的时候，这样的逻辑还是比较简单的，但一旦有错误出现就会相当麻烦。比如我们已经将库存减掉，但是在生成订单的过程中发生了错误，这样我们还得想办法让库存进行回滚。一旦类似的业务逻辑单元变多之后，你的应用代码将变得异常复杂。这个问题就是典型的 end-to-end exactly once，我们希望一个错综复杂的计算流程，要么全部一起成功，要么全部失败，就当它完全没发生过一样。

为了解决这样的问题，结合 Flink 目前的一些积累，Stephan 推出了一个全新的项目：[statefun.io](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fstatefun.io%2F)，即 Stateful Functions。通过结合 Stateful Stream Processing 和 FaaS，来提供一种全新的编写 Stateful Application 的方式。


具体的实现逻辑，我就不再过多介绍，大家可以自行到官网进行查看和学习。

### Cloudera

Stephan 给的第一个 Keynote 还是比较的偏技术化，这也符合他的个人风格。在之后的包括第二天的所有 Keynote，基本上都是知名的大公司来给 Flink 站台了。先从 Cloudera 说起，他们表示现在已经收到了越来越多的客户点名要 Flink 的情况，因此就”顺应民意“在他们的数据平台里加入了 Flink 的支持。能在这种商业开源软件提供商中占据一席之地，基本也算是标志在 Flink 已经进入了一个比较成熟的阶段。另外，Cloudera 是玩开源的老大哥级别人物了，当然不会只是简单的提供 Flink 软件这么简单。他们在会上宣布了他们已经组建了一支由两名 Flink PMC 带队的工程团队，并且打算后续在 Flink 社区也投入更多的资源，这无疑是给 Flink 社区的繁荣又注入了一股新鲜又强大的力量。


### AWS

AWS 在第二天登场，由他们主管 EMR、Athena、DocumentDB以及区块链的老大 Rahul 给出。他先是回顾了一下流计算相关的产品在 AWS 的发展历程：


从图中可以看出，他们早在2016年 Flink 崭露头角的时候就已经将 Flink 加入到了他们的 EMR 当中。相比 Cloudera 的后知后觉，AWS 在这方面果然就老江湖了许多。令人印象深刻的是，AWS 这几年围绕流计算产品的发展，一直有一个清晰的主线，那就是针对不同体量的客户推出更加适合他们的产品和解决方案。他们很好的总结了不同体量的客户对产品的需求的不同（相信这不仅仅只是针对流计算，针对其他的产品也是异曲同工）：


比如他们发现了大量的客户有时候使用流计算框架只是简单的解决一个数据转存的问题，比如简单的把数据从 Kinesis Data Stream（这个其实是他们的一个消息队列服务，光看名字容易有点误导）转存到 S3 上，或者把数据发到 Redshift 或者 Elasticsearch。针对这种场景，他们就开发了专门的 Kinesis Data Firehose 产品，让用户不需要写代码就能够完成这样的工作。另外，一些具备一些开发能力的客户，会写一些代码或者 SQL 来对数据进行处理和分析。针对这种场景，他们提供了 Kinesis Data Analytics 服务。

另外让人印象深刻的一点是，AWS 的各个产品之间的协同做的非常好（我在后来还参加了一个 AWS Kinesis 产品的演示分享，其中涉及到不少产品之间的协调和打通，让人印象深刻）。每个产品专注解决一部分的问题，产品和产品之间在功能上不能说完全没有重叠的地方，但基本上还是非常克制。演讲中分享的每个真实的用户场景，基本都涉及了3-5个以上的产品互相的协同。对客户需求的精准把握，以及产品的协同站位精确解决用户问题，这两点非常值得我们去学习。

扯的有点远了，回到 Flink 上来。Rahul 最后总结了一下 Flink 是他们目前看到的会去消息队列里消费数据的产品中增长最快的系统，但从绝对体量上来看还是偏小。这也基本符合 Flink 目前的一个状态，热度高，增长也很快，但是绝对体量还偏小，不过这也预示着想象的空间还比较大。

### Google

Google 在 AWS 之后出场，由 Reven 和 Sergei 带来（前者也是《Streaming Systems》一书的作者之一，终于见到真人了）。这个 Talk 整体上来讲和 Flink 没有太大的关系，分享的是 Google 这些年在流计算相关系统的研发过程中得到的经验。和 AWS 相比，两家公司的特色也是相当鲜明。AWS 分享的都是对客户需求和产品的总结，而 Google 说的基本上都是纯技术上的经验收获。听了之后也确实收获良多，不过由于篇幅问题就不在这具体展开了。人家也已经准备好一段总结让我们可以打包带走：


主议程
===

由于分身乏术，在主议程中我只挑选了一些个人比较感兴趣或者是不怎么了解的领域进行观摩和学习。但为了整篇报告的完整性，我还是尽量的简单介绍一下其他我没有参与但是还算熟悉的议题。后续主办方也会将所有的视频和 PPT 上传到网上供大家进行查看。接下来我就把议题按照个人理解分成几个不同的类别，分别抛砖引玉一下。大家如果对其中的某些议题的细节特别感兴趣的，可以再去仔细查看视频和 PPT。

平台化实践
-----

基于 Flink 构建数据平台可以算得上最热门的一个议题方向了。这几年阿里巴巴实时计算团队一直不遗余力的向社区推广基于 SQL 构建数据处理平台的经验，目前看起来大家也基本上认同了这个方向，也纷纷的开始上了生产。不过根据具体的场景，作业量的规模等特点，也有一些公司会选择使用更加底层和更加灵活的 DataStream API 来构建数据平台，或者两者都提供。这也符合我们一开始的判断，SQL 能解决大多数问题，但不是全部。在一些灵活的场景下，DataStream 能更方便和高效的解决用户的问题。

#### 议题1：《Writing a interactive SQL engine and interface for executing SQL against running streams using Flink》

这个分享来自美国的一家名叫 eventador 的创业公司，也是本次大会的赞助商之一。整个分享大部分还是他们产品架构和功能的介绍，基本上和我们以及其他公司的平台架构类似。比较有意思的是，他们也发现了在平台化的实践过程中，用户是同时需要 SQL 这种高阶 API 以及更加灵活和偏底层点的 DataStream API，并且这两者的比例是8：2开。


还有一个比较有意思的功能是，他们在 SQL 上提供了 JavaScript 的 UDF 支持，并且在他们的用户之间非常受欢迎。在 SQL 上，持续的降低使用门槛确实是一个比较靠谱的路子，和我们想提供 Python UDF 支持也是基于同样的出发点。


#### 议题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 接下去一个比较重要的方向之一）。


#### 其他议题推荐

*   《Stream SQL with Flink @ Yelp》：Yelp 已经算是 Flink 的老牌玩家了，在这个分享里他们总结了他们目前的流计算场景，以及他们的平台的做法。我因为时间冲突的原因没有听到这个分享，不过从其他渠道得到的反馈看起来他们应该是属于玩的比较溜的。推荐大家在视频和 PPT 上线后观摩学习一下。
*   《Flink for Everyone: Self-Service Data Analytics with StreamPipes》：一般来说，平台化建设都是公司内部项目，很少进行开源。这个叫做 FZI 的非盈利机构跳出来当了一把雷锋，提供了一套完全开源的平台化工程实现：[streampipes](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fwww.streampipes.org%2F)。自带一整套托拉拽的作业构建流程，而且看起来界面也相当的不错，有需要的同学可以参考一下。
*   《Dynamically Generated Flink Jobs at Scale》：这是高盛分享的基于 Flink 的平台实践，支持一天运行 12 万的作业。在银行和金融业的 IT 同学们可以参考下。

篇幅有限，还有其他相关的议题就不一一列出了。总体来说，基于 Flink 构建数据平台已经是一个相当成熟的实践，各行各业都有成功的案例进行参考。还没有上车的同学们，你们还在等什么？

应用场景类
-----

除了上面的平台化实践，使用 Flink 解决某些应用场景的具体问题也是这次分享中一个比较热门的方向。这些用户往往自己编写少量作业，来解决他们的实际问题。或者就干脆是平台的使用方，来分享如何使用平台来解决更贴近终端用户的问题。这也是 Flink 能够真正创造实际业务价值的地方，本想多听几个，可无奈老是时间冲突。

#### 议题1：《Making Sense of Streaming Sensor Data: How Uber Detects On-trip Car Crashes》

这是 Uber 分享的一个脑洞比较大的应用场景，他们使用 Flink 来实时判断乘客是不是发生了车祸。和 Pinterest 一样，在这个业务场景下，Uber 也是为了时效性而从 Spark 迁移到了 Flink。他们介绍了他们如何依赖两项最重要的数据（GPS信息和手机加速信息），再套用机器学习模型，来实时的判断乘客是否发生了车祸。


后续也提到了他们希望共享这个业务上收集的数据，以及在这个数据的基础上生成的一些特征，在其他的团队进行推广（怎么感觉方向又要转到平台化了-\_-!）


#### 其他议题推荐

*   《Airbus makes more of the sky with Flink》：空客公司介绍了他们如何使用 Azure、Flink 来进行飞行数据的分析，旨在提供更好的飞行体验。
*   《Intelligent Log Analysis and Real-time Anomaly Detection @ Salesforce》：Salesforce 介绍了他们使用 Flink 结合机器学习模型来解决实时日志分析，并且实时探测一些异常情况比如关键服务性能下降等。
*   《Large Scale Real Time Ad Invalid Traffic Detection with Flink》：Criteo 这家法国的广告公司介绍了广告场景下进行实时的异常流量探测。
*   《Enabling Machine Learning with Apache Flink》：Lyft 分享了他们如何基于 Flink 构建了机器学习的平台来解决多种多样的业务问题。

简单总结一下，在偏应用场景的方向上，已经越来越多的看到了 Flink 和机器学习结合使用的案例。基本上，一些稍微复杂点的问题很难通过规则逻辑，或者 SQL 来进行简单的判定。这种情况下，机器学习就能够派上比较大的用场。目前看来，大家还是更多的先使用其他引擎训练好模型，然后让 Flink 加载模型之后进行预测操作。但是过程中也会碰到类似两个引擎对样本的处理逻辑不同等问题而影响最终的效果。这也算是 Flink 今后的一个机会，如果 Flink 在更加偏向批处理的模型训练上能提供比较好的支持，那么用户完全可以使用同一个引擎来进行诸如用本拼接，模型训练以及实时预测这一整套流程。整个的开发体验包括实际上线效果相信都会有较大的提升，让我们拭目以待 Flink 在这方面的动作。

生产实践
----

这部分主要是生产实践的经验分享，很不好意思的是，相关的议题我一个都没有参与。我根据议题的简介简单做个介绍，感兴趣的同学可以自行查看相关资料。

*   《Apache Flink Worst Practices》：大家可能都听过不少 Best Practices，这个分享反其道而行之，专门介绍各种使用 Flink 的最差姿势，基本上算是分享各种踩坑或者踩雷的地方，让听众能够避开。
*   《How to configure your streaming jobs like a pro》：Cloudera 基于这些年他们在数百个流计算作业上总结下来的调参经验。针对不同类型的作业，哪些参数比较关键。
*   《Running Flink in production: The good, the bad and the in-between》：Lyft 分享的他们运维 Flink 的经验，有哪些 Flink 做的比较好的地方，也包括哪些 Flink 现在做的不够好的地方。让大家对运维 Flink 生产作业有更全面的认知。
*   《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 热点，优化完之后可能只会让系统其它地方等待的时间变长，并不能真正带来延迟的下降和吞吐的上升。所以他们先提出了一种”关键路径“的理论，在判断性能瓶颈时是以链路为单元进行判断和测量。只有真正的降低整条关键路径的耗时，才能有有效的降低作业的延迟。


第二个部分是介绍了一种新的作业自动扩缩容机制，并且和微软的 Dhalion 进行了对比。这个做法的特色在于，其他类似的系统总是对一个算子单独做决策，而他们会更多的把多个算子进行同时考虑。在扩缩容的时候让多个算子同时操作，减少收敛所需要的动作次数。


流计算任务的自治化也是我个人非常感兴趣的一个方向，也看到不少研究型的项目和论文在阐述这方面的工作，但暂时还未见到工业界对比有比较深入的分享（AWS 的 kinesis 服务具备动态扩缩容能力，但由于缺乏细节介绍不确定是否足够通用以及是否能够应对比较复杂的场景）。阿里巴巴实时计算团队早在一年前就启动了类似的项目，在这方向上进行了尝试和探索。面对内部大量的业务场景和需求，加上目前各种前沿的研究，相信不远的将来可以有所突破。

#### 其他议题推荐

*   《Moving on from RocksDB to something FASTER》：这也是苏黎世联邦理工带来的关于状态存储相关的研究，寻找比 RocksDB 更快的解决方案。在 Statebackend 上，阿里巴巴实时计算团队也有所布局，我们正在探索一种完全基于 Java 的存储引擎。
*   《Scotty: Efficient Window Aggregation with General Stream Slicing》：介绍了一种使用切片来提升窗口聚合性能的方法。

深度技术剖析
------

这个部分主要介绍的都是 Flink 在过去1-2个版本内做的一些大的 feature 和重构。由于本人就是 Flink 的开发者，对这些工作都比较熟悉，因此就没有选择去听这些分享。借用 Stephan 在 Keynote 中的两张图，基本做了比较好的概括。

 

有同学对其中个别的技术点感兴趣的话，基本都能够找到对应的议题，在这里我就不展开一一介绍了。

总结和感想
=====

这几年随着阿里巴巴持续对 Flink 的大力投资，Flink 的成熟度和活跃度均有了质的飞跃。社区生态也越发的繁荣，包括 cloudera 和 AWS 都已经开始积极的拥抱 Flink，也得到了不错的成果。各大公司的议题也从早年的抱着尝鲜的态度尝试 Flink，转变成了来分享使用 Flink 大规模上线后的一些成果和经验教训。在此基础之上，逐渐了形成了基于 Flink 的平台化实践、结合机器学习进行具体业务的问题解决和一些比较新颖的探索研究型项目等方向，让整个生态的发展更加的完整和壮实。不仅如此，Flink 也在积极的探索一些新的热门方向，比如和 K8S 的结合，和在线服务场景的结合等等，体现了这个生态的强大生命力。

不过归根结底，Flink 到底还是一个大数据计算引擎，其宗旨还是希望去解决大数据计算这个问题。在文章的一开头，我也提到了在看到 Flink 进军 Application 和 FaaS 的方向时，一个疑问一直在我的心头萦绕：Flink 到底是怎么样的一个计算引擎，它究竟是要解决什么样的问题？如果没有一个很清晰的主线和长远认识，在引擎的发展过程中很容易就会走偏，最终导致失败。

大部分人可能还停留在 Flink 是一个成熟的实时计算引擎的认知，但 Flink 从诞生的第一天起就想着要解决批处理的问题。即便现在 Flink 已经逐渐填补了批处理这个坑，但又朝着 Application 这样的在线服务场景发起了探索。乍一看，Flink 好像什么问题都想解，什么方向都想插一脚，真的是这样吗？

带着这样的疑问参加完了整个大会，又额外思考了几天，我开始有了一些新的认识和见解。想要回答 Flink 到底是怎么样的一个计算引擎，它究竟想解决什么样的问题这个疑问，我们得从数据本身开始看起。毕竟，一个计算引擎所要处理的对象，就是数据本身。

第一个问题是，我们需要处理的数据都是从哪里来的？对大部分公司和企业来说，数据可能来自各种手机APP，IoT设备，在线服务的日志，用户的查询等等。虽然数据的来源和种类各不相同，但有一个特点可能是大部分情况下都具备的：**数据总是实时的不断产生**。

我们可以使用流（Stream）或者日志（Log）这样的概念来模拟抽象所需要处理的数据，这也是现在一种比较流行的抽象方式，Jay Kreps 大神早年就在不遗余力的推广这样的方式，感兴趣的同学可以读一下这篇博文： 
[《The Log: What every software engineer should know about real-time data's unifying abstraction》](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fengineering.linkedin.com%2Fdistributed-systems%2Flog-what-every-software-engineer-should-know-about-real-time-datas-unifying)。


在这里先解答一下常见的几个疑惑，因为这个看起来和大家平时接触到的数据比较不一样。常见的问题会有：

*   我平时的接触的数据都存在Database里，看起来这个不一样啊？Database 可以理解成为将这些 Stream 物化后的产物，一般是为了后续的频繁访问可以更快。而且大部分 Database 系统的实现里，其实也是用的 Log 来存储所有的增删改行为。
*   我平时接触的数据都放在数仓里，按照天做了分区。这种情况可以再往数据的源头想一下，数据刚产生的时候不会直接到你的数仓，一般也是需要经过一个 ETL 过程。一般的数仓可以理解成将过去的一段段有限流，转存成了更高效的格式。

当我们使用这样的方式来抽象数据之后，我们就可以考虑我们会在这样的数据上做什么样类型的计算了。先从有限流开始：

*   对过去的一部分数据做一下简单的清洗和处理，这基本上就是大部分经典的批处理 ETL 作业
*   对过去的一部分数据做一些稍微复杂点的关联和分析，这算是比 ETL 稍微复杂点的批处理作业
*   对过去的一部分数据进行深度的挖掘从而产生更深的洞察，这是机器学习训练模型的场景

对于无限流来说，我们需要时刻消费最新产生的数据，那么可能产生的计算类型会有：

*   和批处理类似的 ETL 和分析型的数据处理场景，只不过计算发生在最新实时产生的数据上
*   对于最新产生的数据进行特征分析和挖掘，这是机器学习实时训练模型的场景
*   将最新产生的数据样本化，然后套用机器学习模型进行判定，这是典型的实时预测场景
*   根据最新产生的数据，触发一系列后台业务逻辑，这就是典型的 Application 或者在线服务场景


特别值得注意的是，有限流的计算和无限流的计算并不是完全独立存在的，有时候我们的计算需要在两者之间进行切换，比如这些场景：

*   先将所有的历史数据进行处理，然后开始实时消费最新产生的数据。比如说统计的场景，当统计口径变化之后，我们希望先把所有历史数据重新统计一遍，然后再接上最新的数据进行实时统计。
*   我们先根据历史数据进行样本生成然后训练模型，然后再消费最新的数据，将其转化为样本后开始做实时的预测和判定。这也是机器学习中很典型的做法，关键点在于需要保证训练模型时的样本逻辑和实时判定时的样本逻辑需要保持一致。

另外，我们也可以尝试从计算的延迟的角度对这些繁多的计算模式进行大致的分类：


列举了这么多例子和场景之后，大家应该也差不多能领悟到其中的道理了。当我们基于 Stream 来抽象所有的数据之后，在数据之上引发的计算模式是相当的多样化的。正如 Stephan 一开始在 keynote 中提到的，传统的 Data Processing 和消息驱动的 Application 场景，都不足以覆盖所有的计算模型。所有计算模型的本质是 Stream Processing，只不过有时候我们需要去处理有限的数据，有时候我们又需要去处理最新的实时数据。Flink 的愿景就是成为一个通用的 Stream Processing 引擎，并覆盖基于这个范式的所有可能的比较具体的计算场景。这样一来当用户有不同的计算需求时，不需要选择多个不同的系统（比如经典的 lambda 架构，我们需要选择一个专门的批处理引擎和专门的流计算引擎）。同时当我们需要在不同的计算模式间进行切换的时候（比如先处理历史数据再接上实时数据），使用相同的计算引擎也有利于我们保证行为的统一。

 

 

[原文链接](https://yq.aliyun.com/articles/721993)

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