FLink的窗口机制与流处理Join的方案

FLink底层引擎是一个流式引擎，支持流处理和批处理，而window是streaming到batch的桥梁。因为流处理过程中，数据是源源不断流进来的，需要对数据进行实时处理的话，可以通过来一个消息处理一个的方式，也可以通过把一段时间内的数据聚合之后，再一起处理的形式，此时需要定义一个窗口来收集过去那段时间内的数据再进行处理。

Flink 提出了三种时间的概念，分别是event time（事件时间：事件发生时的时间），ingestion time（摄取时间：事件进入流处理系统的时间），processing time（处理时间：消息被计算处理的时间）。

窗口类型

窗口可以是时间驱动的（Time Window，例如：每30秒钟），也可以是数据驱动的（Count Window，例如：每一百个元素）。一种经典的窗口分类为：

• Tumbling window （滚动窗口，无重叠）

滚动窗口分配器将每个元素分配给指定窗口大小的窗口。滚动窗口具有固定的大小并且不重叠。例如，如果指定大小为5分钟的滚动窗口，则将评估当前窗口，并且每五分钟将启动一个新窗口，如下图所示。 Flink流类型

接下来，对join的一个实现类WindowJoin进行分析。基本思想为在一个时间窗内对两条数据结构为键值对数据流进行inner join操作。

重要参数配置：根据Flink的时间概念，时间属性时间选为ingestion time，并设置了窗口大小和数据传输速率。

函数调用

• where（）:给两条数据流指定各自的keySelector，获取key的类型

• equal（）判断key是否相同

• window（）:制作一个ID标识符，配置窗口中的

  • 输入流DataStream、keySelector、key type等元数据
  • 窗口组件window assigner、Trigger、EVictor
  image.png

• apply（）：配置join操作方法

• 最后通过execute（）执行inner join操作

问题

join 窗口的双流数据都是被缓存在内存中的，也就是说如果某个key上的窗口数据太多就会导致 JVM OOM。双流join的难点也正是在这里。例如可以借鉴Flink在批处理join中的优化方案，也可以像HDFS对中间结果的操作那样，当数据超过阈值时能spill到硬盘。