Cours
Présentation de l’ingénierie des données
2 h
373.2K
Les data contracts sont l'ossature de la qualité et de la scalabilité des données pour les solutions distribuées. Ils précisent le format, le schéma et les protocoles qui encadrent les échanges entre entités de base de données. Ces accords formels éliminent les ambiguïtés et les hypothèses non documentées sur les données.
Dans cet article, je clarifie la notion de data contract en proposant à la fois des techniques fondamentales et avancées pour faciliter leur mise en œuvre efficace.
Comprendre les data contracts
Un data contract définit précisément les paramètres d'échange de données entre deux modèles. Ces accords formels garantissent l'absence d'ambiguïté quant au format et aux schémas des données.
La définition et la validation des data contracts sont essentielles pour une collaboration efficace entre équipes.
En bref, un data contract est un accord formel entre le processus qui modifie l'état initial de nos données (producteurs) et les destinations (consommateurs). C'est très proche du fonctionnement des contrats commerciaux : ils formalisent des engagements entre fournisseurs et clients d'un produit. Les data contracts font la même chose avec les produits de données, c'est-à-dire les tables, vues, modèles de données, etc.
L'objectif est de réduire les perturbations en aval des pipelines de données et de rendre les transformations stables et fiables.
Les principaux composants d'un data contract sont le schéma (colonnes et formats), la partie couche sémantique (mesures, calculs et restrictions), les accords de niveau de service (SLA) et la gouvernance des données.
Les avantages des data contracts incluent :
- Automatisation et contrôles de qualité des données lors de la création ou de la mise à jour de nouveaux jeux de données.
- Scalabilité efficace, en particulier pour les architectures distribuées, par exemple le data mesh.
- Amélioration du cycle de développement des données, avec un accent sur les outils de validation des contrats.
- Renforcement de la collaboration via les retours entre producteurs et consommateurs de données.
Data contracts. Image de l'auteur.
Exemple de data contract avec dbt
Dans un data contract, les schémas définissent les noms d'attributs, les types de données et le caractère obligatoire des attributs. Ils peuvent aussi préciser le format, la longueur et les plages de valeurs acceptables pour les colonnes.
Considérons un schéma de modèle dbt défini comme suit dans un fichier YAML. Le schéma de notre table est défini dans columns :
models:
- name: dim_orders
config:
materialized: table
contract:
enforced: true
columns:
- name: order_id
data_type: int
constraints:
- type: not_null
- name: order_type
data_type: stringImaginons maintenant que nous définissions notre modèle dim_orders ainsi :
select
'abc123' as order_id,
'Some order type' as order_typeLe fait d'avoir contract avec enforced: true dans la définition du modèle déclenchera l'erreur suivante si nous essayons de matérialiser dim_orders en table sur notre plateforme de données :
20:53:45 Compilation Error in model dim_customers (models/dim_orders.sql)
20:53:45 This model has an enforced contract that failed.
20:53:45 Please ensure the name, data_type, and number of columns in your contract match the columns in your model's definition.
20:53:45
20:53:45 | column_name | definition_type | contract_type | mismatch_reason |
20:53:45 | ----------- | --------------- | ------------- | ------------------ |
20:53:45 | order_id | TEXT | INT | data type mismatch |
20:53:45
20:53:45
20:53:45 > in macro assert_columns_equivalent (macros/materializations/models/table/columns_spec_ddl.sql)Il en serait de même avec des colonnes supplémentaires, des contrôles SLA ou des métadonnées manquantes, si nous avions choisi de les définir.
Un exemple dbt plus avancé inclurait des contraintes de modèle appliquées :
# models/schema.yaml
models:
- name: orders
# required
config:
contract:
enforced: true
# model-level constraints
constraints:
- type: primary_key
columns: [id]
- type: FOREIGN_KEY # multi_column
columns: [order_type, SECOND_COLUMN, ...]
expression: "OTHER_MODEL_SCHEMA.OTHER_MODEL_NAME (OTHER_MODEL_FIRST_COLUMN, OTHER_MODEL_SECOND_COLUMN, ...)"
- type: check
columns: [FIRST_COLUMN, SECOND_COLUMN, ...]
expression: "FIRST_COLUMN != SECOND_COLUMN"
name: HUMAN_FRIENDLY_NAME
- type: ...
columns:
- name: FIRST_COLUMN
data_type: DATA_TYPE
# column-level constraints
constraints:
- type: not_null
- type: unique
- type: foreign_key
expression: OTHER_MODEL_SCHEMA.OTHER_MODEL_NAME (OTHER_MODEL_COLUMN)
- type: …Fournir une définition de schéma comme ensemble de règles et de contraintes appliquées aux colonnes d'un jeu de données apporte des informations clés pour le traitement et l'analyse.
Les schémas évoluent avec le temps.
C'est un cas fréquent. Imaginons que notre table source ajoute une colonne contractuelle supplémentaire :
select
'abc123' as order_id,
'Some order type' as order_type,
'USD' as currencyIl est essentiel de tenir compte des changements de schéma lors des mises à jour incrémentales, sinon la sortie du modèle incrémental en aval invalidera le contrat.
On peut résoudre cela en ajoutant on_schema_change: append à la stratégie incrémentale dbt.
Les validations de schéma peuvent être explicites ou implicites.
Certains formats de fichiers big data, comme AVRO et Parquet, intègrent nativement des définitions de schéma et des validations implicites ; il n'est donc pas nécessaire d'ajouter une validation externe.
À l'inverse, les formats sans schéma comme JSON nécessitent une validation externe. Des bibliothèques Python comme pydantic ou un simple @dataclass, peuvent l'assurer :
from pydantic import BaseModel
class ConnectionDataRecord(BaseModel):
user: str
ts: int
record = ConnectionDataRecord(user="user1", ts=123456789)Si nous enfreignons les règles en attribuant des valeurs qui ne correspondent pas aux critères, une exception sera levée. Par exemple, l'appel à ConnectionDataRecord('', 1) déclenchera une erreur.
Devenez ingénieur en données
Développez vos compétences en Python pour devenir un ingénieur de données professionnel.
Devenez ingénieur en données
Faites la preuve de vos compétences en tant qu'ingénieur en données prêt à l'emploi.
Quelle est la différence entre data contracts, validation des données et tests de données ?
Peut-on utiliser des data contracts dans des pipelines de streaming temps réel ?
Comment gérer le versionnage des data contracts lorsque les schémas évoluent souvent ?
Quel est le rôle des data contracts dans une architecture data mesh ?
Comment les data contracts aident-ils à se conformer aux réglementations de confidentialité comme le RGPD ou HIPAA ?
Sujets