Concepts de connecteur de base de données¶

Composants des connecteurs¶

Les connecteurs de base de données Snowflake se composent de Snowflake Native App, installé depuis Marketplace sur votre compte Snowflake, et d’une application Agent exécutée dans votre infrastructure, soit sur site, soit dans le cloud.

• Les Agents se connectent directement à vos bases de données sources, suivent les mises à jour des tables que vous avez choisi de répliquer et chargent les modifications dans votre compte Snowflake. Les Agents nécessitent une seule configuration pour se connecter à Snowflake et aux sources de données, puis une mise à niveau uniquement lorsque de nouvelles versions sont publiées. Pour le reste, ils sont entièrement contrôlés et configurés via Native App.

• Les Native Apps contrôlent le processus de réplication des données. Elles indiquent aux agents les tables à suivre, reçoivent les modifications et les fusionnent dans vos bases de données de destination. La plupart de vos interactions se feront avec Native App. Elle est automatiquement mise à niveau lorsqu’une nouvelle version est disponible.

Ce modèle, dans lequel un agent s’exécute localement, est nécessaire pour que le connecteur puisse accéder en toute sécurité aux bases de données sources dans les réseaux fermés aux connexions externes.

Une instance Agent se connecte toujours à une seule instance Native App, et une Native App fonctionne toujours avec un Agent. Si vous devez exécuter plusieurs instances Agent, peut-être pour répliquer des bases de données sources à partir de réseaux déconnectés, vous devrez installer et configurer plusieurs instances de Native App. Contactez l”Assistance Snowflake pour obtenir de l’aide.

En interne, le connecteur s’appuie sur un échange de commandes asynchrone axé sur les événements. Native App doit également communiquer et se coordonner avec l’Agent. C’est pourquoi vous pouvez remarquer un délai entre l’exécution d’une commande et l’apparition de l’effet de cette commande.

Sources de données, tables, journaux et destinations¶

Lorsqu’on parle du flux de données via le connecteur, on distingue les zones de préparation suivantes :

Source de données

Base de données qui contient les tables que le connecteur réplique. Suivant le moteur de base de données, il peut s’agir du serveur de toutes les base de données ou de l’une des bases de données hébergées à l’intérieur du serveur.

Une seule instance de connecteur peut être répliquée à partir de plusieurs sources de données, à condition que l’Agent puisse se connecter directement à toutes les sources.

Table source

Table spécifique de la base de données source dont les modifications sont suivies par le connecteur pour être ensuite répliquées dans Snowflake. Chaque source de données peut contenir plusieurs tables sources qui sont répliquées simultanément par la même instance de connecteur.

Le parent immédiat de la table source de la source de données devient le schéma de la table de destination correspondante dans Snowflake.

Journal

Table Snowflake, détenue et gérée par Native App du connecteur, qui reçoit et stocke toutes les modifications appliquées à la table source : insertions, mises à jour et suppressions. Il s’agit d’un journal des modifications de facto des données de la table source, et sa structure reflète la manière dont les moteurs de base de données diffusent généralement les modifications à leurs répliques.

Chaque table source possède une table de journal distincte.

Table de destination

Table Snowflake de votre compte dans laquelle le connecteur réplique les données. Il existe une table de destination distincte pour chaque table source. Ses noms de colonne reflètent les noms de la table source et leurs types correspondent aux types Snowflake des colonnes sources.

Chaque table de destination comprend également des colonnes contenant des informations de réplication : _SNOWFLAKE_INSERTED_AT, _SNOWFLAKE_UPDATED_AT, _SNOWFLAKE_DELETED, contenant les horodatages de l’insertion initiale, de la dernière mise à jour et de la suppression de la ligne donnée, respectivement.

La table de destination dispose d’un suivi des modifications préactivé pour permettre la création de flux. Native App du connecteur conserve l’autorisation OWNERSHIP sur la table.

Chargement instantané et chargement incrémentiel¶

La réplication des données d’une table récemment ajoutée commence par un chargement instantané. L’Agent effectue une seule instruction SELECT <colonnes> sur la table source, puis diffuse tous les enregistrements dans une table intermédiaire dans Snowflake, pour ensuite les copier dans la table de destination. Cette opération peut nécessiter beaucoup de ressources sur la base de données source et prendra généralement beaucoup de temps pour les tables volumineuses. Vous devrez peut-être attendre un certain temps avant de voir apparaître les premiers enregistrements dans la table de destination.

Un chargement instantané peut également être répété, en remplaçant les données précédemment répliquées, pour synchroniser la table source avec la destination, dans les scénarios suivants :

• Lorsque la réplication de la table échoue définitivement, en raison de types de données ou de tailles non pris en charge, de bogues de connecteur ou d’autres problèmes.

• Lorsque la réplication a été interrompue et après sa reprise, le journal des modifications de la base de données source ne contient plus d’entrées depuis la dernière réplication de la table.

Une fois l’instantané initial terminé, la réplication de la table passe au chargement incrémentiel. L’Agent suit le journal des modifications de la base de données source et diffuse ces modifications dans la table de journal correspondante, d’où elles sont ensuite fusionnées dans la table de destination. Ce cycle de lecture, de diffusion et de fusion peut être effectué en continu ou selon une planification. Pour plus d’informations sur ces modes, voir Prochaines étapes et Prochaines étapes.

Cycle de vie de la réplication de table¶

Le cycle de réplication d’une table source récemment ajoutée commence par la phase Introspection du schéma. C’est ici que le connecteur découvre les colonnes de la table source, leurs noms, leurs types, puis les valide par rapport aux limitations de Snowflake et du connecteur. Les échecs de validation entraîneront l’échec de cette phase et le cycle se terminera. Une fois l’introspection du schéma correctement terminée, le connecteur crée une table de destination vide.

La deuxième phase est le Chargement instantané, au cours duquel le connecteur copie toutes les données disponibles dans la table source dans la table de destination. L’échec de cette phase mettra également fin au cycle et aucune autre donnée ne sera répliquée. Une fois l’opération correctement terminée, le jeu de données complet de la table source sera disponible dans la table de destination.

Pour finir, la table passe au Chargement incrémentiel, dans le cadre duquel le connecteur continue de suivre les modifications dans la table source et de les copier dans la table de destination. Cette opération se poursuit jusqu’à ce que la table soit retirée de la réplication. L’échec à ce stade arrêtera définitivement la réplication de la table source, jusqu’à ce que le problème soit résolu.

Pour obtenir des instructions sur la manière de déterminer à quelle phase de la réplication se trouvent actuellement vos tables, voir Surveillance du Snowflake Connector for MySQL et Surveillance du Snowflake Connector for PostgreSQL.

Flux de données de la source vers la destination¶

Le connecteur déplace les données différemment de la table source vers la destination suivant qu’il effectue un chargement instantané ou incrémentiel. Pour plus d’informations, voir Chargement instantané et chargement incrémentiel.

Réplication continue ou planifiée¶

Le mode de réplication par défaut des sources de données qui récemment ajoutées est le mode Continu. Dans ce mode, le connecteur vise à répliquer les modifications de données le plus vite possible. Il s’agit du mode optimal pour les sources de données qui changent souvent, lorsque vous avez besoin que ces données soient disponibles dans Snowflake à de faibles latences.

Vous pouvez modifier la source de données de sorte qu’elle applique une réplication en mode Planifié, dans le cadre duquel les données sont copiées de la source vers les tables de destination par lots, selon une planification fixe. Il s’agit du mode optimal pour les sources de données qui changent rarement ou lorsque vous souhaitez réduire la consommation de crédit et que vous n’avez pas besoin que les données soient disponibles dans Snowflake à de faibles latences.

Lors de l’exécution de la réplication continue, le chargement incrémentiel ne sera jamais signalé comme « terminé ». En mode planifié, le chargement incrémentiel est signalé comme terminé après la fusion de chaque lot de données dans la table de destination. En mode planifié, un « lot » se compose de toutes les entrées du journal des modifications comprises entre l’exécution planifiée précédente et le moment où l’exécution planifiée suivante démarre.

Types d’entrepôt¶

Pour fonctionner, les connecteurs nécessitent deux entrepôts :

• Un entrepôt opérationnel, parfois appelé entrepôt Ops, est utilisé pour exécuter les opérations de commande et de contrôle du connecteur. Cet entrepôt est automatiquement créé par l’assistant de configuration et sa taille optimale est XS.

• Un entrepôt de calcul est utilisé pour exécuter les tâches de fusion qui déplacent les données des journaux vers les tables de destination. Cet entrepôt peut être créé par l’assistant de configuration ou manuellement. Sa taille et son type optimaux dépendent de l’échelle de votre réplication.

La distinction ci-dessus est nécessaire pour garantir l’exécution des requêtes opérationnelles en temps opportun, sans qu’elles soient mises en file d’attente avec les requêtes qui déplacent de grandes quantités de données. Cela signifie également que l’entrepôt opérationnel ne peut pas être réutilisé entre les instances de connecteur et ne doit pas être partagé avec d’autres charges de travail du compte.

L’entrepôt de calcul, quant à lui, peut être partagé avec d’autres instances et charges de travail du connecteur. Gardez toutefois à l’esprit le fait que le partage de cet entrepôt peut entraîner des retards dans l’apparition des données dans vos tables de destination.