Corso
Capire il Data Engineering
2 ore
378K
I data contract sono la spina dorsale della qualità e della scalabilità dei dati nelle soluzioni distribuite. Specificano il formato, lo schema e i protocolli che regolano lo scambio tra entità del database. Questi accordi formali eliminano ambiguità e assunzioni non documentate sui dati.
In questo articolo chiarirò il concetto di data contract offrendo sia tecniche di base sia avanzate per facilitarne un'implementazione efficace.
Capire i data contract
Un singolo data contract delinea i parametri precisi per lo scambio dati tra due modelli. Questi accordi formali assicurano che non ci siano ambiguità riguardo a formati e schemi dei dati.
La definizione e la validazione dei data contract sono fondamentali per una collaborazione efficace tra team.
In poche parole, un data contract è un accordo formale tra il processo che modifica lo stato originale dei nostri dati (producer) e le destinazioni (consumer). È molto simile al funzionamento dei contratti commerciali: rappresentano obblighi tra fornitori e consumatori di un prodotto. I data contract fanno lo stesso con i data product, cioè tabelle, viste, modelli di dati, ecc.
L'obiettivo è ridurre le interruzioni a valle delle pipeline e rendere le trasformazioni dati stabili e affidabili.
I componenti principali di un data contract sono lo schema (colonne e formati), la parte di semantic layer (misure, calcoli e restrizioni), i service level agreement (SLA) e la data governance.
I vantaggi dei data contract includono:
- Automazione e verifiche della qualità dei dati quando si creano o si aggiornano nuovi output.
- Abilitare uno scaling efficiente, soprattutto per architetture dati distribuite, ad esempio il data mesh.
- Migliorare il ciclo di sviluppo dei dati, con un focus sulla creazione di strumenti per la validazione dei contratti.
- Favorire la collaborazione attraverso feedback tra producer e consumer di dati.
Data contract. Immagine dell'autore.
Esempio di data contract con dbt
In un data contract, gli schemi definiscono i nomi degli attributi, i tipi di dato e se gli attributi sono obbligatori. Possono anche specificare formato, lunghezza e intervalli di valori accettabili per le colonne.
Consideriamo uno schema di modello dbt definito così in un file YAML. Lo schema della nostra tabella è definito sotto 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: stringOra immaginiamo di definire il nostro modello dim_orders così:
select
'abc123' as order_id,
'Some order type' as order_typeAvere un contract con enforced: true nella definizione del modello genererà il seguente errore se proviamo a materializzare dim_orders in una tabella nella nostra piattaforma dati:
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)Lo stesso accadrebbe con colonne extra, controlli SLA e metadati mancanti, qualora scegliessimo di definirli.
Un esempio dbt più avanzato includerebbe vincoli di modello applicati:
# 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: …Fornire una definizione di schema come insieme di regole e vincoli applicati alle colonne di un dataset offre informazioni molto importanti per l'elaborazione e l'analisi dei dati.
Gli schemi tendono a cambiare nel tempo.
È uno scenario comune. Immaginiamo che alla nostra tabella sorgente venga aggiunta una colonna contrattualizzata extra:
select
'abc123' as order_id,
'Some order type' as order_type,
'USD' as currencyÈ essenziale considerare i cambiamenti di schema durante gli aggiornamenti incrementali perché, altrimenti, l'output del modello incrementale a valle invaliderebbe il contratto.
Questo si può risolvere aggiungendo on_schema_change: append alla strategia incrementale di dbt.
Le validazioni di schema possono essere esplicite o implicite.
Alcuni formati file big data, come AVRO e Parquet, supportano di default uno schema a bordo e definizioni implicite, quindi non servono validazioni esterne aggiuntive.
Al contrario, formati file senza schema come JSON richiedono una validazione esterna. Alcune librerie Python, come pydantic o un semplice @dataclass, possono occuparsene:
from pydantic import BaseModel
class ConnectionDataRecord(BaseModel):
user: str
ts: int
record = ConnectionDataRecord(user="user1", ts=123456789)Se infrangiamo le regole assegnando valori che non rispettano i criteri, verrà sollevata un'eccezione. Ad esempio, l'eccezione verrà generata se proviamo a chiamare ConnectionDataRecord('', 1).
In cosa differiscono i data contract dalla validazione e dal testing dei dati?
I data contract possono essere usati nelle pipeline di streaming in tempo reale?
Come gestisci il versioning nei data contract quando gli schemi cambiano spesso?
Che ruolo hanno i data contract in un'architettura data mesh?
Come possono i data contract aiutare a rispettare normative sulla privacy come GDPR o HIPAA?
Argomenti
