Un Data Catalog n’est pas une solution de DQM (Data Quality Management)
Soyons une nouvelle fois clairs: chez Zeenea, nous ne sous-estimons pas l’importance de la qualité des données pour le succès des projets data, bien au contraire. Il est juste absurde de confier ce sujet à une solution qui, par nature, ne sera pas en mesure de réaliser les contrôles au bon moment.
Il existe une règle élémentaire en matière de contrôle qualité, une règle que l’on peut appliquer virtuellement dans tous les domaines où la qualité est un enjeu, que ce soit une chaîne de production industrielle, une organisation de développement logiciel ou la cuisine d’un grand restaurant: plus un défaut est détecté tôt, moins il est coûteux à corriger.
On imagine mal un constructeur automobile se contenter d’une batterie de tests une fois le véhicule achevé, quand tout le coût de production a été engagé, quand l’occurrence d’un défaut a le prix le plus élevé. Non. Chaque pièce fait l’objet de contrôles poussés, chaque étape de la production est testée, les pièces défectueuses sont écartées avant même d’être intégrées dans le circuit de production, et la chaîne complète peut être stoppée si des problèmes de qualité sont détectés à l’une quelconque de ses étapes. Quant aux problèmes de qualité à proprement parler, ils sont corrigés le plus en amont possible du processus de production – car c’est aussi en amont que les corrections sont les moins coûteuses et les plus durables.
« Dans une organisation data moderne, la production de données repose sur les mêmes principes. Il s’agit d’une chaîne d’assemblage destinée à alimenter des usages à haute valeur ajoutée. Le contrôle de la qualité doit être fait à chacune des étapes, et les corrections réalisées le plus en amont possible. La nature et le niveau des contrôles sont au demeurant très dépendants des usages (ou, pour être précis, du coût de la non qualité, qui est lui dépendant des usages). »
Si vous traitez de la donnée, vous disposez nécessairement de pipelines destinés à alimenter vos usages. Ces pipelines comprennent potentiellement des dizaines d’étapes – acquisition des données, nettoyage, transformations diverses, combinaison avec d’autres sources, etc. Pour développer ces pipelines, vous utilisez probablement une batterie de technologies, allant de scripts maisons à de coûteux ETL, en passant par d’autres middlewares plus 10 ou moins exotiques.
C’est dans ces pipelines que vous devez insérer et piloter vos mesures qualité, le plus tôt possible, en les adaptant aux enjeux du produit fini. Mesurer uniquement le niveau de qualité des données finales est non seulement absurde, c’est également fondamentalement inefficace.
Partant de ce constat, il est difficile de déterminer comment un Data Catalog (dont le rôle est d’inventorier et documenter tous les jeux de données potentiellement exploitables afin d’en faciliter la découverte et la consommation) pourrait se révéler un outil efficace de mesure et de pilotage de la qualité.
Un Data Catalog travaille sur le stock (les jeux de données disponibles), vise l’exhaustivité (tous les systèmes contenant des données) et devrait être aussi peu intrusif que possible afin de se déployer rapidement dans toute l’organisation.
Une solution de DQM travaille sur les flux (les pipelines), se focalise sur les données de production (celles effectivement utilisées dans des usages) et est par construction intrusive et longue à déployer. Et je ne vois pas d’architecture logicielle permettant de combiner efficacement les deux problématiques sans dégrader radicalement l’une ou l’autre de ses promesses.
Les vendeurs de Data Catalogs qui promettent de résoudre au passage vos problèmes de qualité sont à notre sens dans une impasse – il est peu probable qu’ils aillent au-delà d’une démo alléchante. Quant aux vendeurs de DQM (qui vendent également souvent des ETLs), leurs solutions sont trop complexes et coûteuses à déployer pour se transformer en catalogues crédibles.
La bonne nouvelle, c’est que l’orthogonalité entre les problématiques de catalogage et celles de contrôle qualité permet de faire cohabiter facilement des solutions spécialisées dans chaque domaine, sans chevauchement de responsabilités.
En effet, si un Data Catalog n’a pas vocation à réaliser les contrôles qualité, il peut en revanche exploiter avec beaucoup de bénéfices les informations sur la qualité des jeux de données qu’il contient.
Le Data Catalog exploite cette métadonnée en premier lieu pour diffuser l’information (et les éventuelles alertes qui l’accompagnent) auprès de consommateurs avérés ou potentiels de ces jeux de données; il peut également tirer bénéfice de ces informations pour ajuster son moteur de recherche et de recommandation et orienter les utilisateurs vers les jeux de données les plus qualitatifs.
Et il suffit de quelques APIs pour intégrer à peu de frais les deux solutions…
Take Away
La qualité des données s’évalue le plus tôt possible dans les pipelines d’alimentation de vos usages.
Le rôle d’un Data Catalog n’est pas de réaliser les contrôles qualité, juste de diffuser le plus largement possible le résultat de ces contrôles. Par nature, un Data Catalog est une mauvaise solution de DQM, et les solutions de DQM sont des Data Catalog médiocres ou trop complexes. L’intégration entre une solution de DQM (ou un système ad hoc) et un Data Catalog devrait être très simple, et constitue l’approche la plus pragmatique.
Téléchargez notre eBook : Les 7 mensonges des fournisseurs de Data Catalog pour en savoir plus !
