Un Data Catalog doit s’appuyer sur l’automatisation
Certains vendeurs de Data Catalogs, dont la culture vient plutôt du monde de la cartographie, développent une rhétorique selon laquelle l’automatisation est un sujet secondaire, qui peut être adressé dans un second temps.
Ils vous expliqueront qu’il suffit de quelques imports de fichiers manuels, d’un peu d’huile coude et d’une communauté d’utilisateurs collaborant sur leur outil pour alimenter et utiliser le catalogue.
Un peu d’arithmétique permet de bien comprendre pourquoi cette approche est vouée à l’échec dans une organisation data-centric.
Un data lake actif, même de taille modeste, contient rapidement, sur ses différentes couches, plusieurs centaines voire milliers de jeux de données. A ces jeux de données viennent s’ajouter ceux des autres systèmes (bases de données applicatives, API diverses, CRMs, ERPs, no-SQL, etc.) que l’on souhaite généralement intégrer dans le catalogue.
Les ordres de grandeur dépassent rapidement plusieurs milliers voire dizaines de milliers de jeux de données. Chaque jeu de données contient à son tour plusieurs dizaines de champs (ou colonnes, si vous préférez). Jeux de données et champs représentent donc à eux seuls plusieurs centaines de milliers d’objets (on pourrait également comptabiliser les autres actifs: modèles ML, tableaux de bord, rapports, etc.).
Pour que le catalogue soit utile, il ne suffit pas d’inventorier tous ces objets.
Il faut également leur associer toutes les propriétés (métadonnées) qui permettront aux utilisateurs finaux de trouver, comprendre et savoir exploiter ces actifs. Les métadonnées sont de plusieurs natures: informations techniques, classification métier, sémantique, sécurité, sensibilité, qualité, normes, usages, popularité, contacts, etc.
On parle donc là aussi, pour chaque actif, de plusieurs dizaines de propriétés. Faites le calcul: au final, il s’agit de millions d’attributs à définir, puis maintenir.
Une telle volumétrie à elle seule devrait disqualifier irrévocablement l’approche manuelle.
Mais ce n’est pas tout. Le stock d’actifs informationnels n’est pas statique. Il grossit en permanence. Dans une organisation data-centric, chaque jour, des jeux de données sont créés, d’autres sont modifiés ou déplacés.
Le catalogue doit refléter ces changements. A défaut, son contenu sera en permanence obsolète, et les utilisateurs finaux ne l’adopteront pas (qui ferait confiance à un catalogue dont le contenu est structurellement incomplet et faux?).
Si vous pensez que votre organisation est en mesure d’absorber la charge nécessaire pour maintenir le catalogue à jour, très bien. Sinon, nous vous invitons vivement à vérifier très tôt le niveau d’automatisation proposé par les différentes solutions que vous évaluez.
Que peut-on automatiser dans un Data Catalog?
En matière d’automatisation, la capacité la plus fondamentale, c’est l’inventaire. Un Data Catalog doit pouvoir scanner en permanence toutes vos sources de données, et mettre à jour automatiquement l’inventaire des actifs (jeux de données, structures et métadonnées techniques à minima) pour refléter la réalité opérationnelle des systèmes qui les hébergent.
Croyez-nous: un Data Catalog qui ne sait pas se connecter à vos sources de données deviendra vite inutile, car son contenu sera toujours douteux.
Une fois l’inventaire traité, la question suivante est de savoir comment automatiser l’alimentation du métamodèle. Sur ce plan, et au-delà des métadonnées techniques, une automatisation intégrale est difficilement imaginable.
Mais il reste possible de réduire de façon significative la charge de travail nécessaire à la maintenance du métamodèle.
La valeur de certaines propriétés (ou attributs) peut ainsi être déterminée en appliquant simplement des règles au moment de l’intégration des objets dans le catalogue (on sait par exemple que les jeux de données provenant de tel système appartiennent à telle classification métier, sont destinés à tel type d’usage, ou sont sous la responsabilité de tel individu).
Il est également possible de suggérer des valeurs de propriétés en utilisant des algorithmes plus ou moins sophistiqués (détection de types logiques, analyse sémantique, pattern matching sur le contenu du catalogue, etc.).
Enfin, il est souvent possible d’alimenter une partie du catalogue en s’intégrant aux systèmes produisant ou contenant de la métadonnées. Ce peut être le cas par exemple pour les mesures de qualité (qui peuvent être intégrées dans le catalogue au moment où elles sont réalisées), pour les informations de lineage (connues par votre pipeline ou votre ETL), pour votre ontologie métier (qui peut être gérée dans un autre logiciel spécialisé), etc. Pour que cette approche soit possible, le Data Catalog doit être ouvert, et proposer un jeu d’APIs complet permettant de mettre à jour les métadonnées depuis d’autres systèmes.
Take Away
Un Data Catalog recense des millions d’informations sur un patrimoine en mutation permanente.
Maintenir ces informations manuellement est virtuellement impossible, ou extrêmement coûteux. Sans automatisation au moins de l’inventaire, le contenu du catalogue sera en permanence douteux, et les équipes data ne l’adopteront pas.
Téléchargez notre eBook : Les 7 mensonges des fournisseurs de Data Catalog pour en savoir plus !
