为什么增量在Dataflow-BigTable连接器中不受支持？

我们在Streaming模式下有一个用例，我们想从管道中跟踪BigTable上的计数器（某些#items已完成处理），我们需要增量操作。从查看https://cloud.google.com/bigtable/docs/dataflow-hbase，我发现此客户端不支持HBase API的追加/增量操作。原因是批处理模式下的重试逻辑，但是如果Dataflow保证一次，为什么会支持它是一个坏主意，因为我确定增量被称为只有一次？我想了解我失踪的部分。为什么增量在Dataflow-BigTable连接器中不受支持？

另外，是CloudBigTableIO可用于流式传输模式还是仅与批处理模式绑定？我想我们可以直接在管道中使用BigTable HBase客户端，但连接器似乎具有很好的属性，比如我们想要利用的Connection-pooling，因此也是问题所在。

来源

2017-05-08 Gowrishankar Sunder

数据流（和其他系统）提供的确切出现的方式 - 在出现故障和重试时执行一次就是要求副作用（如变异BigTable）是幂等的。 “写”是幂等的，因为它在重试时被覆盖。插入可以通过包含确定性的“插入ID”来重复插入，从而使其具有幂等性。

对于增量，情况并非如此。它不被支持，因为它在重试时不会是幂等的，所以它不会完全支持 - 一次执行。

来源

2017-05-08 21:32:42

感谢您的回复。我正在阅读https://cloud.google.com/dataflow/service/dataflow-service-desc#structuring-your-user-code，我只是看着_exactly-once_保证书，但却意识到它与_idempotency_ guarantee这是DoFn的预期。因此，Dataflow实际上保证的是_atleast-once_和应用程序本身的_idempotency_有助于使它非常完美地 - once_--能够更好地在文档中更加明确地列出恕我直言。 –

你能解释一下这个_atleast-once_语义如何应用于[Stateful ParDo]（https://beam.apache.org/blog/2017/02/13/stateful-processing.html）。如果一个计数器在'ParDo'状态下被维护并且一个元素被重试，它是否会导致计数器对相同元素进行两次突变（就像任何其他副作用一样），或者将状态突变正确处理为_exactly -一旦_？ –

在理论上不可能提供一次执行的副作用：如果工作人员在元素上运行DoFn代码时死亡，那么除了再次运行代码之外，没有任何Beam可以做。然而，Beam模型语义只是一次，所有PCollections的内容，度量值，状态变化等都会发生，仿佛代码只运行一次，通常通过跑步者中的一些类似事务的机制来实现。 – jkff

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

来源

2017-05-09 14:11:46

为什么增量在Dataflow-BigTable连接器中不受支持？

回答

相关问题