Contrats de données
Les responsabilités étant distribuées entre les domaines d’une architecture fédérée, il peut être difficile de superviser les dépendances et d’obtenir des insights sur l’utilisation des données. Les contrats de données peuvent vous aider à obtenir des insights sur l’utilisation des données, car ils fournissent des informations sur les propriétaires de chaque produit de données. Les contrats de données vous aident à définir des normes et à gérer en toute confiance vos pipelines de données. Essentiels dans le cadre d’une gestion robuste des données, ils fournissent des informations sur :
les produits de données consommés ;
les utilisateurs et les produits de données qu’ils consomment ;
le ou les objectifs incitant les utilisateurs à utiliser des produits de données spécifiques.
La distribution et l’utilisation des produits de données comportent deux volets : un volet technique et un volet commercial. Le volet technique comprend la gestion des pipelines de données et les attentes mutuelles en matière de stabilité des données. Le volet commercial comprend les contrats d’objectif de partage de données, qui définissent les objectifs d’utilisation, de confidentialité et de finalité, y compris d’éventuelles limitations.
Les deux volets font appel à des rôles différents. En général, vous vous référez aux propriétaires d’applications ou aux ingénieurs de données pour le volet technique, et aux propriétaires de produits ou aux représentants commerciaux pour le volet commercial.
Contrats de données
Les contrats de données sont similaires aux contrats de service ou aux contrats de livraison de données.
Dans une architecture plus grande ou distribuée, il peut être difficile de superviser les changements. Pour simplifier la supervision, vous pouvez implémenter la gestion de versions et gérer la compatibilité chaque fois que vous avez un produit de données populaire et largement utilisé.
Si les applications sont couplées, cela indique qu’il existe un degré élevé d’interdépendance entre ces applications. Les applications qui consultent ou consomment des données provenant d’autres applications souffrent toujours lorsqu’elles sont couplées. Par exemple, toute modification apportée à la structure de données peut affecter directement d’autres applications qui consultent ou consomment ces données. Lorsque de nombreuses applications sont couplées, une petite modification apportée à une seule application peut affecter beaucoup d’autres applications. C’est ce qu’on appelle un « effet en cascade ». En raison de la probabilité accrue d’effets imprévus même après des modifications mineures, de nombreux architectes et ingénieurs logiciels évitent de créer des architectures couplées.
Un contrat de données garantit la compatibilité de l’interface et comprend les conditions d’utilisation du service et un contrat de niveau de service (SLA). Les conditions d’utilisation du service décrivent comment les données peuvent être utilisées, par exemple en limitant leur utilisation au développement, aux tests ou à la production. Les contrats SLA décrivent la qualité requise au niveau de l’interface et de la livraison des données. Voici quelques-uns des détails de qualité que vous pouvez spécifier dans un contrat SLA :
- Uptime
- Taux d’erreur
- Disponibilité
- Dépréciation
- Feuille de route
- Numéros de version
Vous pouvez placer les métadonnées qui capturent ces détails sous contrôle de code source, ce qui permet le déclenchement automatique de validations et de déploiements. Pour plus d’informations sur le contrôle de code source, consultez Contrôle de code source dans Azure Data Factory.
Les contrats de données fournissent un aperçu du couplage et des dépendances entre les domaines et les applications. Vous pouvez également tester les contrats, ce qui permet de garantir que toutes les modifications apportées à l’application et à l’interface sont validées par rapport aux exigences en matière de données de vos consommateurs. Vous pouvez savoir quand vos flux de données deviennent vulnérables aux modifications de source de données en amont en détectant la dérive de schéma. Pour plus d’informations, consultez Dérive de schéma dans le flux de données de mappage.
Les contrats de données font souvent partie de frameworks d’ingestion pilotés par les métadonnées. Vous pouvez stocker des contrats de données dans des enregistrements de métadonnées au sein d’un metastore géré de manière centralisée. À partir de cet emplacement central, vos contrats de données jouent un rôle important dans plusieurs domaines d’ingestion de données, notamment :
Exécution du pipeline
Création d’un produit de données
Validation du type de données
Schémas
Normes d’interopérabilité
Versions de protocole
Règles par défaut sur les données manquantes
Les contrats de données impliquent de grandes quantités de métadonnées techniques. Pour documenter vos pipelines de données et vos produits de données, vous devez avoir une description claire de vos sources de données, de toutes les transformations que vos données ont subi et de la livraison finale des données.
Dans une architecture distribuée, vous distribuez une infrastructure de pipeline de données sur différents domaines, ces derniers étant conformes à un mode de travail commun. Étant donné que les domaines traitent eux-mêmes les données, le contrôle et la responsabilité restent avec eux, tandis que le framework et les métadonnées sont sous la gouvernance centrale.
Lors de l’implémentation d’une méthode fédérée, commencez petit. Commencez par les principes de base tels que le stockage des métadonnées pour la validation de schéma, les identificateurs d’entreprise et les références à d’autres jeux de données dans votre référentiel de métadonnées partagé. Ajoutez la prise en charge de la traçabilité des données pour vous aider à visualiser le déplacement des données. Démarrez vos processus et utilisez des bibliothèques comme Great Expectations pour implémenter des contrôles afin de valider la qualité des données techniques.
Tous vos contrôles doivent faire partie de vos procédures d’intégration continue. Capturez toutes les informations d’exécution, y compris les métriques et la journalisation, intégrez ces informations à votre base de métadonnées pour obtenir des insights sur la stabilité du pipeline de données. Cette configuration garantit que vous disposez d’une boucle de rétroaction entre vos domaines et votre poste central de pilotage.
À mesure que vous stabilisez tous les déplacements des données, capturez les attributs de données (comme les tables et les colonnes) utilisés par les consommateurs de données et utilisez ces informations pour poursuivre la mise à l’échelle. Vous pouvez inclure ces informations dans votre metastore géré de manière centralisée. Les informations sur l’utilisation des données vous permettent de détecter les changements cassants et d’identifier leurs effets sur vos producteurs et consommateurs de données. Si un jeu de données de produit de données n’a aucun consommateur, vous pouvez l’autoriser à subir des changements perturbants. Utilisez le contrôle de code source (comme Git) pour autoriser un processus d’établissement de liaison entre les fournisseurs et les consommateurs de vos données.
Contrat de partage de données
Les contrats de partage de données sont une extension des contrats de données. Les contrats décrivent l’utilisation des données, la confidentialité et l’objectif, y compris d’éventuelles limitations. Les contrats de partage de données sont indépendants de l’interface et offrent des insights sur les données utilisées à des fins particulières. Ils font également office d’entrée pour les contrôles de sécurité des données. Vous pouvez utiliser un contrat de partage de données pour décrire les filtres ou les protections de sécurité à appliquer à vos données.
Les contrats de partage de données permettent également d’éviter les erreurs de communication concernant l’utilisation des données. Les propriétaires de domaine doivent discuter des problèmes de partage et d’utilisation des données avant de partager les données. Une compréhension commune est essentielle pour que vous puissiez réglementer les données et leur utilisation et garantir la création de valeur pour votre organisation. Quand tous les propriétaires de domaine arrivent à une compréhension collaborative, veillez à ce qu’ils documentent cela dans un contrat de partage de données. Dans ce contrat, vous pouvez également aborder des domaines tels que les suivants :
Qualité des données fonctionnelles
Historisation
Gestion du cycle de vie des données
Distribution supplémentaire des données
Appliquez des classifications et des conditions telles que des étiquettes de confidentialité ou des conditions de filtrage pour sécuriser vos données.
Dans le diagramme de la section précédente, certains éléments sont étiquetés sidecar de produit de données. Un sidecar de produit de données est un composant ou une couche pour injecter l’exécution de la stratégie, comme des contrôles d’accès aux données ou des méthodes de sortie de consommation de données. Il s’agit d’une abstraction de sécurité qui utilise des contrats de données pour gérer l’application de la sécurité sur vos données de domaine. Vous pouvez créer un sidecar de produit de données à partir de votre référentiel de contrats de données sous la forme d’une vue ACL (liste de contrôle d’accès) ou serverless, ou en créer un avec un jeu de données en double que vous sélectionnez et filtrez pour un consommateur spécifique. Dans tous les cas, l’objectif est de dériver des vues de sécurité de vos contrats de données de manière entièrement automatisée.
Connectez les attributs des contrats de données et votre documentation. Veillez à fournir un contexte sémantique et une relation à votre glossaire afin que vos consommateurs puissent comprendre comment les exigences métier se traduisent en implémentation réelle. Si une relation avec les termes métier est importante pour votre organisation, envisagez d’implémenter des stratégies. Vous pouvez par exemple autoriser uniquement l’établissement de contrats de données une fois tous les attributs de produit de données liés aux entités des termes métier. Vous pouvez également appliquer ce type de stratégie aux changements contextuels comme les ajustements de relation ou de définition.
Utiliser des contrats de données
Quand vous commencez à utiliser des contrats de données, prenez votre temps. N’introduisez pas trop de changements à la fois : les contrats de données nécessitent un virage culturel, et vos utilisateurs ont besoin de temps pour se familiariser avec eux et comprendre l’importance de la propriété des données. Vous devez également trouver le juste équilibre concernant le nombre d’attributs de métadonnées dans vos contrats de données : ni trop ni trop peu.
Les étapes suivantes décrivent le processus d’implémentation de contrats de données pour votre organisation.
Vérifiez que vos pipelines de données techniques sont stables. Les cas d’usage ne peuvent pas arriver en phase de production si les pipelines qu’ils traversent subissent des perturbations inattendues.
Mettez en place des processus simples et pragmatiques quand vous commencez à utiliser des contrats de partage. Vous pouvez commencer par concevoir un formulaire ou un modèle simple dans Microsoft Forms. Écrivez dans un langage clair et concis que les lecteurs peuvent facilement comprendre. L’objectif de cette première phase est un virage culturel et la collecte d’exigences. Veillez à ne pas trop compliquer les choses : acceptez les processus manuels, limitez vos exigences initiales en matière de métadonnées et itérez jusqu’à ce que ces exigences soient stables.
Une fois vos premiers processus bien en place, commencez à remplacer vos formulaires manuels par une application web, une base de données et/ou une file d’attente de messages. Votre équipe centrale de gouvernance des données doit toujours être responsable de la supervision au cours de cette phase. À ce stade, la granularité de l’accès aux données est généralement grossière et axée sur les dossiers ou les fichiers. Dans la mesure du possible, utilisez des API REST pour provisionner automatiquement vos stratégies d’accès aux données ou listes de contrôle d’accès.
Confiez aux propriétaires ou aux gestionnaires de données un workflow fort pour la gestion des approbations. Votre rôle central de gouvernance des données doit désormais superviser les approbations uniquement à partir d’un rôle secondaire et passer régulièrement en revue tous les contrats de données. À ce stade, vous devriez avoir un catalogue de données en place, comme Azure Purview, pour présenter tous vos produits de données prêts à la consommation. Améliorez vos données et votre capacité d’application de la sécurité en autorisant des sélections et un filtrage précis, et envisagez d’utiliser des techniques telles que le masquage dynamique des données pour empêcher la duplication de vos données.
Au cours de la dernière étape du parcours d’implémentation de votre contrat de données, tout doit être en libre-service et entièrement automatisé. Le Machine Learning automatisé doit prédire les approbations de données. Sécurité
À la fin de votre parcours, tout sera libre-service et entièrement automatisé. Cela inclut l’application automatisée de la sécurité et le Machine Learning pour prédire les approbations de données. Les vues sécurisées, par exemple, sont déployées automatiquement après approbation.
Les contrats de données sont un ajout relativement important à l’architecture du maillage de données, offrant transparence au niveau de l’utilisation des données et de leurs dépendances. Concentrez-vous sur la stabilité technique et la normalisation à mesure que vous commencez à utiliser des contrats de données, puis utilisez un processus basé sur les leçons apprises quand vous itérez. Développez et automatisez lentement votre gouvernance des données de manière à ne pas augmenter les frais généraux de votre organisation.
Dans le cadre de votre documentation sur les contrats de données, vous avez également besoin de conditions d’utilisation du service et de contrats de niveau de service (SLA). Utilisez les SLA pour définir les exigences de qualité pour la livraison de vos données et les interfaces, y compris la durée de bon fonctionnement, les taux d’erreur et la disponibilité. Les SLA peuvent également inclure toutes les exigences en matière de dépréciation, de feuille de route et de numéro de version que vous devez définir.