Flink Table & SQL API--动态表与Redo和Undo

今年4月11日在San Francisco举办的Flink Forward 2017会议上，来自Data Artisans公司的Timo Walther介绍了目前Flink社区中关于Table & SQL API的内容与展望。

展望的内容主要介绍了Dynamic Tables Model，即流上的动态表模型。初看到这一概念，我立刻想到了Oracle中的物化视图，只不过物化视图刷新的频率是有一定周期和间隔的。

而流是无界的且源源不断的，再加上流上可能出现的乱序以及状态的增量计算、延迟数据的重新计算等问题，我觉得Flink动态表的实现确实比较前沿。

下面就根据Timo Walther的视频演讲与PPT，对Flink动态表做一下简单的介绍。

1、什么是动态表

动态表并不是Flink独有的一个概念，表本身来讲，也不是严格意义的静态的，随着数据不断的insert、update、delete等操作，表中的数据也是不断变化的。同样的，Flink中的动态表也是随着时间的移动不断改变，通常我们基于一个时间范围来查询动态表的数据，这样就是相当于在流上应用window操作。所以，流和动态表之间是可以相互转化的。

注意：流上的数据不可能像数据库中表一样一直存储着数据，而是随着时间移动，flink表上的数据不断的被purge，或者clean-up或设置超时时间，否则状态太大很容易将内存撑爆。

2、流转换为动态表

有2种模式可以将流转换为动态表：

1、Append模式--没有key的概念
2、Update模式--有key的概念

Append模式就是不断的insert数据，那么动态表中将包含流上的所有数据，没有范围；
Update模式就是不断的update数据，动态表中只保留流上最新的数据。

例如上图中，时间从1到9，Append模式拥有所有数据，而Update模式只有每个K最新的数据，相当于对前一条K的更新。

3、动态表的查询

动态表上的查询确实很像维护着一个物化视图，而且这个查询的结果是不断更新的。

以上图为例，分别在时间为8、9、12时，进行3次查询，查询每个k包含的数量。
A[t]代表在时间t对表A进行的查询。
q(A[t])代表在时间t对表进行特定的查询，例如上图中对每个K进行计数。

首先，q(A[8])时查询的动态表结果是A包含3条，B包含2条，C包含1条。
其次，q(A[9])时查询的动态表结果是A包含3条，B包含3条，C包含1条。
最后，q(A[12])时查询的动态表结果是A包含3条，B包含3条，C包含2条。

这种SQL并没有限定范围，即就是我们上面介绍的Append模式，就有点类似于流上word count的例子。下面看一个有范围的word count的例子。

上图中，SQL中规定每隔5秒进行一次查询，窗口类型是翻滚窗口，即每5秒都是一次新的动态表。

首先，q(A[5])时查询的动态表结果是A包含2条，B包含1条，C包含1条。
其次，q(A[10])时查询的动态表结果是A包含1条，B包含2条。
最后，q(A[15])时查询的动态表结果是A包含2条，C包含2条。

值得注意的是，由于是翻滚窗口，之前的结果并没有累加到下一次结果中，而且要等到5秒的水位线到达后才触发计算。

由于流上的操作有诸多限制，因此不是任何的查询都可以应用到动态表上的，原因如下：

1、无界的数据必须设置超时时间或者约束，否则状态太大。
2、随着数据不断的到达，也许仅仅需要触发一部分的重新计算。
3、查询要在有界的范围内进行。

4、动态表转换为流

这里很像数据库中日志的技术：

1、Undo:数据被更新，保留以前的数据，例如Oracle中的闪回查询，就利用undo机制。
2、Redo:数据被更新，重新计算最新的值，即重做。
3、Undo+Redo:既要以前的数据，也要最新的数据。

对于动态表而言，支持2种模式：

1、Redo
2、Undo+Redo

这里介绍的太抽象了，简单点说，Redo就是根据key，在key上进行更新操作；而Undo+Redo就是删除之前的结果，重新计算最新的数据。我们下面看2个例子：

1、Undo+Redo

这里对结果不断进行撤回操作，并redo重新计算。

2、Redo

这里对结果进行基于key的更新操作。

我们知道，流上的操作可以处理乱序和late element，而flink SQL同样支持，例如我们设定一个一天的窗口查询，每个30分钟分钟触发一次计算，那么每次触发其实就是对之前结果的更新。当然我们可以设定允许的迟到时间，之后再次触发计算，也可以设置最后的触发时间。之后，窗口的状态将被purge。

5、关于Retraction

中文解释为撤回、撤销。那么在流处理中，retraction是什么意思呢？其实就是对与之前触发（early trigger）的结果，进行不断的改善和更新操作。

主要有2个地方需要retraction：

1、基于Key的表上，更新之前的结果
2、session window，后续的触发导致之前的窗口发生merge

这两种情况都需要对之前触发过的计算再次进行计算。

最后，附上3张上半年Flink Forward 2017的照片：

1、欢迎各年龄段的选手：）

2、Club Mate德国软饮还有中文字画

3、谁带过去的日本米酒。。。

参考：

YouTube–Timo Walther - Table & SQL API– unified APIs for batch & stream processing
SlideShare–Timo Walther - Table & SQL API – unified APIs for batch and stream processing