Cette page explique comment configurer votre destination BigQuery pour diffuser des données en flux continu depuis une base de données source à l'aide de Datastream.
Configurer les ensembles de données de destination
Lorsque vous configurez des ensembles de données pour la destination BigQuery, vous pouvez sélectionner l'une des options suivantes:
Ensemble de données pour chaque schéma: l'ensemble de données est sélectionné ou créé dans l'emplacement BigQuery spécifié, en fonction du nom de schéma de la source. Par conséquent, pour chaque schéma de la source, Datastream crée automatiquement un ensemble de données dans BigQuery.
Si vous sélectionnez cette option, Datastream crée des ensembles de données dans le projet contenant le flux.
Par exemple, si vous avez une source MySQL qui inclut une base de données
mydb
et une tableemployees
dans la base de données, Datastream crée l'ensemble de donnéesmydb
et la tableemployees
dans BigQuery.Un seul ensemble de données pour tous les schémas: vous pouvez sélectionner un ensemble de données BigQuery pour le flux. Datastream diffuse toutes les données en flux continu dans cet ensemble de données. Pour l'ensemble de données sélectionné, Datastream crée toutes les tables en tant que
<schema>_<table>
.Par exemple, si vous disposez d'une source MySQL qui inclut une base de données
mydb
et une tableemployees
dans la base de données, Datastream crée la tablemydb_employees
dans l'ensemble de données que vous sélectionnez.
Comportement d'écriture
Datastream ajoute une colonne STRUCT
nommée datastream_metadata
à chaque table écrite dans la destination BigQuery.
Si une table a une clé primaire à la source, la colonne contient les champs suivants:
UUID:
Ce champ contient le type de donnéesstring
.SOURCE_TIMESTAMP:
Ce champ contient le type de donnéesinteger
.
Si une table ne possède pas de clé primaire, la colonne contient un champ supplémentaire: IS_DELETED
. Ce champ est associé au type de données boolean
. Il indique si les données diffusées par Datastream vers la destination sont associées à une opération DELETE
au niveau de la source. Les tables sans clé primaire sont de type "append-only".
La taille maximale des événements lorsque vous insérez des données en flux continu dans BigQuery est de 20 Mo.
Configurer le mode d'écriture
Lorsque vous configurez votre flux, vous pouvez sélectionner la manière dont Datastream écrit vos données modifiées dans BigQuery:
- Fusionner: il s'agit du mode d'écriture par défaut. Lorsque cette option est sélectionnée, BigQuery reflète la façon dont vos données sont stockées dans la base de données source. Cela signifie que Datastream écrit toutes les modifications apportées à vos données dans BigQuery, qui regroupe ensuite les modifications avec les données existantes, créant ainsi des tables finales qui sont des instances répliquées des tables sources. Avec le mode Fusionner, aucun historique des événements de modification n'est conservé. Par exemple, si vous insérez, puis mettez à jour une ligne, BigQuery ne conserve que les données mises à jour. Si vous supprimez ensuite la ligne de la table source, BigQuery ne conserve plus aucune trace de cette ligne.
- Ajouter uniquement: le mode d'écriture "append-only" vous permet d'ajouter des données à BigQuery sous la forme d'un flux de modifications (événements
INSERT
,UPDATE-INSERT
,UPDATE-DELETE
etDELETE
). Utilisez ce mode lorsque vous devez conserver l'état historique de vos données. Pour mieux comprendre le mode d'écriture "append-only", envisagez les scénarios suivants :- Remplissage initial: après le remplissage initial, tous les événements sont écrits dans BigQuery en tant qu'événements de type
INSERT
, avec le même code temporel, le même identifiant unique universel (UUID) et le même numéro de séquence de modifications. - Mise à jour de la clé primaire: lorsqu'une clé primaire est modifiée, deux lignes sont écrites dans BigQuery :
- Une ligne
UPDATE-DELETE
avec la clé primaire d'origine - Une ligne
UPDATE-INSERT
avec la nouvelle clé primaire
- Une ligne
- Mise à jour d'une ligne: lorsque vous mettez à jour une ligne, une seule ligne
UPDATE-INSERT
est écrite dans BigQuery. - Suppression d'une ligne: lorsque vous supprimez une ligne, une seule ligne
DELETE
est écrite dans BigQuery.
- Remplissage initial: après le remplissage initial, tous les événements sont écrits dans BigQuery en tant qu'événements de type
Utiliser des tables BigQuery avec l'option max_staleness
Dans le cadre d'une ingestion en quasi-temps réel, Datastream utilise la compatibilité intégrée de BigQuery pour les opérations d'insertion des données, telles que la mise à jour, l'insertion et la suppression de données. Les opérations d'insertion dynamique vous permettent de mettre à jour de manière dynamique la destination BigQuery à mesure que des lignes sont ajoutées, modifiées ou supprimées. Datastream diffuse ces opérations upsert dans la table de destination à l'aide de l'API Storage Write de BigQuery.
Spécifier une limite d'obsolescence des données
BigQuery applique les modifications de source en arrière-plan de manière continue ou au moment de l'exécution de la requête, en fonction de la limite d'obsolescence des données configurée. Lorsque Datastream crée une table dans BigQuery, l'option max_staleness
de la table est définie en fonction de la valeur actuelle de la limite d'obsolescence des données pour le flux.
Pour en savoir plus sur l'utilisation des tables BigQuery avec l'option max_staleness
, consultez la section Obsolescence de la table.
Contrôler les coûts BigQuery
Les coûts BigQuery sont facturés séparément de Datastream. Pour savoir comment contrôler vos coûts BigQuery, consultez les tarifs de la CDC BigQuery.
Types de données cartographiques
Le tableau suivant répertorie les conversions de types de données depuis les bases de données sources compatibles vers la destination BigQuery.
Base de données source | Type de données source | Type de données BigQuery |
---|---|---|
MySQL | BIGINT (unsigned) |
DECIMAL |
MySQL | BINARY(size) |
STRING (hex encoded) |
MySQL | BIT(size) |
INT64 |
MySQL | BLOB(size) |
STRING (hex encoded) |
MySQL | BOOL |
INT64 |
MySQL | CHAR(size) |
STRING |
MySQL | DATE |
DATE |
MySQL | DATETIME(fsp) |
DATETIME |
MySQL | DECIMAL(precision, scale) |
Si la valeur de précision est <=38 et que la valeur de l'échelle est <=9, alors NUMERIC . Sinon BIGNUMERIC |
MySQL | DOUBLE(size, d) |
FLOAT64 |
MySQL | ENUM(val1, val2, val3, ...) |
STRING |
MySQL | FLOAT(precision) |
FLOAT64 |
MySQL | FLOAT(size, d) |
FLOAT64 |
MySQL | INTEGER(size) |
INT64 |
MySQL |
|
JSON
|
MySQL | LONGBLOB |
STRING (hex encoded) |
MySQL | LONGTEXT |
STRING (hex encoded) |
MySQL | MEDIUMBLOB |
STRING (hex encoded) |
MySQL | MEDIUMINT(size) |
INT64 |
MySQL | MEDIUMTEXT |
STRING |
MySQL | SET(val1, val2, val3, ...) |
STRING |
MySQL | SMALLINT(size) |
INT64 |
MySQL | TEXT(size) |
STRING |
MySQL | TIME(fsp) |
INTERVAL |
MySQL | TIMESTAMP(fsp) |
TIMESTAMP |
MySQL | TINYBLOB |
STRING (hex encoded) |
MySQL | TINYINT(size) |
INT64 |
MySQL | TINYTEXT |
STRING |
MySQL | VARBINARY(size) |
STRING (hex encoded) |
MySQL | VARCHAR |
STRING |
MySQL | YEAR |
INT64 |
Oracle | ANYDATA |
UNSUPPORTED |
Oracle | BFILE |
STRING |
Oracle | BINARY DOUBLE |
FLOAT64 |
Oracle | BINARY FLOAT |
FLOAT64 |
Oracle | BLOB |
BYTES |
Oracle | CHAR |
STRING |
Oracle | CLOB |
STRING |
Oracle | DATE |
DATETIME
|
Oracle | DOUBLE PRECISION |
FLOAT64 |
Oracle | FLOAT(p) |
FLOAT64 |
Oracle | INTERVAL DAY TO SECOND |
UNSUPPORTED |
Oracle | INTERVAL YEAR TO MONTH |
UNSUPPORTED |
Oracle | LONG /LONG RAW |
STRING |
Oracle | NCHAR |
STRING |
Oracle | NCLOB |
STRING |
Oracle | NUMBER(precision, scale>0) |
Si 0<p=< 78, mappez à des types décimaux paramétrés. Si p>=79, mapper vers STRING |
Oracle | NVARCHAR2 |
STRING |
Oracle | RAW |
STRING |
Oracle | ROWID |
STRING |
Oracle | SDO_GEOMETRY |
UNSUPPORTED |
Oracle | SMALLINT |
INT64 |
Oracle | TIMESTAMP |
TIMESTAMP
|
Oracle | TIMESTAMP WITH TIME ZONE |
TIMESTAMP
|
Oracle | UDT (user-defined type) |
UNSUPPORTED |
Oracle | UROWID |
STRING |
Oracle | VARCHAR |
STRING |
Oracle | VARCHAR2 |
STRING |
Oracle | XMLTYPE |
UNSUPPORTED |
PostgreSQL | ARRAY |
JSON
|
PostgreSQL | BIGINT |
INT64 |
PostgreSQL | BIT |
BYTES |
PostgreSQL | BIT_VARYING |
BYTES |
PostgreSQL | BOOLEAN |
BOOLEAN |
PostgreSQL | BOX |
UNSUPPORTED |
PostgreSQL | BYTEA |
BYTES |
PostgreSQL | CHARACTER |
STRING |
PostgreSQL | CHARACTER_VARYING |
STRING |
PostgreSQL | CIDR |
STRING |
PostgreSQL | CIRCLE |
UNSUPPORTED |
PostgreSQL | DATE |
DATE |
PostgreSQL | DOUBLE_PRECISION |
FLOAT64 |
PostgreSQL | ENUM |
STRING |
PostgreSQL | INET |
STRING |
PostgreSQL | INTEGER |
INT64 |
PostgreSQL | INTERVAL |
INTERVAL |
PostgreSQL | JSON |
JSON |
PostgreSQL | JSONB |
JSON |
PostgreSQL | LINE |
UNSUPPORTED |
PostgreSQL | LSEG |
UNSUPPORTED |
PostgreSQL | MACADDR |
STRING |
PostgreSQL | MONEY |
FLOAT64 |
PostgreSQL | NUMERIC |
Si la précision est égale à -1 , alors STRING (les types NUMERIC BigQuery nécessitent une précision fixe). Sinon, BIGNUMERIC /NUMERIC . Pour en savoir plus, consultez la section Nombres de précision arbitraire dans la documentation PostgreSQL. |
PostgreSQL | OID |
INT64 |
PostgreSQL | PATH |
UNSUPPORTED |
PostgreSQL | POINT |
UNSUPPORTED |
PostgreSQL | POLYGON |
UNSUPPORTED |
PostgreSQL | REAL |
FLOAT64 |
PostgreSQL | SMALLINT |
INT64 |
PostgreSQL | SMALLSERIAL |
INT64 |
PostgreSQL | SERIAL |
INT64 |
PostgreSQL | TEXT |
STRING |
PostgreSQL | TIME |
TIME |
PostgreSQL | TIMESTAMP |
TIMESTAMP |
PostgreSQL | TIMESTAMP_WITH_TIMEZONE |
TIMESTAMP |
PostgreSQL | TIME_WITH_TIMEZONE |
TIME |
PostgreSQL | TSQUERY |
STRING |
PostgreSQL | TSVECTOR |
STRING |
PostgreSQL | TXID_SNAPSHOT |
STRING |
PostgreSQL | UUID |
STRING |
PostgreSQL | XML |
STRING |
SQL Server | BIGINT |
INT64 |
SQL Server | BINARY |
BYTES |
SQL Server | BIT |
BOOL |
SQL Server | CHAR |
STRING |
SQL Server | DATE |
DATE |
SQL Server | DATETIME2 |
DATETIME |
SQL Server | DATETIME |
DATETIME |
SQL Server | DATETIMEOFFSET |
TIMESTAMP |
SQL Server | DECIMAL |
BIGNUMERIC |
SQL Server | FLOAT |
FLOAT64 |
SQL Server | IMAGE |
BYTES |
SQL Server | INT |
INT64 |
SQL Server | MONEY |
BIGNUMERIC |
SQL Server | NCHAR |
STRING |
SQL Server | NTEXT |
STRING |
SQL Server | NUMERIC |
BIGNUMERIC |
SQL Server | NVARCHAR |
STRING |
SQL Server | NVARCHAR(MAX) |
STRING |
SQL Server | REAL |
FLOAT64 |
SQL Server | SMALLDATETIME |
DATETIME |
SQL Server | SMALLINT |
INT64 |
SQL Server | SMALLMONEY |
NUMERIC |
SQL Server | TEXT |
STRING |
SQL Server | TIME |
TIME |
SQL Server | TIMESTAMP /ROWVERSION |
BYTES |
SQL Server | TINYINT |
INT64 |
SQL Server | UNIQUEIDENTIFIER |
STRING |
SQL Server | VARBINARY |
BYTES |
SQL Server | VARBINARY(MAX) |
BYTES |
SQL Server | VARCHAR |
STRING |
SQL Server | VARCHAR(MAX) |
STRING |
SQL Server | XML |
STRING |
Interroger un tableau PostgreSQL en tant que type de données de tableau BigQuery
Si vous préférez interroger un tableau PostgreSQL en tant que type de données ARRAY
BigQuery, vous pouvez convertir les valeurs JSON
en un tableau BigQuery à l'aide de la fonction JSON_VALUE_ARRAY
BigQuery:
SELECT ARRAY(SELECT CAST(element AS TYPE) FROM UNNEST(JSON_VALUE_ARRAY(BQ_COLUMN_NAME,'$')) AS element)AS array_col
Remplacez les éléments suivants :
TYPE: type BigQuery correspondant au type d'élément du tableau source PostgreSQL. Par exemple, si le type de source est un tableau de valeurs
BIGINT
, remplacez TYPE parINT64
.Pour savoir comment mapper les types de données, consultez Mapper les types de données.
BQ_COLUMN_NAME: nom de la colonne concernée dans la table BigQuery.
Il existe deux exceptions concernant la conversion des valeurs:
Pour les tableaux de valeurs
BIT
,BIT_VARYING
ouBYTEA
dans la colonne source, exécutez la requête suivante:SELECT ARRAY(SELECT FROM_BASE64(element) FROM UNNEST(JSON_VALUE_ARRAY(BQ_COLUMN_NAME,'$')) AS element)
AS array_of_bytes Pour les tableaux de valeurs
JSON
ouJSONB
dans la colonne source, utilisez la fonctionJSON_QUERY_ARRAY
:SELECT ARRAY(SELECT element FROM UNNEST(JSON_QUERY_ARRAY(BQ_COLUMN_NAME,'$')) AS element)
AS array_of_jsons
Limitations connues
Voici quelques limites connues liées à l'utilisation de BigQuery en tant que destination:
- Vous ne pouvez répliquer des données que dans un ensemble de données BigQuery qui se trouve dans le même projet Google Cloud que le flux Datastream.
Si une table de la base de données source possède une clé primaire (par exemple, l'ID utilisateur), puis qu'une modification a été apportée à la table pour que la clé primaire soit différente (dans cet exemple, la clé primaire est désormais l'ID utilisateur et la date), Datastream ne peut pas diffuser cette modification dans la destination.
Pour que Datastream diffuse la table dans la destination avec la clé primaire modifiée, procédez comme suit:
- Modifiez la clé primaire de la table de base de données source.
- Vérifiez la métrique de latence totale du flux et attendez au moins autant de temps que la latence actuelle pour vous assurer que tous les événements en cours de transfert sont écrits dans la destination. Ainsi, tous les événements associés à la clé primaire d'origine sont bien diffusés.
- Mettez en pause le flux.
- Déposez la table dans la destination.
- Reprenez la diffusion.
- Déclenchez le remplissage sur la table.
Dans BigQuery, les clés primaires doivent correspondre aux types de données suivants:
DATE
BOOL
GEOGRAPHY
INT64
NUMERIC
BIGNUMERIC
STRING
TIMESTAMP
DATETIME
Les tables contenant des clés primaires de types de données non compatibles ne sont pas répliquées par Datastream.
BigQuery n'accepte pas les noms de table contenant les caractères
.
,$
,/
,@
ou+
. Datastream remplace ces caractères par des traits de soulignement lors de la création de tables de destination.Par exemple,
table.name
dans la base de données source devienttable_name
dans BigQuery.Pour en savoir plus sur les noms de tables dans BigQuery, consultez la section Nommage des tables.
- BigQuery ne prend pas en charge plus de quatre colonnes de clustering. Lors de la réplication d'une table comportant plus de quatre colonnes de clé primaire, Datastream utilise quatre colonnes de clé primaire comme colonnes de clustering.
- Datastream mappe les littéraux de date et d'heure hors plage, tels que les types de date infini PostgreSQL, aux valeurs suivantes :
- Valeur
DATE
positive à la valeur de9999-12-31
DATE
négatif à la valeur de0001-01-01
- Valeur
TIMESTAMP
positive à la valeur de9999-12-31 23:59:59.999000 UTC
TIMESTAMP
négatif à la valeur de0001-01-01 00:00:00 UTC
- Valeur
- BigQuery n'est pas compatible avec les tables d'insertion en flux continu qui possèdent des clés primaires de types de données
FLOAT
ouREAL
. Ces tables ne sont pas répliquées.
Pour en savoir plus sur les types de dates et les plages de dates BigQuery, consultez Types de données.