Abonnements BigQuery

Ce document présente un abonnement BigQuery, son flux de travail et les propriétés associées.

Un abonnement BigQuery est un type d'abonnement d'exportation qui écrit des messages dans une table BigQuery existante qu'elles soient reçues. Vous n'avez pas besoin de configurer un client abonné distinct. utiliser la console Google Cloud, la Google Cloud CLI, les bibliothèques clientes ou l'API Pub/Sub pour créer, mettre à jour, répertorier, dissocier ou supprimer Abonnement BigQuery.

Sans le type d'abonnement BigQuery, vous avez besoin d'un abonnement pull ou push, (comme Dataflow) qui lit les messages et les écrit dans une table BigQuery. Les frais généraux liés à l'exécution Le job Dataflow n'est pas nécessaire lorsque les messages ne nécessitent pas un traitement supplémentaire avant de les stocker dans une table BigQuery, vous pouvez utiliser un abonnement BigQuery à la place.

Toutefois, un pipeline Dataflow est toujours recommandé Les systèmes Pub/Sub pour lesquels une transformation des données est requise avant les données sont stockées dans une table BigQuery. Pour apprendre à diffuser de Pub/Sub vers BigQuery grâce à la transformation à l'aide de Dataflow, consultez la section Flux de Pub/Sub vers dans BigQuery.

Le modèle d'abonnement Pub/Sub à BigQuery de Dataflow applique une distribution de type "exactement une fois" par par défaut. Cela est généralement possible grâce à des mécanismes de déduplication dans le pipeline Dataflow. Toutefois, l'API BigQuery L'abonnement ne peut être distribué qu'au moins une fois. Si la déduplication exacte est essentielles pour votre cas d'utilisation, tenez compte des processus en aval BigQuery pour gérer les doublons potentiels.

Avant de commencer

Avant de lire ce document, assurez-vous de maîtriser les points suivants:

  • le fonctionnement de Pub/Sub et les différentes Termes de Pub/Sub.

  • Les différents types d'abonnements compatibles avec Pub/Sub et pourquoi vous pourriez vouloir utiliser Abonnement BigQuery.

  • Fonctionnement et configuration de BigQuery et gérer des tables BigQuery.

Workflow d'abonnement BigQuery

L'image suivante illustre le workflow entre BigQuery et BigQuery.

Flux de messages pour un abonnement BigQuery
Figure 1. Workflow pour un abonnement BigQuery

Voici une brève description du workflow qui fait référence à la figure 1:

  1. Pub/Sub utilise le service d'écriture de données dans l'espace de stockage BigQuery pour envoyer des données à BigQuery tableau.
  2. Les messages sont envoyés par lots à la table BigQuery.
  3. À la fin d'une opération d'écriture, l'API renvoie une réponse de réponse.
  4. En cas d'échec de l'opération d'écriture, Le message Pub/Sub lui-même fait l'objet d'un accusé de réception négatif. La le message est ensuite renvoyé. Si le message échoue suffisamment de fois file d'attente de lettres mortes configuré sur l'abonnement, le message est déplacé à la file d'attente des lettres mortes.

Propriétés d'un abonnement BigQuery

Propriétés que vous configurez pour un abonnement BigQuery déterminer la table BigQuery dans laquelle Pub/Sub les messages et le type de schéma de cette table.

Pour en savoir plus, consultez la page BigQuery propriétés.

Compatibilité des schémas

Pub/Sub et BigQuery recourent à des méthodes différentes définir leurs schémas. Les schémas Pub/Sub sont définis dans Apache au format Avro ou Protocol Buffer, tandis que Les schémas BigQuery sont définis à l'aide d'un différents formats. Voici une liste des des informations importantes sur la compatibilité du schéma entre un sujet Pub/Sub et une table BigQuery.

  • Tout message contenant un champ dont le format est incorrect n'est pas écrit dans dans BigQuery.

  • Dans le schéma BigQuery, INT, SMALLINT, INTEGER BIGINT, TINYINT et BYTEINT sont des alias de INTEGER. DECIMAL est un alias pour NUMERIC ; et BIGDECIMAL est l'alias de BIGNUMERIC.

  • Lorsque le type dans le schéma du sujet est string et que le type dans le Table BigQuery : JSON, TIMESTAMP, DATETIME, DATE, TIME, NUMERIC ou BIGNUMERIC, puis toute valeur de ce champ dans une Le message Pub/Sub doit respecter le format spécifié pour le Données BigQuery par défaut.

  • Certains types logiques Avro sont compatibles, comme indiqué dans le tableau suivant. Tous les types logiques non répertoriés ne correspondent qu'au type Avro équivalent qu'ils annoter, comme indiqué dans la spécification Avro.

Voici un ensemble de mappages de différents formats de schéma Types de données BigQuery.

Types Avro

Type Avro Type de données BigQuery
null Any NULLABLE
boolean BOOLEAN
int INTEGER, NUMERIC ou BIGNUMERIC
long INTEGER, NUMERIC ou BIGNUMERIC
float FLOAT64, NUMERIC ou BIGNUMERIC
double FLOAT64, NUMERIC ou BIGNUMERIC
bytes BYTES, NUMERIC ou BIGNUMERIC
string STRING, JSON TIMESTAMP, DATETIME DATE, TIME NUMERIC ou BIGNUMERIC
record RECORD/STRUCT
array sur Type REPEATED Type
map avec le type de valeur ValueType REPEATED STRUCT <key STRING, value ValueType>
union avec deux types, dont un qui est null et l'autre Type NULLABLE Type
autres union Impossible à mapper
fixed BYTES, NUMERIC ou BIGNUMERIC
enum INTEGER

Types logiques Avro

Type logique Avro Type de données BigQuery
timestamp-micros TIMESTAMP
date DATE
time-micros TIME
duration INTERVAL
decimal NUMERIC ou BIGNUMERIC

Types de tampon de protocole

Type de tampon de protocole Type de données BigQuery
double FLOAT64, NUMERIC ou BIGNUMERIC
float FLOAT64, NUMERIC ou BIGNUMERIC
int32 INTEGER, NUMERIC BIGNUMERIC ou DATE
int64 INTEGER, NUMERIC BIGNUMERIC, DATE DATETIME ou TIMESTAMP
uint32 INTEGER, NUMERIC BIGNUMERIC ou DATE
uint64 NUMERIC ou BIGNUMERIC
sint32 INTEGER, NUMERIC ou BIGNUMERIC
sint64 INTEGER, NUMERIC BIGNUMERIC, DATE DATETIME ou TIMESTAMP
fixed32 INTEGER, NUMERIC BIGNUMERIC ou DATE
fixed64 NUMERIC ou BIGNUMERIC
sfixed32 INTEGER, NUMERIC BIGNUMERIC ou DATE
sfixed64 INTEGER, NUMERIC BIGNUMERIC, DATE DATETIME ou TIMESTAMP
bool BOOLEAN
string STRING, JSON TIMESTAMP, DATETIME DATE, TIME NUMERIC ou BIGNUMERIC
bytes BYTES, NUMERIC ou BIGNUMERIC
enum INTEGER
message RECORD/STRUCT
oneof Impossible à mapper
map<KeyType, ValueType> REPEATED RECORD<key KeyType, value ValueType>
enum INTEGER
repeated/array of Type REPEATED Type

Représentation sous forme de nombre entier de date et d'heure

Lors du mappage d'un entier à l'un des types de date ou d'heure, ce nombre doit représentent la valeur correcte. Voici le mappage à partir des données BigQuery à l'entier qui les représente.

Type de données BigQuery Représentation d'entiers
DATE Nombre de jours écoulés depuis l'epoch Unix, 1er janvier 1970
DATETIME Date et heure en microsecondes, exprimées en temps civil à l'aide du CivilTimeEncoder
TIME Temps en microsecondes, exprimé en temps civil à l'aide du CivilTimeEncoder
TIMESTAMP Nombre de microsecondes écoulées depuis l'epoch Unix, le 1er janvier 1970 à 00:00:00 UTC

Capture des données modifiées dans BigQuery

Les abonnements BigQuery sont compatibles avec la capture de données modifiées (CDC) des mises à jour use_topic_schema ou use_table_schema est défini sur true dans les propriétés de l'abonnement. Pour utiliser cette fonctionnalité avec use_topic_schema : définissez le schéma du sujet à l'aide de la commande champ suivant:

  • _CHANGE_TYPE (obligatoire): champ string défini sur UPSERT ou DELETE.

    • Si un message Pub/Sub écrit _CHANGE_TYPE de la table BigQuery est défini sur UPSERT. BigQuery met à jour la ligne avec la même clé si s'il existe ou insère une nouvelle ligne si ce n'est pas le cas.

    • Si un message Pub/Sub écrit _CHANGE_TYPE de la table BigQuery est défini sur DELETE. BigQuery supprime ensuite la ligne de la table comportant la la même clé, le cas échéant.

Pour utiliser l'élément géographique avec use_table_schema, incluez le champ précédent dans le message JSON.

Autorisations du compte de service Pub/Sub

Pour créer un abonnement BigQuery, compte de service doit être autorisé à écrire dans le bucket table BigQuery et lire ses métadonnées. Pour plus d'informations, consultez Attribuer des rôles BigQuery Service Pub/Sub compte.

Gérer les échecs de messages

Lorsqu'un message Pub/Sub ne peut pas être écrit dans BigQuery, vous ne pouvez pas accuser réception du message. Pour transférer ces de messages impossibles à distribuer, configurez une lettre morte sujet sur la Abonnement BigQuery. Le message Pub/Sub transférées au file d'attente de lettres mortes contient un attribut CloudPubSubDeadLetterSourceDeliveryErrorMessage qui a pour cause Impossible d'écrire le message Pub/Sub dans dans BigQuery.

Si Pub/Sub ne peut pas écrire de messages dans BigQuery, Pub/Sub interrompt la distribution des messages, comme comportement d'intervalle push. Toutefois, si le a un lettre morte en pièce jointe Pub/Sub n'annule pas la distribution en cas d'échec sont dues à des erreurs de compatibilité de schéma.

Quotas et limites

Des limites de quota s'appliquent à l'abonné BigQuery par région. Pour en savoir plus, consultez la page sur les quotas Pub/Sub et limites.

Les abonnements BigQuery écrivent des données à l'aide de la classe API BigQuery Storage Write. Pour sur les quotas et les limites de l'API Storage Write, consultez la section API BigQuery Storage Write requêtes. BigQuery ne consomment que le quota de débit pour l'API Storage Write. Toi peut ignorer les autres considérations relatives au quota de l'API Storage Write dans cette instance.

Tarifs

Pour connaître les tarifs des abonnements BigQuery, consultez la Page des tarifs de Pub/Sub

Étape suivante