首页 > 解决方案 > 当写入接收器时必须保留事件时间顺序时,apache-beam 是一个不错的选择吗?

问题描述

我正在考虑使用 apache Beam 编写流式管道以应用突变流以按事件时间的顺序将事件从源数据库复制到目标数据库。来源可以是 kafka 或 pubsub。

一个例子是这样的,除了将突变应用于接收器的顺序必须是它们到达的顺序。

我确实回顾了一些关于保留顺序的先前问题:

我知道如果我沿着 apache 梁路走,我将不得不

  1. 选择一个可以适应延迟数据的窗口策略(具有允许延迟或全局窗口的固定窗口策略,有触发器来为延迟数据发出窗格和缓冲区)
  2. 应用转换
  3. GroupByKey 在单个键上(以便一切都转到同一个工作人员),排序并写入接收器

除了上述之外,我还必须确保窗口​​(如果我遵循固定窗口策略)按顺序执行。第 3 步必然是瓶颈。

如果上面的步骤列表中的 [2] 需要大量计算,那么 apache Beam 将有意义地利用 beam 提供的并行性。但是,如果 [2] 只是一个简单的一对一映射,那么 apache Beam 对于这个复制用例是否有意义。如果我遗漏了什么,请告诉我。

注意:我们在数据流上有一个批处理管道,使用 apache Beam 将 gcs 上的数据转储加载到数据库中,其中整个数据都在磁盘上,写入接收器的顺序无关紧要。

标签: google-cloud-dataflowapache-beam

解决方案


保持秩序是可能的,但不确定它是否简单或有效。

它还取决于您期望的数据量(元素/秒)以及接收器类型是什么。潜在地,您可以让管道将有序条目写入 GCS,而接收器只是按顺序读取文件,作为辅助进程。

您的另一个选择是使用并行写入并确保数据库仅在最后一个梁阶段的输出水印时间之前可用,这可能是可行的,但并不是 Dataflow/Apache Beam 的核心用例。

也许有办法无序处理流,但写入一个可以轻松按顺序读取的中间接收器。即写出带有步骤或文件编号的突变批次,当应用于最终接收器时,可以轻松地用于对文件进行排序。

窗口 + 写入最终接收器架构将很难正确处理,可能对于少量元素来说太复杂,而对于大量元素来说效率太低。是一个很好的例子。

但同样,请记住,所有这些方法绝对不是 Dataflow/Apache Beam 的核心用例。


推荐阅读