为什么我的Flink SQL查询的检查点大小不同?

时间:2019-03-19 06:52:08

标签: apache-flink flink-sql

在我的项目中使用Flink Table SQL时,我发现如果我的SQL中有任何GROUP BY子句,则检查点的大小将大大增加。

例如,

INSERT INTO COMPANY_POST_DAY
SELECT
    sta_date,
    company_id,
    company_name
FROM
    FCBOX_POST_COUNT_VIEW

检查点大小将小于500KB。

但是当这样使用时,

INSERT INTO COMPANY_POST_DAY
SELECT
    sta_date,
    company_id,
    company_name,
    sum(ed_post_count)
FROM
    FCBOX_POST_COUNT_VIEW
GROUP BY
    sta_date, company_id, company_name, TUMBLE(procTime, INTERVAL '1' SECOND)

即使没有任何消息处理,检查点大小也将超过70MB。像这样

Image is here.

但是当使用DataStream API和keyBy而不是Table SQL GROUP BY时,检查点大小将是正常的,小于1MB。

为什么?

-------更新于2019-03-25 --------

经过一些测试并阅读了源代码,我们发现其原因是RocksDB。

使用RockDB作为状态后端时,每个密钥检查点的大小将超过5MB,而使用文件系统作为状态后端时,检查点的大小将降至每个密钥小于100KB。 / p>

为什么RocksDB需要那么多空间来保存状态?我们什么时候应该选择RocksDB?

1 个答案:

答案 0 :(得分:0)

首先,我不认为70 MB是巨大的状态。有许多具有多个TB状态的Flink作业。关于两个查询的状态大小为何不同的问题:

第一个查询是一个简单的投影查询,这意味着每个记录都可以独立处理。因此,查询不需要“记住”任何记录,而只需“流”偏移即可恢复。

第二个查询执行窗口聚合,并且需要记住每个窗口的中间结果(部分和),直到时间足够长以使结果是最终的并且可以发出为止。

由于Flink SQL查询已转换为DataStream运算符,因此SQL查询与使用keyBy().window()实现聚合之间没有太大区别。两者都运行几乎相同的代码。

更新:已确定状态增加的原因是由RocksDBStateBackend引起的。此开销不是每个键的开销,而是每个有状态运算符的开销。由于RocksDBStateBackend用于保存多个GB到TB的状态大小,因此几MB的开销可以忽略不计。