Qu’est-ce qu’un produit de données ?
Chaque application crée et stocke des données de façon temporaire ou permanente. De nombreuses applications créent et enregistrent également des données à des fins de gestion opérationnelle, telles que la journalisation des erreurs et la surveillance de l’intégrité. Les équipes de données centralisées utilisent des processus ETL pour consommer et traiter les données produites par ces applications. Les équipes d’opérations d’application ont souvent des flux de traitement de données supplémentaires pour des éléments tels que l’intégrité de l’application et la surveillance de l’état de l’indicateur de performance clé.
L’approche traditionnelle d’une cascade d’équipes et de responsabilités dans votre intégration de données n’est pas idéale. Cela peut entraîner des lacunes de connaissances, des problèmes de propriété et des conflits de communication qui affectent la qualité, la chronologie et la valeur de vos données pour les utilisateurs finaux. Les équipes d’application sont responsables des performances et de la réussite des applications. Dans leur travail, elles doivent apporter des modifications aux processus en aval appartenant à d’autres équipes, mais ces modifications ne se déroulent pas souvent comme prévu. Par exemple, vous pouvez constater qu’un changement mineur en amont modifie considérablement la tendance d’un indicateur de performance clé. Ces types de problèmes de données peuvent affecter votre capacité à prendre des décisions critiques.
L’approche de maillage de données empêche ces problèmes en adoptant le concept de données en tant que produit. Les propriétaires d’applications et les équipes d’applications traitent les données comme un produit entièrement autonome dont ils sont responsables, plutôt qu’un sous-produit de certains processus que d’autres gèrent. Les applications et les tâches de service de données analytiques se trouvent dans des zones de responsabilité de domaine.
Les produits de données sont créés spécifiquement pour la consommation analytique. Ils ont des formes définies et convenues, des interfaces de consommation et des cycles de maintenance et d’actualisation, qui sont tous documentés.
Les produits de données sont des ressources de données/jeux de données de domaine traité partagés avec des processus en aval via des interfaces dans un SLO. Sauf indication contraire, vos données brutes doivent être traitées, mises en forme, nettoyées, agrégées et normalisées pour répondre aux normes de qualité convenues avant de les rendre disponibles pour la consommation.
Les sections suivantes décrivent les caractéristiques courantes dont disposent les bons produits de données.
Caractéristiques des produits de données
Un produit de données bien conçu est :
Détectable, compréhensible et digne de confiance : les équipes de domaine fournissent une détectabilité et une compréhension en partageant et en mettant à jour des informations sur chaque produit de données, ses données, sa signification, le format de la forme de ses données et son cycle d’actualisation. Elles communiquent les modifications de données ou de formes aux consommateurs en aval en temps voulu. Les interfaces garantissent la fiabilité en fournissant une compatibilité descendante limitée dans le temps pour les formes de produit de données.
Adressable, accessible en mode natif et sécurisé : les processus définis pour localiser et accéder à chaque produit de données fournissent une adressabilité. Des mesures de sécurité nécessaires pour différentes exigences d’accès sont en place. La mentalité de propriété du domaine de données passe des données de contrôle aux données de service avec des précautions de sécurité bien définies. Les interfaces d’accès proposées sont bien documentées et peuvent varier en différentes technologies. Les interfaces couramment utilisées pour les produits de données accessibles en mode natif incluent des API, des utilisateurs de base de données, des tables ou des vues et des fichiers avec les droits d’accès nécessaires.
Interopérable, fiable et utile : les données fournissent une interopérabilité en suivant les normes communes définies, telles que les mêmes valeurs ayant toujours le même nom et le même type de données. Par exemple, une colonne contenant des données d’identification client peut être intitulée CustomerID dans chaque produit de données, et ses données peuvent toujours être un entier, ou utiliser snake_case ou camelCase dans chaque instance. Les produits de données fournissent de la valeur aux clients, et ils peuvent également être utilisés comme sources en amont pour les nouveaux produits de données dans les mêmes domaines ou des domaines différents. Toutefois, vous ne pouvez pas simplement transporter et copier le même produit de données à plusieurs endroits. Chaque produit de données provenant d’un produit de données précédent doit fournir de nouvelles valeurs et informations aux consommateurs en aval. Les produits de données doivent également toujours fournir des données fiables et non erronées.
Les produits de données bien conçus et bien gérés et leurs interfaces aident les organisations à éviter de dupliquer des données et peuvent aider à créer une seule source native de vérité.
Recommandations en matière de conception de produits de données
Pour répondre aux exigences de service des produits de données, vos équipes de domaine doivent acquérir un nouvel ensemble de compétences et utiliser de nouveaux outils et plateformes.
Équipez entièrement vos équipes d’applications de domaine pour créer les applications de données et produire ou servir des produits de données. Vos équipes peuvent créer des produits de données à l’aide d’une pile technologique familière. Elles peuvent également préférer disposer de leur propre instance Spark ou moteur de pipeline si possible. Par exemple, un grand domaine qui sert de nombreux produits de données peut décider de traiter et de servir des produits de données à partir de son propre service Azure Synapse Analytics. Les petites organisations et les petits domaines des grandes entreprises peuvent décider de développer et d’exécuter leurs applications de données sur une plateforme partagée, comme un service Azure Data Factory, Azure Synapse Analytics ou Azure Databricks centralisé.
Assurez-vous que vos produits de données possèdent les caractéristiques courantes décrites dans cet article, que votre référentiel de traçabilité reflète la traçabilité de votre application de données, et que votre implémentation et vos accès sont régis.
Aide concernant les applications de données et les produits de données pour Azure
Vous pouvez positionner toutes les approches possibles pour votre environnement d’application de données dans les zones d’atterrissage de données Azure si vos équipes d’applications de domaine utilisent une plateforme partagée et un ensemble de services.
Vous trouverez trois modèles de modèle d’application de données différents pour les zones d’atterrissage de données Azure dans les Produits de données d’analyse à l’échelle du cloud dans Azure : exemples d’applications de données.