Bonnes pratiques des Data Contracts
Quelles sont les bonnes pratiques pour les Data Contracts ?
Par Dr. Simon Harrer · · vidéo de 2:58 · 7 diapositives
En bref
Utilisez un Data Contract pour un Output Port, avec un schéma et un rôle de lecture. Gardez le Data Contract dans le dépôt Git du produit de données. Versionnez-le comme une API, et traitez le Data Contract actif comme la source de vérité.
Regarder sur YouTube
Un pour un
Un Data Contract dans une version majeure décrit un Output Port. Cet Output Port est un schéma de base de données avec une ou plusieurs tables et un rôle de lecture. Vous pouvez utiliser une autre structure, mais cela pose des problèmes. Avec un Data Contract par table, vous obtenez trop de Data Contracts.
Quelles données il protège
Un Data Contract protège un schéma de base de données avec toutes ses tables. La section schema du Data Contract liste ces tables. L'Output Port, le schéma et le serveur portent le même nom. Chaque nom contient la version majeure, et chaque environnement a son propre serveur.
Un seul rôle de lecture
Chaque Data Contract définit un rôle de lecture. La plateforme crée ce rôle automatiquement, avec un accès en lecture à ce seul schéma. Les Data Consumers demandent l'accès à ce rôle, ils savent donc quoi demander. Un second rôle, par exemple pour les données personnelles, est possible et pose peu de problèmes.
Où vivent les Data Contracts
Les Data Contracts vivent dans le dépôt Git du produit de données, à côté du code. Le Data Contract de l'Output Port dit ce que le produit de données fournit. Un Data Contract d'Input Port, optionnel, dit ce que le produit de données utilise d'un autre produit de données. Vous pouvez y ajouter vos propres contrôles de qualité.
Une nouvelle colonne est une version mineure
Versionnez le Data Contract comme une API. Au sens strict, une nouvelle colonne est un changement cassant, car SELECT star renvoie alors une colonne de plus. Nous n'autorisons pas SELECT star. Une nouvelle colonne n'est donc qu'une version mineure.
Un changement cassant passe en v2
Un changement cassant reçoit une nouvelle version majeure. La version 2 a son propre Output Port, son propre schéma et son propre rôle de lecture. La version 1 passe en deprecated, et les deux versions tournent en parallèle pendant une période de transition. Les Data Consumers passent à la version 2 à leur rythme. Puis la version 1 s'arrête.
La source de vérité
Quand un Data Contract est actif, il est la source de vérité. Si les données et le Data Contract ne concordent pas, les données sont fausses. Chaque changement commence donc dans le Data Contract. Le code et les données suivent ensuite.