【问题标题】:How are Dataflow bundles created after GroupBy/Combine?在 GroupBy/Combine 之后如何创建 Dataflow 捆绑包?
【发布时间】:2019-03-09 08:38:28
【问题描述】:

设置:

从 pubsub 读取 -> 30 秒窗口 -> 按用户分组 -> 组合 -> 写入云数据存储

问题:

我看到 DataStoreIO 写入器错误,因为具有相似键的对象存在于同一事务中。

问题:

  1. 我想了解我的管道在 group by/combine 操作之后如何将结果组合成包。我希望在合并后为每个窗口创建捆绑包。但显然,一个捆绑包可以包含超过 2 次出现的同一用户?

  2. 重新执行(重试)捆绑包会导致此行为吗?

  3. 此捆绑是否依赖于跑步者?

  4. 是否可以选择重复数据删除?如果是这样,我将如何最好地解决这个问题?

请注意,我不是在寻找管道末端的数据存储写入器的替代品,我已经知道我们可以使用不同的策略。我只是想了解捆绑是如何发生的。

【问题讨论】:

  • 啊,这是一个很好的问题。 TBH 我不知道,但我会尽我所能找到一个在这里做的人。
  • 非常感谢@pablo! :)
  • 抱歉耽搁了。明天会尝试得到一些东西!
  • 好的,我四处打听。我希望答案是有帮助的。

标签: google-cloud-dataflow apache-beam


【解决方案1】:

您的问题有两个答案。一个特定于您的用例,另一个通常是关于流中的捆绑/窗口化。


特定于您的管道

我假设 Datastore 的“键”是用户 ID?在这种情况下,如果您在多个窗口中拥有来自同一用户的事件,则您的 GroupByKeyCombine 操作将为每一对用户+窗口具有一个单独的元素。

所以问题是:您要向数据存储区插入什么?

  • 单个用户的结果汇总所有时间?在这种情况下,您需要使用全局窗口。
  • 用户每 30 秒的聚合结果?然后,您需要将该窗口用作用于插入数据存储区的密钥的一部分。这有帮助/有意义吗?

很高兴帮助您设计您想要做的事情的管道。在 cmets 或通过 SO 聊天与我聊天。


关于数据捆绑的更大问题

捆绑策略因跑步者而异。在 Dataflow 中,您应该考虑以下两个因素:

  • 每个工作人员都分配了一个键范围。相同键的元素将由相同的工作人员处理。
  • 窗口属于单个元素;但一个包可能包含来自多个窗口的元素。例如,如果 数据新鲜度 指标大幅提升*,可能会触发多个窗口 - 不同窗口中相同键的元素 将在同一个包中处理

*- 数据新鲜度什么时候可以突然跳跃?具有非常旧时间戳的单个元素且处理速度非常慢的流可能会长时间保留水印。一旦处理了这个元素,水印可能会跳很多,到下一个最旧的元素 (Check out this lecture on watermarks ; ))。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-03-13
    • 1970-01-01
    • 2012-06-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多