Flink Table API& SQL编程指南（Dynamic Table、Continuous Querires、Query Restriction）

Streaming Concepts

Flink的Table API或者是SQL的计算针对于一些Batch或者Streaming数据在语义上是一致的。由于关系运算和SQL分析最初是为了对批处理而设计的，所以讲关系查询或者SQL应用在无界的流计算方面不如有界批处理那么好理解。因此我们后面将给大家介绍Flink 的关系API在流计算上的一些概念。

Dynamic Table

由于传统SQL和关系分析早期的设计主要是用于批处理，因为在关系运算、SQL处理方面与流计算是由一些差异的。下面我们分别从数据、输入形式、计算形式三个维度对比一下：

传统SQL分析	流处理
获取的是有界的数据集合	获取的无界的数据集
计算时候，可以获取完整的数据集	流的查询是无法获取所有数据，当流启动以后必须wait数据的到来
由于输入是固定的数据集，因此Batch查询可以输出固定的大小的结果，然后计算终止	由于输入的数据是无界的，因此一个流的查询仅仅只能做持续更新结果，计算永不截止

尽管存在这么多差异，使用关系查询SQL处理流并不是不可能的，先进的关系型数据库系统提供了一个特性称为Materialized Views。该Materialized View和常规的Virtual Views很相似，但是和常规的Virtual Views的区别在于Materialized Views会缓存相应SQL的查询结果，以便在视图访问的时候，无需再次运行SQL查询。

如果使用Materialized View技术去缓存计算的结果，虽然会提升性能，但是我们又必须考虑到在流计算中的数据是无界的，因此数据在不同的更新，这个时候如果我们查询Materialized View会导致获取的是过期的数据，因此Eager View Maintenance（急切视图管理）技术可以在基表发生变化的时候，立即更新Materialized View防止系统提供过期的数据。因此在流计算中的SQL分析与Eager View Maintenance联系就变得显而易见了：

• 表是通过stream中中产生了Insert、Update和Delete等DML语句之后产生的结果，通过被称为 changelog stream
• 我们通常会将Materialized View定义为一个SQL查询，该查询会持续的处理changelog stream，因此可以更新该Materialized View
• Materialized View同样也可以理解为SQL查询的结果

在Flink的Table API或者SQL中，将上述的changelog stream定义为动态表,通过对动态表查询会产生一个Continuous Query(持续查询)。其中Continuous Query永远不会终止，并且会产生一个动态表作为结果。当有数据更新的时候的，该查询会持续的更新这个动态表。

为了在流上使用关系分析/SQL，我们首先要做的就是把stream转换为Table.从概念量讲，流的每个记录都被解释为对结果表的INSERT操作，本质上我们从仅对change log做INSERT的流结构中建表。

Continuous Querires

在动态表上执行持续查询，并生成一个新的动态表作为结果。与静态的查询同，持续的查询永远都不会终止并且如果输入发生变换，该查询会更新结果表。在任何时间点上，连续查询的结果在语义上等同于在输入表的快照上以批处理的模式执行统一查询结果。

查询限制

很多(但不是所有)语义有效的查询都可以基于流做持续查询，因为某些查询可能受限于需要维护的状态太大或者是计算成本过于昂贵。

• State Size - 基于流的持续计算往往会支持数周或者几个月，这就会导致持续计算的总数据量会变得很大。因为每一次查询都要去更新先前的输出的结果信息，所以系统必须保留所有输出的行的结果，以便做后续更新。例如有以下SQL统计网站的点击量：

  SELECT user, COUNT(url) FROM clicks GROUP BY user;
  

  如果我们限定仅仅只对网站的已经注册用户做统计，那么这种计算不会太大。但是如果非网站注册用户也会分配一个唯一的name，同时我们采集做持续计算，随着会随着时间的推移所需要的管理的状态数据越来越大，最终会导致计算失效。

• Computing Updates - 还有一种计算时，即使仅仅添加更新一条记录，某些查询也需要重新计算和更新很大一部分结果，很明显针对于这种查询是不太适合做持续查询的。例如 我们计算根据用户名计算用户的登陆时间排名：

  select user,rank() over ( order by lastActionc  ) 
  from (select user ,max(cTime) as lastAction from clicks group by user)
  

  这个例子中不难发现，只要有记录进来，系统就需要重新计算lastAction结果，同时还需要对所有user数据做排名，因此这种类型的计算就不适合做持续计算。

一般可以设置查询的状态的时间，来限制状态过大，用户可以通过:

TableConfig tConfig = tableEnv.getConfig();
// 设置查询参数，最少12小时，最多24小时，参数至少间隔5分钟
tConfig.setIdleStateRetentionTime(Time.hours(12), Time.hours(24));

表示，系统会在删除一些空闲状态的时候，一定会删除空闲状态数据大于24小的数据空闲数据。如果空闲时间小于12小时吗，

Table到流的转换

当再将一个动态表转换为DataStream或者将动态表数据写入到外围系统的时候，需要更改进行编码，Flink的Table API和SQL支持山中方式来编码动态表的变更。

• Append-only Stream:如果一个动态表中只有INSERT操作，这样可以把动态表转换为Append-Only Stream
• Retract stream - 当系统中存在添加消息和重发消息的时候，需要转换为Retract Stream.Flink通过INSERT表示添加一则消息，通过DELETE进行Retract（撤回）操作，如果是UPDATE消息那么就是先执行一个撤回操作，然后执行一个添加新行的操作，如下图所示：
  
• Upsert stream - 与Retract stream类似，只是在UPDATE的时候不会发出两个消息，仅仅发出一个消息，因此比Retract更加高效，如下：
  

**Note：**将Dynamic Table转换为流目前仅仅支持Append和Retract流