目录
（1）增量聚合函数（incremental aggregation functions）
（2）全窗口函数（full window functions）
一、窗口
1、窗口的概念
在流处理中，我们往往需要面对的是连续不断、无休无止的无界流，不可能等到所有所有数据都到齐了才开始处理。更加高效的做法是，把无界流进行切分，每一段数据分别进行聚合，结果只输出一次。这就相当于将无界流的聚合转化为了有界数据集的聚合，这就是所谓的“
窗口”（Window）聚合操作。
窗口聚合其实是对实时性和处理效率的一个权衡。
在 Flink 中
窗口就是用来处理无界流的核心。我们很容易把窗口想象成一个固定位置的“框”，数据源源不断地流过来，到某个时间点窗口该关闭了，就停止收集数据、触发计算并输出结果。
我们为了正确处理迟到数据，结果把早到的数据划分到了错误的窗口——最终结果都是错误的。所以在 Flink 中，
窗口其实并不是一个“框”，流进来的数据被框住了就只能进这一个窗口。相比之下，我们应该
把窗口理解成一个“桶”，如图 6-15 所示。在 Flink 中，窗口可以把流切割成有限大小的多个“存储桶”（bucket)；每个数据都会分发到对应的桶中，当到达窗口结束时间时，就对每个桶中收集的数据进行计算处理。
Flink 中窗口并不是静态准备好的，而是动态创建——当有落在这个窗口区间范围的数据达到时，才创建对应的窗口。
2、窗口的分类
（1）按照驱动类型分类——时间窗口和计数窗口
按照时间段去截取数据，这种窗口就叫作“时间窗口”（
TimeWindow）。
按照固定的个数，来截取一段数据集，这种窗口叫作“计数窗口”（Count Window）
Flink 中有一个专门的类来表示时间窗口，名称就叫作 TimeWindow。这个类只有两个私有属性：start 和 end，表示窗口的开始和结束的时间戳，单位为毫秒。
在 Flink 内部也并没有对应的类来表示计数窗口，底层是通过“全局窗口”（Global Window）来实现的。
（2）按照窗口分配数据的规则分类
- 滚动窗口（Tumbling Windows）
滚动窗口有固定的大小，是一种对数据进行“均匀切片”的划分方式。窗口之间没有重叠，也不会有间隔，是“首尾相接”的状态。滚动窗口可以基于时间定义，也可以基于数据个数定义；需要的参数只有一个，就是窗口的大小（window size）。
- 滑动窗口（Sliding Windows）
与滚动窗口类似，滑动窗口的大小也是固定的。区别在于，窗口之间并不是首尾相接的，而是可以“错开”一定的位置。如果看作一个窗口的运动，那么就像是向前小步“滑动”一样。
定义滑动窗口的参数有两个：除去
窗口大小（window size）之外，还有一个“
滑动步长”（window slide）。
滑动窗口可以基于时间定义，也可以基于数据个数定义。
- 会话窗口（Session Windows）
就是数据来了之后就开启一个会话窗口，如果接下来还有数据陆续到来，那么就一直保持会话；如果一段时间一直没收到数据，那就认为会话超时失效，窗口自动关闭。
会话窗口只能基于时间来定义，“会话”终止的标志就是“隔一段时间没有数据来”，
对于会话窗口而言，最重要的参数就是这段时间的长度（size
），它表示会话的超时时间，也就是两个会话窗口之间的最小距离。
在 Flink
底层，对会话窗口的处理会比较特殊：每来一个新的数据，都会创建一个新的会话窗口；然后判断已有窗口之间的距离，如果小于给定的 size
，就对它们进行合并（
merge
） 操作。在 Window
算子中，对会话窗口会有单独的处理逻辑。
- 全局窗口（Global Windows）
这种窗口全局有效，会把相同 key 的所有数据都分配到同一个窗口中；说直白一点，就跟没分窗口一样。无界流的数据永无止尽，所以这种窗口也没有结束的时候，默认是不会做触发计算的。如果希望它能对数据进行计算处理，还需要自定义“触发器”（Trigger）。
全局窗口没有结束的时间点，所以一般在希望做更加灵活的窗口处理时自定义使用。Flink 中的计数窗口（
Count Window
），底层就是用全局窗口实现的。
3、窗口 API
（1）按键分区窗口（Keyed Windows）
经过按键分区 keyBy
操作后，数据流会按照
key
被分为多条逻辑流（
logical streams
），这
就是
KeyedStream
。基于
KeyedStream
进行窗口操作时
,
窗口计算会在多个并行子任务上同时执行。相同 key
的数据会被发送到同一个并行子任务，而窗口操作会基于每个
key
进行单独的处理。所以可以认为，每个 key
上都定义了一组窗口，各自独立地进行统计计算。
stream.keyBy(...)
.window(...)（2）非按键分区（Non-Keyed Windows）
如果没有进行 keyBy
，那么原始的
DataStream 就不会分成多条逻辑流，
只有一条逻辑流
。这时窗口逻辑只能在一个任务（task
）上执行，就相当于并行度变成了
1。所以在实际应用中一般不推荐使用这种方式。在代码中，直接基于
DataStream
调用
.windowAll()
定义窗口。
stream.windowAll(...)（3）窗口 API 的调用
窗口操作主要有两个部分：窗口分配器（Window Assigners
）和窗口函数（
WindowFunctions
）。
stream.keyBy(<key selector>)
.window(<window assigner>)
.aggregate(<window function>)4、窗口分配器
窗口分配器其实就是在指定窗口的类型。窗口按照驱动类型可以分成时间窗口和计数窗口，而按照具体的分配规则，又有滚动窗口、滑动窗口、会话窗口、全局窗口四种。标准的声明方式就是直接调用.window()，在里面传入对应时间语义下的窗口分配器。我们不需要专门定义时间语义，默认就是事件时间；如果想用处理时间，那么在这里传入处理时间的窗口分配器就可以了。
（1）滚动处理时间窗口
stream.keyBy(...)
.window(TumblingProcessingTimeWindows.of(Time.seconds(5)))
.aggregate(...)
// 得到北京时间每天 0 点开启的滚动窗口
// 只要设置-8 小时的偏移量就可以了：
.window(TumblingProcessingTimeWindows.of(Time.days(1), Time.hours(-8)))（2）滑动处理时间窗口
stream.keyBy(...)
.window(SlidingProcessingTimeWindows.of(Time.seconds(10), Time.seconds(5)))
.aggregate(...)（3）处理时间会话窗口
stream.keyBy(...)
.window(ProcessingTimeSessionWindows.withGap(Time.seconds(10)))
.aggregate(...)（4）滚动事件时间窗口
stream.keyBy(...)
.window(TumblingEventTimeWindows.of(Time.seconds(5))) .aggregate(...)（5）滑动事件时间窗口
stream.keyBy(...)
.window(SlidingEventTimeWindows.of(Time.seconds(10), Time.seconds(5)))
.aggregate(...)（6）事件时间会话窗口
stream.keyBy(...)
.window(EventTimeSessionWindows.withGap(Time.seconds(10)))
.aggregate(...)（7）滚动计数窗口
定义了一个长度为 10
的滚动计数窗口，当窗口中元素数量达到
10
的时候，就会触发计算执行并关闭窗口：
stream.keyBy(...)
.countWindow(10)（8）滑动计数窗口
与滚动计数窗口类似，不过需要在.countWindow()
调用时传入两个参数：
size
和
slide
，前
者表示窗口大小，后者表示滑动步长：
stream.keyBy(...)
.countWindow(10，3)（9）全局窗口
全局窗口是计数窗口的底层实现，一般在需要自定义窗口时使用。它的定义同样是直接调
用
.window()
，分配器由
GlobalWindows
类提供。
stream.keyBy(...)
.window(GlobalWindows.create());5、窗口函数
经窗口分配器处理之后，数据可以分配到对应的窗口中，而数据流经过转换得到的数据类型是 WindowedStream。这个类型并不是 DataStream，所以并不能直接进行其他转换，而必须进一步调用窗口函数，对收集到的数据进行处理计算之后，才能最终再次得到 DataStream。窗口函数定义了要对窗口中收集的数据做的计算操作，根据处理的方式可以分为两类：增量聚合函数和全窗口函数。
（1）增量聚合函数（incremental aggregation functions）
就像
DataStream
的简单聚合一样，每来一条数据就立即进行计算，中间只要保持一个简单的聚合状态就可以了；区别只是在于不立即输出结果，而是要等到窗口结束时间。等到窗口到了结束时间需要输出计算结果的时候，我们只需要拿出之前聚合的状态直接输出，这无疑就大大提高了程序运行的效率和实时性。 典型的增量聚合函数有两个：ReduceFunction
和
AggregateFunction
。
- 归约函数（ReduceFunction）
就是将窗口中收集到的数据两两进行归约。窗口函数中也提供了 ReduceFunction：只要基于 WindowedStream 调用
.reduce()方法，然后传入
ReduceFunction 作为参数，就可以指定以归约两个元素的方式去对窗口中数据进行聚合了。
stream.keyBy(r -> r.f0)
// 设置滚动事件时间窗口
.window(TumblingEventTimeWindows.of(Time.seconds(5)))
.reduce(new ReduceFunction<Tuple2<String, Long>>() {
@Override
public Tuple2<String, Long> reduce(Tuple2<String, Long> value1, Tuple2<String, Long> value2) throws Exception {
// 定义累加规则，窗口闭合时，向下游发送累加结果
return Tuple2.of(value1.f0,value1.f1+value2.f1);
}
}).print();- 聚合函数（AggregateFunction）
ReduceFunction
可以解决大多数归约聚合的问题，但是这个接口有一个限制，就是聚合状
态的类型、输出结果的类型都必须和输入数据类型一样。这就迫使我们必须在聚合前，先将数
据转换（
map）成预期结果类型；直接基于 WindowedStream 调 用
.aggregate()方法，就可以定义更加灵活的窗口聚合操作。这个方法需要传入一个
AggregateFunction 的实现类作为参数。
AggregateFunction
的工作原理是：首先调用
createAccumulator()
为任务初始化一个状态(
累加器
)
；而后每来一个数据就调用一次
add()
方法，对数据进行聚合，得到的结果保存在状态中；等到了窗口需要输出时，再调用 getResult()
方法得到计算结果。
// 使用AggregateFunction实现PV/UV
public static void main(String[] args) throws Exception {
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.setParallelism(1);
// 确定时间戳和水位线,取出字段中的时间戳
SingleOutputStreamOperator<Event> stream = env.addSource(new ClickSource())
.assignTimestampsAndWatermarks(WatermarkStrategy.<Event>forMonotonousTimestamps()
.withTimestampAssigner(new SerializableTimestampAssigner<Event>() {
@Override
public long extractTimestamp(Event event, long l) {
return event.timestamp;
}
}));
// 所有数据设置相同的key，发送到同一个分区内统计PV和UV，再相除
stream.keyBy(r -> "chris")
.window(SlidingEventTimeWindows.of(Time.seconds(10),Time.seconds(2)))
.aggregate(new AvgPV())
.print();
env.execute();
}
// 自定义 aggregate 方法
public static class AvgPV implements AggregateFunction<Event, Tuple2<HashSet<String>,Long>,Double> {
@Override
public Tuple2<HashSet<String>, Long> createAccumulator() {
// 创建累加器
return Tuple2.of(new HashSet<>(),0L);
}
@Override
public Tuple2<HashSet<String>, Long> add(Event event, Tuple2<HashSet<String>, Long> accumulator) {
// 属于本窗口的数据，来一条累加一条，并返回累加器
accumulator.f0.add(event.user);
return Tuple2.of(accumulator.f0,accumulator.f1+1L);
}
@Override
public Double getResult(Tuple2<HashSet<String>, Long> accumulator) {
// 窗口闭合时，增量聚合结束，将计算结果发送到下游
return (double) accumulator.f1 / accumulator.f0.size();
}
@Override
public Tuple2<HashSet<String>, Long> merge(Tuple2<HashSet<String>, Long> hashSetLongTuple2, Tuple2<HashSet<String>, Long> acc1) {
return null;
}
}（2）全窗口函数（full window functions）
全窗口函数需要先收集窗口中的数据，并在内部缓存起来，等到窗口要输出结果的时候再取出数据进行计算。很明显，这就是典型的批处理思路了——先攒数据，等一批都到齐了再正式启动处理流程，这样做毫无疑问是低效的。
那为什么还需要有全窗口函数呢？这是因为有些场景下，我们要做的计算必须基于全部的数据才有效，这时做增量聚合就没什么意义了；另外，输出的结果有可能要包含上下文中的一些信息（比如窗口的起始时间），这是增量聚合函数做不到的。
- 窗口函数（WindowFunction）
我们可以基于 WindowedStream
调用
.apply()
方法，传入一个
WindowFunction
的实现类。
stream
.keyBy(<key selector>)
.window(<window assigner>)
.apply(new MyWindowFunction());
不过我们也看到了，
WindowFunction
能提供的上下文信息较少，也没有更高级的功能。事实上，它的作用可以被 ProcessWindowFunction
全覆盖，所以之后可能会逐渐弃用。一般在实际应用，直接使用 ProcessWindowFunction
就可以了。
- 处理窗口函数（ProcessWindowFunction）
ProcessWindowFunction
是
Window API
中最底层的通用窗口函数接口。之所以说它“最底层”，是因为除了可以拿到窗口中的所有数据之外，ProcessWindowFunction 还可以获取到一个
“上下文对象”（Context
）。这个上下文对象非常强大，不仅能够获取窗口信息，还可以访问当前的时间和状态信息。
作 为 一 个 全 窗 口 函 数 ， ProcessWindowFunction 同样需要将所有数据缓存下来、等到窗口触发计算时才使用。
// 自定义窗口处理函数
public static class UvCountByWindow extends ProcessWindowFunction<Event, String, Boolean, TimeWindow>{
@Override
public void process(Boolean aBoolean, Context context, Iterable<Event> elements, Collector<String> out) throws Exception {
HashSet<String> userSet = new HashSet<>();
// 遍历所有数据，放到Set里去重
for (Event event: elements){
userSet.add(event.user);
}
// 结合窗口信息，包装输出内容
Long start = context.window().getStart();
Long end = context.window().getEnd();
out.collect("窗口: " + new Timestamp(start) + " ~ " + new Timestamp(end)
+ " 的独立访客数量是：" + userSet.size());
}
}（3）增量聚合和全窗口函数的结合使用
如果我们采用增量聚合的方式，那么只需要保存一个当前和的状态，每个数据到来时就会做一次加法，更新状态；到了要输出结果的时候，只要将当前状态直接拿出来就可以了。增量聚合相当于把计算量“均摊”到了窗口收集数据的过程中，自然就会比全窗口聚合更加高效、输出更加实时。
而全窗口函数的优势在于提供了更多的信息，可以认为是更加“通用”的窗口操作。它只负责收集数据、提供上下文相关信息，把所有的原材料都准备好，至于拿来做什么我们完全可以任意发挥。这就使得窗口计算更加灵活，功能更加强大。所以在实际应用中，我们往往希望兼具这两者的优点，把它们结合在一起使用。Flink
的Window API 就给我们实现了这样的用法。
我们之前在调用
WindowedStream
的
.reduce()
和
.aggregate()
方法时，只是简单地直接传入了一个 ReduceFunction
或
AggregateFunction
进行增量聚合。除此之外，其实还可以传入第二个参数：一个全窗口函数，可以是 WindowFunction
或者
ProcessWindowFunction
。
这样调用的处理机制是：基于第一个参数（增量聚合函数）来处理窗口数据，每来一个数据就做一次聚合；等到窗口需要触发计算时，则调用第二个参数（全窗口函数）的处理逻辑输出结果。需要注意的是，这里的全窗口函数就不再缓存所有数据了，而是直接将增量聚合函数的结果拿来当作了 Iterable
类型的输入。一般情况下，这时的可迭代集合中就只有一个元素了。
// 按照url分组，开滑动窗口统计
stream.keyBy(data -> data.url)
.window(SlidingEventTimeWindows.of(Time.seconds(10),Time.seconds(5)))
// 同时传入 增量聚合函数 和 全窗口函数
.aggregate(new urlCountAgg(),new urlCountResult())
.print();
// 自定义增量聚合函数，来一条数据就加一条
public static class urlCountAgg implements AggregateFunction<Event,Long,Long> {
@Override
public Long createAccumulator() {
return 0L;
}
@Override
public Long add(Event event, Long accumulator) {
return accumulator+1;
}
@Override
public Long getResult(Long aLong) {
return aLong;
}
@Override
public Long merge(Long aLong, Long acc1) {
return null;
}
}
// 自定义窗口处理函数，只需要包装窗口信息
public static class urlCountResult extends ProcessWindowFunction<Long,UrlViewCount,String, TimeWindow> {
@Override
public void process(String url, ProcessWindowFunction<Long, UrlViewCount, String, TimeWindow>.Context context, Iterable<Long> iterable, Collector<UrlViewCount> collector) throws Exception {
// 结合窗口信息，包装输出内容
Long start = context.window().getStart();
Long end = context.window().getEnd();
// 迭代器中只有一个元素，就是增量聚合函数的计算结果
collector.collect(new UrlViewCount(url,iterable.iterator().next(),start,end));
}
}
窗口处理的主体还是增量聚合，而引入全窗口函数又可以获取到更多的信息包装输出，这 样的结合兼具了两种窗口函数的优势，在保证处理性能和实时性的同时支持了更加丰富的应用场景。
6、其他 API
（1）触发器（Trigger）
触发器主要是用来控制窗口什么时候触发计算。所谓的“触发计算”，本质上就是执行窗口函数，所以可以认为是计算得到结果并输出的过程。
Trigger
是窗口算子的内部属性，每个窗口分配器（
WindowAssigner
）都会对应一个默认的触发器；对于 Flink
内置的窗口类型，它们的触发器都已经做了实现。例如，所有事件时间窗口，默认的触发器都是 EventTimeTrigger
；类似还有
ProcessingTimeTrigger
和
CountTrigger
。所以一般情况下是不需要自定义触发器的。
stream.keyBy(...)
.window(...)
.trigger(new MyTrigger())（2）移除器（Evictor）
移除器主要用来定义移除某些数据的逻辑。基于
WindowedStream
调用
.evictor()
方法，就可以传入一个自定义的移除器（Evictor
）。
stream.keyBy(...)
.window(...)
.evictor(new MyEvictor())
Evictor
接口定义了两个方法：
- evictBefore()：定义执行窗口函数之前的移除数据操作
- evictAfter()：定义执行窗口函数之后的以处数据操作
默认情况下，预实现的移除器都是在执行窗口函数（
window fucntions
）之前移除数据的。
（3）允许延迟（Allowed Lateness）
为了解决迟到数据的问题，
Flink
提供了一个特殊的接口，可以为窗口算子设置一个 “允许的最大延迟”（Allowed Lateness
）。也就是说，我们可以设定允许延迟一段时间，在这段时间内，窗口不会销毁，继续到来的数据依然可以进入窗口中并触发计算。直到水位线推进到了 窗口结束时间 +
延迟时间，才真正将窗口的内容清空，正式关闭窗口。
stream.keyBy(...)
.window(TumblingEventTimeWindows.of(Time.hours(1)))
.allowedLateness(Time.minutes(1))（4）将迟到的数据放入侧输出流
即使可以设置窗口的延迟时间，终归还是有限的，后续的数据还是会被丢弃。如果不想丢弃任何一个数据，又该怎么做呢？
Flink
还提供了另外一种方式处理迟到数据。我们可以将未收入窗口的迟到数据，放入“侧输出流”（side output
）进行另外的处理。所谓的侧输出流，相当于是数据流的一个“分支”，这个流中单独放置那些错过了该上的车、本该被丢弃的数据。基于 WindowedStream
用
.sideOutputLateData()
方法，就可以实现这个功能。方法需要传入一个“输出标签”（OutputTag
），用来标记分支的迟到数据流。因为保存的就是流中的原始数据，所以 OutputTag
的类型与流中数据类型相同。
DataStream<Event> stream = env.addSource(...);
OutputTag<Event> outputTag = new OutputTag<Event>("late") {};
winAggStream = stream.keyBy(...)
.window(TumblingEventTimeWindows.of(Time.hours(1)))
.sideOutputLateData(outputTag)
DataStream<Event> lateStream = winAggStream.getSideOutput(outputTag);7、窗口的生命周期
（1） 窗口的创建
窗口的类型和基本信息由窗口分配器（
window assigners
）指定，但窗口不会预先创建好，
而是由数据驱动创建。当第一个应该属于这个窗口的数据元素到达时，就会创建对应的窗口。
（2）窗口计算的触发
除了窗口分配器，每个窗口还会有自己的窗口函数（
window functions
）和触发器（
trigger
）。
窗口函数可以分为增量聚合函数和全窗口函数，主要定义了窗口中计算的逻辑；而触发器则是
指定调用窗口函数的条件。
（3）窗口的销毁
一般情况下，当时间达到了结束点，就会直接触发计算输出结果、进而清除状态销毁窗口。这时窗口的销毁可以认为和触发计算是同一时刻。这里需要注意，Flink
中只对时间窗口
有销毁机制；由于计数窗口
是基于全局窗口实现的，而全局窗口不会清除状态，所以就不会被销毁。
二、迟到数据的处理
所谓的“迟到数据”（
late data
），是指某个水位线之后到来的数据，它的时间戳其实是在水位线之前的。所以只有在事件时间语义下，讨论迟到数据的处理才是有意义的。
1、设置水位线延迟时间
水位线是事件时间的进展，它是我们整个应用的全局逻辑时钟。水位线生成之后，会随着数据在任务间流动，从而给每个任务指明当前的事件时间。
那一般情况就不应该把它的延迟设置得太大，否则流处理的实时性就会大大降低。因为水位线的延迟主要是用来对付分布式网络传输导致的数据乱序，而网络传输的乱序程度一般并不会很大，大多集中在几毫秒至几百毫秒。所以实际应用中，我们往往会给水位线设置一个“能够处理大多数乱序数据的小延迟”，视需求一般设在毫秒~
秒级。
当我们设置了水位线延迟时间后，所有定时器就都会按照延迟后的水位线来触发。如果一个数据所包含的时间戳，小于当前的水位线，那么它就是所谓的“迟到数据”。
2、允许窗口处理迟到数据
水位线延迟设置的比较小，那之后如果仍有数据迟到该怎么办？对于窗口计算而言，如果水位线已经到了窗口结束时间，默认窗口就会关闭，那么之后再来的数据就要被丢弃了。
在水位线到达窗口结束时间时，先快速地输出一个近似正确的计算结果；然后保持窗口继续等到延迟数据，每来一条数据，窗口就会再次计算，并将更新后的结果输出。这样就可以逐步修正计算结果，最终得到准确的统计值了。
将水位线的延迟和窗口的允许延迟数据结合起来，最后的效果就是先快速实时地输出一个近似的结果，而后再不断调整，最终得到正确的计算结果。回想流处理的发展过程，这不就是著名的Lambda
架构吗？原先需要两套独立的系统来同时保证实时性和结果的最终正确性，如今 Flink
一套系统就全部搞定了。
3、将迟到数据放入窗口侧输出流
即使我们有了前面的双重保证，可窗口不能一直等下去，最后总要真正关闭。窗口一旦关 闭，后续的数据就都要被丢弃了。那如果真的还有漏网之鱼又该怎么办呢？
那就要用到最后一招了：用窗口的侧输出流来收集关窗以后的迟到数据。这种方式是最后“兜底”的方法，只能保证数据不丢失；因为窗口已经真正关闭，所以是无法基于之前窗口的结果直接做更新的。我们只能将之前的窗口计算结果保存下来，然后获取侧输出流中的迟到数据，判断数据所属的窗口，手动对结果进行合并更新。尽管有些烦琐，实时性也不够强，但能够保证最终结果一定是正确的。
所以总结起来，
Flink
处理迟到数据，对于结果的正确性有三重保障：水位线的延迟，窗口允许迟到数据，以及将迟到数据放入窗口侧输出流。
// 处理迟到数据的综合案例
public static void main(String[] args) throws Exception {
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.setParallelism(1);
// 读取socket文本流
SingleOutputStreamOperator<Event> stream = env.socketTextStream("localhost", 7777)
.map(new MapFunction<String, Event>() {
@Override
public Event map(String value) throws Exception {
String[] fields = value.split(" ");
return new Event(fields[0].trim(), fields[1].trim(), Long.valueOf(fields[2].trim()));
}
})
// 方式一：设置watermark延迟时间，2秒钟
.assignTimestampsAndWatermarks(WatermarkStrategy.<Event>forBoundedOutOfOrderness(Duration.ofSeconds(2))
.withTimestampAssigner(new SerializableTimestampAssigner<Event>() {
@Override
public long extractTimestamp(Event element, long recordTimestamp) {
return element.timestamp;
}
}));
// 定义侧输出流标签
OutputTag<Event> outputTag = new OutputTag<Event>("late"){};
SingleOutputStreamOperator<UrlViewCount> result = stream.keyBy(data -> data.url)
.window(TumblingEventTimeWindows.of(Time.seconds(10)))
// 方式二：允许窗口处理迟到数据，设置1分钟的等待时间
.allowedLateness(Time.minutes(1))
// 方式三：将最后的迟到数据输出到侧输出流
.sideOutputLateData(outputTag)
.aggregate(new UrlViewCountAgg(), new UrlViewCountResult());
result.print("result");
result.getSideOutput(outputTag).print("late");
// 为方便观察，可以将原始数据也输出
stream.print("input");
env.execute();
}
public static class UrlViewCountAgg implements AggregateFunction<Event, Long, Long> {
@Override
public Long createAccumulator() {
return 0L;
}
@Override
public Long add(Event value, Long accumulator) {
return accumulator + 1;
}
@Override
public Long getResult(Long accumulator) {
return accumulator;
}
@Override
public Long merge(Long a, Long b) {
return null;
}
}
public static class UrlViewCountResult extends ProcessWindowFunction<Long, UrlViewCount, String, TimeWindow> {
@Override
public void process(String url, Context context, Iterable<Long> elements, Collector<UrlViewCount> out) throws Exception {
// 结合窗口信息，包装输出内容
Long start = context.window().getStart();
Long end = context.window().getEnd();
out.collect(new UrlViewCount(url, elements.iterator().next(), start, end));
}
}
907
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
