Paramétrez Openflow Connector for SQL Server

Note

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

Cette rubrique explique comment configurer le Openflow Connector for SQL Server.

Pour plus d’informations sur le processus de chargement incrémentiel, consultez Réplication incrémentielle.

Conditions préalables

Avant de configurer le connecteur, assurez-vous d’avoir rempli les conditions préalables suivantes :

  1. Assurez-vous d’avoir consulté À propos de Openflow Connector for SQL Server.

  2. Assurez-vous d’avoir consulté Versions du serveur SQL prises en charge.

  3. Assurez-vous d’avoir configuré votre déploiement d’exécution. Pour plus d’informations, consultez les rubriques suivantes :

  4. Si vous utilisez Openflow - Snowflake Deployments, assurez-vous d’avoir examiné la configuration des domaines requis et d’avoir accordé l’accès aux domaines requis pour le connecteur SQL Server.

Configurer votre instance SQL Server

Avant de configurer le connecteur, effectuez les tâches suivantes dans votre environnement SQL Server :

Note

Vous devez effectuer ces tâches en tant qu’administrateur de base de données.

  1. Activez le suivi des modifications sur les bases de données et les tables que vous prévoyez de répliquer, comme montré dans l’exemple SQL Server suivant :

    ALTER DATABASE <database>
      SET CHANGE_TRACKING = ON
      (CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
    
    ALTER TABLE <schema>.<table>
      ENABLE CHANGE_TRACKING
      WITH (TRACK_COLUMNS_UPDATED = ON);
    
    Copy

    Note

    Exécutez ces commandes pour chaque base de données et chaque table que vous prévoyez de répliquer.

    Le connecteur exige que le suivi des modifications soit activé sur les bases de données et les tables avant le début de la réplication. Assurez-vous que le suivi des modifications est activé pour chaque table que vous prévoyez de répliquer. Vous pouvez également activer le suivi des modifications pour d’autres tables lorsque le connecteur est en cours d’exécution.

  2. Créez une connexion pour l’instance SQL Server :

    CREATE LOGIN <user_name> WITH PASSWORD = '<password>';
    
    Copy

    Cette connexion est utilisée pour créer des utilisateurs pour les bases de données que vous prévoyez de répliquer.

  3. Créez un utilisateur pour chaque base de données que vous répliquez en exécutant la commande SQL Server suivante dans chaque base de données :

    USE <source_database>;
    CREATE USER <user_name> FOR LOGIN <user_name>;
    
    Copy
  4. Accordez les autorisations SELECT et VIEW CHANGE TRACKING à l’utilisateur pour chaque base de données que vous répliquez :

    GRANT SELECT ON <database>.<schema>.<table> TO <user_name>;
    GRANT VIEW CHANGE TRACKING ON <database>.<schema>.<table> TO <user_name>;
    
    Copy

    Exécutez ces commandes dans chaque base de données pour chaque table que vous prévoyez de répliquer. Ces autorisations doivent être accordées à l’utilisateur de chaque base de données que vous avez créée précédemment.

  5. (Facultatif) Configurez la connexion SSL.

    Si vous utilisez une connexion SSL pour vous connecter au SQL Server, créez le certificat racine pour votre serveur de base de données. Ceci est nécessaire lors de la configuration du connecteur.

Configurer votre environnement Snowflake

En tant qu’administrateur de compte Snowflake, effectuez les tâches suivantes :

  1. Créez une base de données de destination dans Snowflake pour stocker les données répliquées :

    CREATE DATABASE <destination_database>;
    
    Copy
  2. Créez un utilisateur de service Snowflake :

    CREATE USER <openflow_user>
      TYPE = SERVICE
      COMMENT='Service user for automated access of Openflow';
    
    Copy
  3. Créez un rôle Snowflake pour le connecteur et accordez-lui les privilèges requis :

    CREATE ROLE <openflow_role>;
    GRANT ROLE <openflow_role> TO USER <openflow_user>;
    GRANT USAGE ON DATABASE <destination_database> TO ROLE <openflow_role>;
    GRANT CREATE SCHEMA ON DATABASE <destination_database> TO ROLE <openflow_role>;
    
    Copy

    Utilisez ce rôle pour gérer l’accès du connecteur à la base de données Snowflake.

    Pour créer des objets dans la base de données de destination, vous devez accorder les privilèges USAGE et CREATE SCHEMA sur la base de données au rôle utilisé pour gérer l’accès.

  4. Créez un entrepôt Snowflake pour le connecteur et accordez-lui les privilèges requis :

    CREATE WAREHOUSE <openflow_warehouse> WITH
      WAREHOUSE_SIZE = 'XSMALL'
      AUTO_SUSPEND = 300
      AUTO_RESUME = TRUE;
    GRANT USAGE, OPERATE ON WAREHOUSE <openflow_warehouse> TO ROLE <openflow_role>;
    
    Copy

    Snowflake recommends starting with a XSMALL warehouse size, then experimenting with size depending on the number of tables being replicated and the amount of data transferred. Large numbers of tables typically scale better with multi-cluster warehouses, rather than a larger warehouse size. For more information, see multi-cluster warehouses.

  5. Configurez les clés publiques et privées pour l’authentification par paire de clés :

    1. Créez une paire de clés sécurisées (publique et privée).

    2. Stockez la clé privée de l’utilisateur dans un fichier à fournir à la configuration du connecteur.

    3. Attribuez la clé publique à l’utilisateur du service Snowflake :

      ALTER USER <openflow_user> SET RSA_PUBLIC_KEY = 'thekey';
      
      Copy

      Pour plus d’informations, voir Authentification par paire de clés et rotation de paires de clés.

Configuration du connecteur

En tant qu’ingénieur des données, installez et configurez le connecteur à l’aide des sections suivantes.

Installer le connecteur

  1. Accédez à la page d’aperçu d’Openflow. Dans la section Featured connectors, sélectionnez View more connectors.

  2. Sur la page des connecteurs Openflow, trouvez le connecteur et sélectionnez Add to runtime.

  3. Dans la boîte de dialogue Select runtime, sélectionnez votre environnement d’exécution dans la liste déroulante Available runtimes, puis cliquez sur Add.

    Note

    Avant d’installer le connecteur, assurez-vous que vous avez créé une base de données et un schéma dans Snowflake pour que le connecteur puisse stocker les données ingérées.

  4. Authentifiez-vous au déploiement avec les identifiants de votre compte Snowflake et sélectionnez Allow lorsque vous êtes invité à autoriser l’application d’exécution à accéder à votre compte Snowflake. Le processus d’installation du connecteur prend quelques minutes.

  5. Authentifiez-vous auprès de l’environnement d’exécution avec les identifiants de votre compte Snowflake.

Le canevas Openflow apparaît avec le groupe de processus du connecteur ajouté.

Configuration du connecteur

Pour configurer le connecteur, procédez comme suit :

  1. Cliquez avec le bouton droit de la souris sur le groupe de processus importé et sélectionnez Parameters.

  2. Renseignez les valeurs des paramètres requis comme décrit dans Paramètres de débit.

Paramètres de débit

Commencez par définir les paramètres du contexte des paramètres source SQLServer, puis définissez le contexte des paramètres de destination SQLServer. Une fois cette opération terminée, activez le connecteur. Le connecteur se connecte à la fois à SQLServer et à Snowflake et démarre l’exécution. Toutefois, le connecteur ne réplique aucune donnée tant que les tables à répliquer n’ont pas été explicitement ajoutées à sa configuration.

Pour configurer des tables spécifiques pour la réplication, modifiez le contexte des paramètres d’ingestion SQLServer. Une fois que vous avez appliqué les modifications au contexte des paramètres d’ingestion SQLServer, la configuration est reprise par le connecteur et le cycle de vie de la réplication démarre pour chaque table.

Contexte des paramètres source SQLServer

Paramètre

Description

URL de connexion au serveur SQL

L’adresse complète URL JDBC de la base de données source.

Exemple :

  • jdbc:sqlserver://example.com:1433;encrypt=false;

Pilote JDBC du serveur SQL

Cochez la case Reference asset pour charger le pilote JDBC du serveur SQL.

Nom d’utilisateur du serveur SQL

Le nom d’utilisateur du connecteur.

Mot de passe du serveur SQL

Le mot de passe du connecteur.

Contexte des paramètres de destination SQLServer

Paramètre

Description

Obligatoire

Base de données de destination

La base de données dans laquelle les données sont conservées. Elle doit déjà exister dans Snowflake. Le nom est sensible à la casse. Pour les identificateurs sans guillemets, indiquez le nom en majuscules.

Oui

Stratégie d’authentification Snowflake

Lorsque vous utilisez :

  • Snowflake Openflow Deployment or BYOC: Use SNOWFLAKE_MANAGED_TOKEN. This token is managed automatically by Snowflake. BYOC deployments must have previously configured runtime roles to use SNOWFLAKE_MANAGED_TOKEN.

  • BYOC : BYOC peut également utiliser KEY_PAIR comme valeur pour la stratégie d’authentification.

Oui

Identificateur de compte Snowflake

Lorsque vous utilisez :

  • Stratégie d’authentification par jeton de session : doit être vide.

  • KEY_PAIR : nom d’utilisateur Snowflake au format [nom-organisation]-[nom-utilisateur] où les données seront conservées.

Oui

Stratégie de connexion à Snowflake

Lorsque vous utilisez KEY_PAIR, spécifiez la stratégie de connexion à Snowflake :

  • STANDARD (par défaut) : Connectez-vous à l’aide du routage public standard aux services Snowflake.

  • PRIVATE_CONNECTIVITY : Connectez-vous en utilisant des adresses privées associées à la plateforme Cloud prise en charge, comme AWS PrivateLink.

Requis pour BYOC avec KEY_PAIR uniquement ; ignoré dans les autres cas.

Résolution de l’identificateur d’objet Snowflake

Spécifie la manière dont les identificateurs d’objets sources tels que les schémas, les tables et les noms de colonnes sont stockés et interrogés dans Snowflake. Ce paramètre détermine si vous devrez utiliser des guillemets doubles dans les requêtes SQL.

Option 1 : Par défaut, insensible à la casse (recommandé).

  • Transformation : Tous les identificateurs sont convertis en majuscules. Par exemple, My_Table devient MY_TABLE.

  • Requêtes : les requêtes SQL ne sont pas sensibles à la casse et ne nécessitent pas de guillemets doubles SQL.

    Par exemple SELECT * FROM my_table; renvoie les mêmes résultats que SELECT * FROM MY_TABLE;.

Note

Snowflake recommande d’utiliser cette option si les objets de la base de données ne sont pas censés avoir des noms avec une casse mixte.

Important

Ne modifiez pas ce paramètre une fois que l’ingestion du connecteur a commencé. La modification de ce paramètre après le début de l‘ingestion interrompt l’ingestion existante. Si vous devez modifier ce paramètre, créez une nouvelle instance de connecteur.

Option 2 : sensible à la casse.

  • Transformation : La casse est préservée. Par exemple, My_Table reste My_Table.

  • Requêtes : les requêtes SQL doivent utiliser des guillemets doubles pour respecter la casse exacte des objets de base de données. Par exemple, SELECT * FROM "My_Table";.

Note

Snowflake recommande d’utiliser cette option si vous devez préserver la casse source pour des raisons héritées ou de compatibilité. Par exemple, si la base de données source comprend des noms de tables qui ne diffèrent que par la casse, comme MY_TABLE et my_table, il en résultera un conflit de noms lors de l’utilisation de comparaisons non sensibles à la casse.

Oui

Clé privée de Snowflake

Lorsque vous utilisez :

  • Stratégie d’authentification par jeton de session : doit être vide.

  • KEY_PAIR : Doit correspondre à la clé privée RSA utilisée pour l’authentification.

    La clé RSA doit être formatée conformément aux normes PKCS8 et posséder des en-têtes et des pieds de page PEM standards. Notez qu’un fichier de clé privée Snowflake ou une clé privée Snowflake doit être défini.

Non

Fichier de clé privée de Snowflake

Lorsque vous utilisez :

  • Stratégie d’authentification par jeton de session : le fichier de la clé privée doit être vide.

  • KEY_PAIR : Chargez le fichier qui contient la clé privée RSA utilisée pour l’authentification auprès de Snowflake, formatée conformément aux normes PKCS8 et possédant des en-têtes et des pieds de page PEM standards. La ligne d’en-tête commence par -----BEGIN PRIVATE. Pour charger le fichier de la clé privée, cochez la case Reference asset.

Non

Mot de passe de la clé privée de Snowflake

Lorsque vous utilisez :

  • Stratégie d’authentification par jeton de session : doit être vide.

  • KEY_PAIR : fournissez le mot de passe associé au fichier de la clé privée Snowflake.

Non

Rôle Snowflake

Lorsque vous utilisez :

  • Stratégie d’authentification par jeton de session : Utilisez votre rôle d’exécution. Vous pouvez trouver votre rôle d’exécution dans l’UI d’Openflow, en naviguant jusqu’à View Details pour votre exécution.

  • Stratégie d’authentification KEY_PAIR : Utilisez un rôle valide configuré pour votre utilisateur de service.

Oui

Nom d’utilisateur Snowflake

Lorsque vous utilisez :

  • Stratégie d’authentification par jeton de session : doit être vide.

  • KEY_PAIR : indiquez le nom d’utilisateur utilisé pour vous connecter à l’instance Snowflake.

Oui

Entrepôt Snowflake

Entrepôt Snowflake utilisé pour exécuter des requêtes.

Oui

Contexte des paramètres d’ingestion SQLServer

Paramètre

Description

Noms des tables incluses

Une liste de chemins d’accès aux tables sources séparés par des virgules, y compris leurs bases de données et leurs schémas, par exemple :

database_1.public.table_1, database_2.schema_2.table_2

Table incluse Regex

Une expression régulière à associer aux chemins d’accès aux tables, y compris les noms de bases de données et de schémas. Chaque chemin correspondant à l’expression est répliqué, et les nouvelles tables correspondant au modèle qui sont créées ultérieurement sont également incluses automatiquement, par exemple :

database_name\.public\.auto_.*

Filtre JSON

Une adresse JSON contenant une liste de noms de tables entièrement qualifiés et un modèle de regex pour les noms de colonnes à inclure dans la réplication.

L’exemple suivant inclut toutes les colonnes qui se terminent par name dans la table1 du schéma public dans la base de données my_db :

[ {"database":"my_db", "schema":"public", "table":"table1", "includedPattern":".*name"} ]

Fusionner la planification des tâches CRON

Expression CRON définissant les périodes au cours desquelles les opérations de fusion du journal vers la table de destination seront déclenchées. Paramétrez cet élément sur * * * * * ? si vous souhaitez une fusion continue ou une planification pour limiter la durée d’exécution de l’entrepôt.

Par exemple :

  • La chaîne * 0 * * * ? indique que vous souhaitez planifier des fusions à l’heure pleine pendant une minute

  • La chaîne * 20 14 ? * MON-FRI indique que vous souhaitez planifier les fusions à 14h20 tous les lundis et vendredis.

Pour plus d’informations et d’exemples, consultez le tutoriel sur les déclencheurs cron dans la documentation de Quartz

Supprimez et ajoutez à nouveau une table à la réplication

Pour supprimer une table de la réplication, supprimez-la des paramètres Noms de tables inclus ou Expressions régulières de table incluses dans le contexte des paramètres de réplication.

Pour ajouter à nouveau la table à la réplication ultérieurement, supprimez d’abord la table de destination correspondante dans Snowflake. Ensuite, ajoutez à nouveau la table aux paramètres Noms des tables incluses ou Table incluse Regex. Cela permet de garantir que le processus de réplication démarre à nouveau pour la table.

Cette approche peut également être utilisée pour récupérer un scénario de réplication de table qui a échoué.

Répliquer un sous-ensemble de colonnes dans une table

Le connecteur filtre les données répliquées par table sur un sous-ensemble de colonnes configurées.

Pour appliquer des filtres aux colonnes, modifiez la propriété Filtre de colonne dans le contexte Paramètres de réplication, en ajoutant un tableau de configurations, une entrée pour chaque table à laquelle vous souhaitez appliquer un filtre.

Incluez ou excluez des colonnes par nom ou modèle. Vous pouvez appliquer une seule condition par table ou combiner plusieurs conditions, les exclusions ayant toujours la priorité sur les inclusions.

L’exemple suivant montre les champs disponibles. Les champs schema et table sont obligatoires. Une ou plusieurs des adresses suivantes : included, excluded, includedPattern, excludedPattern sont exigées.

[
    {
        "schema": "<source table schema>",
        "table" : "<source table name>",
        "included": ["<column name>", "<column name>"],
        "excluded": ["<column name>", "<column name>"],
        "includedPattern": "<regular expression>",
        "excludedPattern": "<regular expression>",
    }
]
Copy

Suivre les changements de données dans les tables

Le connecteur réplique l’état actuel des données provenant des tables sources, mais aussi chaque état de chaque ligne de chaque jeu de modifications. Ces données sont stockées dans des tables de journal créées dans le même schéma que la table de destination.

Les noms des tables de journal sont formatés comme suit : <source table name>_JOURNAL_<timestamp>_<schema generation> where <timestamp> is the value of epoch seconds when the source table was added to replication, and <schema generation> est un nombre entier qui augmente à chaque modification du schéma sur la table source. Par conséquent, les tables sources qui subissent des modifications de schéma auront plusieurs tables de journal.

Lorsque vous supprimez une table de la réplication, puis que vous l’ajoutez à nouveau, la <timestamp> value changes, and <schema generation> starts again from 1.

Important

Snowflake recommande de ne pas modifier la structure des tables de journal de quelque manière que ce soit. Le connecteur les utilise pour mettre à jour la table de destination dans le cadre du processus de réplication.

Le connecteur ne supprime jamais les tables de journal, mais il utilise le journal le plus récent pour chaque table source répliquée, en se contentant de lire les flux d’ajout uniquement au-dessus des journaux. Pour récupérer le stockage, vous pouvez :

  • Tronquer toutes les tables de journal à tout moment.

  • Supprimer les tables de journal liées aux tables sources qui ont été retirées de la réplication.

  • Supprimer toutes les tables de journal de la dernière génération, sauf les tables activement répliquées.

Par exemple, si votre connecteur est paramétré pour répliquer activement la table source orders, et que vous avez précédemment supprimé la table customers de la réplication, vous pouvez avoir les tables de journal suivantes. Dans ce cas, vous pouvez toutes les supprimer, à l’exception de orders_5678_2.

customers_1234_1
customers_1234_2
orders_5678_1
orders_5678_2

Configuration de la planification des tâches de fusion

Le connecteur utilise un entrepôt pour fusionner les données de capture des données de changement (CDC) dans les tables de destination. Cette opération est déclenchée par le processeur MergeSnowflakeJournalTable. S’il n’y a pas de nouvelles modifications ou si aucun nouveau fichier de flux n’est en attente dans la file d’attente MergeSnowflakeJournalTable, aucune fusion n’est déclenchée et l’entrepôt se suspend automatiquement.

Utilisez l’expression CRON dans le paramètre de planification CRON de la tâche de fusion pour limiter le coût de l’entrepôt et restreindre les fusions aux seules heures planifiées. Elle limite les fichiers de flux arrivant au processeur MergeSnowflakeJournalTable et les fusions ne sont déclenchées qu’au cours d’une période donnée. Pour plus d’informations sur la planification, voir Stratégie de planification.

Exécutez le flux

  1. Cliquez avec le bouton droit de la souris sur l’avion et sélectionnez Enable all Controller Services.

  2. Cliquez avec le bouton droit de la souris sur le groupe de processus importé et sélectionnez Start. Le connecteur démarre l’ingestion des données.