【问题标题】:Dataflow override processing time数据流覆盖处理时间
【发布时间】:2016-02-17 08:47:28
【问题描述】:

有没有办法覆盖数据流中的处理时间(不是事件时间)?

我正在尝试推理失败场景,以及如何重新计算管道的输出。

假设我有一个管道,它只计算接收到的事件,固定窗口为 1 小时,允许迟到 2 小时。假设我对窗口 [t0, t0+1h) 感兴趣,并说我有:

  • 事件A,事件时间=t0+10m,处理时间=t0+30m
  • 事件 B,事件时间 = t0+10m,处理时间 = t0 + 90m

然后对事件A进行计数,丢弃事件B。

现在,假设几天后我​​在代码中发现了一个错误,我想重新运行管道以重新计算过去同一窗口 [t0, t0+1h) 中的事件。 如果处理时间现在 = t0 + 几天,则所有事件都将被丢弃。

如果我忽略允许的延迟(假设无限期),那么事件 A 和 B 都会被计算在内。

通过覆盖处理时间(假设我第一次存储它),我可以确保事件 A 被计算在内,而事件 B 不被计算在内。有没有办法做到这一点?谢谢!

【问题讨论】:

    标签: google-cloud-dataflow


    【解决方案1】:

    处理时间是元素到达系统进行处理的时间。水印跟踪我们在输入流中相对于元素的事件时间的位置。

    水印通常只是一种启发式方法,因此当它出错并且出现比预期更早的元素时,这些元素将被标记为延迟。水印可能会落后于处理时间,因此元素可能会在延迟后到达,但仍不会被标记为延迟。例如,如果用户正在玩手机游戏,则水印可能会针对导致多个延迟事件的大型网络减速进行调整。在这种情况下,实际上没有元素可能被认为是迟到的。但是水印不会针对偶尔在离线模式下玩游戏的用户进行调整,因此这可能会导致数据延迟。有关水印和数据流模型的有用背景信息,请参阅这些文章:Streaming 101Streaming 102

    如果无限源支持重放过去的事件,系统第二次可能会获得更好的水印,因此第一次标记为延迟的内容不太可能仍然被标记为延迟。

    我不太确定您要保证什么,但您可以让您的管道读取输入,然后写入数据副本,其中包括事件时间、处理时间以及元素是否考虑晚了。例如,TriggerExample 将大量此类信息写入 BigQuery 以演示其工作原理。然后,如果您需要准确地重新处理它,您可以运行一个从副本中读取并执行回填的批处理管道。 (这就是统一批处理+流式编程模型的好处!)

    【讨论】:

    • 非常感谢弗朗西斯,我阅读了博客文章,这就是最初的困惑所在。 TriggerExample 确实说明了很多。
    猜你喜欢
    • 1970-01-01
    • 2018-06-26
    • 1970-01-01
    • 2015-09-25
    • 2013-05-16
    • 2019-06-21
    • 2012-04-29
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多