Cette page a été traduite par l'API Cloud Translation.

Configurer une destination BigQuery

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 table employees dans la base de données, Datastream crée l'ensemble de données mydb et la table employees 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 table employees dans la base de données, Datastream crée la table mydb_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ées string.
SOURCE_TIMESTAMP: Ce champ contient le type de données integer.

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 et DELETE). 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
- 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.

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(size)`	`INT64`
MySQL	`BIGINT (unsigned)`	`NUMERIC`
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`	`JSON` Les types de données `BOOLEAN`, `NUMBER`, `OBJECT`, `STRING`, `ARRAY` et `NULL` sont acceptés.
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` Les dates nulles ne sont pas acceptées. Elles sont remplacées par des valeurs `NULL`.
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`	`STRING`
Oracle	`NUMBER(precision=*)`	`STRING`
Oracle	`NUMBER(precision, scale<=0)`	Si p<=18, alors `INT64`. Si 18<p=<78, mappez à des types décimaux paramétrés. Si p>=79, mapper vers `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` Les dates nulles ne sont pas acceptées. Elles sont remplacées par des valeurs `NULL`.
Oracle	`TIMESTAMP WITH TIME ZONE`	`TIMESTAMP` Les dates nulles ne sont pas acceptées. Elles sont remplacées par des valeurs `NULL`.
Oracle	`UDT (user-defined type)`	`UNSUPPORTED`
Oracle	`UROWID`	`STRING`
Oracle	`VARCHAR`	`STRING`
Oracle	`VARCHAR2`	`STRING`
Oracle	`XMLTYPE`	`UNSUPPORTED`
PostgreSQL	`ARRAY`	`JSON` Les tableaux de types de données `DATE`, `TIMESTAMP` ou `TIMESTAMP WITH TIME ZONE` ne sont pas acceptés.
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 par INT64.

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 ou BYTEA 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 ou JSONB dans la colonne source, utilisez la fonction JSON_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:
1. Modifiez la clé primaire de la table de base de données source.
2. 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.
3. Mettez en pause le flux.
4. Déposez la table dans la destination.
5. Reprenez la diffusion.
6. Déclenchez le remplissage sur la table.
Il est possible que des événements écrits dans la destination BigQuery arrivent tardivement. Toutefois, remplir la table corrigera les lignes susceptibles d'être désynchronisées.
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 devient table_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 de 9999-12-31
- DATE négatif à la valeur de 0001-01-01
- Valeur TIMESTAMP positive à la valeur de 9999-12-31 23:59:59.999000 UTC
- TIMESTAMP négatif à la valeur de 0001-01-01 00:00:00 UTC
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 ou REAL. 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.

Implémenter Datastream et Dataflow pour l'analyse

Configurer une destination Cloud Storage