点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！
基于event-time的窗口操作
Event-time就是事件产生的时间而不是spark接受到消息的时间，在结构化数据流模型中，产生一个事件就是一行数据，event-time就是行中的一列，这就允许基于event-time的窗口聚合操作，每个窗口都是一个组，每行数据可以属于多个窗口，因此基于事件窗口的聚合查询可以适用于静态表和数据流。
此外，结构化数据流模型很自然的处理基于event-time的延迟数据，因为spark是更新结果表，只要延迟数据到达就会删除旧状态进行更新，自spark2.1以后可以使用水印（watermark）指定延迟数据阙值清除旧状态。
想象这样一种场景，spark不断接受输入，然后进行词频统计，输入包括词语和词语产生时间，我们要统计每10分钟之内的词频统计，每5分钟统计一次，模型如下：
如图可知时间步长是5分钟（每5分钟统计一次）每次统计的是10分钟之内的数据，应用程序12:00启动，开始接受数据，12:00-12:05时间内接到两条数据（产生时间分别是12:02和12:03），到12:05时开始第一次统计数据，统计的是12:00-12:10之间接受到的数据，然后12:05-12:10时间内接受到一条数据（产生时间为12:07），12:10时第二次统计数据，统计的是12:05-12:15之间接受到的数据，请注意12:07这条数据也属于12:00-12:10分窗口中的数据，所以更新了上一个窗口的数据，也新增了新窗口的数据，最后12:10-12:15时间内接受到了两条数据（产生时间分别为12:11,12:13），12:15进行了第三次窗口统计，同样最后两条数据不仅属于12:05-12:15窗口也属于12:10-12:20窗口，所以接受的这两条数据更新了12:05-12:15窗口的结果也新增了12:10-12:20窗口数据。
代码中可以这样写：
现在想象一下，如果某条数据产生时间是12:04，但是spark接受到该条数据时间是12:11，这就属于迟到数据，正常情况下该条数据到达时间与产生时间基本一致，对于这种迟到数据结构化数据模型会保持这种迟到数据再内存中，所以该条数据还是按照12:04来处理的。
但是这也存在一个问题，假如应用程序需要长时间运行，那么内存中会保存大量这种迟到数据状态，所以系统就需要迟到何时应该丢弃迟到数据，为了解决这个问题，自spark2.1，引入了watermarking，你可以通过指定event-time列并且指定数据可以迟到时间阙值，迟到时间在阙值以内，watermarking依然会将其按照正确时间处理，迟到时间在阙值之外会将其丢弃。
通过一下例子进行理解：
如上指定event time列timeStamp,并且指定了迟到时间阙值为10分钟。此查询模式为Update。所以结果表中将保持更新的状态。
蓝色虚线：目前为止可以看到的最大event-time。
红色实线：watermarking线=蓝色虚线（最大event-time）-阙值，水印值只能增加，不能减小。
当观察到12:04数据时，将下一个水印设置为12:04，此水印可以保持10分钟的中间状态，以便对于较晚的数据进行计数，例如对于12:09这条数据的延迟，其仍在12:04水印线之前，所以仍保持其中间状态，但是当观察到12:21数据时，水印更新为12:11，并将12:00-12:05窗口的中间状态清除，这时12:04的数据就会被丢弃，可以这样说，蓝色线和红色线中间的数据都不会被丢弃，水印线之下的数据都会被丢弃。
然后再来看下在Update输出模式下，每次触发后哪些数据会被输出：
12:05分第一次触发后，未观察到数据。
12:10分第二次触发时有两条数据（12:07dog,12:08:owl），这两条数据分别属于两个窗口，12:00-12:10和12:05-12:15,（如图）此时，这些数据都会被输出。
12:15第三次触发后，又观察到两条新数据（12:09cat，12:14dog），其中12:09cat数据属于窗口12;00-12:10和12:05-12:15，可以看到这两个窗口分别新增了一条数据cat（如上图），12:14dog数据属于窗口12:05-12:15和窗口12:10-12:20，所以12:05-12:15窗口dog计数+1,12:10-12:20窗口新增一条dog计数，此时这些更新的和新增的数据将是被输出的（紫色的）。
12:20第四次触发后，此时观察到新增数据有4条（12:08dog，12:13owl，12:15cat，12:21owl）,12:08dog数据属于窗口12:00-12:10和12:05-12:15，所以这两个窗口dog计数+1，12:13owl属于窗口12:05-12:15和12:10-12:20,所以12:05-12:15窗口owl计数+1，12:10-12:20窗口新增一条owl计数，12:15cat属于12:05-12:15和12:10-12:20窗口，所以12:05-12:15窗口cat计数+1，12:10-12:20窗口新增一条cat计数，12:21owl属于12:15-12:25和12:20-12:30窗口，所以这两个窗口新增一条owl计数（图中未标识出 ），此时，这些更新和新增数据将会被输出（如图紫色部分）。
12:25第五次触发时观察到12:04donkey数据（该数据太迟被丢弃，不参与计数）和其他1条数据（12:17owl），12:17owl属于12:10-12:20和12:15-12:25窗口，所以12:10-12:20窗口owl计数+1，12:15-12:25窗口owl计数+1（图中未标识出），此时这些更新数据将会被输出。
再来看下Append输出模式下，该模式下仅将最终数据写入存储器，如图：
例如12:25触发时，很明显12:00-12:10窗口的数据已经确定（水印线值大于窗口endtime），不可能再接受event time在12:00-12:10之间的数据了（太迟的数据会被丢弃），此时窗口计数如图，这也是第一次进行输出。
12:30时12:05-12:15窗口计数已经确定，如图，这次输出的是图中紫色部分。每次输出一个窗口的计数。请注意设置水印后只支持append和Update模式。
使用水印清除中间状态条件
输出模式必须是Append，Update，因为complete模式需要保留所有聚合数据。
聚合必须有event-time列或者event-time列的窗口。
水印作用的列必须与聚合列保持一致，例如df.withWatermark("time", "1 min").groupBy("time2").count()对于Append模式不可用。
水印函数调用必须在聚合函数之前。df.groupBy("time").count().withWatermark("time", "1 min")不可用。
水印聚合语义保证
水印延迟（设置为withWatermark）为“ 2小时”，确保引擎永远不会丢弃任何少于2小时的数据。换句话说，任何在此之前处理过的最新数据比事件时间少2小时（以事件时间计）的数据都可以保证得到汇总。
保证仅在一个方向上严格。延迟超过2小时的数据不能保证被删除；它可能会或可能不会聚合。数据延迟更多，引擎处理数据的可能性越小。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/129472.html
摘要：基于云迁移的三个阶段细分为八个主要步骤，评估阶段主要包括项目启动现状梳理以及应用系统关联关系分析三个步骤，设计阶段包括云架构优化设计和云迁移方案设计，实施阶段包括目标架构迁移演练及实施和试运行三个步骤。 在云计算市场规模不断扩大的大背景下，云迁移的需求越来越大且面临挑战。云迁移不是一个迁移软件工具，而是一种服务。前IBM资深架构师姜亚杰从云迁移的三个阶段、四个维度到八个步骤的方法，简述...
摘要：理解数组实现的滑动窗口，看下边这个图就可以了。第秒，开始计数，此时数组内开始存入计数周期，保存在数组第个位置，表示这是当前滑动窗口内的第个计数周期。在FireflySoft.RateLimit之前的版本中，进程内滑动窗口的实现是基于MemoryCache做的，虽然能够正确的实现滑动窗口的算法逻辑，但是性能比较差，其吞吐量只有其它算法的1/4。性能为何如此之差呢？滑动窗口的原理我们先来看下滑动...
摘要：两个浏览器窗口间通信总结一个窗口更新，另一个窗口监听对象的事件，来实现通信。通过窗口的属性来指定哪些窗口能接收到消息事件，其值可以是字符串表示无限制或者一个。父窗口先打开一个子窗口，载入一个不同源的网页，该网页将信息写入属性。 两个浏览器窗口间通信总结 1、localStorage 一个窗口更新localStorage，另一个窗口监听window对象的storage事件，来实现通信。注...
摘要：代码实现代码实现接下来思考一个熔断器如何实现。同时熔断器的状态也需要依靠指标统计来实现可观测性，我们实现任何系统第一步需要考虑就是可观测性，不然系统就是一个黑盒。可能是，熔断器需要实时收集此数据。熔断方法，自动上报执行结果自动挡。。。为什么需要熔断微服务集群中，每个应用基本都会依赖一定数量的外部服务。有可能随时都会遇到网络连接缓慢，超时，依赖服务过载，服务不可用的情况,在高并发场景下如果此时...
摘要：你只可以看到在滑动窗口内的数字。滑动窗口每次只向右移动一位。返回滑动窗口最大值。算法思路暴力破解法用两个指针，分别指向窗口的起始位置和终止位置，然后遍历窗口中的数据，求出最大值向前移动两个指针，然后操作，直到遍历数据完成位置。 Time：2019/4/16Title: Sliding Window MaximumDifficulty: DifficultyAuthor: 小鹿 题目...
阅读 1235·2023-01-11 13:20
阅读 1543·2023-01-11 13:20
阅读 996·2023-01-11 13:20
阅读 1652·2023-01-11 13:20
阅读 3958·2023-01-11 13:20
阅读 2456·2023-01-11 13:20
阅读 1290·2023-01-11 13:20
阅读 3454·2023-01-11 13:20
