系列文章目录
Flink/Blink 原理漫谈(一)时间,watermark详解
Flink/Blink 原理漫谈(二)流表对偶性和distinct详解
Flink/Blink 原理漫谈(三)state 有状态计算机制 详解
Flink/Blink 原理漫谈(五)流式计算的持续查询实现 详解
Flink/Blink 原理漫谈(六)容错机制(fault tolerance)详解
文章目录
持续查询
静态查询和动态查询的关系
传统数据库表我们这里叫Static table,是指在查询的那一刻数据库表的内容不再变化了,查询进行一次计算完成之后表的变化也与本次查询无关了,我们将在Static Table 上面的查询叫做静态查询。连续查询发生在流计算上面,流表对偶性中我们提到过Dynamic Table,连续查询是作用在Dynamic table上面的,永远不会结束的,随着表内容的变化计算在不断的进行着。
在语义上 持续查询 中的每一次查询计算的触发都是一次静态查询(相对于当时查询的时间点), 在实现上 Blink会利用上一次查询结果+当前记录 以增量的方式完成查询计算。Blink上面的持续查询内部实现是增量处理,随着时间的推移,每条数据的到来实时处理当前的那一条记录,不会再处理曾经来过的历史记录!!
持续查询的实现
一句话概括就是,在一个动态表上不断地进行查询,并且将结果用增量计算的方式进行存储。
下面进行增加计算的介绍。
增量计算:
在持续查询的计算过程中,Blink采用增量计算的方式,也就是每次计算都会将计算结果存储到state中,下一条事件到来的时候利用上次计算的结果和当前的事件进行聚合计算。

APPEND ONLY场景
统计订单数量和总金额的场景,订单表本身是一个append only的数据源(假设没有更新,截止到2018.5.14日,blink内部支持的数据源都是append only的),在持续查询过程中经过count(id),sum(amount)统计计算之后产生的动态表也是append only的,种场景blink内部只需要进行aggregate function的聚合统计计算就可以
用人话解释就是,这种类型的场景,数据只是进行一个类似累加的过程,它只会单调递增,不会存在回撤,取消这种操作。

UPDATE 场景
这部分文档中写的很好,下面搬运一下:
无PK的Append Only 场景
在实际的业务场景中,我们只需要进行简单的数据统计,然后就将统计结果写入的业务的数据存储系统里面,比如上面统计订单数量和总金额的场景,订单表本身是一个append only的数据源(假设没有更新,截止到2018.5.14日,blink内部支持的数据源都是append only的),在持续查询过程中经过count(id),sum(amount)统计计算之后产生的动态表也是append only的,种场景blink内部只需要进行aggregate function的聚合统计计算就可以,如下:

有PK的Update 场景
现在我们将上面的订单场景稍微变化一下,在数据表上面我们将金额字段amount,变为地区字段region,数据如下:

查询统计的变为,在计算具有相同订单数量的地区数量;查询SQL如下:
CREATE TABLE order_tab(
id BIGINT,
region VARCHAR
) WITH (
type='xxx'
);
CREATE TABLE region_count_sink(
order_cnt BIGINT,
region_cnt BIGINT,
PRIMARY KEY(order_cnt) -- 主键
) WITH (
type = 'print'
);
-- 按地区分组计算每个地区的订单数量
CREATE VIEW order_count_view AS
SELECT
region

本文深入探讨Flink/Blink的持续查询原理,讲解静态查询与动态查询的关系,以及在Blink中如何通过增量计算处理APPEND ONLY和UPDATE场景。文章还介绍了Blink Store在双流join和Sink中的应用,特别是如何处理数据更新和错误处理的retraction机制。
最低0.47元/天 解锁文章
1677

被折叠的 条评论
为什么被折叠?



