Flink 动态表 (Dynamic Table) 解读

|--------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| | 博主历时三年精心创作的《大数据平台架构与原型实现：数据中台建设实战》一书现已由知名IT图书品牌电子工业出版社博文视点出版发行，点击《重磅推荐：建大数据平台太难了！给我发个工程原型吧！》了解图书详情，京东购书链接：https://item.jd.com/12677623.html，扫描左侧二维码进入京东手机购书页面。 |

题记

根据过去在流上维持状态的编程经验，我们可以深刻地体会到：Dynamic Table 的本质其实是基于 changelog 数据流维持的一个流上的状态（Streaming State）！

动态表是 Flink 能以 SQL 驱动和操纵流式处理的基础，也是 Flink 实现 "批流一体" 的一项内在的技术支撑。简单地说，它的思想就是：将一个"流"抽象成一张"无界"的数据表，这样就可以在上面施加 SQL 操作了。静态的关系表和数据流有可以类比的地方，这是能将两者映射在一起的理论基础，同时，它们之间也有难以弥合的差异，所以在某些方面要进行限制或做出适当的妥协。文本将以 Flink 官方文档：动态表 (Dynamic Table) 为基底，给出一些批注式的解读。

对齐"概念"

首先，让我们来统一一些概念，对于一张动态表的查询可以有两个层面的解读，从上层应用的角度看：它就是一条 SQL，在查询一张表，只不过这张表是动态的，它的查询结果会一直在变（不同时间查，结果是不一样的），相应地，这条SQL其实是一直在跑的（不是反复查询，而是是一个持续运行 streaming job)；从底层实现的角度看，这条 SQL 其实是被翻译成了一个Streaming 作业，从源端不停地读取 changelog 数据，然后在流上维持一个"状态"数据，状态数据就是 SQL 要表达的结果表。所以：

查询动态表就是生成一个连续查询（一个 Streaming Job），一个连续查询是不会终止的（流是不会自行终止的，动态表是"无界"的），结果会生成一个动态表 (Streaming 上的 "状态")，查询会不断更新这张结果表（更新状态），实时地反映新流入的数据后对结果表的影响（同样的条件，不同时间查询，结果也可能不同，结果表里的数据可能一直在变）。

为了方便描述，我们可能会交替使用以下称谓或术语，它们指得都是同一件事情：

流式 SQL 查询 <=> 查询动态表 <=> 连续查询

"动态表" 两例

Flink 官方文档给出的两个张"动态表"的图示还是非常形象的，也是后面解释关联问题的基础，所以，这里先列出来：

• 第一个示例：

• 第二个示例：

结果表的状态：更新中... 或 追加中...

既然连续查询是永不停止的，那么结果表自然也是一直在变化的，它要么是在持续"更新"记录中，要么是在持续 "追加"记录中，至于是更新还是追加，取决于中间的处理逻辑，也就是 SQL 本身。官方文档给出的两个示例恰好一个是更细，另一个是追加：

• 第一个查询的结果表是需要"持续更新"的（有 UPSERT 操作），以 Mary 为例，她的 cnt 从 1 到 2 时就是一次更新
• 第二个查询只附加到结果表，即结果表的 changelog 流只包含 INSERT 操作。

一个查询是产生一个只追加的表还是一个更新的表有一些含义:

• 产生更新更改的查询通常必须维护更多的状态。
• 将 append-only 的表转换为流与将已更新的表转换为流是不同的(参阅表到流的转换章节)。

查询限制

尽管动态表的概念在语义上能将SQL（二维关系模型）比较好地映射到流上，但还是会有一些"力所不能及"的地方，这主要体现在对查询的一些"限制"上。有两类典型的限制：

• 维持了过多/过大的"状态"：这一点比较好理解，如果你的流式查询的结果表每一条都是一个"状态"，那流就需要一直维持这个状态，表的结果集绝大，维持的状态就越大/越大，直到程序因资源不足最后报错。此类案例就是：在第一个查询示例中，如果结果表中的每一条用户数据都是一个"状态"（可被 Upsert ），如果用户数量巨大，这个 SQL 就会报错，因为维持的 "状态" 负担太大；

  -- 若用户数量过多，则维持的状态就会过多过大，可能会消耗大量资源
  SELECT user, COUNT(url) FROM clicks GROUP BY user;

• 更新的数据量过大：通俗一点说就是：更新牵涉的数量太大，这一点在基于静态表的批量查询中并不会体现出来，但基于动态表的流式 SQL 查询是"连续查询"，它会不停地查询，不停地更新结果表，此时，如果查询每次都要更新大量已输出的结果行，那么查询成本就会被叠加"放大"，变得非常高！此类案例就是官方文档给出的示例，每此有新记录产生，都要重新进行排名，更新所有已输出的行，对于不停刷新的动态表来说，这一操作成本太大。

  -- 每此有新记录产生，都要重新进行排名，更新所有已输出的行，对于不停刷新的动态表来说，这一操作成本太大
  SELECT user, RANK() OVER (ORDER BY lastAction)
  FROM (
    SELECT user, MAX(cTime) AS lastAction FROM clicks GROUP BY user
  );