1

Wir haben einen Anwendungsfall im Streaming-Modus, wo wir einen Zähler auf BigTable aus der Pipeline (etwas # Items abgeschlossene Verarbeitung) verfolgen wollen, für die wir die Inkrement-Operation benötigen. Aus Blick auf https://cloud.google.com/bigtable/docs/dataflow-hbase, sehe ich, dass Append/Inkrement-Operationen der HBase API von diesem Client nicht unterstützt werden. Der Grund dafür ist die Wiederholungslogik im Batch-Modus, aber wenn Dataflow genau einmal garantiert, warum würde die Unterstützung eine schlechte Idee sein, da ich sicher weiß, dass das Inkrement nur einmal aufgerufen wurde? Ich möchte verstehen, welchen Teil ich vermisse.Warum werden Inkremente im Dataflow-BigTable-Connector nicht unterstützt?

Ist CloudBigTableIO auch im Streaming-Modus verwendbar oder nur im Batch-Modus? Ich denke, wir könnten den BigTable HBase Client direkt in der Pipeline verwenden, aber der Connector scheint nette Eigenschaften wie Connection-Pooling zu haben, die wir gerne nutzen würden und daher die Frage.

Antwort

1

Die Art und Weise, wie Dataflow (und andere Systeme) das Auftreten einer genau einmaligen Ausführung bei Fehlern und Neuversuchen bieten, besteht darin, dass Nebenwirkungen (wie das Mutieren von BigTable) idempotent sind. Ein "Write" ist idempotent, da es beim erneuten Versuch überschrieben wird. Einfügungen können durch Einfügen einer deterministischen "Einfüge-ID", die die Einfügung dedupliziert, idempotent gemacht werden.

Für ein Inkrement ist das nicht der Fall. Es wird nicht unterstützt, weil es nicht idempotent wäre, wenn es erneut versucht wird, also würde es nicht genau einmal Ausführung unterstützen.

+0

Danke für die Antwort. Ich habe https://cloud.google.com/dataflow/service/dataflow-service-desc#structuring-your-user-code gelesen und ich habe mir die Garantie "_exactly-once_" angesehen, ohne zu erkennen, dass sie mit der Garantie _idempotenz_ verbunden war das wird vom DoFn erwartet. Was Dataflow tatsächlich garantiert, ist _atleast-once_ und die _idempotenz_ der App selbst hilft, _exactly-once_ zu machen - wäre schön, es in der Dokumentation IMHO expliziter zu machen. –

+0

Können Sie bitte erklären, wie diese _atleast-once_ Semantik auf [Stateful ParDo] zutrifft (https://beam.apache.org/blog/2017/02/13/stateful-processing.html). Wenn ein Zähler in dem Zustand des "ParDo" beibehalten wird und ein Element darin wiederholt wird, führt dies dazu, dass der Zähler zweimal für dasselbe Element mutiert (wie jeder andere Nebeneffekt) oder wird die Zustandsänderung korrekt ausgeführt, um genau zu sein -Einmal_? –

+0

Es ist theoretisch unmöglich, genau einmal die Ausführung von Nebenwirkungen bereitzustellen: Wenn ein Arbeiter stirbt, während er den DoFn-Code für ein Element ausführt, kann Beam nichts anderes tun, als den Code erneut auszuführen. Die Semantik des Beam-Modells ist jedoch genau einmal in dem Sinne, dass Inhalte aller PCollections, Werte von Metriken, Statusmutationen usw. vorkommen, als ob der Code genau einmal ausgeführt würde, was üblicherweise durch einige transaktionsähnliche Mechanismen in einem Runner erreicht wird. – jkff

0

CloudBigTableIO kann im Streaming-Modus verwendet werden. Wir mussten ein DoFn anstelle eines Sinks implementieren, um dies über das Dataflow SDK zu unterstützen.

Verwandte Themen