本文是日本川崎的富士通实验室发表于2020 IEEE/ACM Fifth International Conference on Internet-of-Things Design and Implementation (IoTDI)的一篇会议文章,也是关于流处理引擎中延迟数据处理问题的。
INTRODUCTION
有许多real-time物联网应用程序高度依赖于事件发生的顺序,例如从联网的汽车接收输入信息的自动事故原因分析,以及智能交通系统在交通事故发生的瞬间对事件发生顺序的关注(比如,是某辆车先进入人行道然后指示灯变红,还是指示灯先变色再驶入人行道?)。尽管有很多这样的需求,但是在许多情况下,事件消息从设备到达数据中心的事件处理系统的顺序并不是按时间顺序排列的,原因有几个,例如,由于暂时网络拥塞,事件消息到达的顺序倒排或由分布式系统导致的输入乱序。因此这样的处理系统需要对到达的事件消息进行缓冲、排序最后进行处理。
在这里,系统需要考虑预留多长时间来缓冲到达的信息。如果时间窗口(缓冲时间)太大,它可以保证顺序的正确,但是会导致高延迟。此外,部署在分布式节点中的有状态流处理的故障恢复机制让这个问题更加困难。有状态的故障恢复流处理系统包括:恢复保存点状态、恢复故障时刻的上游消息队列。在恢复过程中,队列中的事件信息将被高速处理,而不考虑其事件时间,这将导致最快处理节点和最慢处理节点处理的事件时间之差变大。它经常在分布式数据流中导致大规模时序颠倒,这无法用为实时处理而设计的缓存机制来处理,因为这一机制假定到来的信息的事件时间和现实中是同一进度。
本文引入了一种新的技术来自适应地确定最小必要缓冲时间,以保证在事件时间进度的基础上对信息进行排序。更精确地说,本方法不是改变实际缓冲时间,而是自适应地控制最小时间间隔,以确定当前的watermark。在该技术中,事件时间的进度是由摄入时间和最近到达的信息的事件时间一起计算得到的,并且根据事件时间的标准差分布来估测是否以及接收到了所有的信息。因为本技术从最近到达的消息中获得事件时间的进展,因此可以处理失败恢复。
本文的第二个贡献是,基于watermark技术,在我们开发的SPE平台“dracena”中,我们开发了一个完整的功能来进行排序并且保持低延时,它是通过flink实现的。
PROBLEM DESCRIPTION
A.Assumptions
首先,我们有如下假设:
- 集中式系统:信息被发送到一个集中的地方进行处理
- 时间戳的精度合理:每个数据源设备都有一个准确且同步良好的时钟并将事件时间放在每个消息里
- 事件到达率高:假设有大量的活动设备(如,100万辆联网的汽车正在行驶),并且每个设备都周期性地发送事件数据。
- 有状态流处理:在流处理中保存每个设备的状态,以便后续查询历史数据。
B.Motivating Case
为了解释我们的研究动机,下面展示实际上发生了多少时间顺序反转。
上图显示了在联网汽车应用中实时处理和故障恢复场景中的时序反转率。应用程序以pipeline的形式通过三个阶段处理事件消息。stage-0处理来自物联网设备的数据,stage1和2使用上游的消息进行聚合处理。在每个阶段之前,可以通过网络传输信息,以便在正确的节点上进行处理。时序反转率表示,新到来的数据携带了比最近一个消息的事件时间戳更早,这样的消息在所有消息中的占比。
应注意以下几点。
- 事件时间反转发生在stage1和2的实时处理期间,这两个阶段对来自多个对象的事件消息进行聚合处理。
- 在恢复过程中,各阶段事件时间反转率都在95%以上。特别的是,即便是在stage0,也会发生反转。
结果表明,即使是在实时处理中,也会发生时序颠倒,并且在恢复过程中,大多数事件消息都没有按照事件时间顺序处理。在这种情况下,严重依赖于事件发生顺序的应用程序需要对消息进行排序来生成预期的结果。
C.Cause of Time-order Reversal
下文讨论了两种不同类型的时序反转并对其原因进行了描述。
- 事件生成时间和处理时间之差:这种时间顺序反转主要发生在实时处理期间,受到各种因素影响,且每个事件消息的时间差各不相同,以下是典型因素:
- 物联网设备和数据处理节点的物理距离
- 物联网设备可能会在短暂地缓存一会之后再发送消息
- 数据等待处理的时间,取决于资源可用性如CPU利用率。在这种情况下,时间延迟在各个流处理节点中有很大不同。
- 由于在事件流上游的处理时间,延迟进一步加大。
- 处理路径的不同产生的时滞。
- 分布式系统中的故障恢复方法:在故障恢复过程中,队列中的消息会被高速的重新读取,并且会发生大的事件时间反转。我们会在后文详细解释。在实时处理中,流处理中的时间进度基本上遵循现实世界中产生事件消息的时间进度。另一方面,当在恢复中重新读取队列中的消息时,消息的事件时间顺序被完全忽略。
D.Failure Recovery in Distributed Event Stream Processing
略
E.Difficulties on Determing Watermark
略
ADAPTIVE WATERMARK DETERMINATION TECHNIQUE
A.Basic Idea
计算watermark的要求如下:
- 不知道事件时间和到达时间之间的差异
- 相应上述时差的动态变化
- 既支持实时处理也支持故障恢复。在故障恢复中,上述时间差变大,动态变化变快,事件时间的进度与现实世界的时间进度相差很大。
上图展示了我们设计的Adaptive watermark技术,其基本思想是,不再用一个固定的预定义时间间隔来从到达消息的事件时间中确定watermark,而是根据最近到达的事件消息中事件时间的分布而自适应地确定的。
首先,为了得到到达消息的事件时间进度的平均速度,在每个水印生成周期中计算平均事件时间,并通过最小二乘法得到过去几个周期的平均事件时间的线性近似方程(图中红线),作为事件时间进度的参考线;
其次,在当前watermark生成周期内(红色区域),对该周期内每个事件消息计算事件时间到参考线的残差。
最后,基于均值 (μ) 和方差(θ)的置信区间,推导出周期内的第99个百分位点作为新watermark(星星标记)
由于我们获得了事件时间的进度和事件时间与最近到达消息的到达时间之间的差值变化,因此在故障恢复的时候可以处理大的更改而无需任何前置的知识。此外,线性近似方程的估计是在适度数量的样本下进行的,因此周期总长度足够短,以快速响应事件时间进程的动态变化。
算法描述如下
——————————————————————————————————————————————————————
算法1 自定义水印生成器
——————————————————————————————————————————————————————
Input: preconfigured parameters
X:计算回归线的周期次数
Y:置信区间范围
Δt:水印生成的间隔
Output:generate watermarks
/*初始化*/
avgAT,avgET ← queue(sizeX) //计算平均到达时间和平均事件时间
AT,ET ← list //一轮循环中的到达数据的到达时间和事件时间
residuals ← list //计算残差
nextWatermarkTime ← currentTime + Δt //下一个水印生成时间
/*主程序*/
repeat until the end of stream processing
sleep until(nextWatermarkTime || message arrives)
if (currentTime ≥ nextWatermarkTime) then
nextWatermarkTime = currentTime + Δt
/*用最小二乘法计算回归线*/
estimateET(t) ← Least-Square(t)
/*更新平均list*/
avgAT.append(average(AT))
avgET.append(avergae(ET))
if avgAT.size > X then
avgAT.removeFirst()
avgET.removeFirst()
end if
/*计算残差*/
for each ta and te in AT and ET do
residual ← estimateET(ta)-te //a是arrival,e是event
residuals.append(residual)
end for
μ,σ ← upperEndpoint(residuals,Y)
margin ← μ + 2.58σ
wmTime ← estimateET(currentTime) - margin
generateWatermark(wmTime)
clear all elements in AT,ET,residuals
end if
if(new event message arrives) then
AT.append(currentTime)
ET.append(arrivedMessage.eventTime)
end id
end repeat
- Least-Square(t)方法用最小二乘法返回一个二元一次方程。
- upperpoint(list,α)返回总体均值和总体方差上α置信区间的上端点,假设list是正态分布
- 2.58是99百分位点的z值
代码块已经对算法描述的比较详细了,后面是测试,我就不翻译了,当然还是很棒棒啦