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, en creusant encore plus profondément, dans de nombreux cas, il est important d’avoir une troisième capacité dans l’architecture des données : un vocabulaire pour contextualiser la télémétrie et raisonner sur les données elles-mêmes : le vocabulaire des métadonnées. Cela est particulièrement important dans le contexte des exigences de gouvernance des données d’entreprise, que ce soit pour la conformité, l’audit ou même pour les flux de travail internes qui nécessitent une compréhension holistique des données gérées dans un entrepôt de données. Les métadonnées se présentent souvent sous la forme d’annotations sur les données, les annotations suivant le même type de cohérence syntaxique et sémantique que les données elles-mêmes. Par exemple, les champs de métadonnées seraient probablement utilisés pour enregistrer l’identité de la source des données, la chronologie du traitement des données collectées, afin de se conformer aux exigences légales de conservation des données.
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’elle est considérée comme un domaine d’intérêt explicite et bien exécutée, une architecture de données ressemble donc beaucoup à une bonne infrastructure logistique militaire. Tout comme dans le contexte militaire, il fournit une base qui multiplie l’efficacité et la robustesse de tous les composants des systèmes qui reposent sur lui, permettant ainsi aux systèmes les plus visibles d’être exploités de manière optimale. Dans le contexte d'un système de traitement de données, la fondation de l'architecture des données fournit la base de modèles plus flexibles et plus puissants pour la gouvernance des données, un partage de données plus facile entre les sources de données à l'aide d'un entrepôt de données robuste et une approche plus réactive pour l'ingestion de nouveaux flux de données pour l'agilité de l'entreprise.