Di Andrew Tan
Il Problema del Monitoraggio degli Schemi
Il monitoraggio degli schemi dovrebbe rilevare i cambiamenti critici. Non lo fa.
Una pipeline funziona per mesi senza problemi. Poi un servizio a monte aggiunge un campo revenue_v2. Il vecchio campo revenue esiste ancora, ma ora è deprecato e sempre nullo. La pipeline ingerisce i nulli felicemente. Nessun errore. Tutto verde.
La metrica aziendale è semplicemente sbagliata.
Questo accade perché il monitoraggio osserva i cambiamenti strutturali, non quelli semantici.
Perché il Monitoraggio Fallisce
La maggior parte dei team imposta avvisi per nuove colonne. Cambiamenti di tipo. Campi mancanti. Una persona esamina ogni avviso.
Dopo la cinquantesima notifica di "nuovo campo opzionale", smetti di leggere. Il tuo cervello approva automaticamente. INT a BIGINT? Innocuo. Approva. Vai avanti.
I veri problemi passano inosservati. Il problema sopra non era strutturale. Era semantico. È apparso un nuovo campo — apparentemente sicuro. Il vecchio campo esisteva. Nessun cambiamento critico rilevato.
Il contratto era rotto. Nessuno se ne è accorto.
Il monitoraggio cattura gli incidenti. Hai bisogno di qualcosa che catturi le bugie.
Contratti vs. Registri
Un registro degli schemi controlla la struttura. Nomi dei campi, tipi, nullabilità. Importante. Non sufficiente.
Un contratto dati controlla le promesse.
- Hai inviato un numero?
- Significa ciò che hai detto?
- È positivo? Nel range? Referenzialmente intatto?
Pensa agli API REST. Non controlli solo che il JSON venga analizzato. Controlli che l'endpoint faccia ciò che dicono i documenti. Rompere quella promessa è un cambiamento critico, anche se il JSON è tecnicamente valido.
Le pipeline di dati hanno bisogno della stessa cosa. I sistemi a valle si basano su promesse implicite. Quando queste si rompono, tutto si rompe.
Come Sono Fatti i Buoni Contratti
I team che fanno bene questo definiscono tre cose per ogni dataset:
Garanzie strutturali. Ma con una svolta: qualsiasi deviazione è critica. Nuovo campo opzionale? Incremento di versione. Sembra doloroso. Elimina completamente i "cambiamenti semantici furtivi".
Aspettative semantiche. Regole aziendali come validazione. Età del paziente 0-120. I codici di diagnosi devono esistere nella tabella di riferimento. Timestamp entro 24 ore dalla creazione del file.
Impegni dei consumatori. I sistemi a valle dichiarano le dipendenze. Cambia un campo utilizzato da tre pipeline critiche? Alto rischio. Anche se sembra "sicuro" strutturalmente.
I cambiamenti di schema passano da giorni di coordinamento a ore. La deriva semantica silenziosa scende a zero.
La Parte Difficile è Organizzativa
I contratti forzano conversazioni che la maggior parte delle persone non vuole avere.
I produttori devono promettere cose sui dati che non controllano completamente. Il team CRM non conosce ogni consumatore a valle. Il team mobile non sa come la data science utilizza i loro eventi.
Tre modelli di proprietà:
Di proprietà del produttore. Il team che produce i dati definisce il contratto. Pulito in teoria. Spesso fallisce perché i produttori ottimizzano per la convenienza, non per le esigenze a valle.
Di proprietà del consumatore. Il downstream definisce i requisiti. Protegge i consumatori, ma i produttori non possono sempre conformarsi. Ottieni contratti su carta che vengono violati nella pratica.
Mediato dalla piattaforma. Un team centrale media la conversazione. Più overhead. Funziona davvero.
Mediato dalla piattaforma con revisioni trimestrali è costoso in termini di tempo per le riunioni. Economico rispetto agli incidenti.
Inizia in Piccolo
Non hai bisogno di una piattaforma per iniziare.
Scrivi tre cose per i tuoi dataset critici:
Cosa rappresenta? Non definizioni dei campi. Il concetto aziendale. "Snapshot giornaliero degli abbonamenti attivi" differisce da "la tabella ha customer_id, plan_type, renewal_date."
Su cosa possono fare affidamento le persone? Nullabilità, frequenza di aggiornamento, conservazione. Le cose che tutti danno per scontate.
Cosa succede quando si rompe? Chi chiami? Quanto velocemente? Qual è il rollback?
Inizia con i tuoi tre asset più critici. Questo è tutto.
Anche i Contratti Creano Problemi
Si ossificano. Cambiare un contratto richiede coordinamento. Questo è il punto — previene cambiamenti critici — ma rallenta anche i buoni cambiamenti. I team evitano di proporre cambiamenti a causa del costo del coordinamento.
Mentono. Un contratto è valido solo quanto la sua validazione. Dire "tutti i customer_id devono esistere" senza controllare? Teatro. La falsa fiducia è peggiore di nessuna.
Spostano la colpa. Il consumatore rileva una violazione. Risposta: "il produttore ha rotto la sua promessa." Vero. Inutile. L'obiettivo è correggere i dati, non assegnare colpe. Hai bisogno di procedure di recupero, non di puntare il dito.
Gli Strumenti
Great Expectations e Soda hanno aggiunto funzionalità di contratto. Non piattaforme complete, ma fanno rispettare le aspettative semantiche ai confini.
Data Contract Club e AICP stanno emergendo. Contratti di prima classe con versionamento e validazione.
I cataloghi di dati — Collibra, Alation, Atlan — ora hanno la gestione dei contratti. Di solito pesanti in termini di flusso di lavoro, leggeri in termini di validazione. Meglio per i documenti che per l'applicazione.
Da layline.io integriamo i contratti nei Workflows. Definisci il movimento dei dati, definisci le promesse. Aspettative di schema, regole di validazione, soglie di qualità. Applicato in fase di runtime, non controllato dopo.
Ma non hai bisogno di strumenti sofisticati. Un file JSON Schema con un passaggio di validazione è un contratto funzionante. La pratica organizzativa batte la tecnologia.
Il Test
Scegli un asset di dati critico. Qualcosa che farebbe male se sbagliato.
A monte cambiano il loro formato. Tecnicamente valido — nuovi campi, stessi tipi. Semanticamente sbagliato. Quanto tempo prima che te ne accorga?
Se la risposta è "quando qualcuno si lamenta," hai bisogno di contratti.
Se è "lo cattureremmo nel monitoraggio," scava più a fondo. Il tuo monitoraggio cattura i cambiamenti semantici o solo quelli strutturali?
L'obiettivo non è la qualità perfetta dei dati. È prevenire i problemi stupidi. Quelli derivanti da assunzioni che nessuno ha scritto.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, costruendo infrastrutture di elaborazione dati aziendali che gestiscono carichi di lavoro sia batch che in tempo reale su larga scala.