在GroupBy中将密钥标记为完成|数据流流媒体管道

Question

对于我们的Streaming管道，我们要提交唯一的GCS文件，每个文件包含多个事件信息，每个事件还包含一个键（例如， device_id ）。作为处理的一部分，我们希望通过此 device_id 进行随机播放，以便实现某种形式的 worker to device_id 亲和关系（有关我们为什么要这样做的更多背景信息是this another SO question。一旦来自同一文件的所有事件都完成，我们希望通过源GCS文件减少（GroupBy）（我们将创建事件本身的属性，例如 file_id ）最后将输出写入GCS（可能是多个文件）。

我们想要进行最终GroupBy的原因是因为我们希望在特定输入文件完成处理后通知外部服务。这种方法的唯一问题是，由于数据由 device_id 进行混洗，然后由 file_id 在最后进行分组，因此无法保证所有数据来自特定的 file_id 已完成处理。

我们能做点什么吗？我理解Dataflow提供 exact_once 保证，这意味着所有事件最终都会被处理，但是有没有办法设置确定性触发器来说明特定键的所有数据都已分组？

修改 我想强调我们在这里面临的更广泛的问题。标记的能力  文件级完整性将帮助我们检查外部消费者看到的数据的不同阶段。例如，

• 这将允许我们触发每小时或每天完整性，这对我们生成该窗口的报告至关重要。鉴于这些阶段/障碍（小时/天）在输入上明确定义（GCS文件是日期/小时分区），因此期望输出相同是很自然的。但是使用Dataflow的模型，这似乎是不可能的。
• 同样，虽然Dataflow保证完全一次，但是有些情况需要重新启动整个管道，因为出现了可怕的错误 - 在这种情况下，几乎不可能从正确的地方重新启动输入标记，因为无法保证已经消耗的内容已被完全清除。 DRAIN 模式尝试实现此目的，但如上所述，如果整个管道混乱并且排水本身无法取得进展，则无法知道源的哪个部分应该是起点。 / LI>

我们正在考虑使用 Spark ，因为它的基于微批处理的Streaming模型似乎更合适。如果可能的话，我们仍然希望探索Dataflow，但似乎如果不在应用程序内部存储这些检查点，我们就无法实现它。如果有另一种方法可以从Dataflow提供这些保证，那就太好了。扩大这个问题背后的想法是看看我们是否缺少可以解决我们问题的替代观点。

由于

Answer 1

这实际上很棘手。 Beam和Dataflow都没有每个密钥水印的概念，并且很难实现这种级别的粒度。

一个想法是使用有状态DoFn而不是第二个shuffle。此DoFn需要接收文件中预期的元素数（来自侧输入或主输入上的某些特殊值）。然后它可以计算它已处理的元素数量，并且只有在看到元素数量后才输出已经处理完所有元素。

这可以假设可以提前确定预期的元素数量等等。