Flink SQL 内置优化参数功能以及适用场景介绍

前言

这几天在看 Flink SQL 内置优化参数的功能和原理,虽然网上会有一些文章介绍,这里还是自己做一个整体的总结和思考,方便自己以后的回顾。

Flink SQL 内置的优化参数是 Blink Planner 里面的功能,也就是 1.9 以后 Blink Planner 自带功能,从 Flink 1.11 开始,Blink Planner 已经成为 Flink 默认的 Planner,目前聚合优化参数是针对无界流非窗口类聚合,窗口类聚合优化参数未来会进行支持。下面开始讲解一下 Flink SQL 优化参数的功能以及其适用场景,官网相关参考:Streaming Aggregation。

结论

  1. 针对无界流非窗口聚合,在数据量非常大的情况下,如果业务方允许一定的时延,那么可以配置 Mini Batch 参数,通过牺牲一点延迟,降低对于状态的频繁操作,换取更大的吞吐量。同时对于可撤回流做二次聚合时,配置该参数,尽可能降低因数据记录撤回导致数据抖动的问题。
  2. 对于 SUM,COUNT, MAX, MIN,AVG 等非 Distinct 聚合时,为了防止数据倾斜对实时作业的影响,可以配置 Local-Global Aggregation 参数,一般公司内部的实时计算平台会支持该参数的配置。另外一种方式,可以在消息记录后面加一个随机数,然后聚合时,group by 后面的 Key 再加上这个随机数,先打散明细记录再聚合,然后再在该聚合流上进行一次聚合,key 还是之前的业务聚合 key,这种情况也需要配置 Mini Batch,防止数据抖动。
  3. 针对 Distinct 类聚合,配置 table.optimizer.distinct-agg.split.enabled 参数,尽可能减低数据倾斜对于实时作业的影响。
  4. 针对 Distinct 类聚合,同时多个指标都是相同的聚合类型和 Key 时,只是聚合条件不同,可以使用 FILTER 代替 CASE WHEN,能够减小对于状态的访问以及状态的存储大小。

一、Mini Batch 优化参数

1.1 Mini Batch 介绍

默认情况下,在无界流聚合场景下,每来一条记录,会经历下面三个步骤:
在这里插入图片描述

  1. 会先获取到这条记录的所对应的 Key,从状态后端获取其状态值
  2. 通过聚合函数,结合之前状态,进行结果计算
  3. 将新的结果值写入到状态后端中

当数据量非常大时,由于每条记录都需要经过上面三个步骤,同时还涉及到序列化和反序列化,所以此时这种场景下,实时作业的吞吐量以及 RocksDB StateBackend 负载都会受到很大的影响,所以在 Blink Planer 中就引入了 MiniBatch 功能。

MiniBatch 的本质还是在内存中缓存一批数据,通过周期性时间或者缓存的记录数到达预设值时,会触发计算。简单理解,会将记录存储在一个 HashMap 中,Key 就是业务聚合 Key,Value 是这个 Key 的消息记录集合,之后会遍历内存的数据(通过 Key),先获取该 Key 之前的状态值,将内存中缓存的数据参与到状态计算,最终写入到状态后端中。通过对数据攒批处理后,降低对于状态后端的操作,从而提升实时作业的吞吐量。Mini Batch 功能是 Flink 在吞吐量以及延迟之间做的权衡。
在这里插入图片描述

开启 Mini Bathch 功能有三个参数:

// instantiate table environmentTableEnvironment tEnv = ...// access flink configurationConfiguration configuration = tEnv.getConfig().getConfiguration();// set low-level key-value optionsconfiguration.setString("table.exec.mini-batch.enabled", "true");configuration.setString("table.exec.mini-batch.allow-latency", "5 s"); configuration.setString("table.exec.mini-batch.size", "5000");

1.2 Mini Batch 适用场景

个人认为 Mini Batch 参数开启的适用场景有两点:

  1. 应用场景为无界流非窗口聚合时,而且实时任务的数据量非常大,业务方能够允许实时作业有一定延迟,这种情况下,你可以牺牲一点点延迟,来换取更大的实时任务的吞吐量。
  2. 对于可撤回流的二次聚合,引入该参数,尽可能降低聚合值突然变小而后又恢复正常值的抖动。比如下面统计最新 word 的次数:
    select word,count(*) as cnt from (select name,last_value(word) as new_word from source group name) as t group word
    由于内层逻辑是一个聚合场景,同时实时数据也可能一直在变,所以内层结果存在撤回情况。当外层聚合逻辑遇到撤回记录时,会减去撤回消息记录 key 的相关结果值,然后在根据新发送的记录进行统计,所以就可能导致结果抖动,尤其在大促期间,大屏实时统计类任务,这种会造成业务方的疑问和担心,为什么结果值变小了,数据会不会丢失等等。引入 Mini Batch 参数,可以对一批数据进行计算后,在进行结果更新,尽可能减少这种数据抖动的情形。

二、Local-Global Aggregation

Local-Global 聚合参数主要解决非 Distinct 聚合场景下,比如 SUM, COUNT, MAX, MIN, AVG,数据倾斜问题。Flink 在进行 keyBy 时,相同的 Key 肯定会到同一 TaskManager 中,所以如果某类 Key 数据量过多时,会造成某个 TaskManager 负载过高,极端情况可能会导致实时作业反压,Checkpoint 超时失败等问题。

Flink Local-Global 聚合类似 Hadoop MapReduce 任务的 Combine,先在上游将结果本地聚合好,在发送聚合后的数据到下游,大大降低了发送到下游的数据量(将明细数据转换成聚合后数据),从而解决数据倾斜问题。下面是 Flink Local-Global 聚合示意图:
在这里插入图片描述

使用 Local-Global 聚合优化的前提,需要开启 Mini Batch 功能,下面是代码使用 Local-Global 功能:

// instantiate table environmentTableEnvironment tEnv = ...// access flink configurationConfiguration configuration = tEnv.getConfig().getConfiguration();// set low-level key-value optionsconfiguration.setString("table.exec.mini-batch.enabled", "true"); // local-global aggregation depends on mini-batch is enabledconfiguration.setString("table.exec.mini-batch.allow-latency", "5 s");configuration.setString("table.exec.mini-batch.size", "5000");configuration.setString("table.optimizer.agg-phase-strategy", "TWO_PHASE");

三、Split Distinct Aggregation

Local-Global 聚合类参数,能够解决非 Distinct 类的聚合场景数据倾斜问题,却无法解决 Distinct 类聚合场景,因为 Distinct 需要记住之前的原始数据,进行去重。下面是可能存在 Distinct 类数据倾斜聚合的 SQL 语句:

SELECT day, COUNT(DISTINCT user_id)FROM TGROUP BY day

由于 day 一般是当天的日期,所以这种情况,day 相同的数据都会到同一个 TaskManager 上面去,最终造成实时任务热点。Flink 内置的 Distinct 聚合优化参数table.optimizer.distinct-agg.split.enabled,通过将 Key 相同的记录,分到不同的 BUCKET(桶) 中去,BUCKET 默认数量为 1024,可以通过参数table.optimizer.distinct-agg.split.bucket-num 配置,配置 Split Distinct 聚合优化参数后,上面 SQL 会被转成:

SELECT day, SUM(cnt)FROM (    SELECT day, COUNT(DISTINCT user_id) as cnt    FROM T    GROUP BY day, MOD(HASH_CODE(user_id), 1024))GROUP BY day

在 day 相同的情况下,通过对 user_Id hash 取模,尽可能把消息打散到多个桶中,多个桶有分散在不同的 TaskManager,可以确定的是,user_id 相同的记录肯定会到同一 TaskManager 上面进行进行聚合。

下图是使用 Local Global 聚合参数和Split Distinct 聚合优化参数示意图:
在这里插入图片描述

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值