Présentation
La hiérarchie des données dans Datastream est la suivante :
- Un flux, qui comprend une source de données et une destination.
- Un objet, qui correspond à une partie d'un flux, telle qu'une table provenant d'une base de données spécifique.
- Un événement, qui correspond à une modification unique générée par un objet spécifique, tel qu'une insertion dans une base de données.
Les flux, les objets et les événements sont associés à des données et à des métadonnées. Ces données et métadonnées peuvent être utilisées à différentes fins.
À propos des événements
Chaque événement se compose de trois types de données :
- Données d'événement : représentent la modification apportée aux données elles-mêmes par l'objet provenant de la source de flux. Chaque événement contient l'intégralité de la ligne modifiée.
- Métadonnées génériques : ces métadonnées apparaissent pour chaque événement généré par Datastream utilisé pour des actions, telles que la suppression de données en double dans la destination.
- Métadonnées spécifiques à la source:ces métadonnées apparaissent sur chaque événement généré par une source de flux spécifique. Ces métadonnées varient selon la source.
Données d'événement
Les données d'événement correspondent à la charge utile de chaque modification provenant d'un objet donné issu d'une source de flux.
Les événements sont au format Avro ou JSON.
Lorsque vous utilisez le format Avro, l'événement contient l'index et la valeur de chaque colonne. L'index de colonne vous permet d'extraire le nom de la colonne et le type unifié à partir du schéma de l'en-tête Avro.
Lorsque vous utilisez le format JSON, pour chaque colonne, l'événement contient le nom et la valeur de la colonne.
Les métadonnées d'événement peuvent servir à collecter des informations sur l'origine de l'événement, et à supprimer les données en double dans la destination et les événements de commande par le consommateur en aval.
Les tableaux suivants listent et décrivent les champs et les types de données des métadonnées d'événement génériques et spécifiques à la source.
Métadonnées génériques
Ces métadonnées sont cohérentes pour tous les types de flux.
| Champ | Type Avro | Type JSON | Description |
|---|---|---|---|
stream_name |
chaîne | chaîne | Nom unique du flux tel que défini au moment de la création. |
read_method |
chaîne | chaîne | Indique si les données ont été lues à partir de la source à l'aide d'une méthode de capture de données modifiées (CDC, Change Data Capture) dans le cadre d'un remplissage d'historique ou dans le cadre d'une tâche de complément créée lors d'un rollback d'une transaction pendant la réplication CDC. Les valeurs possibles sont les suivantes :
|
object |
chaîne | chaîne | Nom utilisé pour regrouper différents types d'événements, généralement le nom de la table ou de l'objet dans la source. |
schema_key |
chaîne | chaîne | Identifiant unique du schéma unifié de l'événement. |
uuid |
chaîne | chaîne | Identifiant unique de l'événement généré par Datastream. |
read_timestamp |
timestamp-millis | chaîne | Horodatage (UTC) de la lecture de l'enregistrement par Datastream (horodatage de l'epoch en millisecondes). |
source_timestamp |
timestamp-millis | chaîne | Horodatage (UTC) de la modification de l'enregistrement dans la source (horodatage de l'epoch en millisecondes). |
sort_keys |
{"type": "array", "items": ["string", "long"]} |
tableau | Tableau des valeurs pouvant être utilisées pour trier les événements dans l'ordre dans lequel ils se sont produits. |
Métadonnées spécifiques à la source
Ces métadonnées sont associées aux événements CDC et de remplissage de données d'une base de données source. Pour afficher ces métadonnées, sélectionnez une source dans le menu déroulant ci-dessous.
| Source | Champ | Type Avro | Type JSON | Description |
|---|---|---|---|---|
| MySQL | log_file |
chaîne | chaîne | Fichier journal à partir duquel Datastream extrait des événements lors de la réplication CDC. |
| MySQL | log_position |
long | long | Oosition du journal (décalage) dans le journal binaire MySQL |
| MySQL | primary_keys |
tableau de chaînes | tableau de chaînes | Liste (d'une ou de plusieurs) des noms de colonnes qui constituent la clé primaire de la table. Si la table ne possède pas de clé primaire, ce champ est vide. |
| MySQL | is_deleted |
boolean | boolean |
|
| MySQL | database |
chaîne | chaîne | Base de données associée à l'événement. |
| MySQL | table |
chaîne | chaîne | Table associée à l'événement. |
| MySQL | change_type |
chaîne | chaîne | Type de modification ( |
| Oracle | log_file |
chaîne | chaîne | Fichier journal dont Datastream extrait les événements dans la réplication CDC. |
| Oracle | scn |
long | long | Position du journal (offset) dans le journal des transactions Oracle. |
| Oracle | row_id |
chaîne | chaîne | row_id d'Oracle. |
| Oracle | is_deleted |
boolean | boolean |
|
| Oracle | database |
chaîne | chaîne | Base de données associée à l'événement. |
| Oracle | schema |
chaîne | chaîne | Schéma associé à la table de l'événement. |
| Oracle | table |
chaîne | chaîne | Tableau associé à l'événement. |
| Oracle | change_type |
chaîne | chaîne | Type de modification ( |
| Oracle | tx_id |
chaîne | chaîne | ID de la transaction à laquelle appartient l'événement. |
| Oracle | rs_id |
chaîne | chaîne | ID du jeu d'enregistrements. Le couplage de rs_id et ssn identifie de manière unique une ligne dans V$LOGMNR_CONTENTS. rs_id identifie de manière unique l'enregistrement de rétablissement qui a généré la ligne. |
| Oracle | ssn |
long | long | Numéro de séquence SQL. Ce numéro est utilisé avec rs_id et identifie de manière unique une ligne dans V$LOGMNR_CONTENTS. |
| PostgreSQL | schema |
chaîne | chaîne | Schéma associé à la table de l'événement. |
| PostgreSQL | table |
chaîne | chaîne | Tableau associé à l'événement. |
| PostgreSQL | is_deleted |
booléen | boolean |
|
| PostgreSQL | change_type |
chaîne | chaîne | Type de modification (INSERT, UPDATE, DELETE) représenté par l'événement.
|
| PostgreSQL | tx_id |
chaîne | chaîne | ID de la transaction à laquelle appartient l'événement. |
| PostgreSQL | lsn |
chaîne | chaîne | Numéro séquentiel dans le journal de l'entrée actuelle. |
| PostgreSQL | primary_keys |
tableau de chaînes | tableau de chaînes | Liste (d'une ou de plusieurs) des noms de colonnes qui constituent la clé primaire de la table. Si la table ne possède pas de clé primaire, ce champ est vide. |
| SQL Server | table |
chaîne | chaîne | Tableau associé à l'événement. |
| SQL Server | database |
long | long | Base de données associée à l'événement. |
| SQL Server | schema |
tableau de chaînes | tableau de chaînes | Schéma associé à la table de l'événement. |
| SQL Server | is_deleted |
booléen | booléen |
|
| SQL Server | lsn |
chaîne | chaîne | Numéro de séquence dans le journal de l'événement. |
| SQL Server | tx_id |
chaîne | chaîne | ID de la transaction à laquelle l'événement appartient. |
| SQL Server | physical_location |
Tableau d'entiers | Tableau d'entiers | Emplacement physique de l'enregistrement de journal décrit par trois entiers : l'ID de fichier, l'ID de page et l'ID d'emplacement de l'enregistrement. |
| SQL Server | replication_index |
Tableau de chaînes. | Tableau de chaînes. | Liste des noms de colonne d'un index pouvant identifier de manière unique une ligne de la table. |
| SQL Server | change_type |
Chaîne | Chaîne | Type de modification ("INSERT", "UPDATE", "DELETE") représenté par l'événement. |
Exemple de flux d'événements
Ce flux illustre les événements générés par trois opérations consécutives : INSERT, UPDATE et DELETE, sur une seule ligne d'une table SAMPLE pour une base de données source.
| TIME | THIS_IS_MY_PK (int) | FIELD1 (nchar pouvant être nul) | FIELD2 (nchar non nul)> |
|---|---|---|---|
| 0 | 1231535353 | foo | TLV |
| 1 | 1231535353 | NULL | TLV |
INSERT (T0)
La charge utile du message consiste en l'intégralité de la nouvelle ligne.
{
"stream_name": "projects/myProj/locations/myLoc/streams/Oracle-to-Source",
"read_method": "oracle-cdc-logminer",
"object": "SAMPLE.TBL",
"uuid": "d7989206-380f-0e81-8056-240501101100",
"read_timestamp": "2019-11-07T07:37:16.808Z",
"source_timestamp": "2019-11-07T02:15:39",
"source_metadata": {
"log_file": ""
"scn": 15869116216871,
"row_id": "AAAPwRAALAAMzMBABD",
"is_deleted": false,
"database": "DB1",
"schema": "ROOT",
"table": "SAMPLE"
"change_type": "INSERT",
"tx_id":
"rs_id": "0x0073c9.000a4e4c.01d0",
"ssn": 67,
},
"payload": {
"THIS_IS_MY_PK": "1231535353",
"FIELD1": "foo",
"FIELD2": "TLV",
}
}
UPDATE (T1)
La charge utile du message consiste en l'intégralité de la nouvelle ligne. Il n'inclut pas les valeurs précédentes.
{
"stream_name": "projects/myProj/locations/myLoc/streams/Oracle-to-Source",
"read_method": "oracle-cdc-logminer",
"object": "SAMPLE.TBL",
"uuid": "e6067366-1efc-0a10-a084-0d8701101101",
"read_timestamp": "2019-11-07T07:37:18.808Z",
"source_timestamp": "2019-11-07T02:17:39",
"source_metadata": {
"log_file":
"scn": 15869150473224,
"row_id": "AAAGYPAATAAPIC5AAB",
"is_deleted": false,
"database":
"schema": "ROOT",
"table": "SAMPLE"
"change_type": "UPDATE",
"tx_id":
"rs_id": "0x006cf4.00056b26.0010",
"ssn": 0,
},
"payload": {
"THIS_IS_MY_PK": "1231535353",
"FIELD1": null,
"FIELD2": "TLV",
}
}
DELETE (T2)
La charge utile du message consiste en l'intégralité de la nouvelle ligne.
{
"stream_name": "projects/myProj/locations/myLoc/streams/Oracle-to-Source",
"read_method": "oracle-cdc-logminer",
"object": "SAMPLE.TBL",
"uuid": "c504f4bc-0ffc-4a1a-84df-6aba382fa651",
"read_timestamp": "2019-11-07T07:37:20.808Z",
"source_timestamp": "2019-11-07T02:19:39",
"source_metadata": {
"log_file":
"scn": 158691504732555,
"row_id": "AAAGYPAATAAPIC5AAC",
"is_deleted": true,
"database":
"schema": "ROOT",
"table": "SAMPLE"
"change_type": "DELETE",
"tx_id":
"rs_id": "0x006cf4.00056b26.0011",
"ssn": 0,
},
"payload": {
"THIS_IS_MY_PK": "1231535353",
"FIELD1": null,
"FIELD2": "TLV",
}
}
Mise en ordre et cohérence
Cette section explique comment Datastream gère la mise en ordre et la cohérence.
commandes
Datastream ne garantit pas le tri, mais chaque événement contient la ligne complète de données et le code temporel correspondant au moment où les données ont été écrites dans la source. Dans BigQuery, les événements dans le désordre sont automatiquement fusionnés dans la bonne séquence. BigQuery utilise les métadonnées d'événement et un numéro de séquence de modification interne (CSN) pour appliquer les événements à la table dans le bon ordre. Dans Cloud Storage, les événements d'un même moment peuvent s'étendre sur plusieurs fichiers.
Les événements générés dans le désordre se produisent dès lors qu'ils sont remplis pour le remplissage initial des données créées au lancement du flux.
Il est possible de classer les données en fonction de la source.
| Source | Description |
|---|---|
| MySQL | Le champ Le champ L'ordre peut être déduit de la combinaison du champ |
| Oracle | Le champ Le champ L'ordre peut être déduit de la combinaison du champ |
| PostgreSQL | Pour les événements qui font partie du remplissage initial, le champ Le champ L'ordre peut être inféré par la combinaison du champ |
| SQL Server |
Le champ Le champ L'ordre peut être déduit de la combinaison du champ |
Cohérence
Datastream garantit que les données de la base de données source seront livrées à la destination au moins une fois. Aucun événement ne sera manqué, mais il est possible que des événements soient dupliqués dans le flux. La période de détection des événements en double doit être de l'ordre de quelques minutes. L'identifiant unique universel (UUID) de l'événement dans les métadonnées de l'événement peut être utilisé pour détecter les doublons.
Lorsque les fichiers journaux de la base de données contiennent des transactions non validées, si des transactions font l'objet d'un rollback, la base de données l'indique dans les fichiers journaux comme "inverse". de traitement des données (LMD). Par exemple, une opération INSERT annulée est associée à une opération DELETE. Datastream lit ces opérations à partir des fichiers journaux.
À propos des flux
Chaque flux comporte des métadonnées qui décrivent le flux et la source à partir duquel il extrait des données. Ces métadonnées incluent des informations telles que le nom du flux, les profils de connexion source et de destination, etc.
Pour afficher la définition complète de l'objet Stream, consultez la documentation de référence de l'API.
État d'un flux
Un flux peut avoir l'un des états suivants :
Not startedStartingRunningDrainingPausedFailedFailed permanently
Vous pouvez utiliser les journaux pour obtenir des informations d'état supplémentaires, telles que le remplissage des tables, le nombre de lignes traitées, etc. Vous pouvez également utiliser l'API FetchStreamErrors pour récupérer les erreurs.
Métadonnées d'objets disponibles en utilisant l'API Discovery
L'API Discover renvoie des objets qui représentent la structure des objets définis dans la source de données ou la destination représentée par le profil de connexion. Chaque objet possède des métadonnées sur l'objet lui-même, ainsi que pour chaque champ de données qu'il extrait. Ces métadonnées sont disponibles via l'API Discover.
Étape suivante
- Pour en savoir plus sur les flux, consultez la section Cycle de vie des flux.
- Pour savoir comment créer une diffusion, consultez Créer un flux.