Connecteur Snowflake

Cet article explique comment utiliser le connecteur Snowflake pour DataGalaxy. 

Ce connecteur est disponible dans les modes suivants :

Ce connecteur supporte les modes d'import suivants :

Technologie

Créé en 2012, Snowflake est un SaaS qui propose une plateforme unique pour le data warehousing, les data lakes, le data engineering, la data science, le développement d’applications data ainsi que le partage et l’usage sécurisé de données en temps réel/partagées.

Périmètre, attributs et représentation dans DataGalaxy

Objets

Certains attributs listés ci-dessous pourraient ne pas être présents par défaut dans la configuration de vos écrans. Pour les faire apparaître dans les écrans DataGalaxy, il peut être nécessaire d'adapter les configuration d'écrans des objets concernés avant de lancer le connecteur. Voir cet article pour en savoir plus sur la customisation des écrans. 

Note : la récupération des objets Snowflake utilise les vues Account Usage. Une latence normale d'environ deux heures est à prendre en compte entre les changements effectués sur Snowflake et la mise à jour de ces vues. Cette latence impacte donc directement la représentation des objets dans DataGalaxy. Plus d'informations ici.

Compte

Un Compte Snowflake est représenté par une Source du Dictionnaire (base de données relationnelle).

L'URN suit cette syntaxe :

urn:snowflake-1:accountName

Les attributs suivants sont récupérés de la configuration de la connexion :

Base de données

Une Base de Données est représentée par un Modèle.

L'URN suit cette syntaxe :

urn:snowflake-1:accountName:database

Les attributs suivants sont récupérés depuis la vue SNOWFLAKE.ACCOUNT_USAGE.DATABASES :

Schéma

Un Schéma est représenté par un Modèle.

L'URN suit cette syntaxe :

urn:snowflake-1:accountName:database:schema

Les attributs suivants sont récupérés depuis la vue SNOWFLAKE.ACCOUNT_USAGE.SCHEMATA (<SHARED_DATABASE>.INFORMATION_SCHEMA.SCHEMATA pour les bases de données partagées):

Les attributs suivants sont calculés :

Table

Une Table est représentée par une Table.

L'URN suit cette syntaxe :

urn:snowflake-1:accountName:database:schema:table

Les attributs suivants sont récupérés depuis la vue SNOWFLAKE.ACCOUNT_USAGE.TABLES (<SHARED_DATABASE>.INFORMATION_SCHEMA.TABLES pour les bases de données partagées):

Vue

Une Vue est représentée par une Vue.

L'URN suit cette syntaxe :

urn:snowflake-1:accountName:database:schema:view@view

Les attributs suivants sont récupérés depuis les vues SNOWFLAKE.ACCOUNT_USAGE.TABLES et SNOWFLAKE.ACCOUNT_USAGE.VIEWS (<SHARED_DATABASE>.INFORMATION_SCHEMA.TABLES et <SHARED_DATABASE>.INFORMATION_SCHEMA.VIEWS pour les bases de données partagées):

Table Dynamique

Une Table Dynamique est représentée par une Table.

L'URN suit cette syntaxe :

urn:snowflake-1:accountName:database:schema:dtable@dynamictable

ATTENTION: en-dehors de ces 3 types (Table, Vue et Table Dynamique), les autres types de table ne sont pas récupérés actuellement (EXTERNAL TABLE et MATERIALIZED VIEW par exemple).

Les attributs suivants sont récupérés depuis la vue SNOWFLAKE.ACCOUNT_USAGE.TABLES (<SHARED_DATABASE>.INFORMATION_SCHEMA.TABLES pour les bases de données partagées):

Colonne

Une Colonne est représentée par une Colonne.

L'URN suit cette syntaxe :

urn:snowflake-1:accountName:database:table:column

Les attributs suivants sont récupérés depuis la vue SNOWFLAKE.ACCOUNT_USAGE.COLUMNS (<SHARED_DATABASE>.INFORMATION_SCHEMA.COLUMNS pour les bases de données partagées):

Clé Primaire

Une Clé Primaire est représentée par une Clé Primaire.

L'URN suit cette syntaxe :

urn:snowflake-1:accountName:database:schema:table:pk@primarykey

Les Clés Primaires sont récupérées avec la requête SHOW PRIMARY KEYS.

Clés Etrangères

Une Clé Etrangère est représentée par une Clé Etrangère.

L'URN suit cette syntaxe :

urn:snowflake-1:accountName:database:schema:table:fk@foreignkey

Les Clés Etrangères sont récupérées avec la requête SHOW IMPORTED KEYS.

Synchronisation bi-directionnelle des Tags

La synchronisation bi-directionnelle des tags permet de récupérer les tags des objets Snowflake dans le champ "Tags externes" de DataGalaxy, et de pousser les tags présents dans l'attribut "Tags" de DataGalaxy sur les objets Snowflake.

Les tags appliqués aux objets Snowflake sont récupérés depuis la vue SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES.
Veuillez noter que, dans la mesure où DataGalaxy ne supporte pas les tags clé|valeur mais seulement les labels, les tags dans DataGalaxy seront créés en concaténant le nom et la valeur du tag dans Snowflake.

Dans Snowflake, les tags sont d'abord créés dans un schéma spécifique à fournir au connecteur (le seul pour lequel le connecteur a besoin de droits en écriture pour la requête CREATE TAGS) et ensuite appliqués à chaque objet.

Veuillez noter que, dans la mesure où DataGalaxy ne supporte pas les tags clé|valeur mais seulement les labels, les tags dans Snowflake seront créé en utilisant seulement le nom du tag dans DataGalaxy.

Liens

Les liens créés par le connecteur Snowflake sont des liens de lineage de données entre les structures du Dictionnaire, au niveau table ou colonne selon la configuration du connecteur. Les liens de lineage sont récupérés avec la fonction SNOWFLAKE.CORE.GET_LINEAGE() et sont représentés dans DataGalaxy avec des liens Utilise/Est Utilisé Par.

Lors d’un import unitaire (mono-db) en mode URN, seules les informations liées à la base de données importée sont prises en compte. Les liens vers des objets provenant d’autres bases de données ne seront donc pas remontés dans DataGalaxy. 

Périmètre détaillé

    Entrée

• Database, schéma, table et vue 

        Dans l’onglet “Worksheets” de la console classique ces éléments apparaîtront sur la gauche

• Colonne

• Database, schéma, table et vue partagés 

        L’emplacement est le même que pour les tables "classiques", simplement ces bases de données se distinguent par la petite flèche à la gauche du symbole de la base de données (en exemple ici, “SNOWFLAKE” et “SNOWFLAKE_SAMPLE_DATA”)

• Colonne partagée

        Ces colonnes se retrouvent au même emplacement que les colonnes classiques

• Primary Key, Foreign Key

        Ces informations sont visibles à l’aide des requêtes suivantes (exemple de résultat pour les clés primaires ci-dessous):

SHOW PRIMARY KEYS IN DATABASE "DEMO_DB";

SHOW IMPORTED KEYS IN DATABASE "DEMO_DB";

Pour que ces éléments apparaissent dans l'espace "Worksheets" de Snowflake, le rôle employé doit disposer des autorisations nécessaires. Ce rôle est visible en haut à droite de la fenêtre. C'est un bon moyen de tester si le rôle custom que vous allez créer pour l'emploi du connecteur dispose des autorisations nécessaires (exemple avec le rôle "DATAGALAXY_CONNECTOR_ROLE" ici)

    Sortie

• Source, schéma, table, vue et colonne

• Clé primaire, clé étrangère

Configuration de la connexion

    Côté Snowflake

Le rôle nécessaire à l'extraction du premier périmètre de métadonnées est un rôle de base de données défini par Snowflake nommé OBJECT_VIEWER. Vous pouvez trouver ici l'intégralité des objets auxquels il donne accès. Nous vous recommandons d'associer ce rôle à un rôle custom dédié comme montré ci-dessous:

• Création d’un rôle dédié, attribution à ce rôle du rôle de base de données OBJECT_VIEWER, attribution des autorisations nécessaires sur un entrepôt à ce rôle, création d’un utilisateur dédié et attribution du rôle ainsi que d’un entrepôt par défaut à cet utilisateur

  Pour réaliser ces actions, veuillez exécuter les commandes suivantes dans l’onglet “Worksheets” de Snowflake en remplaçant les valeurs entre <> (exemple ci-dessous):

// Création d’un rôle dédié
create or replace role <datagalaxy_role_name>;

// Attribution du rôle de base de données OBJECT_VIEWER à ce rôle dédié
grant database role SNOWFLAKE.OBJECT_VIEWER to role <datagalaxy_role_name>;

// Attribution des autorisations nécessaires sur un entrepôt à ce rôle
grant usage on warehouse "<warehouse_name>" to role <datagalaxy_role_name>;

// Création d’un utilisateur dédié et attribution du rôle ainsi que d’un entrepôt par défaut à cet utilisateur (ne pas mettre de guillemets autour du rôle par défaut!)
create user <datagalaxy_user_name> password="<datagalaxy_user_password>" default_role = <datagalaxy_role_name> default_warehouse = "<warehouse_name>";

// Attribution du rôle à l'utilisateur
grant role <datagalaxy_role_name> to user <datagalaxy_user_name>;

• Niveau 1 : Database, schéma, table, vue et colonne

        Une fois le rôle créé en suivant la procédure ci-dessous, vous n'aurez pas besoin d'autorisations supplémentaires pour remonter l'ensemble des métadonnées associées au niveau 1, qu'il s'agisse d'un import unitaire ou d'un import de plusieurs bases de données, tant qu'aucune d'entre elles n'est une base de données partagée.

    Pour remonter les métadonnées des bases de données partagées il faudra donner au rôle un accès explicite à celles-ci via la commande suivante: 

grant imported privileges on all tables IN DATABASE "<shared_database_name>" to role <datagalaxy_role_name>;

• Option 2 : Clés primaires, clés étrangères

        En complément de ces droits, lorsque vous souhaitez faire remonter les clés primaires et étrangères il est nécessaire de disposer de certains droits directement sur les schémas et tables des databases en utilisant les commandes suivantes :

grant MONITOR on all schemas in DATABASE "<database_name>" to role <datagalaxy_role_name>; 
grant SELECT on all tables in DATABASE "<database_name>" to role <datagalaxy_role_name>;

grant MONITOR on all schemas in DATABASE "<database_name>" to role <datagalaxy_role_name>; 
grant MONITOR on all dynamic tables in DATABASE "<database_name>" to role <datagalaxy_role_name>;

GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE <ACCOUNT_ROLE>;

    Côté DataGalaxy

Les informations suivantes sont demandées pour configurer une connexion:

⚠ La récupération du lineage peut augmenter significativement le temps d'exécution du connecteur et génère plus de calculs côté Snowflake, impactant par conséquent les coûts du Warehouse associé. 

* Seulement disponible en mode URN

Appliquer les étiquettes DataGalaxy dans Snowflake

Si vous souhaitez appliquer les étiquettes DataGalaxy dans Snowflake, voici les prérequis à mettre en place :

• Dans Snowflake :
  • Donner le privilège "APPLY TAG" au niveau du compte au rôle utilisé par le connecteur. Ceci peut être fait avec la requête suivante :

grant apply tag on account to role <connector_role>;

• Créer un schéma qui contiendra les étiquettes DataGalaxy. Ceci peut être fait à l'aide de la requête CREATE SCHEMA
• Donner le privilège "USAGE" sur la base de données parent du schéma qui contiendra les étiquettes DataGalaxy. Ceci peut être fait avec la requête suivante :

grant usage on database <dg_database>;

• Donner le privilège "CREATE TAG" sur le schéma qui contiendra les étiquettes DataGalaxy. Ceci peut être fait avec la requête suivante :

grant create tag on schema <dg_database>.<dg_schema> to role <connector_role>;

Du mode standard au mode URN

Différences

1. En mode Standard le nom de votre objet racine sera celui que vous lui donnerez lorsque vous créez la connexion (ou de l'objet racine du module Dictionnaire que vous ciblerez). En mode URN le nom de l'objet racine sera le nom de compte Snowflake utilisé lors du paramétrage de la connexion.
   • Mode Standard
   • Mode URN
2. En mode standard, dans le cadre d'un import unitaire (qui vise à remonter une base de données unique), votre base de données sera considéré comme l’objet racine de la hiérarchie. En mode URN cette base de données se retrouvera un niveau plus bas, sous votre nom de compte Snowflake qui sera devenu le nouvel objet racine. 
   • Mode Standard (import unitaire)
   • Mode URN

Guide de migration

Ce guide a pour but de vous indiquer les étapes à suivre pour passer votre objet racine et tous les objets Snowflake qu'il contient du mode Standard au mode URN. Une fois ces étapes effectuées, vous serez en mesure de réaliser tous vos futurs imports en mode URN et de profiter des nouvelles fonctionnalités associées à ce mode. 

1. Descendre d’un niveau les schémas contenus dans votre base de données (import unitaire uniquement) de celle-ci:
   • Ouvrir le menu associé à votre objet racine (”Snowflake” ici) et choisir l’option “+ Créer un container”. Il sera de type “Modèle” et vous lui donnerez le nom de votre base de donnée telle qu’elle existe dans Snowflake
   • Une fois cela fait il vous faudra déplacer chacun de vos schémas (”BURST_BANK” ici) en ouvrant leurs menus associés et en choisissant l’option “Déplacer”. Vous ciblerez l’objet créé juste avant, “DEMO_DB” pour cet exemple
   • A partir de maintenant les manipulations seront les mêmes pour passer en mode URN, peu importe le mode d’import initialement choisi en mode Standard
   • Si vous ne réalisez pas cette opération, lors de l'import en mode URN final sur votre objet racine vous créerez des doublons de tous les schémas de votre base de donnée remontés depuis Snowflake
2. Si ce n'est pas encore le cas, associer aux sources “Database” du module "Dictionnaire" l'attribut "URN"
3. Associer à votre objet racine l'URN correspondant
   • A ce propos nous conseillons de suivre les étapes suivantes pour éviter toute erreur:
     • Réaliser un import en mode URN, lequel va créer un nouvel objet racine pour lequel l'attribut URN sera renseigné
     • Copier ledit attribut URN
     • Supprimer l'objet racine que vous venez d'importer en mode URN ainsi que tous ses enfants (vu qu'un URN doit être unique, si vous ne supprimez pas cet objet racine avant d'assigner son URN à un autre objet la plateforme retournera une erreur)
     • Coller l'URN pour renseigner l'attribut URN de votre objet racine qui est encore en mode Standard
4. Réaliser un nouvel import en mode URN
   • Cette fois-ci tous les attributs URN des enfants sous votre objet racine devraient être renseignés

Félicitations, vous avez migré du mode Standard au mode URN et êtes en mesure de profiter de toutes les nouvelles fonctionnalités offertes par celui-ci !

Fonctionnalités

Uniquement en mode URN

• Récupération du lineage

Mises en garde

Format du nom de compte

Snowflake prend en charge plusieurs formats pour les noms de compte. Lorsque vous utilisez différents formats pour le même compte Snowflake entre les connexions, DataGalaxy crée des objets source distincts pour chaque format au lieu de regrouper les objets. De plus, pour utiliser correctement la fonctionnalité du lineage cross-technology avec les imports URN, vous devez maintenir une cohérence en utilisant le même format de compte pour toutes les technologies. Un formatage incohérent entraînera des représentations en double des mêmes objets Snowflake dans DataGalaxy.

Exécution du connecteur

    Etape 1: Installation

• Télécharger le connecteur DataGalaxy depuis le portail
• Extraire l'archive du connecteur dans le répertoire de votre choix
• Télécharger le plug-in Snowflake depuis le portail et le copier dans le répertoire /lib du connecteur

   Etape 2: Exécution du connecteur

• Après avoir démarré le connecteur, accéder aux connecteurs du Dictionnaire

• S'il a été correctement installé, le plug-in Snowflake apparaît dans la liste

• Complétez les champs correspondants à l'aide des informations de connexion données ci-dessus

• Cliquez sur "Test" pour tester la connexion
• Une fois le test de connexion passé vous pouvez suivre les étapes pour finaliser votre import
  

Ce connecteur est également disponible en mode online, pour plus de précisions consulter cette page: 

[HowTo] Exécution du Connecteur Online.

Questions fréquentes

Les tables Iceberg sont-elles supportées par le connecteur ?

Oui, le connecteur a été validé avec des tables Iceberg gérées par le catalogue Snowflake. 

Releases