Abo-Attribute

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

In diesem Dokument werden die verschiedenen Aboeigenschaften beschrieben. die Sie für ein Abo festlegen können.

Hinweis

Allgemeine Abo-Properties

Wenn Sie ein Abo erstellen, müssen Sie eine Reihe von Optionen um das Abo einzurichten. Einige dieser Properties sind für alle Abotypen gleich und werden in den folgenden Abschnitten erläutert.

Aufbewahrungsdauer für Nachrichten

Die Option Nachrichtenaufbewahrungsdauer gibt an, wie lange Pub/Sub Nachrichten werden nach der Veröffentlichung aufbewahrt. Nach Ablauf der Nachrichtenaufbewahrungsdauer kann Pub/Sub die Nachricht unabhängig vom Bestätigungsstatus der Nachricht verwerfen. So bewahren Sie bestätigte Nachrichten für Informationen zur Aufbewahrungsdauer von Nachrichten finden Sie unter Nachrichten wiedergeben und verwerfen.

Folgende Werte sind für die Option Aufbewahrungsdauer von Nachrichten verfügbar:

  • Standardwert: 7 Tage
  • Mindestwert = 10 Minuten
  • Höchstwert: 31 Tage

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

  • Inaktive Abos: Inaktive Abos löschen um zu vermeiden, dass Gebühren für die Aufbewahrung von Abonachrichten anfallen.

  • Sicherungsspeicher Wenn Sie die Aboaufbewahrung als Sicherungsspeicher verwenden, können Sie auch eine andere Speicheroption wie Aufbewahrung von Themennachrichten oder Aufbewahrung bestätigter Nachrichten. Bei der Aufbewahrung von Themennachrichten werden Nachrichten gespeichert einmal auf Themenebene und bleiben für alle Abos bei Bedarf zu nutzen.

  • Verarbeitungsverzögerungen Fügen Sie nach Möglichkeit weitere Abonnenten hinzu, Nachrichten innerhalb eines Tages senden.

Bestätigte Nachrichten speichern

Wenn Sie die Aufbewahrungsdauer für Nachrichten angeben, können Sie auch festlegen, ob bestätigte Nachrichten aufbewahrt werden sollen.

Mit der Option Bestätigte Nachrichten aufbewahren können Sie bestätigte Nachrichten für die angegebene Nachrichtenaufbewahrungsdauer aufbewahren. Dies erhöht die Gebühren für Nachrichtenspeicherung. 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 Abo-Attributen laufen ab. Erkennt Pub/Sub Aktivitäten von Abonnenten oder aktualisierst du eine der Aboeigenschaften, wird die Zeit bis zum Löschen des Abos wieder zurückgesetzt. Beispiele für Abonnentenaktivitäten Dazu gehören offene Verbindungen, aktive Pull- und erfolgreiche Push-Vorgänge.

Wenn Sie eine Ablauffrist angeben, muss der Wert länger sein als die im Feld Nachrichtenaufbewahrungsdauer.

Für die Option Ablaufzeitraum gelten folgende Werte:

  • Standardwert: 31 Tage
  • Mindestwert = 1 Tag

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

Bestätigungsfrist

Mit der Option Bestätigungsfrist wird die ursprüngliche Frist angegeben, nach der eine unbestätigte Nachricht noch einmal gesendet wird. Du kannst die Bestätigung verlängern Frist pro Nachricht durch Senden nachfolgender ModifyAckDeadline -Anfragen.

Für die Option Bestätigungsfrist gibt es folgende Werte:

  • Standardwert = 10 Sekunden
  • Mindestwert: 10 Sekunden
  • Höchstwert = 600 Sekunden

In einigen Fällen können Pub/Sub-Clientbibliotheken die Auslieferungsrate steuern und die Bestätigungsfrist dynamisch ändern. In diesem Fall wird die Nachricht möglicherweise vor dem von Ihnen festgelegten Termin für die Bestätigung noch einmal gesendet. Wenn Sie dieses Verhalten überschreiben möchten, verwenden Sie minDurationPerAckExtension und maxDurationPerAckExtension. Weitere Informationen zur Verwendung dieser Werte finden Sie unter Unterstützung der genau einmaligen Zustellung in Clientbibliotheken.

Abo-Filter

Verwende die Option Abofilter, um einen String mit einem Filterausdruck. Wenn ein Abo einen Filter hat, stellt das Abo nur die Nachrichten zu die dem Filter entsprechen. Der Pub/Sub-Dienst wird automatisch bestätigt die Nachrichten, die nicht mit dem Filter übereinstimmen.

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

  • Wenn kein Wert angegeben ist, werden Nachrichten und erhalten Abonnenten 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, gibt die Methode Abonnenten-Clients empfangen Nachrichten, die in derselben Region mit dem Reihenfolge, in der die Nachrichten vom Dienst empfangen wurden.

Bei 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, Pub/Sub liefert Nachrichten in der richtigen Reihenfolge angezeigt.

Ist dies nicht festgelegt, stellt Pub/Sub Nachrichten möglicherweise nicht in der richtigen Reihenfolge zu, auch wenn sie einen Sortierungsschlüssel haben.

Thema für unzustellbare Nachrichten

Wenn eine Nachricht nach einer festgelegten Anzahl von Zustellversuchen nicht zugestellt werden kann oder ein Abonnent sie nicht bestätigen kann, können Sie ein Thema für unzustellbare Nachrichten konfigurieren, unter 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. Die folgenden Werte sind für die maximale Anzahl von Zustellungsversuchen für das Thema für unzustellbare Nachrichten zulässig:

  • Standardwert = 5 Zustellversuche
  • Mindestwert = 5 Übermittlungsversuche
  • Höchstwert = 100 Zustellversuche

Wenn sich das Thema für unzustellbare Nachrichten in einem anderen Projekt als das Abo befindet, muss außerdem die Projekt-ID mit dem Thema für unzustellbare Nachrichten angeben.

Weitere Informationen finden Sie unter An Themen für unzustellbare Nachrichten weiterleiten.

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 erneute Übermittlungsversuch wird als Wiederholungsrichtlinie des Abos bezeichnet.

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

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

Hier finden Sie einige Richtlinien für die Festlegung der Werte für das maximale und minimale Backoff-Intervall:

  • Wenn Sie den maximalen Wert 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, wird der Standardwert für beträgt die maximale Backoff-Dauer 600 Sekunden.

  • Sie können maximal 600 Sekunden festlegen.

Wiederholungsrichtlinie und Batchnachrichten

Wenn sich Nachrichten in einem Batch befinden, startet Pub/Sub die exponentielle 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.

Pull-Aboattribute

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

Genau einmal zugestellt

Genau einmalige Zustellung. Wenn festgelegt, erfüllt Pub/Sub genau einmalige Zustellung garantiert. Wenn keine Angabe gemacht wird, unterstützt das Abo mindestens einmalige Zustellung pro Nachricht.

Push-Abo-Attribute

Beim Konfigurieren eines Push-Abos können Sie Folgendes angeben: Eigenschaften.

Endpunkte

Endpunkt-URL (erforderlich): Eine öffentlich zugängliche HTTPS-Adresse. Der Server für die Push-Übertragung Endpunkt muss ein gültiges SSL-Zertifikat haben, das von einer Zertifizierungsstelle signiert ist. 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 für Push keinen Nachweis der Inhaberschaft mehr Abo-URL-Domains. Wenn Ihre Domain unerwartete POST-Anfragen erhält aus Pub/Sub gesendet haben, können Sie einen verdächtigen Missbrauch melden.

Authentifizierung

Authentifizierung aktivieren. Wenn diese Option aktiviert ist, enthalten von Pub/Sub an den Push-Endpunkt gesendete Nachrichten einen Autorisierungsheader, über den der Endpunkt die Anfrage authentifizieren kann. Für App Engine Standard- und Cloud Run-Funktionen-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 nutzerverwalteten Dienstkonto und den Zielgruppenparametern, die in einem create-, patch- oder ModifyPushConfig-Aufruf angegeben werden. Außerdem müssen Sie einem Kundenservicemitarbeiter eine bestimmte Rolle zuweisen, wie im nächsten Abschnitt beschrieben.

  • Nutzerverwaltetes Dienstkonto (erforderlich). Das Dienstkonto, das dem Push-Abo zugeordnet ist. Dieses Konto wird als email-Anspruch des generierten JSON Web Tokens (JWT) verwendet. Im Folgenden finden Sie eine Liste der Anforderungen für das Dienstkonto:

  • Zielgruppe Ein einzelner String ohne Berücksichtigung der Groß- und Kleinschreibung, mit dem der Webhook die beabsichtigte Zielgruppe dieses bestimmten Tokens überprüfen kann.

  • Dienst-Agent (erforderlich)

    • Pub/Sub erstellt automatisch ein Dienstkonto für Sie mit dem Format service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com

    • Diesem Dienst-Agent muss die Berechtigung iam.serviceAccounts.getOpenIdToken (enthalten im roles/iam.serviceAccountTokenCreator Rolle), damit Pub/Sub JWT-Tokens für authentifizierte Push-Anfragen.

Entpacken der Nutzlast

Mit der Option Entpacken der Nutzlast aktivieren wird Pub/Sub entfernt. Nachrichten aller Metadaten der Nachricht mit Ausnahme der Nachrichtendaten. Mit Nutzlast werden die Nachrichtendaten direkt als HTTP-Text gesendet.

  • Metadaten schreiben Fügt zuvor entfernte Nachrichtenmetadaten wieder hinzu Anfrageheader.

BigQuery-Attribute

Wenn Sie als Abo-Zustellungstyp In BigQuery schreiben auswählen, können Sie die folgenden zusätzlichen Eigenschaften festlegen.

Schema des Themas verwenden

Mit dieser Option kann Pub/Sub das Schema des Pub/Sub-Themas an, Abo ist angehängt. Außerdem kann Pub/Sub schreibt die Felder in Nachrichten in den entsprechenden Spalten in der BigQuery-Tabelle.

Beachten Sie bei der Verwendung dieser Option die folgenden zusätzlichen Anforderungen:

  • Die Felder im Themaschema 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.

  • Erforderliche Felder im Themaschema müssen nicht im BigQuery-Schema erforderlich sein.

  • Wenn es BigQuery-Felder gibt, die nicht im Themaschema vorhanden sind, müssen diese BigQuery-Felder im Modus NULLABLE sein.

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

  • Sie können nur eine der Abo-Properties 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 haben. Pub/Sub schreibt die Nachricht in diese BigQuery-Spalte.

Änderungen am Pub/Sub-Themenschema oder 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 im Pub/Sub-Schema, aber nicht im BigQuery-Schema vorhanden ist, enthalten Nachrichten, die in die BigQuery-Tabelle geschrieben werden, das Feld möglicherweise auch dann nicht, wenn es dem BigQuery-Schema hinzugefügt wurde. Schließlich Die Schemasynchronisierung und nachfolgende Nachrichten enthalten das Feld.

Wenn Sie die Option Themenschema verwenden für Ihr BigQuery-Abo verwenden, können Sie auch BigQuery Change Data Capture (CDC) nutzen. CDC aktualisiert Ihre BigQuery-Tabellen verarbeitet und Änderungen auf vorhandene Zeilen angewendet.

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

Informationen zur Verwendung dieser Funktion mit BigQuery-Abos finden Sie unter BigQuery-Change Data Capture.

Schema der Tabelle 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. Denken Sie bei Verwendung dieser Option daran, Prüfen Sie die folgenden zusätzlichen Anforderungen:

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

  • Die folgenden JSON-Konvertierungen werden unterstützt:

    JSON-Typ BigQuery-Datentyp
    string NUMERIC, BIGNUMERIC, DATE, TIME, DATETIME oder TIMESTAMP
    number NUMERIC, BIGNUMERIC, DATE, TIME, DATETIME oder TIMESTAMP
    • Wenn Sie number bis DATE, DATETIME, TIME oder TIMESTAMP-Conversions verwenden, muss die Zahl den unterstützten Darstellungen entsprechen.
    • Wenn Sie die Konvertierung von number in NUMERIC oder BIGNUMERIC verwenden, sind die Genauigkeit und der Wertebereich auf die vom IEEE 754-Standard für Gleitkommaarithmetik akzeptierten Werte beschränkt. Wenn Sie eine hohe Genauigkeit oder einen größeren Wertebereich benötigen, verwenden Sie stattdessen Conversions vom Typ string bis NUMERIC oder BIGNUMERIC.
    • Bei der Verwendung von string- zu NUMERIC- oder BIGNUMERIC-Konvertierungen geht Pub/Sub davon aus, dass der String eine menschenlesbare Zahl ist (z.B. "123.124"). Wenn die Verarbeitung des Strings als menschenlesbare Zahl fehlschlägt, behandelt Pub/Sub den String als mit BigDecimalByteStringEncoder codierte Byte.
  • Wenn dem Thema des Abos ein Schema zugewiesen ist, muss die Eigenschaft „Nachrichtencodierung“ auf JSON festgelegt sein.

  • Wenn es BigQuery-Felder gibt, die in müssen diese BigQuery-Felder im Modus NULLABLE sein.

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

  • Sie können nur eine der Aboeigenschaften auswählen: Themaschema 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 haben. Pub/Sub schreibt die Nachricht in diese BigQuery-Spalte.

Änderungen am BigQuery-Tabellenschema werden möglicherweise nicht sofort für Nachrichten übernommen, die in die BigQuery-Tabelle geschrieben werden. Wenn beispielsweise die Option Unbekannte Felder löschen aktiviert ist und ein Feld die zwar in den Nachrichten vorhanden sind, aber nicht im BigQuery-Schema, Nachrichten, die in die BigQuery-Tabelle geschrieben wurden, enthalten möglicherweise nachdem es dem BigQuery-Schema hinzugefügt wurde. Nach einiger Zeit wird das Schema synchronisiert und nachfolgende Nachrichten enthalten das Feld.

Wenn Sie für Ihr BigQuery-Abo die Option Tabellenschema verwenden verwenden, können Sie auch 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 dieser Funktion mit BigQuery-Abos finden Sie unter Änderungsdatenerfassung in BigQuery.

Unbekannte Felder löschen

Diese Option wird mit der Option Schema des Themas verwenden oder Schema der Tabelle verwenden verwendet. Mit dieser Option kann Pub/Sub jedes im Thema vorhandene Feld löschen Schema oder Nachricht, aber nicht im BigQuery-Schema. 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. Die in einem Fehlerstatus endet.

Metadaten schreiben

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

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

Wenn Sie die Option Metadaten schreiben nicht auswählen, ist für die BigQuery-Zieltabelle nur das Feld data erforderlich, es sei denn, use_topic_schema ist wahr. 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 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 Nachrichtentext.

Das Feld data ist für alle BigQuery-Zieltabellen erforderlich, für die nicht Schema des Themas verwenden oder Tabellenschema verwenden ausgewählt ist. Wenn die vom Typ JSON ist, muss der Nachrichtentext gültigen JSON-Code.

attributes

STRING oder JSON

Ein JSON-Objekt mit allen Nachrichtenattributen. Außerdem enthält zusätzliche Felder, die Teil des Pub/Sub-Nachricht mit dem Schlüssel falls vorhanden.

Cloud Storage-Properties

Wenn du als Übermittlungstyp für das Abo In Cloud Storage schreiben auswählst, kannst du die folgenden zusätzlichen Properties 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 gespeichert. im Bucket.

Der Cloud Storage-Bucket muss Anforderer bezahlt deaktiviert.

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

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

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

Die folgende Liste enthält Details zum Dateiformat und zu den Feldern, die Sie anpassen können:

  • <file-prefix> ist das benutzerdefinierte Dateinamenpräfix. Dieses Feld ist optional.

  • <UTC-date-time> ist ein anpassbarer, automatisch generierter String, der auf dem Zeitpunkt basiert, zu dem das Objekt erstellt wurde.

  • <uuid> ist ein automatisch generierter Zufallsstring für das Objekt.

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

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

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

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

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

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

    • Erforderliche Datum/Uhrzeit-Abgleiche, die nur einmal verwendet werden können: Jahr (YYYY oder YY), Monat (MM), Tag (DD), Stunde (hh), Minute (mm), Sekunde (ss). YY-YYYY oder MMM sind beispielsweise ungültig.

    • Optionale Übereinstimmungen, die nur einmal verwendet werden können: Datums-/Uhrzeit-Trennzeichen (T) und Zeitzonendifferenz (Z oder +00:00).

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

    • Wenn der Wert des Dateinamens im Datums-/Uhrzeitformat beispielsweise YYYY-MM-DD/hh_mm_ssZ ist, ist ein Beispielobjektname prod_2023-09-25/04_10_00Z_uNiQuE_archive.

    • Wenn das Datetime-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 Dateinamens im Datums-/Uhrzeitformat beispielsweise YYYY-MM-DDThh_mm_ss- ist, ist ein Beispielobjektname prod_2023-09-25T04_10_00-uNiQuE_archive.

Batchverarbeitung von Dateien

Mit Cloud Storage-Abos können Sie entscheiden, wann Sie Eine neue Ausgabedatei, die als Objekt in Cloud Storage gespeichert wird Bucket. Pub/Sub schreibt eine Ausgabedatei, wenn einer der bestimmte Batching-Bedingungen erfüllt. Die folgenden Bedingungen gelten für die Batchverarbeitung in Cloud Storage:

  • Maximale Storage-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 keine wenn Sie den Wert angeben, wird ein Standardwert von 5 Minuten angewendet. Folgende Werte sind für die maximale Dauer zulässig:

    • Mindestwert = 1 Minute
    • Standardwert: 5 Minuten
    • Höchstwert = 10 Minuten
  • Max. Storage-Batchbyte Diese Einstellung ist optional. Die Das Cloud Storage-Abo schreibt eine neue Ausgabedatei, der angegebene Wert der maximalen Byte wurde überschritten. Im Folgenden finden Sie Werte für maximale Byte:

    • Mindestwert = 1 KB
    • Maximalwert = 10 GiB
  • Nachrichten zur maximalen Storage-Batchzahl. Diese Einstellung ist optional. Das Cloud Storage-Abo schreibt eine neue Ausgabedatei, wenn die angegebene maximale Anzahl von Nachrichten überschritten wird. Folgende Werte sind für „max. Nachrichten“ zulässig:

    • Mindestwert = 1.000

Sie können beispielsweise „max_duration“ auf 6 Minuten und „max_bytes“ auf 2 GB konfigurieren. Wenn in der 4. Minute die Ausgabedatei einen Dateigröße von 2 GB abgeschlossen ist, schließt Pub/Sub die vorherige Datei in eine neue Datei schreiben.

Ein Cloud Storage-Abo schreibt möglicherweise in mehrere Dateien Cloud Storage-Bucket gleichzeitig ausführen. Wenn Sie Ihr die jede sechste Minute eine neue Datei erstellt, Alle 6 Minuten werden mehrere Cloud Storage-Dateien erstellt.

Es kann vorkommen, dass Pub/Sub vor dem in den Bedingungen für die Datei-Batchverarbeitung konfigurierten Zeitpunkt liegt. Eine Datei kann auch den Wert „Max. Bytes“ überschreiten, wenn das Abo Nachrichten empfängt, die größer als der Wert „Max. Bytes“ sind.

Dateiformat

Beim Erstellen eines Cloud Storage-Abos können Sie das Format der Ausgabedateien, die in einem Cloud Storage-Bucket als Text oder Avro.

  • Text: Die Nachrichten werden als Nur-Text gespeichert. Ein Zeilenumbruch trennt eine Nachricht von der vorherigen Nachricht in der Datei. Es werden nur Nachrichtennutzlasten gespeichert, keine Attribute oder anderen Metadaten.

  • Avro: Die Nachrichten werden im binären Apache Avro-Format gespeichert. Wenn Sie Avro auswählen, können Sie die folgenden zusätzlichen Properties aktivieren:

    • Metadaten schreiben: Mit dieser Option können Sie die Nachrichtenmetadaten zusammen mit der Nachricht speichern. Metadaten wie subscription_name-, message_id-, publish_time- und attributes-Felder werden in die obersten Felder des Ausgabe-Avro-Objekts geschrieben. Alle anderen Nachrichteneigenschaften außer Daten (z. B. ein vorhandener „ordering_key“) werden als Einträge in die attributes-Map eingefügt.

      Wenn Metadaten schreiben deaktiviert ist, wird nur die Nachrichtennutzlast in das Avro-Ausgabeobjekt geschrieben. Hier ist das Avro-Schema für die Ausgabenachrichten, bei dem Metadaten schreiben deaktiviert ist:

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

      Hier ist das Avro-Schema für die Ausgabenachrichten mit aktivierter Option Metadaten schreiben:

      {
        "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" }
        ]
      }
      
    • Schema des Themas verwenden: Mit dieser Option kann Pub/Sub beim Schreiben von Avro-Dateien das Schema des Pub/Sub-Themas verwenden, an das das Abo angehängt ist.

      Beachten Sie bei Verwendung dieser Option die folgenden zusätzlichen Anforderungen:

      • Das Schema des Themas muss im Apache Avro-Format vorliegen.

      • Wenn sowohl Topic-Schema verwenden als auch Metadaten schreiben aktiviert sind, muss das Topic-Schema ein Record-Objekt als Stamm haben. Pub/Sub erweitert die Felderliste des Eintrags um die Metadatenfelder. Daher darf der Datensatz keine Felder mit demselben Namen wie die Metadatenfelder (subscription_name, message_id, publish_time oder attributes) enthalten.

Nächste Schritte