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, Google Cloud CLI, les bibliothèques clientes ou l'API Pub/Sub pour créer, mettre à jour, lister, 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'une tâche Dataflow ne sont pas nécessaires lorsque les messages ne nécessitent pas de traitement supplémentaire avant d'être stockés 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 leur stockage dans une table BigQuery. Pour découvrir comment diffuser des données de Pub/Sub vers BigQuery avec transformation à l'aide de Dataflow, consultez Diffuser des données en streaming depuis Pub/Sub vers BigQuery.

Le modèle d'abonnement Pub/Sub vers BigQuery à partir de Dataflow applique une diffusion de type "exactement une fois" par défaut. Cela se fait généralement via des mécanismes de déduplication dans le pipeline Dataflow. Toutefois, l'abonnement BigQuery n'est compatible qu'avec la distribution au moins une fois. Si la déduplication exacte est essentielle pour votre cas d'utilisation, envisagez d'utiliser des processus en aval dans BigQuery pour gérer les doublons potentiels.

Avant de commencer

Avant de lire ce document, assurez-vous de connaître les éléments suivants:

  • Fonctionnement de Pub/Sub et différents termes de Pub/Sub

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

  • Fonctionnement de BigQuery, et configuration et gestion des tables BigQuery

Workflow d'abonnement BigQuery

L'image suivante présente 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 lot à la table BigQuery.
  3. Une fois une opération d'écriture terminée, 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é de manière 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 le sujet de lettres mortes.

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 les messages et le type de schéma de cette table.

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

Compatibilité des schémas

Cette section ne s'applique que si vous sélectionnez l'option Utiliser un schéma avec sujet lorsque vous créez un abonnement BigQuery.

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 d'une variété de formats.

Vous trouverez ci-dessous une liste d'informations importantes concernant la compatibilité des schémas entre un sujet Pub/Sub et une table BigQuery.

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

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

  • Lorsque le type du schéma de sujet est string et que le type de 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 acceptés, comme indiqué dans le tableau suivant. Les types logiques non listé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émas 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 étant null et l'autre Type NULLABLE Type
autres unions Non cartographié
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 tampons 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 Non cartographié
map<KeyType, ValueType> REPEATED RECORD<key KeyType, value ValueType>
enum INTEGER
repeated/array of Type REPEATED Type

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

Lors du mappage d'un entier sur l'un des types de date ou d'heure, le nombre doit représenter la valeur correcte. Vous trouverez ci-dessous le mappage des types de données BigQuery sur l'entier qui les représente.

Type de données BigQuery Représentation des entiers
DATE Nombre de jours écoulés depuis l'époque Unix (1er janvier 1970)
DATETIME Date et heure en microsecondes exprimées en heure civile à l'aide de CivilTimeEncoder
TIME Heure en microsecondes exprimée en heure civile à 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 BigQuery

Les abonnements BigQuery sont compatibles avec les mises à jour de la 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 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 la valeur _CHANGE_TYPE est définie sur UPSERT pour 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 si elle n'existe pas.

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

  • _CHANGE_SEQUENCE_NUMBER (facultatif): champ int64 (long) défini pour s'assurer 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 croissante 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 aucun effet sur la ligne dans la table BigQuery. Notez que Pub/Sub nécessite une valeur basée sur un entier, contrairement à la valeur basée sur une chaîne utilisée lors de l'interaction directe avec BigQuery.

Pour utiliser cette 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 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 non distribuables, configurez un sujet de lettre morte sur l'abonnement BigQuery. Le message Pub/Sub transféré vers la file d'attente de lettres mortes contient un attribut CloudPubSubDeadLetterSourceDeliveryErrorMessage qui indique pourquoi le message Pub/Sub n'a pas pu être écrit dans BigQuery.

Si Pub/Sub ne peut pas écrire de messages dans BigQuery, il interrompt la diffusion des messages de manière semblable au comportement de suspension de diffusion. Toutefois, si un sujet de lettres mortes est associé à l'abonnement, Pub/Sub ne suspend pas la distribution lorsque les échecs de distribution des messages sont dus à des erreurs de compatibilité de schéma.

Quotas et limites

Des limites de quota s'appliquent au débit des abonnés BigQuery par région. Pour en savoir plus, consultez la section 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 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 de l'API Storage Write. Vous pouvez ignorer les autres considérations concernant les quotas de l'API Storage Write dans ce cas.

Tarifs

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

Étape suivante