Le rôle fondamental de l'architecture des données (dans un monde axé sur l'analyse)
Il y a un dicton dans l’armée : « Les amateurs discutent de tactique, mais les professionnels étudient la logistique. » Cette pensée peut surprendre certains à première vue, lorsqu’on pense au génie de Lee à Chancellorsville, ou au génie d’Hannibal pendant les guerres puniques ; cependant, l’histoire montre que ni Lee ni Hannibal n’ont remporté leurs guerres respectives. La principale raison était la logistique : la capacité à approvisionner une armée en nourriture, en vêtements et en armes, au bon moment et au bon endroit. Malgré une tactique brillante, c'est la logistique qui a finalement décidé de la victoire. En d’autres termes, la tactique vous permet d’utiliser au mieux les atouts dont vous disposez sur le terrain, mais la logistique vous permet avant tout d’être et de rester sur le terrain.
J’aime l’analogie militaire parce que je crois qu’elle présente des parallèles avec la façon dont les solutions basées sur les données sont souvent décrites aujourd’hui. Le glamour des « tactiques » (techniques d’IA avancées telles que l’apprentissage profond, la classification des forêts aléatoires, l’amplification de gradient, etc.) éclipse régulièrement la « logistique » moins sexy des fondements de l’architecture des données qui permettent ces techniques avancées.
La première étape d’une discussion sur l’architecture des données consiste à définir ce que recouvre le concept d’« architecture de données ». Sans surprise, la réponse s’avère nuancée : elle est complexe et comporte de multiples facettes. Pour aider à fonder la discussion, il est utile de commencer par y réfléchir en termes de parcours des données de télémétrie collectées. Le diagramme ci-dessous montre un pipeline de données de haut niveau, mettant en évidence les points de contact entre le pipeline et la base de l'architecture des données.
Le parcours de chaque élément de données commence par sa création, souvent suivie d’une certaine quantité de prétraitement avant d’être sérialisé et transmis à un collecteur/agrégateur de données, résidant généralement dans le cloud. Ensuite, le collecteur de données lui-même peut (après désérialisation et ingestion) effectuer un traitement et un enrichissement supplémentaires avant de livrer les données à un magasin de données persistant et/ou d’alimenter un pipeline d’analyse de données. Enfin, les résultats enrichis/analysés sont mis à disposition pour la consommation humaine à l'aide d'une plateforme de visualisation, et peuvent même être consommés par des systèmes automatisés sous forme d'entrées de rétroaction pour des systèmes en boucle fermée à réglage automatique ou à correction automatique.
Une fois le contexte du pipeline de données établi, nous pouvons maintenant revenir à la question de savoir ce que l’on entend par « architecture de données ». La première réponse, au niveau le plus superficiel, se concentre sur la représentation des données et la syntaxe de sérialisation. Par exemple, si un événement de données contient un champ d’objet intitulé « client », la vue syntaxique détermine si ces données sont représentées sous la forme d’une chaîne, d’un UUID entier ou d’autre chose.
Cependant, si nous creusons un peu plus profondément, une deuxième réponse concerne bien plus que la simple syntaxe ; il s’agit de la sémantique des données, c’est-à-dire d’avoir une interprétation bien définie et cohérente du contenu des données. Une fois de plus, en utilisant le champ « client » comme exemple, supposons que la question syntaxique a reçu une réponse, à savoir qu’en fait, l’élément de données a été défini comme étant un champ de chaîne. Ensuite, l’architecture des données doit être capable de répondre à la question de signification/interprétation : la sémantique est-elle celle du nom d’une personne individuelle ou d’une entreprise ? S’il s’agit du nom d’une personne, est-ce <nom> ou <prénom> ou les deux ? Combinée à une syntaxe uniforme, une sémantique cohérente permet au pipeline de données d'exécuter des fonctions telles que le filtrage et l'agrégation de données de manière générique et robuste, sur la base d'une interprétation logique cohérente du contenu des données. De plus, le magasin de données peut également effectuer facilement des requêtes de données fédérées sur différentes instances de pipeline de création de données, à condition que les données créées suivent une syntaxe et une sémantique cohérentes.
Enfin, il est souvent essentiel de disposer d’une troisième capacité dans l’architecture des données : un vocabulaire qui contextualise la télémétrie et permet de raisonner sur les données elles-mêmes—le vocabulaire des métadonnées. Cela prend tout son sens dans le cadre des exigences de gouvernance des données en entreprise, qu’il s’agisse de conformité, d’audits ou même de processus internes nécessitant une vue complète des données gérées dans un entrepôt de données. Les métadonnées se traduisent souvent par des annotations sur les données, lesquelles respectent la même cohérence syntaxique et sémantique que les données originales. Par exemple, vous utilisez probablement les champs de métadonnées pour enregistrer l’identité de la source, retracer le cycle de traitement des données collectées, et répondre aux obligations légales de conservation.
Une autre façon d’utiliser les champs de métadonnées dans le lexique d’un schéma de description de données est de raisonner sur les aspects des champs de données eux-mêmes, tels que l’ordinalité d’un élément de données ou les sensibilités de confidentialité. Pour revenir une fois de plus à notre exemple de champ de données « client », les annotations de métadonnées dans le schéma de données peuvent marquer l'élément de données comme unique , tandis que des annotations supplémentaires, dans le contexte d'un flux de données (comme pour les transactions d'achat au détail), peuvent marquer les éléments de données comme étant obligatoires et singleton. En d'autres termes, les métadonnées seraient utilisées pour dire que le champ customerID doit être unique (utilisable comme clé de base de données primaire) et que chaque événement d'achat doit avoir un, et exactement un, customerID associé. L’utilité de la totalité des fonctionnalités de métadonnées, dans le contexte du pipeline de données, réside dans le fait qu’elles peuvent être exploitées pour ajouter des annotations pour la conformité des données, fournir un lexique d’enrichissement des données et permettre des flux de travail de gouvernance flexibles pour l’entrepôt de données.
Donc, en résumé, la réponse à la question : « Qu’est-ce que l’architecture des données ? » signifie qu’il s’agit, au minimum, de fournir un cadre qui permette la cohérence, à la fois syntaxique et sémantique, des données collectées. De plus, une architecture de données robuste doit également englober une stratégie de métadonnées suffisamment puissante pour non seulement spécifier des contraintes sur les données, mais également inclure la capacité de raisonner sur les données elles-mêmes.
Lorsqu'on en fait un axe prioritaire et qu'on l'exécute correctement, une architecture de données ressemble beaucoup à une bonne infrastructure logistique militaire. Comme dans le domaine militaire, elle pose une base qui décuple l’efficacité et la solidité de tous les composants des systèmes qui en dépendent, permettant à ces systèmes plus visibles d’agir avec un maximum d’efficacité. Dans un système de traitement des données, cette base d’architecture offre des modèles de gouvernance des données plus flexibles et performants, facilite le partage entre sources via un entrepôt de données fiable, et assure une réactivité optimale lors de l’intégration de nouveaux flux, pour renforcer l’agilité de votre entreprise.