一种基于流式计算实现海量数据滚动窗口聚合计算的方式

springk

已于 2023-07-06 16:29:44 修改

阅读量478

点赞数 1

分类专栏： flink 文章标签： flink

于 2021-02-08 15:56:10 首次发布

本文链接：https://blog.csdn.net/springk/article/details/113756959

版权

flink 专栏收录该内容

23 篇文章

订阅专栏

一、通用实现方式

在使用实时流式计算的时候，经常都会使用窗口的概念。对于storm而言，整体对事件窗口支持较弱，缓存整个窗口的所有数据，窗口结束时一起计算。而Flink，窗口支持较为完善，自带一些窗口聚合方法，并且会自动管理窗口状态。

伴随着大促以及相关秒杀等突发流量的行为下，会导致该窗口下数据量激增，导致数据处理延迟，当消息有延迟时，对应窗口内的信息数据会丢失，无法得到计算，需要对失效的数据做单独处理。整体不足主要体现在如下：
1、数据激增导致处理延迟延迟，尤其是突发流量计算延时严重，需要对延迟不在当前窗口下的数据做单独处理，否则数据就丢失，增加了系统设计的复杂性，因此Watermark的设置，也并未解决实际问题
2、对于突增的数据无法准确预知，在分配资源上容易出现偏差，容易造成资源浪费

二、解决方案

1、自定义滚动窗口实现，基于业务需要，针对时间（埋点上报的时间或者是系统处理时间），分成指定大小的时间段。例如以一天为例，按照5分钟维度计算，一天可以分成244个时间段，每一个时间到达，都可以找到对应的时间段
2、清洗相关的数据之后，留下需要处理的数据，对于需要处理的数据存入到队列中，于此同时，采用常驻线程调度任务，按照队列长度以及时间周期去处理获取到的数据，生成对应指标，对应整体流程图如下：

基于流式窗口的概念，实时处理窗口内的数据，减轻突发流量时窗口计算的压力，减少结果计算延迟，同时，当数据延迟到达时可以同步计算，不是丢失任何数据，总结如下：
1、基于业务时间窗口概念，自定义时间段，可以模拟不同时间段滚动窗口
2、延迟数据过来计算结果不丢失，可以随时统计到需要计算的时间段内
3、采用队列与定时调度任务的方式，增加系统吞吐量，面对突发高流量，减轻系统负担
4、可以准确预测系统所需要资源

三、方案详情

1、数据流
数据流主要是接入的流数据信息，可以是MQ、Kafaka等用来计算的数据源，数据流根据业务情况设置数据上传时间戳。
2、数据过滤处理
根据接收到的数据信息，对数据进行过滤，清理掉无用的数据，减轻系统负担
3、设置业务时间窗口
根据业务实际流程，可以根据系统时间或者数据上报的时间戳对窗口进行分段，按照天维度、小时维度、分钟维度、秒级等维度来设置具体的时间窗口分段。时间处理方式分为两种：
a、数据处理时的系统时间
b、数据自带上报的时间戳
4、时间段数据逻辑计算
根据该条数据的时间戳对应的时间分段，对应的数据处理同步放到该分段时间下进行数据计算。
例如PV、UV计算，假设时间段按照上报的时间点按照小时维度统计，则按照数据流上报的时间，在对应的时间段内数据做累加处理（假设上报的时间点事14时1分1秒，则对应的时间段为14时）
5、在数据聚合计算处理的过程中，每一条数据单独计算和数据按照小批次计算性能差距比较大，以redis为例，对于大数据量计算，每一次Redis数据更新操作会有IO消耗，采用redis pipline的处理方式，会大大提升系统系能，减轻IO损耗。所以在完成上面时间段数据计算逻辑的基础上，为了进一步增加系统处理吞吐量，在数据计算逻辑中引入队列和定时线程调度，作为数据接收和数据计算调度任务，两任务同时进行
a)   数据接收
i.   数据接收主要指数据经过清洗后最终拿到用来计算数值的数据，将对应的数据信息保存到队列中，队列中设置数据的最大值，队列需要创建两个，一个用来保存实时数据（队列A），一个用来接收已经获取到的数据（队列B）
ii.   当队列A中的数据达到最大值时，采用drain To方式，将队列A中的数据保存到队列B中，触发数据计算调度任务，对队列B中计算结果输出，例如redis批量写入。队列A则继续接受数据，不影响程序运行
b)   数据计算定时调度
i.   引入定时线程调度ScheduledExecutorService，按照业务实际需要来设置实际的间隔执行时间，可以按照分钟、秒维度来设置，不适合时间力度过长，影响实时计算效率，当调度时间间隔到达，则获取队列A中的数据，将队列A中的数据保存到队列B中，对队列B中计算结果输出，队列A继续接收最新数据
c)   通过数据接收和数据计算定时调度两个维度，从数据量和时间两个层面控制计算的吞吐量，两个调度同时进行，极大的提高实时计算的吞吐能力。