对于流处理引擎来说,处理延迟到达的事件是至关重要的功能。 解决这个问题的方法是加水位线的概念。 从Spark 2.1开始,结构化流API就支持它。
什么是水位线?
加水位线是一种有用的方法,可帮助流处理引擎处理延迟。 基本上,水印是一个阈值,用于指定系统等待延迟事件的时间。 如果到达事件位于水位线之内,它将用于更新查询。 否则,如果它早于水位线,它将被丢弃,并且流引擎不会对其进行进一步处理。
![cd0f6ed18bc4a0cf008524fe5ed89b8b.png](https://i-blog.csdnimg.cn/blog_migrate/d7c30c7b8932a6a5f3101a9bbff33f23.jpeg)
> Flooding watermarks
如何使用它?
自Spark 2.1起,水位线被引入到结构化流API中。 您可以通过将withWatermark-Operator添加到查询中来启用它:
withWatermark(eventTime:String,delayThreshold:String):数据集[T]
它需要两个参数,a)一个事件时间列(必须与聚合正在处理的列相同)和b)一个阈值,用于指定应处理多长时间的延迟数据(以事件时间为单位)。 然后,Spark将维持聚合状态,直到max eventTime — delayThreshold> T,其中max eventTime是引擎看到的最新事件时间,T是窗口的开始时间。 如果后期数据落入此阈值之内,则查询将最终得到更新(下图中的右图)。 否则,它将被丢弃,并且不会触发任何重新处理(下图中的左图)。
![dd5e165486cfa441c3d7e4503ab46994.png](https://i-blog.csdnimg.cn/blog_migrate/4be47cd5fb85f22a68dbaa63d0ba85e1.jpeg)
![78a111bf9246e20c57abbb7b304d08a1.png](https://i-blog.csdnimg.cn/blog_migrate/65c2df1661ead9386ebfb7fb659a66ae.jpeg)
> Late donkey in structured word count: event dropped (left), event within watermark updates Window
值得一提的是,查询的输出模式必须设置为"追加"(默认)或"更新"。完全模式不能与设计中的水印结合使用,因为它需要所有 要保存的数据,用于将整个结果表输出到接收器。
可以在这里找到如何在简单的Spark结构化流应用程序中使用该概念的快速演示-它是字数统计(对NLP进行了一些小的增强),还有其他:D
但是,为什么我要关心?
在分布式和联网的系统中,总会有中断的机会-节点故障,传感器丢失连接等等。 因此,不能保证数据将按创建顺序到达流处理引擎。 为了容错,因此有必要处理此类乱序数据。
为了解决此问题,必须保留聚合状态。 如果发生延迟事件,则可以重新处理查询。 但这意味着所有聚合的状态必须无限期地保持,这也导致内存使用量也无限期地增长。 除非系统具有无限的资源(即无限的预算),否则在现实世界中这是不切实际的。 因此,加水位线是一个有用的概念,可以通过设计约束系统并防止其在运行时爆炸。
参考文献
结构化流编程指南,Jacek Laskowski编写的Spark结构化流书,databricks博客,madhu张贴,vishnu viswanath张贴,waitingforcode张贴,Knoldus博客,SoftwareMill博客。
(本文翻译自Thomas Treml的文章《Watermarking in Spark Structured Streaming》,参考:https://towardsdatascience.com/watermarking-in-spark-structured-streaming-9e164f373e9)