Flink水位线Watermaker生产应用避坑分享丨本际云推荐

介绍

基于对处理时间的实时性要求，很多业务场景对“延迟”的忍受能力越来越低，因为能更及时发现问题，就能及时解决问题，进而能提升支撑保证和体验。在大数据分析领域，数据分析地越及时，价值越高，尤其是在推荐、风控等场景中，对实时性的要求更为苛刻。而流计算天然支持对事件发生的先后顺序、时间关系方面的分析，这也是flink在实时场景及大数据中被越来越多使用的原因。今天就和大家分享一下Flink的时间机制介绍，及展开一下watermark。

Flink水位线Watermaker生产应用避坑分享

三种时间机制

Flink有三种时间机制：Processing Time、Event time和Ingestion time。Processing Time是机器或者系统的时间，可理解为真实世界的时间。使用该时间模式有最好的性能和最低的延迟。Event time是数据上自带的时间，可理解为数据世界的时间。实际场景中应用较多，由于数据在传输过程有网络、I/O以及消费等因素，往往不能保证数据按顺序到达，因此导致了时间的乱序等问题。Ingestion time是数据进入程序时的时间，比如12点的一条数据与11点的一条数据同时进入程序，这两者会被认为是同一时间的数据。与事件时间相比，摄入时间程序不能处理任何无序事件或者延迟事件，但是程序无需指定如何产生水印。

Watermaker使用技巧

在实际业务场景中的实时计算，往往都是使用的数据时间EventTime，这样才能保证数据的真实性和准确性。但是数据在传输过程有网络、I/O以及消费等因素，数据的时间可能会存在一定程度的乱序。需要考虑对于整个序列进行更大程度离散化。把数据按照一定的条数组成一些小批次，但这里的小批次并不是攒够多少条就要去处理，而是为了对他们进行时间上的划分。经过这种更高层次的离散化之后，我们会发现最右边方框里的时间就是一定会小于中间方框里的时间，中间框里的时间也一定会小于最左边方框里的时间。这个时候我们在整个时间序列里插入一些类似于标志位的一些特殊的处理数据，这些特殊的处理数据叫做watermark。

Watermaker会以广播的形式在算子之间进行传播，下游所有算子共享watermark。如果在程序里面收到了一个 Long.MAX_VALUE这个数值的watermark，就表示对应的那一条流的一个部分不会再有数据发过来了，它相当于就是一个终止的一个标志。对于单流而言，会选择当前最大的值timestamp作为watermark。对于多流而言，会选择流中最小的watermark作为整个任务的watermark。即可看做一个由多个木块组成的装水的木桶，桶里面水多高取决于组成桶的那个最低的木块。

Watermaker的生成有两类。第一类是定期生成器，默认50ms向下游发送一次；第二类是根据一些在流处理数据流中遇到的一些特殊记录生成的，来一条数据获取一次，发送一次。生产中的使用可根据业务考虑使用何种，已达到性能和业务的平衡。

关于数据的延迟乱序，生成Watermaker时是可以直接增加一个特定延迟时间的。这样做的好处是，在水位到达时，仍然可以再等待一个延迟保证晚到的数据进行统计，保证数据的准确性，当然这样也使得数据实时性延迟，是保证实时性还是准确性，需要生成进行取舍，或者两种之间采用一个平衡值。具体的延迟时长，需要观察实际数据的延迟等进行判断及定义。

Watermaker实际应用避坑指南

避坑一：防止数据倾斜。使用Watermaker没有触发数据汇总场景。数据源一分钟产生一条数据，每条数据中有9条左右的不同key的子数据，程序进行Keyby处理后，开启一分钟的窗口进行汇总统计数量。程序启动4个并行进行处理，结果几分钟后都没触发汇总。

解决方案：不改并行的情况下，需要对程序Watermaker生成之前进行数据负载均衡，最简单直接的办法是进行一次keyby处理。数据量较少的情况，直接改小并行度。两种方法的目的都是保证每个并行都能消费到实时数据。

避坑二：业务链实时指标计算延迟问题。重复注册Watermaker导致任务吞吐量变低，影响计算效率。

解决方案：业务链处理经过算子处理之后m条数据会生成m*n条数据，然后进行keyby汇总。之前水位注册在汇总数据之前，因此需要对m*n条数据都进行水位注册，使得同一时间多次水位处理，程序效率也下来了，整个任务吞吐量变低。利用水位广播传递的特点，将水位注册放到数据源，只需要对m条数据进行注册，处理逻辑直接少了n倍，整个任务吞吐量也随之上来了。建议生成Watermaker的工作越靠近DataSource越好。

原创文章，作者：小编小本本，如若转载，请注明出处：https://www.benjiyun.com/yunzhujiyunwei/vps-yunwei/5821.html