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.
Voici une brève description du workflow qui fait référence à la figure 1:
- Pub/Sub utilise l'API d'écriture de stockage BigQuery pour envoyer des données à la table BigQuery.
- Les messages sont envoyés par lots à la table BigQuery.
- À la fin d'une opération d'écriture, l'API renvoie une réponse OK.
- 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
etBYTEINT
sont des alias pourINTEGER
,DECIMAL
est un alias pourNUMERIC
etBIGDECIMAL
est un alias pourBIGNUMERIC
.Lorsque le type dans le schéma du sujet est
string
et que le type dans la table BigQuery estJSON
,TIMESTAMP
,DATETIME
,DATE
,TIME
,NUMERIC
ouBIGNUMERIC
, 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): champstring
défini surUPSERT
ouDELETE
.Si le paramètre
_CHANGE_TYPE
d'un message Pub/Sub écrit dans la table BigQuery est défini surUPSERT
, 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 surDELETE
, 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.
Si Pub/Sub ne peut pas écrire de messages dans BigQuery, il annule la distribution des messages d'une manière semblable à un comportement d'intervalle entre les tentatives. Toutefois, si l'abonnement est associé à un sujet de lettres mortes, Pub/Sub n'annule pas la distribution lorsque les échecs de messages sont dus à des erreurs de compatibilité de schéma.
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
Créez un abonnement tel qu'un abonnement BigQuery.
Dépannez un abonnement BigQuery.
Découvrez BigQuery.
Consultez les tarifs de Pub/Sub, y compris les abonnements BigQuery.
Créez ou modifiez un abonnement à l'aide des commandes CLI
gcloud
.créer ou modifier un abonnement avec des API REST ;