【问题标题】:apache beam stream processing failure recoveryapache 束流处理故障恢复
【发布时间】:2018-01-19 08:30:25
【问题描述】:

运行流束管道,我使用 avroIO 从 gcs 流式传输文件/记录,然后创建分钟/小时存储桶以聚合事件并将其添加到 BQ。如果管道失败,我如何才能正确恢复并仅处理未处理的事件?我不想重复计算事件。 我想的一种方法是写入扳手或大表,但可能是写入 BQ 成功但数据库失败,反之亦然? 如何在流式管道中以可靠一致的方式保持状态以仅处理未处理的事件? 我想确保 BQ 中的最终汇总数据是不同事件的准确计数,而不是计数不足或过度计数? 火花流管道如何解决这个问题(我知道他们有一些检查点目录来管理查询和数据帧的状态)? 有没有推荐的技术来准确解决流管道中的这类问题?

【问题讨论】:

  • 这是一个使用 BigQuery 解决的具有挑战性的问题 - 幂等流操作。不幸的是,我实现这一点的唯一完整证明方法是求助于批处理。批处理允许使用一些有界数据集完全覆盖 BigQuery 中的表。
  • 不仅仅是 bigquery ,想象一下如果您必须将这些聚合的窗口事件计数写入 bigtable 或 spanner 或 gcs ?这更容易吗?重点是如何可靠地确定哪些事件已被处理,如何保持这种状态。批处理对于监控或分析来说不够实时
  • 你考虑过使用 pubsub 吗?此外,如果您写入由事件时间桶键入的 bigtable 或 spanner 计数,重新处理已处理的事件将覆盖上次处理的结果,这对于您的用例应该没问题(?)。 This 博客文章提供了一些关于一次性处理的有用信息。
  • 我已经阅读了上面的帖子,但它只讨论了在单个作业中只处理一次以及在单个作业中进行状态管理。我的案例更倾向于流式管道故障,以及如何跨多个流式管道作业维护状态。博客大多谈单职业范围内。我确实认为某些技术可能适用,但他们没有谈论任何检查点机制,可以帮助我重新启动作业,同时保持之前作业的状态。
  • YEs 通过 timebuckets 写入 bt 或 spanner 是一种选择,但最终我的目标是拥有一些引擎,可以帮助运行 sql 查询以进行分析,同时消耗实时数据(理想情况下我想转储到 BQ) 。因此,即使我写信给 BT,我也需要一些方法来提取最近的数据或在 BT 模式之上提供 sql 层。

标签: spark-streaming google-cloud-dataflow apache-beam google-cloud-spanner stream-processing


【解决方案1】:

根据 cmets 的澄清,这个问题可以归结为“假设两次运行都是从头开始,我们能否在流作业的两次连续运行中实现恰好一次的语义?”。简短的回答是否定的。即使用户愿意在外部存储中存储一些状态,它也需要与流引擎内部状态原子/一致地提交。 Dataflow、Flink 等流引擎在内部存储所需的状态,这是“恢复”作业所必需的。使用 Flink,您可以从最新的保存点恢复,使用 Dataflow,您可以“update”一个正在运行的管道(请注意,即使出现错误,Dataflow 实际上也不会终止您的作业,您需要明确取消作业)。 Dataflow 确实通过更新提供了一次性处理保证。

通过谨慎使用外部存储,一些宽松的保证是可行的。细节实际上取决于特定的目标(通常不值得额外的复杂性)。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-10-26
    • 2020-03-20
    • 1970-01-01
    • 2013-12-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多