Définitions
Pour éviter des incompréhensions, nous partageons quelques définitions des termes employés dans cette page.
Asset
Un asset de données est n'importe quel objet numérique ou entité construit à partir de données. Cela peut être un jeu de données (dataset), un document, une représentation graphique ou un service data et peut inclure les outils conçus pour rendre ces données disponibles et utilisables. Par exemple, un tableau de bord qui affiche les données d'un site web en temps réel est un asset.
Système data
Une platforme d'une technologie ayant pour but de stocker, transformer ou observer des assets de données. Ce sont les systèmes auxquels les connecteurs se connectent pour échanger des informations, notamment pour cartographier dans DataGalaxy les assets qu'ils contiennent, ou encore pour des scénarios d'intégrations plus avancés. Par exemple : Databricks, Power BI, dbt, Bigeye …
Parfois appelé "Data platform" ou "Système source".Objet
Un objet DataGalaxy, avec son type (dépendant du module), ses attributs et son emplacement dans la hiérarchie ("path"). Certains objets ont pour but de représenter un asset d'un système data (comme un rapport Power BI) et seront probablement créés par un connecteur, d'autres ajoutent de l'information (comme les objets du Glossaire) ou un niveau d'abstraction lié à la gouvernance (comme les Data Products) et seront probablement gérés manuellement.
Egalement appelé "Entité".Objet Orphelin
Un objet dans DataGalaxy qui avait été précédemment créé pour représenter un asset d'un système data, mais qui est devenu "orphelin" car cet asset n'existe plus.
Pourquoi avons-nous construit cette fonctionnalité ?
Lorsqu'il s'agit de cartographier leurs systèmes data et leurs assets dans DataGalaxy, les utilisateurs recherchent le plus d'automatisation possible et dans le même temps, le plus haut niveau de fidélité et de fraîcheur. Comme ces systèmes data sont dynamiques, de nouveaux assets sont créés constamment, certains sont modifiés, d'autres supprimés.
Ces changements devraient être correctement reportés dans DataGalaxy, afin que les utilisateurs bénéficient d'une représentation à jour de tous les assets, en laquelle ils peuvent se fier.
Qu'est-ce que la gestion des objets orphelins ?
Les connecteurs prennent une photo du système source à chaque exécution, généralement de manière planifiée. Comme le système source a continué d'évoluer depuis l'exécution précédente, le connecteur peut faire face à trois situations :
- Un nouvel asset est découvert, qui n'était pas connu dans DataGalaxy → le connecteur devra créer un nouvel objet pour représenter cet asset
- Un asset est reconnu comme existant dans DataGalaxy → le connecteur devra mettre à jour l'objet correspondant
- Un asset qui est représenté par un objet dans DataGalaxy n'existe plus dans le système source → une décision doit être prise au sujet de cet objet, qui est devenu "orphelin" = il ne représente plus aucun asset du système source.
L'objectif de la fonctionnalité de gestion des objets orphelins est d'identifier ces objets et de proposer à l'utilisateur des actions qui seront effectuées sur ceux-ci. Il y a deux raisons principales pour lesquelles il est préférable que le connecteur demande l'action à effectuer à l'utilisateur plutôt que de simplement supprimer les objets :
- Le connecteur pourrait se tromper au sujet de ces assets : dans la plupart des systèmes data, renommer un asset sera interprété par le connecteur comme un nouvel asset avec le nouveau nom et un asset supprimé avec l'ancien nom. Comme de nombreux enrichissements peuvent avoir été manuellement ajoutés aux objets correspondants dans DataGalaxy, l'utilisateur pourrait préférer renommer l'objet en question plutôt que de le voir supprimé avec tous ses enrichissements.
- Même si un asset a été supprimé, l'utilisateur pourrait préférer que l'objet soit toujours présent dans DataGalaxy avec l'information que cet objet est Obsolète, plutôt qu'il disparaisse complètement de DataGalaxy.
C'est pourquoi l'utilisateur a la possibilité de configurer trois comportements pour la gestion des objets orphelins :
- Ne rien faire : les objets resteront dans DataGalaxy sans aucune modification.
- Changer le statut à Obsolète : seulement le statut des objets sera modifié, rendant plus facile leur identification (grâce à une vue filtrée par exemple) et laissant la possibilité d'appliquer à ces objets d'autres actions manuelles si besoin.
- Supprimer : si vous êtes sûr que vous n'allez perdre aucun enrichissement et que vous souhaitez garantir une synchronisation la plus automatique entre votre système data et DataGalaxy, vous pouvez choisir cette option.
Comment cela fonctionne précisément ?
Voici une description détaillée du comportement de la fonctionnalité.
Lorsqu'un connecteur s'exécute, un GUID est généré pour cette exécution. Ce GUID est associé à tous les objets créés ou modifiés par le connecteur pendant cette exécution, grâce à l'attribut importGUID. Ensuite, deux conditions doivent être remplies pour identifier quels objets dans DataGalaxy sont considérés comme orphelins après cette exécution :
- Les objets doivent être dans le périmètre de la connexion courante
- L'importGUID des objets doit être différent de celui de l'exécution courante, ce qui signifie qu'ils ne viennent pas d'être créés ou mis à jour lors de cette exécution.
Après avoir importé des objets dans la plateforme, le connecteur envoie une commande à la plateforme pour que soit appliquée l'actions choisie par l'utilisateur sur les objets orphelins, fournissant le périmètre de la connexion courante ainsi que l'importGUID : c'est le process "reconcile".
Comparer les importGUIDs est simple. Pour définir si un objet appartient au périmètre de la connexion courante, deux versions de cette fonctionnalités ont été implémentées. La première est implémentée dans le mode standard des connecteurs (qui reste le mode le plus utilisé) mais comporte certaines limitations connues. Une nouvelle approche a été implémentée pour le nouveau mode URN des connecteurs, mais ce mode n'est pas encore disponible pour tous les connecteurs à ce jour.
Périmètre des connexions en mode standard et limitations
Dans le mode standard, les connecteurs s'appuient sur des objets racines qui sont définis par l'utilisateur pour chaque module dans lequel le connecteur doit créer des objets. La première implémentation du périmètre d'une connexion est très simple : tous les objets appartenant à la hiérarchie sous l'un de ces objets racines liés à la connexion est considéré comme faisant partie de son périmètre.
Cela génère quelques limitations qu'il est important d'avoir en tête pour éviter des comportements inattendus et d'éventuelles pertes de données (notamment si l'action choisie pour la gestion des objets orphelins est de les supprimer).
⚠️ Si plus d'une connexion utilise les mêmes objets orphelins, elles entreront en conflit. Tous les objets de la connexion A qui ne sont pas importés par la connexion B seront considérés orphelins par la connexion B (et vice-versa) étant donné qu'ils auront un importGUID différent et le même périmètre (= le même objet racine comme parent).
⚠️ Le même comportement se produit en exécutant un connecteur après avoir changé son filtre vers une configuration plus restrictive : tous les objets précédemment importés mais qui ne font plus partie du nouveau filtre seront considérés comme orphelins. Même comportement également si le compte de service utilisé par le connecteur pour se connecter au système source a subi des restrictions dans ses permissions et voit moins d'objets qu'avant.
Approche plus précise du périmètre en mode URN
En mode URN, il n'y a plus d'objets racines configuré par l'utilisateur. Les objets peuvent être importés partout dans la plateforme et un même connecteur peut créer des objets de multiples technologies. Nous avons donc dû implémenter une approche plus précise du périmètre et en avons profité pour résoudre les problèmes de la première version.
En mode URN, chaque connexion prend en compte tous ces paramètres pour définir son périmètre :
- Le connecteur lui-même sait quels objets et attributs il peut manipuler dans la plateforme et ceux qu'il ne peut pas : le connecteur Snowflake sait qu'il ne peut pas considérer un objet Azure SQL comme faisant partie de son périmètre.
- Les filtres configurés par l'utilisateur pour cette connexion : une connexion Snowflake filtrée sur la base de données MY_DB sait qu'elle ne peut pas considérer un objet Snowflake d'une autre base de données comme faisant partie de son périmètre.
Note : des questions restent ouvertes concernant le périmètre, notamment depuis que nous avons implémenté la possibilité des connecteurs de créer des objets d'autres technologies. Par exemple: le connecteur Power BI peut créer une Table Snowflake parce qu'il découvre qu'un Dataset Power BI charge ses données à partir de cette Table dans Snowflake. Imaginons que lors d'une exécution future du connecteur, celui-ci ne trouve plus cette Table : cela signifie juste qu'il n'y a plus de Dataset chargeant ses données depuis cette Table, cela ne signifie pas que cette Table n'existe plus. La décision de considérer ou non l'objet correspondant comme orphelin (et donc de changer son statut à Obsolète ou de la supprimer) peut dépendre des cas d'usages. Nous travaillons toujours sur ce sujet pour donner le contrôle à l'utilisateur. Aujourd'hui, ces objets ne font pas partie du périmètre du connecteur Power BI donc aucune action des objets orphelins ne leur sera appliquée.