Aboeigenschaften

Pub/Sub-Aboattribute sind die Merkmale eines Abos. Sie können beim Erstellen oder Aktualisieren eines Abos Attribute für das Abo festlegen.

In diesem Dokument werden die verschiedenen Aboattribute beschrieben, die du für ein Abo festlegen kannst.

Hinweise

• Weitere Informationen zu Abos

• Machen Sie sich mit dem Workflow für das Abo vertraut, das Sie erstellen werden: Pull, Push oder BigQuery.

Häufige Aboeigenschaften

Wenn Sie ein Abo erstellen, müssen Sie eine Reihe von Optionen zum Einrichten des Abos angeben. Einige dieser Eigenschaften gelten für alle Abotypen und werden in den nächsten Abschnitten erläutert.

Aufbewahrungsdauer für Nachrichten

Die Option Nachrichtenaufbewahrungsdauer gibt an, wie lange Pub/Sub Nachrichten nach der Veröffentlichung aufbewahrt. Nach Ablauf der Nachrichtenaufbewahrungsdauer kann Pub/Sub die Nachricht unabhängig vom Bestätigungsstatus der Nachricht verwerfen. Informationen zum Aufbewahren bestätigter Nachrichten über die Aufbewahrungsdauer von Nachrichten finden Sie unter Nachrichten wiedergeben und verwerfen.

Für die Option Nachrichtenaufbewahrungsdauer gelten folgende Werte:

• Standardwert = 7 Tage
• Mindestwert = 10 Minuten
• Maximalwert = 7 Tage

Hinweis: Ab dem 30. Juni 2024 fallen Gebühren für die Aufbewahrung nicht bestätigter Nachrichten mit Abos für mehr als 24 Stunden an.

Nicht bestätigte Nachrichten können durch inaktive Abos, Sicherungsanforderungen oder eine langsame Verarbeitung verursacht werden. Wenn Sie die Nachrichten innerhalb von 24 Stunden verarbeiten können, fallen keine zusätzlichen Kosten an. So können Sie neue Gebühren vermeiden:

• Inaktive Abos: Löschen Sie inaktive Abos, um Gebühren für die Aufbewahrung von Abonachrichten zu vermeiden.

• Sicherungsspeicher Wenn Sie die Aufbewahrung von Abos als Sicherungsspeicher verwenden, können Sie zu einer anderen Speicheroption wechseln, z. B. zur Aufbewahrung von Themennachrichten oder zum Aufbewahren bestätigter Nachrichten. Bei der Aufbewahrung von Themennachrichten werden Nachrichten auf Themenebene nur einmal gespeichert. Sie bleiben für alle Abos verfügbar, die sie bei Bedarf nutzen können.

• Verzögerungen bei der Verarbeitung: Fügen Sie nach Möglichkeit weitere Abonnenten hinzu, damit die Nachrichten innerhalb eines Tages verarbeitet werden können.

Bestätigte Nachrichten speichern

Wenn Sie die Dauer der Nachrichtenaufbewahrungsdauer festlegen, können Sie auch angeben, ob bestätigte Nachrichten aufbewahrt werden sollen.

Mit der Option Bestätigte Nachrichten aufbewahren können Sie bestätigte Nachrichten für die angegebene Aufbewahrungsdauer aufbewahren. Durch diese Option erhöhen sich die Gebühren für das Speichern von Nachrichten. Weitere Informationen finden Sie unter Speicherkosten.

Ablauffrist

Mit der Option Ablaufzeit können Sie die Ablaufzeit Ihres Abos verlängern.

Abos ohne Abonnentenaktivität oder Änderungen an den Aboeigenschaften laufen ab. Wenn Pub/Sub Abonnentenaktivitäten erkennt oder eines der Aboattribute aktualisiert, wird die Uhr für das Löschen des Abos neu gestartet. Beispiele für Abonnentenaktivitäten sind offene Verbindungen, aktive Pull- oder erfolgreiche Push-Vorgänge.

Wenn Sie die Ablauffrist angeben, muss der Wert länger sein als die unter Dauer der Nachrichtenaufbewahrungsdauer angegebene Nachrichtenaufbewahrungsdauer.

Für die Option Ablaufzeitraum gelten folgende Werte:

• Standardwert = 31 Tage
• Mindestwert = 1 Tag
• Maximalwert = 365 Tage.

Um zu verhindern, dass ein Abo abläuft, legen Sie die Ablaufzeit auf never expire fest.

Bestätigungsfrist

Die Option Bestätigungsfrist gibt die anfängliche Frist an, nach der eine nicht bestätigte Nachricht noch einmal gesendet wird. Sie können die Bestätigungsfrist für einzelne Nachrichten verlängern, indem Sie nachfolgende ModifyAckDeadline-Anfragen senden.

Folgende Werte gelten für die Option Bestätigungsfrist:

• Standardwert = 10 Sekunden
• Mindestwert = 10 Sekunden
• Maximalwert = 600 Sekunden

In einigen Fällen können Pub/Sub-Clientbibliotheken die Bereitstellungsrate steuern und die Bestätigungsfrist dynamisch ändern. Dabei wird die Nachricht möglicherweise vor der von Ihnen festgelegten Bestätigungsfrist noch einmal zugestellt. Verwenden Sie minDurationPerAckExtension und maxDurationPerAckExtension, um dieses Verhalten zu überschreiben. Weitere Informationen zur Verwendung dieser Werte finden Sie unter Unterstützung für genau einmalige Übermittlung in Clientbibliotheken.

Abofilter

Verwenden Sie die Option Abofilter, um einen String mit einem Filterausdruck anzugeben. Wenn ein Abo einen Filter hat, sendet es nur die Nachrichten zu, die dem Filter entsprechen. Der Pub/Sub-Dienst bestätigt automatisch die Nachrichten, die nicht dem Filter entsprechen.

• Sie können Nachrichten nach Attributen filtern, aber nicht nach den Daten in der Nachricht.

• Wenn keine Vorgabe erfolgt, filtert das Abo keine Nachrichten und Abonnenten erhalten alle Nachrichten.

• Filter können nach der Anwendung nicht mehr geändert oder entfernt werden.

Wenn Sie Nachrichten aus einem Abo mit einem Filter erhalten, fallen keine Gebühren für ausgehenden Traffic für die von Pub/Sub angegebenen Nachrichten an. Für diese Nachrichten fallen Gebühren für die Nachrichtenzustellung und suchbezogene Speichergebühren an.

Weitere Informationen finden Sie unter Nachrichten aus einem Abo filtern.

Nachrichtenreihenfolge

Wenn für ein Abo die Nachrichtenreihenfolge aktiviert ist, empfangen die Abonnentenclients Nachrichten, die in derselben Region veröffentlicht wurden, mit demselben Reihenfolgeschlüssel in der Reihenfolge, in der die Nachrichten vom Dienst empfangen wurden.

Bei Verwendung der sortierten Zustellung werden Bestätigungen für spätere Nachrichten erst verarbeitet, wenn Bestätigungen für frühere Nachrichten verarbeitet wurden.

Die Publisher müssen Nachrichten mit einem Reihenfolgeschlüssel senden, damit Pub/Sub die Nachrichten der Reihe nach zustellen kann.

Wenn die Richtlinie nicht konfiguriert ist, sendet Pub/Sub Nachrichten möglicherweise nicht der Reihe nach, auch wenn sie einen Reihenfolgeschlüssel haben.

Thema für unzustellbare Nachrichten

Wenn eine Nachricht nach einer bestimmten Anzahl von Zustellungsversuchen nicht zugestellt werden kann oder ein Abonnent die Nachricht nicht bestätigen kann, können Sie ein Thema für unzustellbare Nachrichten konfigurieren, in dem diese Nachrichten noch einmal veröffentlicht werden können.

Wenn Sie ein Thema für unzustellbare Nachrichten festlegen, können Sie auch die maximale Anzahl der Zustellungsversuche angeben. Im Folgenden finden Sie die Werte für die maximale Anzahl von Zustellungsversuchen für das Thema für unzustellbare Nachrichten:

• Standardwert = 5 Zustellversuche
• Mindestwert = 5 Zustellversuche
• Maximalwert = 100 Zustellversuche

Wenn sich das Thema für unzustellbare Nachrichten in einem anderen Projekt als das Abo befindet, müssen Sie auch die Projekt-ID mit dem Thema für unzustellbare Nachrichten angeben.

Weitere Informationen finden Sie unter Weiterleitung an Themen für unzustellbare Nachrichten.

Wiederholungsrichtlinie

Wenn die Bestätigungsfrist abläuft oder ein Abonnent mit einer negativen Bestätigung antwortet, kann Pub/Sub die Nachricht noch einmal senden. Dieser Versuch zur erneuten Zustellung wird als Wiederholungsrichtlinie für Abos bezeichnet.

Standardmäßig ist die Wiederholungsrichtlinie für ein Abo auf Sofort wiederholen festgelegt. Bei dieser Option sendet Pub/Sub die Nachricht noch einmal, wenn die Bestätigungsfrist abgelaufen ist oder ein Abonnent mit einer negativen Bestätigung antwortet.

Sie können den Wert auch auf Nach exponentieller Backoff-Verzögerung wiederholen festlegen. In diesem Fall müssen Sie die maximalen und minimalen Backoff-Werte angeben.

Im Folgenden finden Sie einige Richtlinien zum Festlegen der Werte für maximale und minimale Backoff-Werte:

• Wenn Sie den Maximalwert für die Backoff-Dauer festlegen, beträgt der Standardwert für die minimale Backoff-Dauer 10 Sekunden.

• Wenn Sie den Mindestwert für die Backoff-Dauer festlegen, beträgt der Standardwert für die maximale Backoff-Dauer 600 Sekunden.

• Sie können maximal 600 Sekunden festlegen.

Wiederholungsrichtlinie und Nachrichten in Batches

Wenn sich Nachrichten in einem Batch befinden, startet Pub/Sub den exponentiellen Backoff, wenn eines der folgenden Ereignisse eintritt:

• Der Abonnent sendet für jede Nachricht im Batch eine negative Bestätigung.

• Die Bestätigungsfrist läuft ab.

Wiederholungsrichtlinie und Push-Abo

Wenn Sie Nachrichten von einem Push-Abo erhalten, sendet Pub/Sub Nachrichten nach dem Push-Backoff und nicht nach der exponentiellen Backoff-Dauer noch einmal. Wenn der Push-Backoff länger als die exponentielle Backoff-Dauer ist, sendet Pub/Sub nicht bestätigte Nachrichten nach dem Push-Backoff noch einmal.

Hinweis: Wenn Sie die Nachrichtenaufbewahrungsdauer oder die Richtlinie zum Aboablauf ändern, muss die Ablaufzeit auf einen Wert festgelegt werden, der größer als die Nachrichtenaufbewahrungsdauer ist. Die standardmäßige Nachrichtenaufbewahrungsdauer für Nachrichten beträgt 7 Tage und die standardmäßige Ablaufzeit beträgt 31 Tage.

Eigenschaften von Pull-Abos

Wenn Sie ein Pull-Abo konfigurieren, können Sie die folgenden Attribute angeben.

Genau einmalige Übermittlung

Genau einmalige Zustellung. Wenn festgelegt, erfüllt Pub/Sub die Garantien für genau einmalige Zustellung. Wenn keine Vorgabe erfolgt, unterstützt das Abo die mindestens einmalige Zustellung für jede Nachricht.

Push-Aboattribute

Wenn Sie ein Push-Abo konfigurieren, können Sie die folgenden Attribute angeben.

Endpunkte

Endpunkt-URL (erforderlich). Eine öffentlich zugängliche HTTPS-Adresse. Der Server für den Push-Endpunkt muss ein gültiges SSL-Zertifikat haben, das von einer Zertifizierungsstelle signiert wurde. Der Pub/Sub-Dienst sendet Nachrichten an Push-Endpunkte aus derselben Google Cloud-Region, in der der Pub/Sub-Dienst die Nachrichten speichert. Der Pub/Sub-Dienst sendet Nachrichten aus derselben Google Cloud-Region auf Best-Effort-Basis.

Pub/Sub erfordert keinen Nachweis der Inhaberschaft für URL-Domains von Push-Abos. Wenn Ihre Domain unerwartete POST-Anfragen von Pub/Sub erhält, können Sie einen mutmaßlichen Missbrauch melden.

Authentifizierung

Aktivieren Sie die Authentifizierung. Wenn diese Option aktiviert ist, enthalten Nachrichten, die von Pub/Sub an den Push-Endpunkt gesendet werden, einen Autorisierungsheader, mit dem der Endpunkt die Anfrage authentifizieren kann. Für App Engine-Standard- und Cloud Functions-Endpunkte, die im selben Projekt wie das Abo gehostet werden, sind automatische Authentifizierungs- und Autorisierungsmechanismen verfügbar.

Die Authentifizierungskonfiguration für ein authentifiziertes Push-Abo besteht aus einem vom Nutzer verwalteten Dienstkonto und den Zielgruppenparametern, die in einem create-, Patch- oder ModifyPushConfig-Aufruf angegeben werden. Außerdem müssen Sie einem speziellen von Google verwalteten Dienstkonto eine bestimmte Rolle zuweisen, wie im nächsten Abschnitt beschrieben.

• Vom Nutzer verwaltetes Dienstkonto (erforderlich). Das Dienstkonto, das mit dem Push-Abo verknüpft ist. Dieses Konto wird als email-Anforderung des generierten JSON-Webtokens (JWT) verwendet. Im Folgenden finden Sie eine Liste der Anforderungen an das Dienstkonto:

  • Dieses Dienstkonto muss sich im selben Projekt wie das Push-Abo befinden.

  • Das Hauptkonto, das das Push-Abo erstellt oder ändert, muss die Berechtigung iam.serviceAccounts.actAs für das Dienstkonto haben. Sie können entweder eine Rolle mit dieser Berechtigung für das Projekt, den Ordner oder die Organisation zuweisen, damit der Aufrufer die Identität mehrerer Dienstkonten übernehmen kann, oder eine Rolle mit dieser Berechtigung für das Dienstkonto zuweisen, damit der Aufrufer nur die Identität dieses Dienstkontos übernehmen kann.

• Zielgruppe: Ein einzelner String, bei dem die Groß-/Kleinschreibung nicht berücksichtigt wird. Er verwendet den Webhook, um die beabsichtigte Zielgruppe dieses bestimmten Tokens zu validieren.

• Von Google verwaltetes Dienstkonto (erforderlich):

  • Pub/Sub erstellt automatisch ein Dienstkonto im Format service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com.

  • Diesem Dienstkonto muss die Berechtigung iam.serviceAccounts.getOpenIdToken (in der Rolle roles/iam.serviceAccountTokenCreator enthalten) gewährt werden, damit Pub/Sub JWT-Tokens für authentifizierte Push-Anfragen erstellen kann.

Entpacken der Nutzlast

Mit der Option Entpacken der Nutzlast aktivieren werden Pub/Sub-Nachrichten aus allen Nachrichtenmetadaten mit Ausnahme der Nachrichtendaten entfernt. Beim Entpacken der Nutzlast werden die Nachrichtendaten direkt als HTTP-Text übermittelt.

• Metadaten schreiben Zuvor entfernte Nachrichtenmetadaten werden wieder in den Anfrageheader eingefügt.

BigQuery-Attribute

Wenn Sie In BigQuery schreiben als Zustellungstyp für das Abo auswählen, können Sie die folgenden zusätzlichen Attribute angeben.

Schema des Themas verwenden

Mit dieser Option kann Pub/Sub das Schema des Pub/Sub-Themas verwenden, mit dem das Abo verknüpft ist. Darüber hinaus schreibt Pub/Sub die Felder in Nachrichten in die entsprechenden Spalten der BigQuery-Tabelle.

Achtung: Das Löschen eines Schemas oder einer Schemaüberarbeitung kann nicht rückgängig gemacht werden. Alle Nachrichten, die zum Zeitpunkt der Veröffentlichung anhand einer gelöschten Schemaversion validiert wurden, können nicht mit einem BigQuery-Abo in BigQuery geschrieben werden, bei dem Schema des Themas verwenden aktiviert ist. Statt ein Schema oder eine Überarbeitung zu löschen, können Sie ein Rollback für das Schema durchführen.

Wenn Sie diese Option verwenden, müssen Sie die folgenden zusätzlichen Anforderungen prüfen:

• Die Felder im Schema des Themas und im BigQuery-Schema müssen dieselben Namen haben und ihre Typen müssen miteinander kompatibel sein.

• Alle optionalen Felder im Schema des Themas müssen auch im BigQuery-Schema optional sein.

• Pflichtfelder im Schema des Themas müssen im BigQuery-Schema nicht erforderlich sein.

• Wenn BigQuery-Felder vorhanden sind, die im Schema des Themas nicht vorhanden sind, müssen diese BigQuery-Felder im Modus NULLABLE sein.

• Wenn das Schema des Themas zusätzliche Felder enthält, die im BigQuery-Schema nicht vorhanden sind, und diese Felder gelöscht werden können, wählen Sie die Option Unbekannte Felder löschen aus.

• Sie können nur eine der Aboattribute auswählen: Schema des Themas verwenden oder Tabellenschema verwenden.

Wenn Sie die Option Schema des Themas verwenden oder Tabellenschema verwenden nicht auswählen, muss die BigQuery-Tabelle eine Spalte namens data vom Typ BYTES, STRING oder JSON enthalten. Pub/Sub schreibt die Nachricht in diese BigQuery-Spalte.

Änderungen am Schema der Pub/Sub-Themen oder BigQuery-Tabellen werden möglicherweise nicht sofort wirksam, wenn Nachrichten in die BigQuery-Tabelle geschrieben werden. Wenn beispielsweise die Option Unbekannte Felder löschen aktiviert ist und im Pub/Sub-Schema ein Feld, aber nicht im BigQuery-Schema vorhanden ist, enthalten auch in die BigQuery-Tabelle geschriebene Nachrichten das Feld möglicherweise trotzdem nicht, nachdem es dem BigQuery-Schema hinzugefügt wurde. Schließlich werden die Schemas synchronisiert und nachfolgende Nachrichten enthalten das Feld.

Wenn Sie die Option Schema des Themas verwenden für Ihr BigQuery-Abo verwenden, können Sie auch die BigQuery-Change Data Capture (CDC) nutzen. CDC aktualisiert Ihre BigQuery-Tabellen durch Verarbeitung und Anwendung von Änderungen auf vorhandene Zeilen.

Weitere Informationen zu dieser Funktion finden Sie unter Tabellenaktualisierungen mit Change Data Capture streamen.

Informationen zur Verwendung dieses Features mit BigQuery-Abos finden Sie unter BigQuery Change Data Capture.

Tabellenschema verwenden

Mit dieser Option kann Pub/Sub das Schema der BigQuery-Tabelle verwenden, um die Felder einer JSON-Nachricht in die entsprechenden Spalten zu schreiben. Wenn Sie diese Option verwenden, müssen Sie die folgenden zusätzlichen Anforderungen prüfen:

• Veröffentlichte Nachrichten müssen im JSON-Format vorliegen.

• Wenn dem Thema des Abos ein Schema zugeordnet ist, muss das Attribut für die Nachrichtencodierung auf JSON festgelegt werden.

• Wenn BigQuery-Felder vorhanden sind, die nicht in den Nachrichten vorhanden sind, müssen diese BigQuery-Felder im Modus NULLABLE sein.

• Wenn die Nachrichten zusätzliche Felder enthalten, die im BigQuery-Schema nicht vorhanden sind, und diese Felder gelöscht werden können, wählen Sie die Option Unbekannte Felder löschen aus.

• In der JSON-Nachricht müssen die Werte für DATE, DATETIME, TIME und TIMESTAMP Ganzzahlen sein, die den unterstützten Darstellungen entsprechen.

• In der JSON-Nachricht müssen die Werte NUMERIC und BIGNUMERIC mit BigDecimalByteStringEncoder in Byte codiert werden.

• Sie können nur eine der Aboattribute auswählen: Schema des Themas verwenden oder Tabellenschema verwenden.

Wenn Sie die Option Schema des Themas verwenden oder Tabellenschema verwenden nicht auswählen, muss die BigQuery-Tabelle eine Spalte namens data vom Typ BYTES, STRING oder JSON enthalten. Pub/Sub schreibt die Nachricht in diese BigQuery-Spalte.

Änderungen am BigQuery-Tabellenschema werden möglicherweise nicht sofort wirksam, wenn Nachrichten in die BigQuery-Tabelle geschrieben werden. Wenn beispielsweise die Option Unbekannte Felder löschen aktiviert ist und ein Feld in den Nachrichten, aber nicht im BigQuery-Schema vorhanden ist, enthalten Nachrichten, die in die BigQuery-Tabelle geschrieben werden, das Feld nach dem Hinzufügen zum BigQuery-Schema möglicherweise immer noch nicht. Schließlich wird das Schema synchronisiert und nachfolgende Nachrichten enthalten das Feld.

Wenn Sie die Option Tabellenschema verwenden für Ihr BigQuery-Abo verwenden, können Sie auch die Vorteile von BigQuery Change Data Capture (CDC) nutzen. CDC aktualisiert Ihre BigQuery-Tabellen durch Verarbeitung und Anwendung von Änderungen auf vorhandene Zeilen.

Weitere Informationen zu dieser Funktion finden Sie unter Tabellenaktualisierungen mit Change Data Capture streamen.

Informationen zur Verwendung dieses Features mit BigQuery-Abos finden Sie unter BigQuery Change Data Capture.

Unbekannte Felder löschen

Diese Option wird mit der Option Schema des Themas verwenden oder Tabellenschema verwenden verwendet. Mit dieser Option kann Pub/Sub alle Felder löschen, die im Schema oder der Nachricht des Themas, aber nicht im BigQuery-Schema vorhanden sind. Wenn Unbekannte Felder löschen nicht festgelegt ist, werden Nachrichten mit zusätzlichen Feldern nicht in BigQuery geschrieben und verbleiben im Rückstand des Abos. Das Abo erhält am Ende einen Fehlerstatus.

Metadaten schreiben

Mit dieser Option kann Pub/Sub die Metadaten jeder Nachricht in zusätzliche Spalten in der BigQuery-Tabelle schreiben. Andernfalls werden die Metadaten nicht in die BigQuery-Tabelle geschrieben.

Wenn Sie die Option Metadaten schreiben auswählen, muss die BigQuery-Tabelle die in der folgenden Tabelle beschriebenen Felder enthalten.

Wenn Sie die Option Metadaten schreiben nicht auswählen, benötigt die BigQuery-Tabelle nur das Feld data, sofern use_topic_schema nicht wahr ist. Wenn Sie sowohl die Option Metadaten schreiben als auch Schema des Themas verwenden auswählen, darf das Schema des Themas keine Felder mit Namen enthalten, die mit denen der Metadatenparameter übereinstimmen. Diese Einschränkung gilt auch für Camelcase-Versionen dieser Snake Case-Parameter.

Parameter
subscription_name	STRING Name eines Abos.
message_id	STRING ID einer Nachricht
publish_time	TIMESTAMP Der Zeitpunkt der Veröffentlichung einer Nachricht.
data	BYTES, STRING oder JSON Der Inhalt der Nachricht. Das Feld data ist für alle BigQuery-Zieltabellen erforderlich, für die nicht Schema des Themas verwenden ausgewählt ist. Wenn das Feld vom Typ „JSON“ ist, muss der Nachrichtentext eine gültige JSON-Datei sein.
attributes	STRING oder JSON Ein JSON-Objekt, das alle Nachrichtenattribute enthält. Außerdem enthält es zusätzliche Felder, die Teil der Pub/Sub-Nachricht sind, einschließlich des Sortierungsschlüssels, falls vorhanden.

Cloud Storage-Attribute

Wenn Sie In Cloud Storage schreiben als Zustellungstyp für das Abo auswählen, können Sie die folgenden zusätzlichen Attribute angeben.

Bucket-Name

Ein Cloud Storage-Bucket muss bereits vorhanden sein, bevor Sie ein Cloud Storage-Abo erstellen.

Die Nachrichten werden als Batches gesendet und im Cloud Storage-Bucket gespeichert. Ein einzelner Batch oder eine einzelne Datei wird als Objekt im Bucket gespeichert.

Für den Cloud Storage-Bucket muss Anforderer bezahlt deaktiviert sein.

Informationen zum Erstellen eines Cloud Storage-Bucket finden Sie unter Buckets erstellen.

Präfix für Dateinamen, Suffix und Datum/Uhrzeit

Die vom Cloud Storage-Abo generierten Cloud Storage-Ausgabedateien werden als Objekte im Cloud Storage-Bucket gespeichert. Der Name des im Cloud Storage-Bucket gespeicherten Objekts hat das folgende Format: <file-prefix><UTC-date-time>_<uuid><file-suffix>.

Die folgende Liste enthält Details zum Dateiformat und zu den anpassbaren Feldern:

• <file-prefix> ist das benutzerdefinierte Präfix des Dateinamens. Dieses Feld ist optional.

• <UTC-date-time> ist ein anpassbarer, automatisch generierter String, der auf dem Erstellungsdatum des Objekts basiert.

• <uuid> ist ein automatisch generierter zufälliger String für das Objekt.

• <file-suffix> ist das benutzerdefinierte Suffix des Dateinamens. Dieses Feld ist optional. Das Suffix des Dateinamens darf nicht mit „/“ enden.

• Sie können das Präfix und Suffix des Dateinamens ändern:

  • Wenn der Wert des Dateinamenpräfixes beispielsweise prod_ und der Wert des Suffixes des Dateinamens _archive lautet, ist ein Beispielobjektname prod_2023-09-25T04:10:00+00:00_uN1QuE_archive.

  • Wenn Sie kein Präfix und Suffix des Dateinamens angeben, hat der im Cloud Storage-Bucket gespeicherte Objektname das folgende Format: <UTC-date-time>_<uuid>.

  • Die Anforderungen für die Benennung von Cloud Storage-Objekten gelten auch für Präfixe und Suffixe von Dateinamen. Weitere Informationen finden Sie unter Informationen zu Cloud Storage-Objekten.

• Sie können ändern, wie Datum und Uhrzeit im Dateinamen angezeigt werden:

  • Erforderliche Datum/Uhrzeit-Matcher, die Sie nur einmal verwenden können: Jahr (YYYY oder YY), Monat (MM), Tag (DD), Stunde (hh), Minute (mm), Sekunde (ss). Beispielsweise ist YY-YYYY oder MMM ungültig.

  • Optionale Abgleicher, die Sie nur einmal verwenden können: Datum/Uhrzeit-Trennzeichen (T) und Zeitzonenversatz (Z oder +00:00).

  • Optionale Elemente, die Sie mehrmals verwenden können: Bindestrich (-), Unterstrich (_), Doppelpunkt (:) und Schrägstrich (/).

  • Wenn der Wert des Datums-/Uhrzeitformats beispielsweise YYYY-MM-DD/hh_mm_ssZ ist, lautet der Name eines Beispielobjekts prod_2023-09-25/04_10_00Z_uNiQuE_archive.

  • Wenn das Datum/Uhrzeit-Format des Dateinamens mit einem Zeichen endet, das kein Matcher ist, ersetzt dieses Zeichen das Trennzeichen zwischen <UTC-date-time> und <uuid>. Wenn der Wert des Datums-/Uhrzeitformats beispielsweise YYYY-MM-DDThh_mm_ss- ist, lautet der Name eines Beispielobjekts prod_2023-09-25T04_10_00-uNiQuE_archive.

Batch-Verarbeitung von Dateien

Mit Cloud Storage-Abos können Sie entscheiden, wann Sie eine neue Ausgabedatei erstellen möchten, die als Objekt im Cloud Storage-Bucket gespeichert wird. Pub/Sub schreibt eine Ausgabedatei, wenn eine der angegebenen Batchbedingungen erfüllt ist. Für die Batchverarbeitung von Cloud Storage gelten folgende Bedingungen:

• Maximale Speicher-Batchdauer. Diese Einstellung ist erforderlich. Das Cloud Storage-Abo schreibt eine neue Ausgabedatei, wenn der angegebene Wert für die maximale Dauer überschritten wird. Wenn Sie keinen Wert angeben, wird ein Standardwert von 5 Minuten angewendet. Die folgenden Werte sind für die maximale Dauer gültig:

  • Mindestwert = 1 Minute
  • Standardwert = 5 Minuten
  • Maximalwert = 10 Minuten

• Max. Storage-Batchbyte. Diese Einstellung ist optional. Das Cloud Storage-Abo schreibt eine neue Ausgabedatei, wenn der angegebene Wert für die maximale Bytezahl überschritten wird. Im Folgenden sind die gültigen Werte für die maximale Anzahl von Byte aufgeführt:

  • Mindestwert = 1 KB
  • Maximalwert = 10 GiB

Beispielsweise können Sie die maximale Dauer mit 6 Minuten und die maximalen Byte mit 2 GB konfigurieren. Wenn die Ausgabedatei in der vierten Minute eine Dateigröße von 2 GB erreicht, schließt Pub/Sub die vorherige Datei ab und beginnt mit dem Schreiben in eine neue Datei.

Ein Cloud Storage-Abo kann gleichzeitig in mehrere Dateien in einem Cloud Storage-Bucket schreiben. Wenn Sie Ihr Abo so konfiguriert haben, dass alle sechs Minuten eine neue Datei erstellt wird, werden möglicherweise mehrere Cloud Storage-Dateien alle sechs Minuten erstellt.

Es kann vorkommen, dass Pub/Sub schon früher in eine neue Datei schreibt als in den Bedingungen für die Datei-Batchverarbeitung. Eine Datei kann auch den Wert für „Max. Byte“ überschreiten, wenn das Abo Nachrichten empfängt, die größer als der Wert „Max. Byte“ sind.

Dateiformat

Wenn Sie ein Cloud Storage-Abo erstellen, können Sie das Format der Ausgabedateien, die in einem Cloud Storage-Bucket gespeichert werden sollen, als Text oder Avro angeben.

• Text: Die Nachrichten werden im Nur-Text-Format gespeichert. Durch ein Zeilenumbruchzeichen wird eine Nachricht von der vorherigen Nachricht in der Datei getrennt. Es werden nur Nachrichtennutzlasten gespeichert, keine Attribute oder andere Metadaten.

• Avro: Die Nachrichten werden im Apache Avro-Binärformat gespeichert.

  Wenn Sie Avro auswählen, können Sie zusätzlich die Option Metadaten schreiben aktivieren. Mit dieser Option können Sie die Metadaten der Nachricht zusammen mit der Nachricht speichern.

  Metadaten wie subscription_name, message_id, publish_time und Attributfelder werden in Felder der obersten Ebene im Avro-Ausgabeobjekt geschrieben, während alle anderen Nachrichtenattribute mit Ausnahme von Daten (z. B. ein Sortierungsschlüssel, falls vorhanden) als Einträge der Attributzuordnung hinzugefügt werden.

  Wenn Write metadata (Metadaten schreiben) deaktiviert ist, wird nur die Nachrichtennutzlast in das Avro-Ausgabeobjekt geschrieben.

  Hier ist das Avro-Schema für die Ausgabenachrichten, für das Metadaten schreiben nicht aktiviert ist:

  {
    "type": "record",
    "namespace": "com.google.pubsub",
    "name": "PubsubMessage",
    "fields": [
      { "name": "data", "type": "bytes" }
    ]
  }
  

  Hier ist das Avro-Schema für die Ausgabenachrichten, für die Metadaten schreiben aktiviert ist:

  {
    "type": "record",
    "namespace": "com.google.pubsub",
    "name": "PubsubMessageWithMetadata",
    "fields": [
      { "name": "subscription_name", "type": "string" },
      { "name": "message_id", "type": "string"  },
      { "name": "publish_time", "type": {
          "type": "long",
          "logicalType": "timestamp-micros"
        }
      },
      { "name": "attributes", "type": { "type": "map", "values": "string" } },
      { "name": "data", "type": "bytes" }
    ]
  }
  

Nächste Schritte

• Erstellen Sie ein Pull-Abo.
• Erstellen Sie ein Push-Abo.
• Erstellen Sie ein BigQuery-Abo.
• Erstellen Sie ein Cloud Storage-Abo.