一、背景
flink做etl、大宽表、统计过程中有些小细节可以尝试优化,这里简单记录下:
二、场景
2.1 允许延迟的数据同步。比如线上订单库binlog同步到查询库,或者简单处理进入分析库,让分析师直接查询明细,进行group by 之类的. 如果吞吐要求大一点,可以开启小批处理。
# 这是SQL 参数,具体的根据业务自己调节
table.exec.mini-batch.enabled: 'true'
table.exec.mini-batch.size: '2000'
table.exec.mini-batch.binary.memory.size: 1mb
2.2 同 2.1类似,适合短时间高频率更新的业务,可以根据window进行过滤,减少存储端的更新频率。同样这种方法能减少下游维表的 join 的压力,相当于N秒更新的数据,内存压缩到1条
# 定义带自己的时间戳
CREATE TEMPORARY TABLE source_table (
id bigint,
name varchar,
ts AS PROCTIME()
);
# 这里用window 减少数据量
# 顺序可以用last_value,乱序用row_number + id + 时间处理
select
id,
last_value(name) as name
GROUP BY id,TUMBLE(ts, INTERVAL '5' SECOND);
2.3 有些场景凌晨的时候partition 没数据过来,导致开启window的时候下游无法输出,从

本文主要记录了Flink在ETL、数据同步、窗口处理、Top-N计算以及Join优化等方面的实用技巧,包括允许延迟数据同步、利用Window减少存储更新频率、解决凌晨无数据问题、避免Group By内存膨胀、Operator Chain的调试以及自定义Join和Top-N优化策略,旨在为Flink初学者提供优化参考。
最低0.47元/天 解锁文章
1117





