Von Pub/Sub in Dataflow lesen

Auf dieser Seite werden Best Practices für das Lesen aus Pub/Sub in Dataflow beschrieben.

Apache Beam bietet eine Referenzimplementierung des Pub/Sub-E/A-Connectors zur Verwendung durch Nicht-Dataflow-Runner. Der Dataflow-Runner verwendet jedoch eine eigene benutzerdefinierte Implementierung des Connectors. Bei dieser Implementierung werden die Vorteile von Google Cloud-internen APIs und Diensten genutzt, um Wasserzeichen mit niedriger Latenz, eine hohe Wasserzeichengenauigkeit und eine effiziente Deduplizierung für die Verarbeitung einmaliger Nachrichten zu bieten. Der Connector ist für Java, Python und Go verfügbar.

Genau einmalige Verarbeitung

Pub/Sub entkoppelt Ereignis-Publisher von Ereignisnutzern. Die Anwendung veröffentlicht Nachrichten zu einem Thema und Pub/Sub liefert die Nachrichten asynchron an Abonnenten.

Pub/Sub weist jeder Nachricht, die erfolgreich in einem Thema veröffentlicht wurde, eine eindeutige Nachrichten-ID zu. Pub/Sub führt standardmäßig mindestens einmalige Nachrichtenzustellung durch. Um eine mindestens einmalige Semantik zu erreichen, versucht Pub/Sub, die Zustellung zu wiederholen, wenn es innerhalb der Bestätigungsfrist keine Bestätigung vom Abonnenten erhält. Wiederholungsversuche können dazu führen, dass eine Nachricht mehr als einmal zugestellt wird. Eine erneute Zustellung kann beispielsweise erfolgen, wenn der Abonnent nach Ablauf der Frist bestätigt oder wenn die Bestätigung aufgrund vorübergehender Netzwerkprobleme verloren gegangen ist.

Wenn Sie Ihre Dataflow-Pipeline im „Genau einmal“-Streamingmodus ausführen, dedupliziert Dataflow Nachrichten, um eine „Genau einmal“-Semantik zu erhalten. Wenn Ihre Pipeline einige doppelte Datensätze tolerieren kann, sollten Sie erwägen, stattdessen den "Mindestens einmal"-Streamingmodus zu verwenden. Dieser Modus kann die Latenz und die Gesamtkosten Ihrer Pipeline erheblich senken. Der Nachteil ist, dass einige Nachrichten zweimal verarbeitet werden können. Weitere Informationen finden Sie unter Den zu verwendenden Streamingmodus auswählen.

Nach Nachrichtenattribut deduplizieren

Standardmäßig dedupliziert Dataflow die Nachrichten-ID. Eine Anwendung kann jedoch denselben Datensatz zweimal senden wie zwei verschiedene Pub/Sub-Nachrichten. Die ursprünglichen Quelldaten können beispielsweise doppelte Datensätze enthalten oder die Anwendung veröffentlicht dieselbe Nachricht möglicherweise zweimal falsch. Letzteres kann aufgrund von Wiederholungsversuchen auftreten, wenn die Bestätigung aufgrund von Netzwerkproblemen oder anderen Unterbrechungen abgebrochen wurde. In diesen Fällen haben die doppelten Nachrichten unterschiedliche Nachrichten-IDs.

Je nach Szenario enthalten Ihre Daten möglicherweise ein eindeutiges Feld, das zur Deduplizierung verwendet werden kann. Datensätze können beispielsweise eine eindeutige Transaktions-ID enthalten. Sie können den Pub/Sub-E/A-Connector so konfigurieren, dass Nachrichten basierend auf dem Wert eines Nachrichtenattributs dedupliziert werden, anstatt die Pub/Sub-Nachrichten-ID zu verwenden. Solange der Publisher dieses Attribut während der Wiederholungsversuche konsistent festlegt, kann Dataflow die Duplikate erkennen. Nachrichten müssen zur Deduplizierung innerhalb von zehn Minuten voneinander in Pub/Sub veröffentlicht werden.

Weitere Informationen zur Verwendung von ID-Attributen finden Sie in den folgenden SDK-Referenzthemen:

Abos

Beim Konfigurieren der Pipeline geben Sie entweder ein Pub/Sub-Thema oder ein Pub/Sub-Abo an, aus dem gelesen werden soll. Wenn Sie ein Abo angeben, verwenden Sie nicht dasselbe Pub/Sub-Abo für mehrere Pipelines. Wenn zwei Pipelines aus einem Abo lesen, empfängt jede Pipeline einen Teil der Daten auf nicht deterministische Weise, was zu doppelten Nachrichten, Wasserzeichenverzögerungen und ineffizientem Autoscaling führen kann. Erstellen Sie stattdessen für jede Pipeline ein eigenes Abo.

Wenn Sie ein Thema angeben, erstellt der Connector ein neues temporäres Abo. Dieses Abo ist pro Pipeline einmalig.

Zeitstempel und Wasserzeichen

Alle Pub/Sub-Nachrichten haben einen Zeitstempel, der den Zeitpunkt darstellt, zu dem Pub/Sub die Nachricht empfängt. Ihre Daten können auch einen Ereigniszeitstempel haben, der die Zeit ist, zu der der Datensatz von der Quelle generiert wurde.

Sie können den Connector so konfigurieren, dass der Ereigniszeitstempel aus einem Attribut in der Pub/Sub-Nachricht gelesen wird. In diesem Fall verwendet der Connector den Ereigniszeitstempel für Wasserzeichen. Andernfalls wird standardmäßig der Pub/Sub-Nachrichtenzeitstempel verwendet.

Weitere Informationen zur Verwendung von Ereigniszeitstempeln finden Sie in den folgenden SDK-Referenzthemen:

Der Pub/Sub-Connector hat Zugriff auf die private API von Pub/Sub, die das Alter der ältesten nicht bestätigten Nachricht in einem Abo angibt. Diese API bietet eine geringere Latenz als in Cloud Monitoring verfügbar. Dataflow kann dadurch Pipeline-Wasserzeichen vorziehen und die Ergebnisse der Fensterberechnungen mit niedrigen Latenzen ausgeben.

Wenn Sie den Connector für die Verwendung von Ereigniszeitstempeln konfigurieren, erstellt Dataflow ein zweites Pub/Sub-Abo. Mit diesem Abo werden die Ereigniszeiten von Nachrichten geprüft, die sich noch im Rückstand befinden. Mit diesem Ansatz kann Dataflow den Rückstand der Ereigniszeit genau schätzen. Weitere Informationen finden Sie auf der StackOverflow-Seite mit Informationen zur Berechnung von Pub/Sub-Wasserzeichen durch Dataflow.

Pub/Sub Seek

Pub/Sub Seek ermöglicht Nutzern, zuvor bestätigte Nachrichten wiederzugeben. Sie können Pub/Sub Seek mit Dataflow verwenden, um Nachrichten in einer Pipeline noch einmal zu verarbeiten.

Wir empfehlen jedoch nicht, Pub/Sub Seek in einer laufenden Pipeline zu verwenden. Das Rückwärtsgehen in einer laufenden Pipeline kann dazu führen, dass doppelte Nachrichten gibt oder Nachrichten gelöscht werden. Außerdem wird die Watermark-Logik von Dataflow ungültig und es kommt zu Konflikten mit dem Status einer Pipeline, die verarbeitete Daten enthält.

Für die erneute Verarbeitung von Nachrichten mit Pub/Sub Seek wird der folgende Workflow empfohlen:

  1. Erstellen Sie einen Snapshot des Abos:
  2. Neues Abo für das Pub/Sub-Thema erstellen Das neue Abo übernimmt den Snapshot.
  3. Nutzen Sie Drain für den aktuellen Dataflow-Job oder brechen Sie ihn ab.
  4. Reichen Sie die Pipeline noch einmal mit dem neuen Abo ein.

Weitere Informationen finden Sie unter Erneute Verarbeitung von Nachrichten mit Pub/Sub-Snapshot und Seek.

Nicht unterstützte Pub/Sub-Features

Die folgenden Pub/Sub-Features werden in der Dataflow Runner-Implementierung des Pub/Sub-E/A-Connectors nicht unterstützt.

Exponentielle Backoffs

Wenn Sie ein Pub/Sub-Abo erstellen, können Sie es so konfigurieren, dass eine Wiederholungsrichtlinie mit exponentiellem Backoff verwendet wird. Der exponentielle Backoff funktioniert jedoch nicht mit Dataflow. Erstellen Sie das Abo stattdessen mit der Wiederholungsrichtlinie Sofort wiederholen.

Exponentielle Backoffs werden durch eine negative Bestätigung oder nach Ablauf der Bestätigungsfrist ausgelöst. Dataflow sendet jedoch keine negativen Bestätigungen, wenn der Pipelinecode fehlschlägt. Stattdessen wiederholt es die Nachrichtenverarbeitung auf unbestimmte Zeit und erweitert gleichzeitig die Bestätigungsfrist für die Nachricht kontinuierlich.

Themen für unzustellbare Nachrichten

Verwenden Sie aus folgenden Gründen keine Pub/Sub-Themen für unzustellbare Nachrichten mit Dataflow:

  • Dataflow sendet negative Bestätigungen aus verschiedenen internen Gründen (z. B. wenn ein Worker heruntergefahren wird). Daher werden Nachrichten möglicherweise an das Thema für unzustellbare Nachrichten gesendet, auch wenn keine Fehler im Pipelinecode auftreten.

  • Dataflow kann Nachrichten bestätigen, bevor die Pipeline die Daten vollständig verarbeitet. Dataflow bestätigt Nachrichten, nachdem sie von der ersten zusammengeführten Phase erfolgreich verarbeitet wurden und die Nebeneffekte dieser Verarbeitung in den nichtflüchtigen Speicher geschrieben wurden. Wenn die Pipeline mehrere zusammengeführte Phasen enthält und nach der ersten Phase Fehler auftreten, werden die Nachrichten bereits bestätigt und gehen nicht an das Thema für unzustellbare Nachrichten.

Implementieren Sie stattdessen das Muster für unzustellbare Nachrichten explizit in der Pipeline. Einige E/A-Senken bieten integrierte Unterstützung für Warteschlangen für unzustellbare Nachrichten. In den folgenden Beispielen werden Muster für unzustellbare Nachrichten implementiert.

Pub/Sub-Genau einmalige Zustellung

Da Dataflow eigene Mechanismen für die genau einmalige Verarbeitung hat, wird nicht empfohlen, die genau einmalige Pub/Sub-Übermittlung mit Dataflow zu verwenden. Das Aktivieren der genau einmaligen Übermittlung an Pub/Sub reduziert die Pipelineleistung, da die Anzahl der Nachrichten begrenzt wird, die für die parallele Verarbeitung verfügbar sind.

Pub/Sub-Nachrichtenreihenfolge

Die Nachrichtenreihenfolge ist ein Feature in Pub/Sub, mit dem ein Abonnent Nachrichten in der Reihenfolge empfangen kann, in der sie veröffentlicht wurden.

Die Verwendung der Nachrichtenreihenfolge mit Dataflow wird aus den folgenden Gründen nicht empfohlen:

  • Der Pub/Sub-E/A-Connector behält die Nachrichtenreihenfolge möglicherweise nicht bei.
  • Apache Beam definiert keine strengen Richtlinien für die Reihenfolge, in der Elemente verarbeitet werden. Daher wird die Reihenfolge in nachgelagerten Transformationen möglicherweise nicht beibehalten.
  • Die Verwendung der Pub/Sub-Nachrichtenreihenfolge mit Dataflow kann die Latenz erhöhen und die Leistung verringern.

Nächste Schritte