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 à l'exportation qui écrit les messages dans une table BigQuery existante au fur et à mesure de leur réception. 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 généraux 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 transformation des données est requise avant de les stocker dans une table BigQuery. Pour savoir comment diffuser des données en flux continu depuis Pub/Sub vers BigQuery avec une transformation à l'aide de Dataflow, consultez la section "Diffuser des données depuis Pub/Sub vers BigQuery".

Le modèle d'abonnement Pub/Sub à BigQuery provenant de Dataflow applique une distribution "exactement une fois" par défaut. Cela est généralement atteint grâce à des mécanismes de déduplication au sein du pipeline Dataflow. Cependant, l'abonnement BigQuery ne permet l'envoi qu'au moins une fois. Si la déduplication exacte est essentielle pour votre cas d'utilisation, envisagez les processus en aval dans BigQuery pour gérer les doublons potentiels.

Avant de commencer

Avant de lire ce document, assurez-vous d'avoir pris connaissance des points suivants:

  • Fonctionnement du fonctionnement de Pub/Sub et des différents termes de Pub/Sub

  • Les différents types d'abonnements acceptés par Pub/Sub et les raisons pour lesquelles vous pourriez vouloir utiliser un abonnement BigQuery

  • le fonctionnement de BigQuery, et les instructions à suivre pour 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. Après une opération d'écriture réussie, 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 est confirmé par la négative. 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 utilisent différentes méthodes pour définir leurs schémas. 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é de schéma entre un sujet Pub/Sub et une table BigQuery.

  • Les messages contenant un champ mal formaté ne sont pas écrits 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 un alias de 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, alors 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 indiqué dans la spécification Avro.

Vous trouverez ci-dessous un ensemble de mappages de différents formats de schéma avec 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 de 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 d'effectuer une mise en correspondance
fixed BYTES, NUMERIC ou BIGNUMERIC
enum INTEGER

Types logiques Avro

Avro Logical Type (Type logique Avro) Type de données BigQuery
timestamp-micros TIMESTAMP
date DATE
time-micros TIME
duration INTERVAL

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 d'effectuer une mise en correspondance
map<KeyType, ValueType> REPEATED RECORD<key KeyType, value ValueType>
enum INTEGER
repeated/array of Type REPEATED Type

Représentation des nombres entiers de date et d'heure

Lorsque vous mappez un nombre entier vers l'un des types de date ou d'heure, le nombre doit représenter la valeur correcte. Voici la correspondance entre les types de données BigQuery et l'entier qui les représente.

Type de données BigQuery Représentation des nombres 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 Durée en microsecondes, exprimée en temps civil à l'aide de CivilTimeEncoder
TIMESTAMP Nombre de microsecondes écoulées depuis l'epoch Unix, 1er janvier 1970 à 00:00:00 UTC

Capture des données modifiées BigQuery

Les abonnements BigQuery sont compatibles avec les mises à jour de capture des données modifiées (CDC, Change Data Capture) lorsque 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 avec les champs suivants:

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

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

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

  • _CHANGE_SEQUENCE_NUMBER (facultatif): un champ int64 (long) ou int32 (int) défini pour garantir que les mises à jour et les suppressions apportées à la table BigQuery sont traitées dans l'ordre. Les messages pour la même clé de ligne doivent contenir une valeur qui augmente de façon monotone pour _CHANGE_SEQUENCE_NUMBER. Les messages dont les numéros de séquence sont inférieurs au numéro de séquence le plus élevé traité pour une ligne n'ont aucune incidence sur la ligne de la table BigQuery.

Pour utiliser la fonctionnalité avec use_table_schema, incluez les champs précédents dans le message JSON.

Autorisations de 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 ses métadonnées. Pour en savoir plus, consultez la section Attribuer des rôles BigQuery au compte de service Pub/Sub.

Gérer les échecs de message

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 lettre morte sur l'abonnement BigQuery. Le message Pub/Sub transféré au file d'attente de lettres mortes contient un attribut CloudPubSubDeadLetterSourceDeliveryErrorMessage qui explique que le message Pub/Sub n'a pas pu être écrit dans BigQuery.

Quotas et limites

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

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

Tarification

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

Étapes suivantes