如何正确理解flink 消费kafka时的watermark

案例1

在source 层面用全量数据watermark 对后面的窗口计算是否有影响?

bash 复制代码
KafkaSource<Event> source = KafkaSource.<Event>builder()
    .setWatermarkStrategy(
        WatermarkStrategy
            .forBoundedOutOfOrderness(Duration.ofSeconds(5))
            .withTimestampAssigner(e -> e.eventTime)
    )  // 全量WM:order+click污染!
    .build();

tream.filter(e -> e.type.equals("order"))  
    .window(...).sum();  

tream.filter(e -> e.type.equals("click"))  
    .window(...).sum();  
分析

10s(order) → 12s(click) → 15s(order) → 18s(click) → 20s(order)

全是数据生成的watermark是20-5=15

order 数据生成的watermark是 20-5=15

click 数据生成的watermark是 18-5=13

假设窗口大小是10s,现在又来了一条数据25s(order)

这里会导致窗口生成的watermark是25-5=20,刚好可以触发窗口计算了,可实际上可click这个数据流还有部分数据未到达,比如19(click) 就会漏算。所以这样生成watermark会有问题

案例2

上面的问题可以通过filter 精确分流,然后再生成watermark

bash 复制代码
public class WatermarkMasterTemplate {
    public static void main(String[] args) {
        // 1. Source:无WM(零污染)
        KafkaSource<Event> source = KafkaSource.builder()
            .build();
        
        // 2. 业务分流 + 独立WM(最精确)
        stream.filter(e -> e.type.equals("order"))
            .assignTimestampsAndWatermarks(preciseWM("order"))
            .window(...).print("ORDER");
            
        stream.filter(e -> e.type.equals("click")) 
            .assignTimestampsAndWatermarks(preciseWM("click"))
            .window(...).print("CLICK");
    }
    
    static WatermarkStrategy<Event> preciseWM(String type) {
        return WatermarkStrategy
            .forBoundedOutOfOrderness(Duration.ofSeconds(5))
            .withTimestampAssigner(e -> e.eventTime);
    }
}
分析

10s(order) → 12s(click) → 15s(order) → 18s(click) → 20s(order)

order 数据生成的watermark是 20-5=15

click 数据生成的watermark是 18-5=13

这样不同流生成的watemark 生成的流是精确的

案例3

如果先加一个rebance 操作,是否会影响per-partition watermark 语义

bash 复制代码
public class WatermarkMasterTemplate {
    public static void main(String[] args) {
        // 1. Source:无WM(零污染)
        KafkaSource<Event> source = KafkaSource.builder()
            .build();
      source.stream()
            .rebalance()
            .assignTimestampsAndWatermarks(preciseWM("order"))
            .window(...)
            .sum()
            .print("ORDER");
    }
    
    static WatermarkStrategy<Event> preciseWM(String type) {
        return WatermarkStrategy
            .forBoundedOutOfOrderness(Duration.ofSeconds(5))
            .withTimestampAssigner(e -> e.eventTime);
    }
}
分析

分区

partition a 10s(order) → 11s(click) → 14s(order) → 16s(click) → 18s(order)

partition b 12s(order) → 13s(click) → 15s(order) → 17s(click) → 19s(order)

但是如果是这样rebalance的话,会打乱单分区的watermark 的递增性,导致watermark 生成不精确

相关推荐
starzy19908 小时前
Flink 提交任务源码深度剖析:从CliFrontend到JobMaster的完整提交链路
大数据·flink
jason.zeng@15022078 小时前
canal做mysql的异步传输工具
数据库·mysql·linq
用户1494484813201 天前
同为消息队列,RocketMQ 和 Kafka 的底层设计差在哪?
kafka
开开心心就好1 天前
办公软件卸载不干净?专用工具一键清残留
java·前端·人工智能·智能手机·kafka·excel·memcache
starzy19901 天前
Flink Rpc通信源码级详解:从RpcService到动态代理的完整调用链路
大数据·rpc·flink
starzy19902 天前
Flink Akka底层原理深度剖析:从ActorSystem到Dispatcher调度器的底层实现
大数据·flink
ly76892 天前
ISR 收缩与 HW 推进:副本同步的边界条件与 UnderReplicated 排障
数据库·kafka·c#·linq·isr·hw·副本同步
nvd112 天前
# 从 192 秒到 13 秒:Apache Flink 批处理极速调优实战记录
大数据·flink·apache
starzy19903 天前
Flink 优化之网络缓存优化及参数详解:从数据传输机制到反压原理的生产调优指南
网络·缓存·flink
此时不提桶,更待何时4 天前
06-09-A-Kafka架构与存储原理详解
架构·kafka·linq