网站注册系统源码,卢松松博客源码 wordpress博客模板,销售管理系统业务流程图,wordpress主题放哪博主历时三年精心创作的《大数据平台架构与原型实现#xff1a;数据中台建设实战》一书现已由知名IT图书品牌电子工业出版社博文视点出版发行#xff0c;点击《重磅推荐#xff1a;建大数据平台太难了#xff01;给我发个工程原型吧#xff01;》了解图书详情#xff0c;…博主历时三年精心创作的《大数据平台架构与原型实现数据中台建设实战》一书现已由知名IT图书品牌电子工业出版社博文视点出版发行点击《重磅推荐建大数据平台太难了给我发个工程原型吧》了解图书详情京东购书链接https://item.jd.com/12677623.html扫描左侧二维码进入京东手机购书页面。
传统的关系模型和 SQL 最开始都是为了批式处理而设计的当把一个关系型查询应用到流式处理上时在实现和转换的过程中会有很多和批处理场景非常不同的地方典型的例子就是为了实现 SQL 的某些语义Flink 必须在流上维持状态典型的代表就是连接、聚合 、去重 这些操作它们都是“状态算子”本质原因还是因为流处理的表是无界的流式查询是持续不停的所以在流上维持状态是必须的。
此外我们应意识到由于 Table API SQL 程序是声明式的管道会哪里维持状态以及状态如何被使用都是不明确的就是说不能从 SQL 直接简单地推断出来另外Flink 还会对查询进行优化尽可能地减少“状态”的使用。
下面是官方文档给出的一个状态算子的示例
CREATE TABLE doc (word STRING
) WITH (connector ...
);
CREATE TABLE word_cnt (word STRING PRIMARY KEY NOT ENFORCED,cnt BIGINT
) WITH (connector ...
);INSERT INTO word_cnt
SELECT word, COUNT(1) AS cnt
FROM doc
GROUP BY word;这里的聚合函数 count 就需要状态维持同时又由于分组group by的存在要维持的状态数据就一下变多了每一个单词都要独立维护一个对应的状态。下图是针对上面的查询语句“编译”转换出的流式程序的图解 在这张详细的图解中我们应该注意这些重点
count函数是一个状态算子它的要维持状态数据也就是每个单词的词频这些状态数据又同时是下游的输入数据状态数据需要实时地推送到下游状态数据的变更也是以 changelog 形式传导的所以才会有 U(hello, 2)-U(hello, 1)这样的消息产生
除了 连接、聚合 、去重 这些显式的状态算子还有一些“隐式”的状态算子按官方文档的介绍是说由优化器隐式推导出来的。这里面的实现机理暂时还不清楚但是例子是非常典型的我们在《Flink 实时数仓关键技术解读Upsert Kafka 和 动态表Dynamic Table》这篇文章中曾经详细地解读过 upsert-kafka 作为 sink 时写入到 kafka 中的数据当再次以这些数据作为 source 进行流式读取时upsert-kafka 是能够完整推导出 changelog 数据的利用的就是这里所谓的“隐式推导”能力具体地说就是一个叫 ChangelogNormalize 的状态算子。
在持续运行的流上维持状态可能是一个成分非常大的操作因为流是不会停止的随着时间的推移和大量数据的涌入状态数据可能会越积越多导致内存挤爆。所以 Flink 提供了状态的 TTL 机制当状态在一定时间内没有被更新后就会被自动移除这个参数就是table.exec.state.ttl
定义了状态的键在被更新后要保持多长时间才被移除。 在之前的查询例子中word 的数目会在配置的时间内未更新时立刻被移除。
通过移除状态的键连续查询会完全忘记它曾经见过这个键。如果一个状态带有曾被移除状态的键被处理了这条记录将被认为是对应键的第一条记录。上述例子中意味着 cnt 会再次从 0 开始计数。 补充介绍
管道 PipelineFlink 文档中会反复出现这个名词在 Flink 中它指的是一个流式查询从 Source 到 Sink 的完整 DAG中间是各种算子简单地说就是一个查询被“翻译”成一个流后的所有的处理环节。
