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. Wiederholungen können auch vor Ablauf der Bestätigungsfrist oder nach Bestätigung einer Nachricht erfolgen.

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. Um die Anzahl doppelter Nachrichten zu reduzieren, verlängert Dataflow die Bestätigungsfrist kontinuierlich, während ein Batch von Nachrichten in dieser Phase verarbeitet wird.

Da Pub/Sub eine Nachricht möglicherweise noch einmal zustellt, können doppelte Nachrichten in der Pipeline ankommen. Wenn Ihre Dataflow-Pipeline den „Genau einmal“-Streamingmodus verwendet, dedupliziert Dataflow diese 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 doppelte 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, das als Tracking-Abo bezeichnet wird. Dataflow verwendet das Tracking-Abo, um die Ereigniszeiten von Nachrichten zu prüfen, die sich noch im Rückstand befinden. Mit diesem Ansatz kann Dataflow den Rückstand der Ereigniszeit genau schätzen. Das Worker-Dienstkonto muss mindestens die folgenden Berechtigungen für das Projekt haben, das das Tracking-Abo enthält:

  • pubsub.subscriptions.create
  • pubsub.subscriptions.consume
  • pubsub.subscriptions.delete

Außerdem benötigt es die Berechtigung pubsub.topics.attachSubscription für das Pub/Sub-Thema. Es wird empfohlen, eine benutzerdefinierte IAM-Rolle (Identity and Access Management) zu erstellen, die nur diese Berechtigungen enthält.

Weitere Informationen zu Wasserzeichen finden Sie auf der StackOverflow-Seite mit Informationen zur Berechnung von Pub/Sub-Wasserzeichen durch Dataflow.

Wenn eine Pipeline mehrere Pub/Sub-Quellen hat und eine davon ein sehr geringes Volumen hat oder inaktiv ist, wird das Fortschreiten des gesamten Wasserzeichens verzögert, was die Gesamtlatenz der Pipeline erhöht. Wenn es in der Pipeline Timer oder Fensteraggregationen gibt, die auf dem Wasserzeichen basieren, werden diese ebenfalls verzögert.

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.

Es wird jedoch nicht empfohlen, 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 Wasserzeichenlogik von Dataflow ungültig und es kommt zu Konflikten mit dem Status einer Pipeline, die verarbeitete Daten enthält.

Für die Neuverarbeitung 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. Senden Sie die Pipeline mit dem neuen Abo noch einmal.

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

Parallelität der Pub/Sub-Quelle

Die Pub/Sub-Quelle weist jeder Nachricht einen deterministischen Schlüssel für die Verarbeitung zu und verwendet diese Schlüssel, um die Nachrichten zu mischen.

  • Bei Streaming Engine-Jobs berechnet Dataflow die Anzahl der Schlüssel dynamisch anhand der aktiven Worker zu einem bestimmten Zeitpunkt: (number of workers * threads per worker) / 2. Der berechnete Wert ist auf einen Bereich zwischen 128 und 65.536 Schlüsseln beschränkt und wird dann auf die nächste Zweierpotenz abgerundet (die höchste Zweierpotenz, die kleiner oder gleich dem berechneten Wert ist).

  • Bei Jobs ohne Streaming Engine ist die Anzahl der Schlüssel die niedrigste Potenz von 2, die größer oder gleich (4 * maximum workers) ist.

Wenn Sie die Standardanzahl von Shuffle-Schlüsseln überschreiben möchten, legen Sie die Dienstoption num_pubsub_keys fest:

Java 

--dataflowServiceOptions=num_pubsub_keys=NUMBER_OF_KEYS

Python 

--dataflow_service_options=num_pubsub_keys=NUMBER_OF_KEYS

Go

--dataflow_service_options=num_pubsub_keys=NUMBER_OF_KEYS

Ersetzen Sie NUMBER_OF_KEYS durch die Anzahl der Schlüssel. Es wird die nächste Zweierpotenz verwendet, die größer oder gleich dem angegebenen Wert ist.

Sie können diese Option beispielsweise in den folgenden Situationen festlegen:

Wenn Sie diese Option festlegen, sollten Sie die unter Parallelisierung und Verteilung beschriebenen Vor- und Nachteile berücksichtigen.

Sie können die Anzahl der Schlüssel nicht im Rahmen eines Pipeline-Updates ändern. Wenn Sie die Anzahl der Schlüssel für einen vorhandenen Pipelinejob ändern möchten, müssen Sie einen neuen Job starten.

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

Es wird aus folgenden Gründen nicht empfohlen, Pub/Sub-Themen für unzustellbare Nachrichten mit Dataflow zu verwenden:

  • 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 bestätigt Nachrichten, nachdem ein Nachrichten-Bundle von der ersten zusammengeführten Phase erfolgreich verarbeitet wurde. 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, indem Sie fehlgeschlagene Nachrichten zur späteren Verarbeitung an ein Ziel weiterleiten. 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.

Pub/Sub-Transformationen für einzelne Nachrichten

Mit Single Message Transforms (SMTs) können Sie Nachrichten anhand ihrer Attribute oder Daten bearbeiten, validieren und filtern, während sie durch das System gestreamt werden. Abos, die Daten in Dataflow einspeisen, sollten keine SMTs verwenden, die Nachrichten herausfiltern, da dies das Autoscaling beeinträchtigen kann. Das liegt daran, dass die SMT-Filterung von Abos dazu führen kann, dass der Rückstand größer erscheint als das, was an Dataflow geliefert wird, bis die herausgefilterten Nachrichten tatsächlich vom SMT verarbeitet werden. Themen-SMTs, die Nachrichten filtern, verursachen keine Probleme beim Autoscaling.

Nächste Schritte