湖北省住房和建设厅网站,辽宁省建设工程注册中心网站,ghost 卸载wordpress,国外做设计赚钱的网站目录
前言#x1f6a9;
动态表和持续不断查询
stream转化成表
连续查询
查询限制
表转化为流 前言#x1f6a9;
传统的数据库SQL和实时SQL处理的差别还是很大的#xff0c;这里简单列出一些区别#xff1a; 尽管存在这些差异#xff0c;但使用关系查询和SQL处理流并…目录
前言
动态表和持续不断查询
stream转化成表
连续查询
查询限制
表转化为流 前言
传统的数据库SQL和实时SQL处理的差别还是很大的这里简单列出一些区别 尽管存在这些差异但使用关系查询和SQL处理流并非不可能。高级关系数据库系统提供称为物化视图的功能。物化视图定义为SQL查询就像常规虚拟视图一样。与虚拟视图相比物化视图缓存查询的结果使得在访问视图时不需要执行查询。缓存的一个常见挑战是避免缓存提供过时的结果。物化视图在修改其定义查询的基表时会过时。Eager View Maintenance是一种在更新基表后立即更新实例化视图的技术。
如果我们考虑以下内容Eager View Maintenance和流上的SQL查询之间的联系就变得很明显
数据库表是INSERTUPDATE和DELETEDML语句流的结果通常被称为更新日志流。物化视图定义为SQL查询。为了更新视图查询需要持续处理视图源表的更改日志流。物化视图是流式SQL查询的结果。
有了上面的基础下面可以介绍一下动态表的概念了。
动态表和持续不断查询
动态表flink table api和SQL处理流数据的核心概念。与静态表相比动态表随时间而变化但可以像静态表一样查询动态表只不过查询动态表需要产生连续查询。连续查询永远不会终止会生成动态表作为结果表。查询不断更新其动态结果表以反映其动态输入表的更改。最终动态表上的连续查询与定义物化视图的查询非常相似。
值得注意的是连续查询的结果始终在语义上等同于在输入表的快照上执行批处理的到的相同查询结果。
下图显示了流动态表和连续查询的关系 数据流被转化为动态表在产生的动态表上执行连续不断的查询产生一个动态结果表。结果动态表再次被转化为数据流。
注意动态表最重要的是逻辑概念。在查询执行期间动态表不一定完全物化。 在下文中会以schema如下的点击事件流来解释动态表和连续不断的查询。
[user: VARCHAR, // the name of the usercTime: TIMESTAMP, // the time when the URL was accessedurl: VARCHAR // the URL that was accessed by the user
]
stream转化成表
当然想要用经典的sql去分析流数据肯定要先将其转化为表。从概念上讲流的每个新增记录都被解释为对结果表的Insert操作。最终可以理解为是在从一个INSERT-only changelog流上构建一个表。
下图显示了click事件流左侧如何转换为表右侧。随着更多点击流记录的插入生成的表不断增长。 注意stream转化的表内部并没有被物化。
连续查询
在动态表上执行连续查询并生成新的动态表作为结果表。与批处理查询不同连续查询绝不会终止而且会根据输入表的更新来更新它的结果表。在任何时间点连续查询的结果在语义上等同于在输入表的快照上以批处理模式得到的查询的结果。
在下文中我们将在用点击事件流定义的clicks表上展示两个示例查询。
第一个查询是一个简单的GROUP-BY COUNT聚合查询。主要是对clicks表按照user分组然后统计url得到访问次数。下图展示了clicks表在数据增加期间查询是如何执行的。 假设当查询启动的事以后clicks表为空。当第一行数据插入clicks表的时候查询开始计算产生结果表。当[Mary, ./home]插入的时候查询会在结果表上产生一行[Mary, 1]。当[Bob, ./cart]插入clicks表之后查询会再次更新结果表增加一行[Bob, 1]。当第三行[Mary, ./prod?id1]插入clicks表后查询会更新结果表的[Mary, 1]为[Mary, 2]。最后二手QQ买卖地图第四行数据插入clicks后查询会给结果表增加一行[Liz, 1].
第二个查询仅仅是在上个查询的基础上增加了一个1小时的滚动窗口。下图展示了整个流水过程。 这个就类似批处理了每个小时产生一次计算结果然后更新结果表。cTime的时间范围在12:00:00 12:59:59的时候总共有四行数据查询计算出了两行结果并将其追加到结果表。Ctime窗口在13:00:00 and 13:59:59的时候总共有三行数据查询再次产生两行结果追加到结果表。随着时间的推移click数据会被追加到clicks表结果表也会不断有新的结果产生。
Update 和 append 查询
尽管两个示例查询看起来非常相似都计算了分组计数聚合但是内部逻辑还是区别较大
第一个查询更新以前发出的结果即结果表的更改日志流包含INSERT和UPDATE更改。第二个查询仅append到结果表即结果表的更改日志流仅包含INSERT更改。
查询是生成仅append表还是update表有一些区别
产生update变化的查询通常必须维护更多状态。将仅append表转换为流与将update表的转换为流方式不同。
查询限制
并不是所有的查询都能以流查询的格式执行的。因为有些查询计算起来成本比较高要么就是要维护的状态比较大要么就是计算更新成本高。
状态大小连续查询在无界流上执行通常应该运行数周或数月甚至7*24小时。因此连续查询处理的数据总量可能非常大。为了更新先前生成的结果可能需要维护所有输出的行。例如第一个示例查询需要存储每个用户的URL计数以便能够增加计数并在输入表收到新行时发出新结果。如果仅统计注册用户则要维护的计数可能不会太高。但是如果未注册的用户分配了唯一的用户名则要维护的计数数将随着时间的推移而增长最终可能导致查询失败。
SELECT user, COUNT(url)
FROM clicks
GROUP BY user;
计算更新有时即使只添加或更新了单个输入记录某些查询也需要重新计算和更新大部分发出的结果行。显然这样的查询不适合作为连续查询执行。下面sql是一个示例查询该查询基于最后一次点击的时间为每个用户计算RANK 。一旦clicks表接收到新增行用户的lastAction就会更新并且必须计算新的排名。但是由于两行不能具有相同的排名因此所有排名较低的行也需要更新。
SELECT user, RANK() OVER (ORDER BY lastLogin)
FROM (SELECT user, MAX(cTime) AS lastAction FROM clicks GROUP BY user
);
表转化为流
可以像传统数据库表一样使用INSERT, UPDATE, 和DELETE修改动态表。当将动态表转化为stream或者写入外部系统的时候需要对修改进行编码。Flink的Table API和SQL支持三种方式来编码动态表的变化。
Append-only stream假如动态表的更改操作仅仅是insert 那么变为stream就仅仅需要将插入的行发送出去即可。
Retract stream: retract(回撤)流是包含两种类型的消息的流增加消息和回撤消息。通过将INSERT编码为增加消息DELETE编码为回撤消息将UPDATE编码为对先前行的回撤消息和对新增行的增加消息来完成将动态表转换为收回流。下图显示了动态表到回收流的转换。 Upsert流 upsert流是一种包含两种消息upsert消息和删除消息的流。转换为upsert流的动态表需要唯一键。具有唯一键的动态表通过将INSERT和UPDATE编码为upsert消息DELETE编码为删除消息来完成动态表转化为流。流算符需要知道唯一键属性才能正确处理消息。与回撤流的主要区别在于UPDATE使用单个消息对update进行编码因此更有效。下图显示了动态表到upsert流的转换。
