1
Streamingモードでは、インクリメント操作が必要なパイプライン（#items finished processing）からBigTableのカウンタを追跡したい場合があります。 https://cloud.google.com/bigtable/docs/dataflow-hbaseを見ると、HBase APIの追加/増分操作がこのクライアントでサポートされていないことがわかりました。理由は、バッチモードのリトライロジックですが、データフローが正確に1回保証されている場合、インクリメントが1回だけ呼び出されたことがわかっているので、それをサポートするのはなぜ難しいのでしょうか？私は欠けている部分を理解したい。Dataflow-BigTableコネクタでインクリメントがサポートされないのはなぜですか？
また、CloudBigTableIOはストリーミングモードで使用できますか、それともバッチモードに限定されていますか？私たちはパイプラインでBigTable HBaseクライアントを直接使うことができると思いますが、コネクターにはConnection-poolingのような素敵なプロパティがあるようです。
お返事ありがとうございます。私はhttps://cloud.google.com/dataflow/service/dataflow-service-desc#structuring-your-user-codeを読んでいましたが、私はちょうど_exactly-once_保証を見ましたが、それは_idempotency_保証と結びついていたことを実感しましたそれはDoFnに期待されています。だから、Dataflowが実際に保証するのは_atleast-once_であり、アプリケーション自身の_idempotency_は、ドキュメントをIMHOでより明示的にするのがいいと思います。 –
この[_atleast-once_ semantic]が[Stateful ParDo]（https://beam.apache.org/blog/2017/02/13/stateful-processing.html）にどのように適用されるか説明してください。カウンタがParDoの状態で維持され、要素がその中で再試行された場合、同じ要素に対して（他の副作用のように）カウンタが2回突然変異するか、正しく処理された状態の突然変異が正しく返されますか？ -once_？ –
理論的には、副作用の実行を一度正確に行うことは不可能です。DoFnのコードを要素上で実行している間に作業者が死亡した場合、Beamはコードを再実行する以外は何もできません。しかし、Beamモデルのセマンティクスは、すべてのPCollectionの内容、メトリックの値、状態の変異などは、コードが正確に1回実行されたかのように発生します。通常、ランナーのトランザクションのようなメカニズムによって実現されます。 – jkff