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.
Voici une brève description du workflow qui fait référence à la figure 1:
- Pub/Sub utilise le service d'écriture de données dans l'espace de stockage BigQuery pour envoyer des données à BigQuery tableau.
- Les messages sont envoyés par lots à la table BigQuery.
- À la fin d'une opération d'écriture, l'API renvoie une réponse de réponse.
- 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
etBYTEINT
sont des alias deINTEGER
.DECIMAL
est un alias pourNUMERIC
; etBIGDECIMAL
est l'alias deBIGNUMERIC
.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
ouBIGNUMERIC
, 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): champstring
défini surUPSERT
ouDELETE
.Si un message Pub/Sub écrit
_CHANGE_TYPE
de la table BigQuery est défini surUPSERT
. 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 surDELETE
. 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
Créez un abonnement, tel qu'un abonnement BigQuery abonnement.
Dépanner une requête BigQuery abonnement.
Découvrez BigQuery.
Consultez les tarifs de Pub/Sub, y compris les tarifs de Abonnements BigQuery.
Créer ou modifier un abonnement avec la CLI
gcloud
commandes.Créer ou modifier un abonnement avec REST API.