Qu’est-ce qu’un produit de données ?

Chaque application crée et stocke des données temporairement ou définitivement. 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é. Pour consommer et traiter les données produites par ces applications, les équipes de données centralisées utilisent des processus d’extraction, de transformation et de chargement (ETL). Les équipes d’opérations d’application ont souvent d’autres flux de traitement des données pour les données telles que les données d’intégrité des applications et les données de surveillance de l’état des indicateurs de performance clé.

Pour l’intégration des données, une approche en cascade traditionnelle, dans laquelle les équipes suivent un ordre spécifique de phases, 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. Les équipes d’application sont responsables des performances et de la réussite des applications. Lorsqu’ils utilisent une approche en cascade, ils apportent des modifications aux processus en aval que d’autres équipes possèdent. Parfois, ces changements peuvent affecter d’autres domaines. Par exemple, une modification mineure en amont peut considérablement modifier la tendance d’un indicateur de performance clé. Ces conflits peuvent affecter votre capacité à prendre des décisions critiques.

Données en tant que produit

Pour éviter ces problèmes, l’approche de maillage de données adopte 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 produit du processus d’une autre équipe. Les applications et les tâches de service des données analytiques se trouvent dans les domaines de responsabilité du domaine.

Les produits de données sont créés spécifiquement pour la consommation analytique. Ils ont défini et convenu des formes, 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 de domaine ou des jeux de données que vous pouvez partager avec des processus en aval via des interfaces dans un objectif de niveau de service. Sauf indication contraire, vous devez traiter, mettre en forme, nettoyer, agréger et normaliser vos données brutes pour répondre aux normes de qualité acceptées avant de les rendre disponibles pour une utilisation.

Les sections suivantes décrivent les caractéristiques courantes des bons produits de données.

Caractéristiques du produit de données

Vérifiez que vos produits de données sont les suivants :

• Détectable, compréhensible et digne de confiance. Pour fournir une détectabilité et une clarté, partager et mettre à jour des informations sur chaque produit de données, ses données, sa signification, le format de forme de ses données et son cycle d’actualisation. Communiquez les modifications de données ou les modifications de forme aux consommateurs en aval en temps opportun. Pour garantir la fiabilité, les interfaces fournissent une compatibilité descendante limitée dans le temps pour les formes de produit de données.

• Adressable, accessible en mode natif et sécurisé. Pour fournir une adresse, créez des processus définis pour localiser et accéder à chaque produit de données. Implémentez des mesures de sécurité pour différentes exigences d’accès. Adoptez une mentalité de propriété de domaine de données axée sur le service des données plutôt que sur leur protection, en prenant des précautions de sécurité bien définies. Les interfaces d’accès bien documentées peuvent varier entre 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, honnête et précieux. Pour fournir une interopérabilité, assurez-vous que vos données suivent des normes courantes définies, telles que les valeurs qui ont le même nom et le même type de données. Par exemple, vous pouvez nommer une colonne qui contient des données d’identification client CustomerID dans chaque produit de données, et ses données peuvent toujours être un entier. Les produits de données fournissent de la valeur aux clients et vous pouvez les utiliser comme sources en amont pour les nouveaux produits de données dans le même domaine ou dans différents domaines. Mais vous ne pouvez pas simplement transporter et copier le même produit de données dans plusieurs emplacements. 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 fournir des données honnêtes et précises.

Utilisez des produits de données bien conçus et bien gérés et leurs interfaces pour éviter de dupliquer des données et créer une source unique 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.

Pour créer les applications de données et produire ou servir des produits de données, équipez entièrement vos équipes d’applications de domaine. Vos équipes peuvent utiliser une pile technologique familière pour créer des produits de données. Ils peuvent également préférer avoir leur propre instance Spark ou le moteur de pipeline. Par exemple, un grand domaine qui sert de nombreux produits de données peut traiter et servir des produits de données à partir de leur propre instance Azure Synapse Analytics. Les petites organisations et les domaines plus petits des grandes organisations peuvent développer et exécuter leurs applications de données sur une plateforme partagée, comme une instance Azure Data Factory, Azure Synapse Analytics ou Azure Databricks.

Assurez-vous que vos produits de données ont les caractéristiques courantes décrites dans cet article, que votre référentiel de traçabilité reflète votre traçabilité d’application de données et que vous régissez votre implémentation et votre accès.

Le diagramme suivant montre un exemple de disposition logique d’application de données dans un domaine et une zone d’atterrissage.

Étape suivante

• considérations relatives à la conception pour les plateformes de données en libre-service