Abonnements BigQuery

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

Un abonnement BigQuery est un type d'abonnement d'exportation qui écrit les messages dans une table BigQuery existante à mesure qu'ils sont reçus. Vous n'avez pas besoin de configurer un client abonné distinct. Utilisez 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 un abonnement BigQuery.

Sans le type d'abonnement BigQuery, vous avez besoin d'un abonnement pull ou push, et d'un abonné (tel que Dataflow) qui lit les messages et les écrit dans une table BigQuery. Les frais liés à l'exécution d'un job Dataflow ne sont pas nécessaires lorsque les messages ne nécessitent pas de 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é pour les systèmes Pub/Sub où une certaine transformation des données est nécessaire avant qu'elles ne soient stockées dans une table BigQuery. Pour savoir comment transférer des données en flux continu depuis Pub/Sub vers BigQuery avec transformation à l'aide de Dataflow, consultez la page Diffuser des données depuis Pub/Sub vers BigQuery.

Par défaut, le modèle d'abonnement Pub/Sub à BigQuery de Dataflow applique une distribution de type "exactement une fois". Cela est généralement réalisé grâce à des mécanismes de déduplication dans le pipeline Dataflow. Toutefois, l'abonnement BigQuery n'accepte qu'au moins une distribution. Si une déduplication exacte est essentielle pour votre cas d'utilisation, envisagez d'utiliser les processus en aval dans BigQuery pour gérer les doublons potentiels.

Avant de commencer

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

  • Découvrez le fonctionnement de Pub/Sub et les différentes conditions d'utilisation de Pub/Sub.

  • Les différents types d'abonnements compatibles avec Pub/Sub et les raisons pour lesquelles vous pouvez utiliser un abonnement BigQuery.

  • comment fonctionne BigQuery, et comment configurer et gérer des tables BigQuery ;

Workflow d'abonnement BigQuery

L'image suivante illustre le workflow entre un abonnement 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 l'API d'écriture de stockage BigQuery pour envoyer des données à la table BigQuery.
  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 OK.
  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. Le message est ensuite renvoyé. Si le message échoue suffisamment de fois et qu'un sujet de lettres mortes est configuré sur l'abonnement, le message est déplacé vers ce sujet.

Propriétés d'un abonnement BigQuery

Les propriétés que vous configurez pour un abonnement BigQuery déterminent la table BigQuery dans laquelle Pub/Sub écrit des messages et le type de schéma de cette table.

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

Compatibilité des schémas

Pub/Sub et BigQuery définissent leurs schémas de différentes manières. Les schémas Pub/Sub sont définis au format Apache Avro ou Protocol Buffer, tandis que les schémas BigQuery sont définis à l'aide de différents formats. Vous trouverez ci-dessous une liste d'informations importantes concernant 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 BigQuery.

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

  • Lorsque le type dans le schéma du sujet est string et que le type dans la table BigQuery est JSON, TIMESTAMP, DATETIME, DATE, TIME, NUMERIC ou BIGNUMERIC, toute valeur de ce champ dans un message Pub/Sub doit respecter le format spécifié pour le type de données BigQuery.

  • 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 annotent, comme détaillé dans la spécification Avro.

Vous trouverez ci-dessous un ensemble de mappages de différents formats de schéma sur les 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, l'un 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, le nombre doit représenter la valeur correcte. Voici le mappage entre les types de données BigQuery et 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 de CivilTimeEncoder
TIME Temps en microsecondes, exprimé en temps civil à l'aide de 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 les mises à jour de capture des données modifiées (CDC) lorsque use_topic_schema ou use_table_schema est défini sur true dans les propriétés de l'abonnement. Pour utiliser la fonctionnalité avec use_topic_schema, définissez le schéma du sujet avec le champ suivant:

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

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

    • Si un message Pub/Sub écrit dans la table BigQuery a la valeur _CHANGE_TYPE définie sur DELETE, BigQuery supprime la ligne de la table ayant la même clé, le cas échéant.

Pour utiliser la fonctionnalité 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, le compte de service Pub/Sub doit être autorisé à écrire dans la table BigQuery spécifique et à lire les métadonnées de la table. Pour en savoir plus, consultez la page Attribuer des rôles BigQuery au compte de service Pub/Sub.

Gérer les échecs de messages

Lorsqu'un message Pub/Sub ne peut pas être écrit dans BigQuery, il ne peut pas être confirmé. Pour transférer ces messages impossibles à distribuer, configurez un sujet de lettres mortes sur l'abonnement BigQuery. Le message Pub/Sub transféré au file d'attente de lettres mortes contient un attribut CloudPubSubDeadLetterSourceDeliveryErrorMessage qui indique que le message Pub/Sub n'a pas pu être écrit dans BigQuery.

Quotas et limites

Il existe des limites de quota sur le débit d'abonné BigQuery par région. Pour plus d'informations, consultez la page Quotas et limites de Pub/Sub.

Les abonnements BigQuery écrivent des données à l'aide de l' API BigQuery Storage Write. Pour plus d'informations sur les quotas et les limites de l'API Storage Write, consultez la page Requêtes de l'API BigQuery Storage Write. Les abonnements BigQuery ne consomment que le quota de débit pour l'API Storage Write. Dans cette instance, vous pouvez ignorer les autres considérations relatives aux quotas de l'API Storage Write.

Tarification

Pour en savoir plus sur les tarifs des abonnements BigQuery, consultez la page des tarifs de Pub/Sub.

Étapes suivantes