为什么 Dataflow-BigTable 连接器不支持增量？答案

【问题标题】：Why increments are not supported in Dataflow-BigTable connector?为什么 Dataflow-BigTable 连接器不支持增量？
【发布时间】：2020-08-20 16:36:27
【问题描述】：

我们在 Streaming 模式中有一个用例，我们希望跟踪来自管道的 BigTable 上的计数器（一些 #items 已完成处理），我们需要对其进行增量操作。通过查看https://cloud.google.com/bigtable/docs/dataflow-hbase，我看到此客户端不支持 HBase API 的追加/增量操作。说明的原因是批处理模式下的重试逻辑，但如果 Dataflow 保证仅一次，为什么支持它是一个坏主意，因为我确定增量只被调用一次？我想了解我缺少哪一部分。

另外，CloudBigTableIO 可以在流模式下使用还是仅与批处理模式相关联？我想我们可以直接在管道中使用 BigTable HBase 客户端，但是连接器似乎具有很好的属性，例如我们想要利用的连接池，因此问题就来了。

【问题讨论】：

标签： google-cloud-dataflow google-cloud-bigtable apache-beam apache-beam-io

【解决方案1】：

Dataflow（和其他系统）在出现故障和重试的情况下提供只执行一次的方式是要求副作用（例如改变 BigTable）是幂等的。 “写”是幂等的，因为它在重试时被覆盖。插入可以通过包含一个确定性的“插入 ID”来实现幂等，该“插入 ID”对插入进行重复数据删除。

对于增量，情况并非如此。不支持，因为重试时不是幂等的，所以不支持exactly-once执行。

【讨论】：

感谢您的回复。我正在阅读cloud.google.com/dataflow/service/…，我只是查看了 exactly-once 保证，但我意识到它与 DoFn 所期望的 idempotency 保证相关。所以 Dataflow 真正保证的是 atleast-once 并且应用程序本身的 idempotency 有助于使其 exactly-once - 能做到这一点会很好在文档恕我直言中更明确。
您能否解释一下这种atleast-once 语义如何应用于Stateful ParDo。如果计数器保持在ParDo 的状态，并且在其中重试了一个元素，是否会导致计数器对同一元素发生两次变异（就像任何其他副作用一样），或者状态变异是否被正确处理为恰好一次？
理论上不可能只提供一次执行副作用：如果工作人员在元素上运行 DoFn 代码时死亡，除了再次运行代码之外，Beam 无能为力。然而，Beam 模型语义恰好是一次，因为所有 PCollection 的内容、度量值、状态突变等都像代码只运行一次一样发生，通常通过运行器中的一些类似事务的机制来实现。
例如，如果工作人员在处理元素时死亡，然后重试并成功处理该元素，则计算成功处理的 PCollection 输出和度量更改以及状态突变等，并从失败的尝试被丢弃，给人的印象是元素只被处理过一次。
我对混合副作用和我现在清楚的实际管道数据感到有些困惑。因此，任何内部状态都是事务性的，但任何外部状态都没有这样的保证，所有这样的外部突变（GCS/BigTable）都需要是幂等的。但是例如，如果CloudBigTableIO 确实在流模式下工作，为什么它仍然不能支持增量操作，因为它们仍然可以事务执行，并且任何失败都可以通过执行其逆操作来逆转？我知道它可能超出了范围，但试图了解这种 API 的可行性。

【解决方案2】：

CloudBigTableIO 在流模式下可用。为了通过 Dataflow SDK 支持这一点，我们必须实现 DoFn 而不是 Sink。

【讨论】：