Data Contracts et CI/CD
Comment les Data Contracts s'intègrent-ils dans votre pipeline CI/CD ?
Par Dr. Simon Harrer · · vidéo de 2:40 · 9 diapositives
En bref
Un Data Contract est un fichier dans le dépôt Git du produit de données. Chaque changement passe par un pipeline CI/CD. Le pipeline vérifie le Data Contract, teste les données dans chaque environnement et publie les résultats sur la marketplace de données.
Regarder sur YouTube
Un changement d'une seule ligne
Un Data Engineer renomme une colonne dans une pull request : customer name devient full name. La revue paraît sans risque. Après le déploiement, un rapport de sinistres, un modèle de churn et un agent IA tombent. Le Data Contract avait l'information, mais rien ne la vérifiait.
Le Data Contract vit dans Git
Gardez le Data Contract dans le même dépôt Git que le code du pipeline. Le nom du fichier indique le jeu de données, la version majeure et la plateforme. Le code et le Data Contract changent ensemble. Chaque commit déclenche le pipeline CI/CD.
Les règles de l'entreprise
D'abord, le job de lint vérifie que le fichier est un ODCS valide. Ensuite, un petit script Python vérifie les règles de votre entreprise. Par exemple, chaque champ d'un Data Contract actif doit avoir une classification. Le build reste bloqué jusqu'à ce que chaque champ en ait une.
Les changements cassants arrêtent le build
Le job suivant compare le Data Contract modifié à la version de la branche main. La Data Contract CLI constate qu'une colonne a été supprimée. C'est un changement cassant, donc le build échoue avant le merge.
Un schéma par pull request
Avant le merge, le pipeline déploie le changement dans son propre environnement. Le serveur du Data Contract tire son nom de schéma d'une variable. Chaque pull request obtient ainsi son propre schéma, et les tests ne touchent pas aux données des autres.
Tester à nouveau en staging
Après le merge, le pipeline déploie en staging et exécute le pipeline de données. Il teste ensuite à nouveau le schéma, les règles de qualité et la fraîcheur. Le pipeline utilise le même Data Contract pour chaque environnement. Seul le serveur du Data Contract change d'un environnement à l'autre.
Publier quand tous les jobs sont verts
Le pipeline déploie ensuite en production et teste à nouveau. Ce n'est que lorsque chaque job est vert qu'il publie le Data Contract et les résultats des tests sur la marketplace de données. Les Data Consumers voient alors l'état actuel de la promesse.
Surveiller la promesse chaque nuit
Le code ne change pas pendant la nuit, mais de nouvelles données arrivent en permanence. Un second pipeline teste donc les données de production chaque nuit. Ici, la table customers a 30 heures, alors que la limite est de 24 heures. La marketplace de données prévient le responsable et les consumers en aval.
À chaque commit et chaque nuit
Chaque commit passe par le pipeline. Chaque nuit, un job planifié teste à nouveau les données. Les problèmes deviennent ainsi visibles avant qu'un Data Consumer n'utilise des données fausses. Le Data Contract est vérifié à chaque changement et chaque jour.