BigQuery-Abos

Dieses Dokument bietet eine Übersicht über ein BigQuery-Abo, seinen Workflow und die zugehörigen Attribute.

Ein BigQuery-Abo ist ein Exportabo, mit dem Nachrichten bei Eingang in eine vorhandene BigQuery-Tabelle geschrieben werden. Du musst keinen separaten Abonnentenclient konfigurieren. Verwenden Sie die Google Cloud Console, die Google Cloud CLI, die Clientbibliotheken oder die Pub/Sub API, um ein BigQuery-Abo zu erstellen, zu aktualisieren, aufzulisten, zu trennen oder zu löschen.

Ohne den BigQuery-Abotyp benötigen Sie ein Pull- oder Push-Abo und einen Abonnenten (z. B. Dataflow), der Nachrichten liest und in eine BigQuery-Tabelle schreibt. Der Aufwand für das Ausführen eines Dataflow-Jobs ist nicht erforderlich, wenn Nachrichten keine zusätzliche Verarbeitung erfordern, bevor sie in einer BigQuery-Tabelle gespeichert werden. Sie können stattdessen ein BigQuery-Abo verwenden.

Eine Dataflow-Pipeline wird jedoch weiterhin für Pub/Sub-Systeme empfohlen, bei denen eine Datentransformation erforderlich ist, bevor die Daten in einer BigQuery-Tabelle gespeichert werden. Informationen zum Streamen von Daten von Pub/Sub zu BigQuery durch Transformation mithilfe von Dataflow finden Sie unter Von Pub/Sub zu BigQuery streamen.

Das Pub/Sub-Abo für BigQuery-Vorlage von Dataflow erzwingt standardmäßig genau eine Zustellung. Dies wird in der Regel durch Deduplizierungsmechanismen in der Dataflow-Pipeline erreicht. Das BigQuery-Abo unterstützt jedoch nur eine Zustellung. Wenn eine genaue Deduplizierung für Ihren Anwendungsfall wichtig ist, sollten Sie nachgelagerte Prozesse in BigQuery zur Handhabung potenzieller Duplikate in Betracht ziehen.

Hinweise

Machen Sie sich vor dem Lesen dieses Dokuments mit Folgendem vertraut:

  • Funktionsweise von Pub/Sub und die verschiedenen Pub/Sub-Begriffe

  • Welche Arten von Abos Pub/Sub unterstützt und warum Sie ein BigQuery-Abo verwenden sollten

  • Wie BigQuery funktioniert und wie BigQuery-Tabellen konfiguriert und verwaltet werden

Workflow für BigQuery-Abos

Die folgende Abbildung zeigt den Workflow zwischen einem BigQuery-Abo und BigQuery.

Nachrichtenfluss für ein BigQuery-Abo
Abbildung 1. Workflow für ein BigQuery-Abo

Es folgt eine kurze Beschreibung des Workflows, der auf Abbildung 1 verweist:

  1. Pub/Sub verwendet die BigQuery Storage Write API, um Daten an die BigQuery-Tabelle zu senden.
  2. Die Nachrichten werden in Batches an die BigQuery-Tabelle gesendet.
  3. Nach erfolgreichem Abschluss eines Schreibvorgangs gibt die API eine OK-Antwort zurück.
  4. Wenn beim Schreibvorgang Fehler auftreten, wird die Pub/Sub-Nachricht selbst negativ quittiert. Die Nachricht wird dann noch einmal gesendet. Wenn die Nachricht häufig fehlschlägt und für das Abo ein Thema für unzustellbare Nachrichten konfiguriert ist, wird die Nachricht in das Thema für unzustellbare Nachrichten verschoben.

Attribute eines BigQuery-Abos

Die Attribute, die Sie für ein BigQuery-Abo konfigurieren, bestimmen die BigQuery-Tabelle, in die Pub/Sub Nachrichten schreibt, sowie den Schematyp dieser Tabelle.

Weitere Informationen finden Sie unter BigQuery-Attribute.

Schemakompatibilität

Pub/Sub und BigQuery verwenden unterschiedliche Methoden zum Definieren ihrer Schemas. Pub/Sub-Schemas sind im Apache Avro- oder Protocol Buffer-Format definiert, BigQuery-Schemas hingegen werden mit verschiedenen Formaten definiert. Im Folgenden finden Sie eine Liste wichtiger Informationen zur Schemakompatibilität zwischen einem Pub/Sub-Thema und einer BigQuery-Tabelle.

  • Nachrichten, die ein falsch formatiertes Feld enthalten, werden nicht in BigQuery geschrieben.

  • Im BigQuery-Schema sind INT, SMALLINT, INTEGER, BIGINT, TINYINT und BYTEINT Aliasse für INTEGER. DECIMAL ist ein Alias für NUMERIC und BIGDECIMAL ein Alias für BIGNUMERIC.

  • Wenn der Typ im Schema des Themas string und der Typ in der BigQuery-Tabelle JSON, TIMESTAMP, DATETIME, DATE, TIME, NUMERIC oder BIGNUMERIC ist, muss jeder Wert für dieses Feld in einer Pub/Sub-Nachricht dem Format entsprechen, das für den BigQuery-Datentyp festgelegt wurde.

  • Einige logische Avro-Typen werden unterstützt, wie in der folgenden Tabelle angegeben. Alle nicht aufgeführten logischen Typen entsprechen nur dem entsprechenden Avro-Typ, den sie annotieren, wie in der Avro-Spezifikation beschrieben.

Im Folgenden finden Sie eine Übersicht über die Zuordnung verschiedener Schemaformate zu BigQuery-Datentypen.

Avro-Typen

Avro-Typ BigQuery-Datentyp
null Any NULLABLE
boolean BOOLEAN
int INTEGER, NUMERIC oder BIGNUMERIC
long INTEGER, NUMERIC oder BIGNUMERIC
float FLOAT64, NUMERIC oder BIGNUMERIC
double FLOAT64, NUMERIC oder BIGNUMERIC
bytes BYTES, NUMERIC oder BIGNUMERIC
string STRING, JSON, TIMESTAMP, DATETIME, DATE, TIME, NUMERIC oder BIGNUMERIC
record RECORD/STRUCT
array von Type REPEATED Type
map mit dem Werttyp ValueType REPEATED STRUCT <key STRING, value ValueType>
union mit den beiden Typen null und dem anderen Type NULLABLE Type
andere union Nicht zugeordnet
fixed BYTES, NUMERIC oder BIGNUMERIC
enum INTEGER

Logische Avro-Typen

Logischer Avro-Typ BigQuery-Datentyp
timestamp-micros TIMESTAMP
date DATE
time-micros TIME
duration INTERVAL

Protokollzwischenspeichertypen

Protokollzwischenspeichertyp BigQuery-Datentyp
double FLOAT64, NUMERIC oder BIGNUMERIC
float FLOAT64, NUMERIC oder BIGNUMERIC
int32 INTEGER, NUMERIC, BIGNUMERIC oder DATE
int64 INTEGER, NUMERIC, BIGNUMERIC, DATE, DATETIME oder TIMESTAMP
uint32 INTEGER, NUMERIC, BIGNUMERIC oder DATE
uint64 NUMERIC oder BIGNUMERIC
sint32 INTEGER, NUMERIC oder BIGNUMERIC
sint64 INTEGER, NUMERIC, BIGNUMERIC, DATE, DATETIME oder TIMESTAMP
fixed32 INTEGER, NUMERIC, BIGNUMERIC oder DATE
fixed64 NUMERIC oder BIGNUMERIC
sfixed32 INTEGER, NUMERIC, BIGNUMERIC oder DATE
sfixed64 INTEGER, NUMERIC, BIGNUMERIC, DATE, DATETIME oder TIMESTAMP
bool BOOLEAN
string STRING, JSON, TIMESTAMP, DATETIME, DATE, TIME, NUMERIC oder BIGNUMERIC
bytes BYTES, NUMERIC oder BIGNUMERIC
enum INTEGER
message RECORD/STRUCT
oneof Nicht zugeordnet
map<KeyType, ValueType> REPEATED RECORD<key KeyType, value ValueType>
enum INTEGER
repeated/array of Type REPEATED Type

Ganzzahldarstellung für Datum und Uhrzeit

Bei der Zuordnung einer Ganzzahl zu einem der Datums- oder Uhrzeittypen muss die Zahl den richtigen Wert darstellen. Im Folgenden wird die Zuordnung von BigQuery-Datentypen zur jeweiligen Ganzzahl dargestellt.

BigQuery-Datentyp Ganzzahldarstellung
DATE Die Anzahl der Tage seit der Unix-Epoche, 1. Januar 1970
DATETIME Das Datum und die Uhrzeit in Mikrosekunden, ausgedrückt als amtliche Zeit unter Verwendung von CivilTimeEncoder.
TIME Die Zeit in Mikrosekunden, ausgedrückt als amtliche Zeit unter Verwendung von CivilTimeEncoder.
TIMESTAMP Die Anzahl der Mikrosekunden seit der Unix-Epoche, 1. Januar 1970, 00:00:00 Uhr (UTC)

Change Data Capture in BigQuery

BigQuery-Abos unterstützen Updates für Change Data Capture (CDC), wenn use_topic_schema oder use_table_schema in den Aboattributen auf true festgelegt ist. Wenn Sie das Feature mit use_topic_schema verwenden möchten, legen Sie das Schema des Themas mit den folgenden Feldern fest:

  • _CHANGE_TYPE (erforderlich): Das Feld string ist auf UPSERT oder DELETE festgelegt.

    • Wenn bei einer Pub/Sub-Nachricht, die in die BigQuery-Tabelle geschrieben wird, _CHANGE_TYPE auf UPSERT gesetzt ist, aktualisiert BigQuery die Zeile mit demselben Schlüssel, sofern vorhanden, oder fügt eine neue Zeile ein, wenn nicht.

    • Wenn bei einer Pub/Sub-Nachricht, die in die BigQuery-Tabelle geschrieben wird, _CHANGE_TYPE auf DELETE gesetzt ist, löscht BigQuery die Zeile in der Tabelle mit demselben Schlüssel, sofern vorhanden.

  • _CHANGE_SEQUENCE_NUMBER (optional): Ein Feld int64 (long) oder int32 (int), mit dem Aktualisierungen und Löschvorgänge an der BigQuery-Tabelle der Reihe nach verarbeitet werden. Nachrichten für denselben Zeilenschlüssel müssen einen kontinuierlich ansteigenden Wert für _CHANGE_SEQUENCE_NUMBER enthalten. Nachrichten mit Sequenznummern, die kleiner als die höchste für eine Zeile verarbeitete Sequenznummer sind, haben keine Auswirkungen auf die Zeile in der BigQuery-Tabelle.

Wenn Sie das Feature mit use_table_schema verwenden möchten, fügen Sie die vorangegangenen Felder in die JSON-Nachricht ein.

Berechtigungen des Pub/Sub-Dienstkontos

Zum Erstellen eines BigQuery-Abos muss das Pub/Sub-Dienstkonto die Berechtigung zum Schreiben in die jeweilige BigQuery-Tabelle und zum Lesen der Tabellenmetadaten haben. Weitere Informationen finden Sie unter Dem Pub/Sub-Dienstkonto BigQuery-Rollen zuweisen.

Fehler bei Nachrichten beheben

Wenn eine Pub/Sub-Nachricht nicht in BigQuery geschrieben werden kann, kann die Nachricht nicht bestätigt werden. Konfigurieren Sie ein Thema für unzustellbare Nachrichten im BigQuery-Abo, um solche nicht zustellbaren Nachrichten weiterzuleiten. Die an das Thema für unzustellbare Nachrichten weitergeleitete Pub/Sub-Nachricht enthält das Attribut CloudPubSubDeadLetterSourceDeliveryErrorMessage mit dem Grund, dass die Pub/Sub-Nachricht nicht in BigQuery geschrieben werden konnte.

Kontingente und Limits

Es gibt Kontingentbeschränkungen für den BigQuery-Abonnentendurchsatz pro Region. Weitere Informationen finden Sie unter Pub/Sub-Kontingente und -Limits.

BigQuery-Abos schreiben Daten mithilfe der BigQuery Storage Write API. Informationen zu den Kontingenten und Limits für die Storage Write API finden Sie unter BigQuery Storage Write API-Anfragen. BigQuery-Abos verbrauchen nur das Durchsatzkontingent für die Storage Write API. Sie können die anderen Überlegungen zum Storage Write API-Kontingent in dieser Instanz ignorieren.

Preise

Informationen zu den Preisen für BigQuery-Abos finden Sie auf der Seite Pub/Sub-Preise.

Nächste Schritte