建设化妆品网站的成本,天河建设网站,前程无忧深圳招聘网站,唱片公司网站模板文章目录 一. 使用关系查询处理流的讨论二. 动态表 连续查询(Continuous Query)三. 在流上定义表1. 连续查询2. 查询限制2.1. 维护状态2.2. 计算更新 四. 表到流的转换1. Append-only 流2. Retract 流3. Upsert 流 本文主要讨论了#xff1a; 讨论通过关系查询处理无界流… 文章目录 一. 使用关系查询处理流的讨论二. 动态表 连续查询(Continuous Query)三. 在流上定义表1. 连续查询2. 查询限制2.1. 维护状态2.2. 计算更新 四. 表到流的转换1. Append-only 流2. Retract 流3. Upsert 流 本文主要讨论了 讨论通过关系查询处理无界流的讨论flink维护一个动态表来处理不断变化的流查询这需要维护状态。动态表转换为流或输出时需要进行流的编码 一. 使用关系查询处理流的讨论
传统关系代数与流处理在流入数据、执行和结果输出的区别
物化视图与即时视图维护提供了关系查询处理流的思路 高级关系数据库系统提供了一个称为 物化视图(Materialized Views) 的特性。物化视图被定义为一条 SQL 查询就像常规的虚拟视图一样。与虚拟视图相反物化视图缓存查询的结果因此在访问视图时不需要对查询进行计算。 缓存的一个常见难题是防止缓存为过期的结果提供服务。当其定义查询的基表被修改时物化视图将过期。 即时视图维护(Eager View Maintenance) 是一种一旦更新了物化视图的基表就立即更新视图的技术。 即时视图维护和流上的SQL查询之间的联系: 数据库表是 INSERT、UPDATE 和 DELETE DML 语句的 stream 的结果–对数据库的所有操作记作为流即binlog通常称为 changelog stream 。物化视图被定义为一条 SQL 查询。为了更新视图查询不断地处理changelog 流。物化视图是流式 SQL 查询的结果。 上面主要表达了通过将数据库的binlog消费为stream用SQL查询作为物化视图并通过changelog更新物化视图。 二. 动态表 连续查询(Continuous Query)
动态表是随时间变化的查询动态表将生成连续查询查询结果会生成一个动态表并且查询会不断更新生成的动态表。 与表示批处理数据的静态表不同动态表是随时间变化的。可以像查询静态批处理表一样查询它们。查询动态表将生成一个 连续查询 。一个连续查询永远不会终止结果会生成一个动态表。查询不断更新其(动态)结果表以反映其(动态)输入表上的更改。本质上动态表上的连续查询非常类似于定义物化视图的查询。 需要注意的是连续查询的结果在语义上总是等价于以批处理模式在输入表快照上执行的相同查询的结果。 流、动态表和连续查询之间的关系: 将流转换为动态表。在动态表上计算一个连续查询生成一个新的动态表。生成的动态表被转换回流。 注意 动态表首先是一个逻辑概念。在查询执行期间不一定(完全)物化动态表。
三. 在流上定义表
流转换为表
为了使用关系查询处理流必须将其转换成 Table。 从概念上讲流的每条记录都被解释为对结果表的 INSERT 操作。本质上我们正在从一个 INSERT-only 的 changelog 流构建表。 显示了单击事件流(左侧)如何转换为表(右侧)。当插入更多的单击流记录时结果表将不断增长。 注意 在流上定义的表在内部没有物化。那什么时候会物化ing。 1. 连续查询
动态表上进行连续查询将生成一个新的动态表连续查询不会终止会根据输入表的更新更新结果表在任何时候连续查询的结果在语义上与以批处理模式在输入表快照上执行的相同查询的结果相同。
例子1基于 user 字段对 clicks 表进行分组并统计访问的 URL 的数量。 例子2将 clicks 分组至每小时滚动窗口中然后计算 url 数量。
两个查询的不同 第一个查询更新先前输出的结果即定义结果表的 changelog 流包含 INSERT 和 UPDATE 操作。第二个查询只附加到结果表即结果表的 changelog 流只包含 INSERT 操作。 2. 查询限制
2.1. 维护状态
连续查询在无界流上计算通常应该运行数周或数月。因此连续查询处理的数据总量可能非常大。这里flink要维护需要保存结果的行字段以便能够及时更新它们。例如第一个查询示例需要一直存储每个用户的 URL 计数以便能够增加该计数并在输入表接收新行时发送新结果。
SELECT user, COUNT(url)
FROM clicks
GROUP BY user;2.2. 计算更新
有些查询需要重新计算和更新大量已输出的结果行即使只添加或更新一条输入记录。显然这样的查询不适合作为连续查询执行(ing)。下面的查询就是一个例子它根据最后一次单击的时间为每个用户计算一个 RANK。一旦 click 表接收到一个新行用户的 lastAction 就会更新并必须计算一个新的排名。然而由于两行不能具有相同的排名所以所有较低排名的行也需要更新。
SELECT user, RANK() OVER (ORDER BY lastAction)
FROM (SELECT user, MAX(cTime) AS lastAction FROM clicks GROUP BY user
);但是我们可以设置一些参数可以用来在维持状态的大小和获得结果的准确性之间做取舍。 四. 表到流的转换
动态表可以像普通数据库表一样通过 INSERT、UPDATE 和 DELETE 来不断修改。
在将动态表转换为流或将其写入外部系统时需要对这些更改进行编码。Flink的 Table API 和 SQL 支持三种方式来编码一个动态表的变化:
1. Append-only 流
仅通过 INSERT 操作修改的动态表可以通过输出插入的行转换为流。 2. Retract 流
retract 流包含两种类型的 message add messages 和 retract messages 。通过 将INSERT 操作编码为 add message将DELETE 操作编码为 retract message将 UPDATE 操作编码为更新(先前)行的 retract message 和更新(新)行的 add message将动态表转换为 retract 流。 3. Upsert 流
upsert 流包含两种类型的 message upsert messages 和delete messages。
转换为 upsert 流的动态表需要(可能是组合的)唯一键。 将 INSERT 和 UPDATE 操作编码为 upsert message将 DELETE 操作编码为 delete message 将具有唯一键的动态表转换为流。 消费流的算子需要知道唯一键的属性以便正确地应用 message。
下图显示了将动态表转换为 upsert 流的过程。 与 retract 流的主要区别在于 UPDATE 操作是用单个 message 编码的因此效率更高。 请注意在将动态表转换为 DataStream 时只支持 append 流和 retract 流。 参考 https://nightlies.apache.org/flink/flink-docs-release-1.18/zh/docs/dev/table/concepts/dynamic_tables/#table-to-stream-conversion
