Flink 2.0前瞻！关于技术栈的重新思考与批流融合

今天我们来解读一下Flink未来的方向：批流融合。这份PPT来自Flink Forward SF 2019。我在之前的一篇推文： Flink Forward 2019 旧金山之行 中曾说有时间会解读一下的，没想到会拖到现在。

这份PPT的演讲者是Flink的PMC Aljoscha，他在社区主要就是负责API、Connector、Scala语言的API的方向。

随着时间的推移，PPT中提到的一些设计可能会产生变化，但是大的方向已经明确了。希望看完这份解读后你依然坚信Flink一直在计算引擎上不断探索，在流计算领域里继续领跑其他框架。

老图了：以流为基础抽象，有界流（批）是无界流上的特例。

数据和查询哪个变化得更快？

对于批而言：很多场景下数据的变化要比查询（通常也理解为业务逻辑）慢。例如ad-hoc，在批的场景下，我们会经常进行各种交互式查询，查询本身可能变得比数据更快；

对于流而言：数据的变化可能要比应用程序的业务逻辑（查询）更快，比如模式检测，很多时候模式没变，只是数据不断地参与模式匹配。

更容易的理解方式：

• 在批中查询跑在Data上；

• 在流中Data跑在查询上；

老掉牙的比喻：星球大战系列的上映时间遵循Processing-Time，但剧情时间（EventTime）相比上映时间却是乱序的。

两个时间存在Skew，理想上应该是一致。

接上图，延迟vs完整性

其实之前在Flink里时间的语义只适用于流，但现在为了实现流批统一的概念，需要将这些概念都适配到流和批上去。

所以，这里进行了分别说明，批场景中延迟和完整性天然没有问题。

这幅图的意思是，如果你将这边方框和箭头组成的图整体看作是Workflow，那么批可以一步一步地阶段式进行，而流则必须每个步骤都一直在线。

这解释了现在拥有两套割裂且完全不一样的API的原因。

现状，对于用Table/SQL的人而言，好像本身批流就是统一的。但在下面，他们在生成物理计划时还是被映射到了不同的底层API上，这一点直接使用底层API的人也同样面临应对两套API的困扰。

现状有哪些可提升的地方？（缺点）

说白了就是割裂，代码重复、冗余，维护成本很高。

这给用户带来的困扰，不难理解。

OK，终于到未来的打算了。

如果批是流的子集的话，是不是可以废掉DataSet API，而只存在一套DataStream API呢？

统一批和流API，其实准确地说应该是放弃DataSet API，在DataStream API中引入一些新的概念来适配针对批的抽象。

这里引入的就是BoundedStream，让它使语义更自然，它将没有processing-time的定时器，Watermark也将从负无穷在处理结束后跳到正无穷。

DataStream的翻译以及运行时算子需要增强来支持优化。 Source也需要统一。

一个常见的批流混合的例子：在流中广播状态。这里状态视为有界的数据集，那么在这个DAG里，浅色的部分将会先执行，然后再执行深色部分的“流”式子图。

接下来展示的DAG层面以及算子/Task层面为了融合批所要进行的改进。

DAG这部分基本上从翻译、调度、部署、内存管理、网络栈、图等等都必须提供对有界流的增强。而真正包含用户业务逻辑的算子以及执行时表示的Task也需要提供对批模式的支持。

网络层可选择性的推模型，

批采用拉模型（等到上游中间结果集（IR）数据准备完成，下游去拉）；

流采用推模型（上游一有数据可供消费，就建立连接，上游将数据推向下游）

当前，跟批流有两套API一样，他们也有两套不同的Source 接口。

批是通过JM分配split，然后task去请求split来进行数据消费。

流里的source function完全是自实现的，目前甚至是需要自己hold主while(true)循环。

所以还需要一个新的统一的source设计：

很明显这部分的设计需要向之前的批的Source倾斜一些，需要引入Split的概念，之前流里的Source太过于自由，完全是没有约束与限制的，但在批里有些设计是无法回避的。

这里会有几个组件：Split, SplitReader, SplitEnumerator

检查点触发相关的逻辑示意：

对Table/SQL API的影响：

这是未来新的技术栈，最上层只有DataStream/Table&SQL API，下面是统一以流为基础抽象的DAG与算子层，再往下是运行时。

总结