À propos de Openflow Connector for Google BigQuery¶

Note

Ce connecteur est soumis aux conditions d’utilisation de Snowflake Connector.

La fonction Openflow Connector for Google BigQuery connecte un projet Google BigQuery dans Snowflake et réplique les données des ensembles de données, des tables et des vues sélectionnés selon une planification. Le connecteur effectue un chargement initial complet pour chaque table, suivi de mises à jour incrémentielles à l’aide de la fonction native BigQuery de suivi des modifications. Les vues sont répliquées à l’aide d’une stratégie de troncature et de chargement.

Cas d’utilisation¶

Le connecteur prend en charge les cas d’utilisation suivants :

Réplication vers Snowflake : mettez continuellement en miroir des ensembles de données depuis BigQuery dans Snowflake pour l’analyse et la modélisation en aval. Les modifications incrémentielles arrivent selon une planification avec une fenêtre de délai de 10 minutes.
Réplication sélective : définissez les régions, les ensembles de données, les tables et les vues à inclure en utilisant des noms ou des filtres regex pour une couverture large avec contrôle.
Migration et capture des modifications : effectuez un chargement d’instantané unique pour les migrations, puis exécutez des synchronisations incrémentielles à l’aide de l’historique des modifications BigQuery pour maintenir la synchronisation des tables.
Réplication des vues : répliquez les vues BigQuery standard et matérialisées vers Snowflake en utilisant une stratégie de troncature et de chargement selon une planification configurable.

Le cycle de vie de la réplication de la table¶

Le cycle de réplication d’une table commence par la découverte du schéma et un chargement d’instantané initial des données. Le cycle passe à la synchronisation incrémentielle une fois les données ingérées dans Snowflake.

Introspection du schéma : le connecteur découvre le schéma de la table source, valide ses types de données, et crée un schéma et une table de destination qui correspondent dans Snowflake.
Chargement d’instantané : après avoir créé le schéma et la table, le connecteur effectue une copie complète de toutes les données existantes à partir de la table BigQuery vers Snowflake. Ce processus s’exécute séquentiellement pour chaque table de la configuration.
Synchronisation incrémentielle : une fois le chargement initial terminé, la table entre en mode de synchronisation incrémentielle planifiée. À chaque exécution, le connecteur utilise la fonction CHANGES de BigQuery pour lire le journal des modifications au niveau des lignes (insertions, mises à jour, suppressions) qui se sont produites depuis la dernière synchronisation. Ces modifications sont ensuite récupérées et fusionnées dans la table de destination dans Snowflake.

Exigences Openflow¶

La taille minimale de l’environnement d’exécution doit être Medium. Utilisez un environnement d’exécution plus grand et une configuration Openflow à plusieurs nœuds si vous répliquez de grands volumes de données.

Limitations¶

BigQuery garantit que les flux de données utilisés pour récupérer les données sources restent valides pendant au moins 6 heures. Par conséquent, le processus de lecture de la table source doit être complété en moins de 6 heures pour éviter que les flux de données n’expirent. Vous devez utiliser un environnement d’exécution plus grand, à plusieurs nœuds, lors de l’ingestion de tables dont les volumes de données sont supérieurs à 100GB.
Le type BIGNUMERIC de BigQuery prend en charge une plus grande précision (jusqu’à 76 chiffres) que le type NUMBER de Snowflake (38 chiffres). Le connecteur ne peut pas ingérer de valeurs provenant de colonnes BIGNUMERIC qui dépassent la limite de Snowflake.
Le connecteur ne prend pas en charge la réplication des tables externes.
La réplication de vues utilise uniquement une stratégie de troncature et de chargement. La synchronisation incrémentielle (CDC) n’est pas prise en charge pour les vues.
Les synchronisations incrémentielles nécessitent une clé primaire pour gérer correctement les mises à jour et les suppressions. Pour les tables sans clé primaire, le connecteur ne prend pas en charge les suppressions et traite les mises à jour comme de nouvelles insertions.

Note

Vous devez vous assurer que les contraintes de clé primaire sont respectées. Si le champ marqué comme clé primaire n’est pas unique, l’incohérence des données peut se produire en mode incrémentiel.
Le connecteur utilise la fonction CHANGES de BigQuery pour les mises à jour incrémentielles. Comme cette fonction ne peut pas interroger les dix dernières minutes de l’historique des tables, les données répliquées en mode incrémentiel présentent un décalage minimum de 10 minutes par rapport à la source.
Le processus de synchronisation incrémentielle est limité à une fenêtre de données maximale de 24 heures en raison de la fonction CHANGES de BigQuery. Si le décalage de réplication d’une table dépasse cette période, le connecteur tronque la fenêtre de modification à 24 heures pour poursuivre la synchronisation. Cette troncation peut entraîner une perte de données.
Le connecteur hérite de toutes les autres limitations de la fonction CHANGES de BigQuery. Pour plus d’informations, consultez la documentation dédiée à la fonction CHANGES de BigQuery.

Réplication de vues¶

Le connecteur prend en charge la réplication des vues standard et des vues matérialisées à partir de BigQuery vers Snowflake. Contrairement à la réplication de tables, les vues ne prennent pas en charge la synchronisation incrémentielle (CDC). Au lieu de cela, le connecteur utilise une stratégie de troncature et de chargement : à chaque cycle de synchronisation, le connecteur remplace entièrement les données dans la table de destination Snowflake par le contenu actuel de la vue source.

La fréquence de synchronisation des vues est configurée séparément de la fréquence de synchronisation incrémentielle de la table à l’aide du paramètre Fréquence de synchronisation des vues. Les exécutions ne se chevauchent pas. Si un cycle prend plus de temps que l’intervalle configuré, l’exécution suivante attend la fin de l’exécution précédente.

Vous pouvez filtrer les vues à répliquer à l’aide des paramètres Noms de vues incluses et Regex des noms de vues incluses. Ces filtres s’appliquent à tous les ensembles de données sélectionnés pour la réplication.

Le connecteur crée des tables temporaires dans BigQuery lors de l’ingestion de vues. Utilisez le paramètre Ensemble de données de table temporaire pour spécifier un ensemble de données dédié à ces tables temporaires. Snowflake recommande d’utiliser un ensemble de données distinct pour les tables temporaires et de ne pas utiliser l’ensemble de données ingéré à cette fin.

Mappages de types de données¶

Le connecteur mappe les types de données BigQuery vers les types de données Snowflake correspondants.


Type de données BigQuery	Type de données Snowflake
BIGNUMERIC	NUMBER
NUMERIC	NUMBER
GEOGRAPHY	VARCHAR
DATETIME	TIMESTAMP_NTZ
JSON	OBJECT
STRUCT	OBJECT
RANGE	OBJECT
INTERVAL	OBJECT
TIMESTAMP	TIMESTAMP_NTZ
DATE	DATE
TIME	TIME
INT64 / INTEGER	NUMBER
FLOAT64	FLOAT
BOOL / BOOLEAN	BOOLEAN
STRING	VARCHAR
BYTES	BINARY
ARRAY	ARRAY

Suivre les modifications de données dans Google BigQuery¶

La fonctionnalité de synchronisation incrémentielle du connecteur est basée sur la fonction CHANGES native de BigQuery. Lorsque vous activez l’historique des modifications sur une table source, BigQuery conserve un journal interne de toutes les modifications au niveau des lignes (insertions, mises à jour et suppressions).

Le connecteur interroge ce journal selon une planification de fréquence de synchronisation incrémentielle configurée pour récupérer un flux de modifications. Le connecteur matérialise ces modifications dans une table de journal au sein du même ensemble de données BigQuery. Cette table de journal respecte une convention d’appellation cohérente : <sourceTableName>_<incremental_number>_<hash>_journal.

Ces tables de journal sont entièrement gérées par le connecteur pendant le processus de réplication et sont utilisées pour fusionner les données dans la table de destination finale dans Snowflake.

Avertissement

Ne modifiez pas les tables de journal de quelque manière que ce soit. La modification des tables de journal peut perturber le processus de synchronisation et entraîner des problèmes d’intégrité des données.

L’opération de fusion traite les changements différemment pour les tables avec une clé primaire (PK) et pour les tables sans clé primaire.

Tables avec une clé primaire¶

Pour les tables avec une clé primaire, le connecteur gère les modifications de données comme suit :

Insertions et mises à jour:: Les lignes identifiées comme INSERT ou UPDATE sont insérées ou mises à jour dans la table Snowflake correspondante.
Suppressions:: Pour préserver l’historique des données, le connecteur utilise une stratégie de suppression douce. Au lieu de retirer physiquement une ligne supprimée de Snowflake, le connecteur effectue une UPDATE sur la ligne cible, en définissant la colonne _SNOWFLAKE_DELETED sur TRUE.

Tables sans clé primaire¶

Pour les tables sans clé primaire, le connecteur gère les modifications de données comme suit :

Insertions et mises à jour:: Les lignes identifiées comme INSERT ou UPDATE sont traitées de la même manière et sont insérées dans la table Snowflake correspondante.
Suppressions:: Non pris en charge.

Note

Le connecteur ajoute automatiquement la colonne _SNOWFLAKE_DELETED (BOOLEAN) au schéma de la table de destination lors de sa création.

Planification de la fréquence de synchronisation configurée et fréquence de synchronisation réelle¶

La planification de fréquence de synchronisation incrémentielle détermine la fréquence de synchronisation de la table. Si la planification que vous avez spécifiée est plus fréquente que le temps réel nécessaire pour synchroniser la table, le système ne suit pas la planification que vous avez spécifiée. Cela se produit si les cycles incrémentaux doivent s’exécuter de manière séquentielle et ne peuvent pas se chevaucher.

Évolution du schéma¶

Le connecteur prend en charge plusieurs modifications de schéma courantes dans la table BigQuery source. Les modifications de schéma suivantes sont détectées et propagées vers la table de destination Snowflake :

Ajout de colonnes:

Les nouvelles colonnes ajoutées dans BigQuery sont automatiquement ajoutées à la table Snowflake correspondante.

Suppression de colonnes (suppression douce):

Lorsqu’une colonne est supprimée dans BigQuery, le connecteur effectue une « suppression douce » dans Snowflake. La colonne n’est pas supprimée de la table de destination. Au lieu de cela, elle est renommée en ajoutant le suffixe _SNOWFLAKE_DELETED à la fin du nom de la colonne. Par exemple, my_column devient my_column_SNOWFLAKE_DELETED. Cela préserve les données historiques dans Snowflake.

Renommage de colonnes:

Une opération de renommage de colonnes est un processus en deux étapes :

La colonne d’origine est « supprimée de manière douce » et renommée en ajoutant le suffixe _SNOWFLAKE_DELETED.
Une nouvelle colonne portant le nouveau nom est ajoutée à la table Snowflake.

Modification des clés primaires:

L’ajout, la suppression et la modification des clés primaires sont pris en charge.

Changements de types de données:

Seuls les changements qui élargissent le type existant sont tolérés. Toute modification qui restreint un type de colonne ou le convertit en un type incompatible n’est pas prise en charge et entraînera l’échec de la réplication pour cette table.

Prochaines étapes¶

Pour plus d’informations sur la configuration du connecteur, reportez-vous à la rubrique suivante :

Configuration du Openflow Connector for Google BigQuery