Le mode URN

Modifié le : Lun, 9 Mars, 2026 à 4:36 H

Les connecteurs proposent une option pour utiliser le mode URN à l'import des objets. Cet article décrit ce qu'est ce mode et quels sont ses avantages et limites. Une liste de questions/réponses courantes est proposée, s'il vous manque toujours des informations après la lecture de cet article n'hésitez pas à contacter le support afin que nous puissions améliorer cette page.

Cette documentation prend ses exemples sur l'usage de l'URN par les connecteurs, qui est le principal usage. Les connecteurs s'appuyant sur les API DataGalaxy, tout ce qui est décrit ici est applicable aux APIs URN qui peuvent être utilisées pour les développements spécifiques autour de la plateforme.

Qu'est-ce qu'un URN ?

Un URN, pour Uniform Resource Name, est une adresse permettant d'identifier de manière unique un objet d'un système data. Cette adresse est construite selon une syntaxe définie par DataGalaxy, mais qui est totalement indépendante de la plateforme DataGalaxy ou de la manière avec laquelle ces objets sont organisés et représentés dans DataGalaxy. Pour information, la syntaxe de l'URN pour chaque technologie est décrite ici.

Les éléments qui composent l'URN d'un objet (appelés "segments") proviennent uniquement du système data lui-même et sont connus par tout autre système data qui devrait interagir avec cet objet. Ceci permet donc à chacun de ces systèmes de construire l'URN de cet objet : l'URN devient donc une adresse unique d'un objet data quel que soit le système qui le manipule.

Par exemple, voici un URN d'une vue Snowflake :

urn:snowflake-1:xx12345.eu-central-1:SNOW_DB:CUSTOMER360:V_CUSTOMER@view

Les segments qui composent l'URN de cette vue sont :

xx12345.eu-central-1 : le nom du compte Snowflake
SNOW_DB : le nom de la base de données
CUSTOMER360 : le nom du schéma
V_CUSTOMER : le nom de la vue
@view : le type de l'objet dans Snowflake

Remarquons que l'URN d'un objet peut contenir l'URN d'un autre objet, lorsque ces deux objets sont liés par un lien de parenté dans le système data. Ainsi, l'URN de la vue contient l'URN du schéma :

urn:snowflake-1:xx12345.eu-central-1:SNOW_DB:CUSTOMER360

qui lui-même contient l'URN de la base de données :

urn:snowflake-1:xx12345.eu-central-1:SNOW_DB

qui lui-même contient l'URN du compte Snowflake :

urn:snowflake-1:xx12345.eu-central-1

Tout système qui souhaite interagir avec cette vue doit connaître l'ensemble de ces éléments (sauf peut-être le type de l'objet, mais qui n'est pas toujours nécessaire). Par exemple, pour construire un dataset Power BI qui charge les données de cette vue, il faudra configurer une connexion Snowflake dans Power BI et renseigner notamment le nom du compte, de la base de données, du schéma et de la vue. Une fois ce dataset Power BI créé, Power BI connaît tous les éléments de l'URN de la vue Snowflake (dans cet exemple précis, Power BI sait même que l'objet est une vue).

Imaginons un outil A qui discuterait avec Snowflake et un autre outil B connecté à Power BI : les deux seraient donc en mesure de créer l'URN de cette vue chacun de leur côté et de la reconnaître grâce à son adresse unique. Dans DataGalaxy, ces outils sont les connecteurs.

Les avantages du mode URN pour les connecteurs

Principe de fonctionnement

Historiquement, les connecteurs DataGalaxy étaient "silotés" : un connecteur pour une technologie ne remontait dans DataGalaxy que des objets de cette technologie. Avec le mode URN, les connecteurs peuvent désormais tirer partie de toutes les métadonnées contenues dans les systèmes data, y compris concernant des objets d'autres technologies avec lesquelles ces systèmes interagissent. Les connecteurs se complètent les uns les autres pour composer dans DataGalaxy une vue complète du paysage data et des interconnexions entre les objets, notamment le lineage.

Pour poursuivre l'exemple précédent, en ajoutant la plateforme d'observabilité Sifflet sur laquelle on aurait créé des moniteurs pour suivre la qualité des données Snowflake :

Le connecteur Power BI remonte le dataset, ainsi que la vue Snowflake V_CUSTOMER à partir de laquelle il charge ses données, reliant les deux objets par un lien de lineage,
Le connecteur Snowflake remonte les objets Snowflake, complétant la fiche objet de la vue V_CUSTOMER avec notamment sa description et créant tous les autres objets Snowflake que Power BI ne connaît pas,
Le connecteur Sifflet ne remonte aucun objet de technologie Sifflet, mais remonte les informations de qualité de données sur l'ensemble des objets Snowflake de la base SNOW_DB.

Nous avons donc trois connecteurs qui ont contribué à la construction de la fiche objet de la vue V_CUSTOMER.

Changements par rapport au mode Standard ("non-URN")

Dans le mode Standard, les connecteurs créent des objets en spécifiant leur chemin et chemin de types (path / typepath) dans la plateforme DataGalaxy. En plus de récupérer les informations dans le système source, les connecteurs en mode Standard ont donc les responsabilités suivantes :

Définir quel type d'objet du métamodèle DataGalaxy est utilisé pour représenter un objet d'un système data
Créer si besoin les technologies manquantes
Ranger les objets dans DataGalaxy.

C'est pour cela que pour une connexion en mode Standard, il est nécessaire de configurer un objet racine pour chaque module, dans lequel le connecteur rangera les objets importés du système data source. Comme seule cette connexion connaît ces objets racines, cela limite fortement les interactions entre les connecteurs. De plus, comme le connecteur range toujours les objets au même endroit, il est impossible de ranger autrement ces objets dans la plateforme.

Dans le mode URN, les connecteurs n'ont plus ces trois responsabilités. Ils ne font que lister les objets et métadonnées trouvés dans le système data source et ils les envoient à la plateforme sous la forme d'une liste d'URNs avec des attributs et des liens.

La plateforme DataGalaxy récupère donc les trois responsabilités précédentes, ce qui a plusieurs impacts :

Il n'est plus nécessaire de configurer des objets racines sur les connexions.
La plateforme range toujours les objets selon la même hiérarchie.
Un peu plus d'explications sur ce point :
En mode Standard, certaines configurations du connecteur pouvaient influer sur le rangement des objets dans la plateforme : par exemple le connecteur Snowflake en configuration "Import unitaire" crée la base de données à la racine du dictionnaire et les schémas comme enfants au niveau 1, alors qu'en configuration "Import plusieurs bases de données" les bases de données se retrouvaient au niveau 1 et les schémas au niveau 2.
En mode URN, quel que soit la configuration du connecteur, la hiérarchie est la même. Pour Snowflake par exemple, le compte Snowflake sera créé à la racine, les bases de données au niveau 1 et les schémas au niveau 2.
A l'import, la plateforme cherchera les objets existants grâce à leur URN uniquement, indépendamment de leur emplacement dans DataGalaxy. Il est donc possible déplacer les objets dans DataGalaxy sans impact sur les futures exécutions du connecteur. Ainsi, par rapport au point précédent, si l'organisation proposée automatiquement ne vous convient pas, vous aurez des options pour l'ajuster selon vos besoins.
Les connecteurs peuvent remonter des objets de multiples technologies.

Mode URN et organisation des objets dans la plateforme

Différences en matière de droit entre les modes URN et Bulktree

Pour effectuer un import en mode URN il est indispensable de disposer des droits Admin sur le workspace visé, même lorsque vous souhaitez simplement mettre à jour une source déjà existante.

En effet, en mode URN il est possible que le connecteur ait à créer une nouvelle source, issue d'une technologie externe liée par exemple, en plus d'avoir à mettre à jour votre source cible. C'est afin que le mode URN utilise 100% de ses capacités que nous imposons les droits Admin lors des imports.

Logique de rangement des objets dans la plateforme

Lorsque les connecteurs envoient une liste d'URNs dans la plateforme, celle-ci range automatiquement les objets suivant quelques règles :

Si l'objet est reconnu (un objet avec cet URN existe déjà dans la plateforme), alors il est mis à jour : ses attributs sont mis à jour et suivant les technologies, l'objet peut être également déplacé dans DataGalaxy si le connecteur sait détecter qu'il a été déplacé dans le système data (ce qui est une autre nouveauté).
Si l'objet n'est pas reconnu il doit être créé, alors la plateforme va chercher son parent le plus proche :
- Si un parent est trouvé dans la plateforme, alors l'objet sera rattaché dessous (avec éventuellement les parents intermédiaires à créer)
- Sinon, l'objet (éventuellement ses parents intermédiaires) sera créé à la racine du module concerné.

Comment réorganiser les objets importés

Un des avantages du mode URN des connecteurs est la capacité de déplacer les objets dans la plateforme sans que cela n'impacte l'exécution des connecteurs concernés. Cela apporte de la flexibilité pour organiser les objets. Cela peut être très utile notamment dans le module Dictionnaire, dans lequel les permissions des utilisateurs DataGalaxy sont gérés au niveau de chaque objet racine.

Prenons quelques exemples.

Répartir des enfants sous plusieurs parents

Il est possible de répartir plusieurs enfants d'une même racine dans plusieurs racines différentes. Il suffit de créer d'autres objets racines et d'y déplacer les enfants que l'on souhaite y ranger. Si un nouvel enfant est créé, il sera toujours automatiquement créé sous la racine initiale, il restera possible de le déplacer ensuite.

Par exemple, si vous exécutez le connecteur Snowflake en configuration "Plusieurs bases de données", celles-ci seront créées dans le Dictionnaire sous un objet racine commun qui représente le compte Snowflake et porte son URN.

Si vous avez besoin de répartir ces bases de données dans plusieurs objets racines, par exemple pour donner des permissions différentes à vos utilisateurs, vous pouvez créer d'autres objets racines et déplacer chaque base de donnée Snowflake sous l'objet racine qui vous convient.

Regrouper des enfants sous un parent commun

Pour ce cas d'usage, le fonctionnement est le même mais les objets vont en plus descendre d'un niveau dans la hiérarchie des objets.

Dans les modules Usages et Traitements, les objets racines créés par les connecteurs seront respectivement App et DataFlow. Dans le métamodèle DataGalaxy, des objets de ces types peuvent être imbriqués dans d'autres objets du même type, ce qui rend facile la création d'une hiérarchie d'objets spécifique. Lorsqu'une grappe d'objets a été créée par un connecteur avec un objet à la racine d'un de ces modules, il est possible de déplacer toute la grappe d'objets ailleurs dans le module sans que cela n'impacte le connecteur. Pour le module Dictionnaire c'est également possible mais il y a quelques limitations à connaître, voir plus bas.

Par exemple après avoir lancé le connecteur Databricks avec la création des Notebooks et Workflows, on obtient dans le module Traitements une grappe d'objet avec l'instance Databricks à la racine. Si nous avons plusieurs environnements Databricks, ils seront tous à la racine du module Traitements.

Si l'on souhaite regrouper ces objets dans un objet racine commun, il suffit de créer cet objet (type DataFlow) et de bouger chaque instance Databricks sous cet objet. Les connecteurs en mode URN continueront à mettre à jour chaque grappe d'objets.

Remonter des enfants à la racine

A l'inverse, il est également possible de remonter à la racine des objets qui sont par défaut créés sous un objet racine commun. Il y a également les mêmes limitations pour le module Dictionnaire, qui sont décrites ci-dessous. Pour les autres modules, il suffit de déplacer les objets enfants à la racine du module, puis de supprimer l'objet racine vide une fois tous les enfants remontés. Encore une fois, si un nouvel objet est importé et qu'il ne trouve pas son parent dans les objets existants, la racine initiale sera recréée et l'objet sera rangé dessous, il faudra donc manuellement déplacer cette nouvelle grappe à la racine si tel est l'organisation souhaitée.

Reprenons Power BI en exemple : par défaut le connecteur crée la plateforme Power BI à la racine du module Usages et les Workspaces Power BI comme enfants. Les deux objets sont de type App. Si l'on souhaite représenter les Workspaces Power BI à la racine du module Usages, on peut tous les déplacer à la racine puis supprimer l'objet racine initial devenu vide. Si un nouveau Workspace Power BI apparaît ultérieurement, la racine sera recréée et il faudra refaire la manipulation pour ce nouvel objet.

Le cas particulier du module Dictionnaire

Dans le Dictionnaire, la particularité est qu'il n'y a aujourd'hui pas de type d'objet racine permettant que les objets soient facilement imbriqués les uns dans les autres, comme le sont les objets DataFlow du module Traitements et App du module Usages. C'est une limitation connue de notre métamodèle et vous êtes nombreux à nous demander plus de flexibilité à ce niveau, sachez que nous y travaillons.

En attendant que cela évolue, il est toujours possible d'organiser les objets et de les déplacer dans la hiérarchie, mais cela demande plus de manipulations. Le principal problème se situe lorsque l'on souhaite changer le niveau hiérarchique auquel les objets sont représentés, car cela nécessite de changer le type d'objets et cela n'est pas permis par l'opération de déplacement. Pour ce faire, il faudra manuellement, ou à l'aide d'export/import csv, recréer les premiers niveaux de hiérarchie souhaités en plaçant les URNs des objets correspondants au bon endroit, afin que les connecteurs puissent s'y raccrocher.

Prenons l'exemple de Google BigQuery. Contrairement à la plupart des plateformes dont nous avons parlé dans nos exemples, BigQuery est un service SaaS qui ne fournit pas d'identifiant pertinent pour un objet racine, comme c'est le cas pour une instance Databricks ou un compte Snowflake. Les objets de plus haut niveau de la hiérarchie BigQuery qui portent des identifiants sont les Projets. Au moment de la rédaction de cet article, les Projets BigQuery sont donc créés par le connecteur en mode URN à la racine du module Dictionnaire.

Si l'on souhaite regrouper les Projets BigQuery du Dictionnaire sous une racine commune, voici comment procéder :

Créer le nouvel objet racine tel que souhaité, de type Source NoSql (comme les autres sources BigQuery) et de technologie Google BigQuery
Sous cet objet racine, créer les Projets, de type Répertoire. Cela peut être fait manuellement ou par export/import csv avec manipulation du fichier pour refléter le changement de hiérarchie et de type. Veillez à ce que chaque Projet ait bien son URN tel qu'importé par le connecteur
Une fois la nouvelle hiérarchie créée, les anciens objets Projets à la racine du module peuvent être supprimés
Le connecteur pourra continuer à mettre à jour le contenu de chaque Projet grâce à leur URN
Dans le cas où un nouveau Projet est remonté par le connecteur, il sera nécessaire de refaire la manipulation pour ce Projet.

Nous sommes conscients que ces limitations et opérations manuelles ne sont pas idéales. C'est pourquoi nous travaillons sur l'évolution du métamodèle du Dictionnaire et c'est aussi la raison pour laquelle pour l'instant le mode URN reste optionnel, car même si il peut apporter de nombreux avantages, pour certains cas la solution doit être améliorée. Si vous êtes impactés par ces limitations, n'hésitez pas à en parler à votre Account Manager qui pourra en parler à l'équipe Produit.

Questions/réponses courantes

Est-ce que le mode URN signifie un lineage complètement automatisé ?

C'est un peu plus complexe que cela. L'URN est une convention pour associer une adresse unique à un objet d'un système data : c'est une convention. Grâce à cette convention, les connecteurs peuvent reconnaître les objets dans de multiples systèmes, cela facilite donc grandement l'automatisation du lineage. Mais l'URN ne crée pas de lineage par lui-même, il n'y a pas de magie : les connecteurs doivent toujours interpréter les métadonnées des différents systèmes, reconnaître les objets et créer les liens entre eux pour créer le lineage. Maintenant que les connecteurs peuvent tirer partie de cet outil, nous allons continuer à améliorer les connecteurs et pousser toujours plus loin l'automatisation du lineage dans DataGalaxy.

Comment migrer du mode Standard au mode URN ?

Selon les connecteurs, la migration peut nécessiter des changements dans l'organisation des objets dans la plateforme. Si vous avez déjà des objets dans DataGalaxy importés par le mode Standard des connecteurs, notre conseil est de commencer par prendre connaissance de la documentation du connecteur correspondant puis de tester le mode URN sur un workspace de tests.

Pour quels connecteurs le mode URN est-il disponible ?

La disponibilité du mode URN est précisée sur la page de documentation des connecteurs qui le supportent. A la date de la rédaction de cet article, 6 connecteurs supportent ce mode :

Le mode URN est-il compatible avec l'export/import CSV ?

L'URN est un attribut comme les autres et peut être importé ou exporté depuis la plateforme en CSV. Par contre, il n'est pas possible d'utiliser l'URN comme identifiant pour mettre à jour des objets en CSV, l'identifiant utilisé en mode CSV reste le path/typepath. C'est pourquoi le mode CSV du connecteur Desktop est désactivé en mode URN, car il générerait un fichier que vous ne pourriez pas importer dans la plateforme.

Y a-t-il des limitations dans l'usage du mode URN ?

Quelques fonctionnalités des connecteurs ne sont pas encore supportées dans ce mode. Voici la liste des limitations connues :

Dans Snowflake, la synchronisation des tags n'est pas encore implémentée en mode URN. L'implémentation est en cours et sera bientôt disponible.

Est-il normal que les connecteurs en mode URN prennent plus de temps qu'en mode Standard ?

Oui, les nouvelles responsabilités de la plateforme décrites dans cet article prennent du temps : rechercher si un objet existe déjà avec son URN, ranger les nouveaux objets à créer en recherchant le premier parent etc. Ceci impacte le temps d'exécution des connecteurs.

Comment activer le mode URN lorsque l'on utilise le CLI pour lancer le connecteur Desktop ?

Le mode d'import fait partie des paramètres stockés dans le fichier .properties de la connexion. Si vous configurez votre profil en mode graphique et le sauvegardez, vous pourrez automatiquement avoir le mode URN activé. Si vous souhaitez éditer manuellement le fichier .properties, le paramètre est data-structure, qui doit passer de la valeur TREE (mode par défaut) à URN pour activer le mode URN.

French