Il pannello di controllo delle analisi era corretto martedì. Entro giovedì mostrava un calo del 23% nell'acquisizione di clienti che il team aziendale stava trattando come un vero segnale aziendale, riorganizzando i budget di marketing, sospendendo le campagne, segnalando al consiglio di amministrazione. Il team di ingegneria dei dati ha scoperto venerdì che il servizio a monte aveva aggiunto una colonna nullable al registrations tabella sei giorni prima. La pipeline ETL non era stata aggiornata. Il calcolo che derivava la metrica di acquisizione trattava i nuovi valori nulli come zeri anziché escluderli. Non era stata inviata alcuna notifica di modifica dello schema. Nessun contratto era stato violato in modo da produrre un errore. La pipeline è stata eseguita correttamente; ha prodotto numeri errati che sembravano corretti.
La deriva dello schema rappresenta una mutazione strutturale; a differenza dei problemi di qualità dei dati, in cui i valori sono errati, la deriva dello schema rompe il contratto tra origine e destinazione. In un ambiente di database monolitico con un DBA centrale che controlla tutte le istruzioni DDL, tale contratto è imposto da un'unica autorità. In un sistema distribuito, dove decine di servizi indipendenti possiedono ciascuno il proprio archivio dati, dove i flussi di eventi trasportano schemi Avro che si evolvono indipendentemente, dove le interfacce a file flat tra i processi batch del mainframe e le piattaforme di analisi cloud definiscono contratti impliciti che non esistono nella documentazione di nessuno dei due sistemi, il contratto è distribuito attraverso ogni confine del sistema. La deriva dello schema in un ambiente distribuito non aspetta che un DBA commetta un errore. Emerge dal normale funzionamento di team autonomi che prendono decisioni individualmente sensate senza una visibilità completa su ogni utente a valle dei loro dati.
Mappare il confine dello schema legacy
SMART TS XL identifica ogni contratto in formato file flat che collega i programmi mainframe alle moderne piattaforme di analisi.
SCOPRI DI PIÙ…Cos'è Schema Drift e cosa non è
Il drift dello schema è una modifica nella struttura di un artefatto di dati che non si riflette nei consumatori di tale artefatto. L'enfasi sui consumatori è ciò che distingue il drift dalla migrazione pianificata: la ridenominazione di una colonna eseguita simultaneamente nella tabella di origine e in ogni query che la utilizza rappresenta una migrazione dello schema. La stessa ridenominazione eseguita solo nella tabella di origine, lasciando i consumatori a leggere nomi di colonna obsoleti, è invece un drift dello schema.
Le pipeline di dati si basano su un contratto di fiducia tra il sistema di origine e il data warehouse di destinazione. Questo contratto è rappresentato dallo schema: la struttura concordata, i tipi di dati e i nomi delle colonne che definiscono il dataset. Quando i team a monte modificano il database dell'applicazione senza informare il team dati, violano questo contratto.
La deriva dello schema non è la stessa cosa della deriva dei dati. La deriva dei dati è un cambiamento nella distribuzione statistica dei valori all'interno di uno schema stabile, con valori medi di ordinamento in calo, tassi di valori nulli in aumento e distribuzioni categoriali che si modificano. Entrambi sono importanti segnali di qualità dei dati, ma richiedono approcci di rilevamento diversi e indicano cause principali differenti. Un sistema di rilevamento delle modifiche dello schema che monitora i nomi e i tipi di colonna non rileverà la deriva dei dati; un sistema di monitoraggio della distribuzione non rileverà l'aggiunta e la rimozione di colonne.
Il cambiamento di schema non è sempre dannoso. Monitorare la gravità del cambiamento nel tempo aiuta a distinguere tra cicli di sviluppo attivi (cambiamento benigno) e instabilità (cambiamento critico). L'aggiunta retrocompatibile di una colonna nullable a una tabella rappresenta un cambiamento di schema, ovvero lo schema è cambiato, ma potrebbe non causare problemi a nessun client che ignora la nuova colonna. La classificazione del cambiamento come benigno o critico richiede la comprensione dei client a valle e di come gestiscono la modifica.
I quattro tipi di deriva dello schema
I sistemi di dati distribuiti producono deriva dello schema lungo quattro dimensioni distinte, ognuna delle quali richiede meccanismi di rilevamento differenti:
Tipo 1: Deriva strutturale
Modifiche alla definizione dello schema fisico: aggiunta di colonne, rimozione di colonne, ridenominazione di colonne, modifiche al tipo di dati, aggiunta o rimozione di vincoli, aggiunta e rimozione di tabelle. Questa è la forma più visibile di deriva dello schema e quella più comunemente affrontata dagli strumenti di osservabilità. Le query INFORMATION_SCHEMA del database, i confronti del registro degli schemi e i log di controllo degli strumenti di migrazione rilevano efficacemente la deriva strutturale per i sistemi connessi.
Rilevamento: confronto dello snapshot dello schema con una baseline; polling INFORMATION_SCHEMA; confronto della versione del registro dello schema.
Tipo 2: Deriva semantica
Modifiche al significato di un campo esistente senza modifiche alla sua definizione. Una colonna denominata
statusche in precedenza contenevano valoriACTIVE,INACTIVE,PENDINGora contiene valori1,2,3perché il servizio produttore ha modificato la sua enumerazione. Lo schema, il nome della colonna, il tipo di dati e il vincolo di nullabilità sono rimasti invariati. Il contratto semantico è stato violato. I consumatori che analizzavano i valori di stato di tipo stringa ora ricevono numeri interi che la loro logica non è in grado di gestire.La deriva semantica e la deriva contestuale sono concetti più recenti e decisamente meno monitorati, nonostante entrambe siano responsabili di una quota crescente di fallimenti nei programmi di intelligenza artificiale. La deriva semantica è la più difficile da rilevare automaticamente perché non produce alcun segnale strutturale e richiede il monitoraggio della distribuzione dei valori (il rapporto tra valori noti e valori sconosciuti che cambiano) o test espliciti dei contratti.
Rilevamento: monitoraggio della distribuzione dei valori; regole di convalida dei valori consentiti; test di contratto che verificano specifici valori validi.
Tipo 3: Deriva del formato
Modifiche alla codifica o al formato dei valori all'interno di campi strutturalmente invariati. Un campo timestamp che in precedenza conteneva stringhe UTC ISO 8601 ora contiene numeri interi Unix epoch. Un campo valuta che in precedenza conteneva importi decimali ora contiene importi in centesimi come numeri interi. La colonna esiste, il tipo è ancora valido per i nuovi valori, ma la convenzione di analisi sintattica è cambiata.
La deriva di formato è particolarmente comune ai confini dei sistemi distribuiti, dove un servizio serializza i dati in un formato che un altro deserializza, e al confine tra sistemi legacy e moderni, dove i programmi COBOL scrivono file flat con specifiche convenzioni di posizionamento dei byte da cui dipendono i processi ETL a valle.
Rilevamento: profilazione statistica di intervalli e modelli di valori; regole di convalida del formato su campi specifici; test di contratto limite.
Tipo 4: Deriva contrattuale
Modifiche alle garanzie di disponibilità, aggiornamento o volume di una fonte di dati. Il sistema sorgente in precedenza forniva un set di dati entro le 3:00 UTC di ogni giorno; ora lo fornisce entro le 6:00, interrompendo silenziosamente i processi a valle che presupponevano l'aggiornamento entro le 3:00. Il sistema sorgente in precedenza garantiva un minimo di 1,000 record al giorno; nei periodi di basso traffico ora ne produce di meno. Nessuna delle due modifiche costituisce una modifica dello schema in senso strutturale, ma entrambe violano il contratto tra produttore e consumatore.
Rilevamento: monitoraggio della freschezza; rilevamento di anomalie di volume; avvisi basati su SLA.
Perché i sistemi distribuiti amplificano il problema
In un sistema monolitico con un unico database e un unico team di sviluppo, le modifiche allo schema sono eventi controllati. L'amministratore del database scrive la migrazione, lo sviluppatore aggiorna le query e la modifica viene implementata congiuntamente. Il rischio di deriva dello schema esiste, ma è circoscritto all'ambito di competenza dell'unica autorità.
I sistemi distribuiti eliminano quell'autorità unica. Ogni servizio possiede i propri dati. Ogni team prende decisioni sullo schema in modo indipendente. I consumatori dei dati di ciascun servizio sono spesso al di fuori della consapevolezza immediata del team, soprattutto quando il consumatore è una piattaforma dati, una pipeline di analisi o un punto di integrazione legacy che nessun team di prodotto gestisce attivamente.
Distributed Schema Drift Propagation Path:
Order Service Kafka Topic Analytics Pipeline
┌─────────────────┐ ┌───────────────┐ ┌──────────────────────┐
│ orders table │──>│ order.created │───>│ orders_fact table │
│ + coupon_id │ │ Avro schema │ │ (missing coupon_id) │
│ (new column) │ │ v1 still used │ │ pipeline runs fine │
│ │ │ │ │ coupon data silently │
│ │ │ │ │ dropped │
└─────────────────┘ └───────────────┘ └──────────────────────┘
▼
BI Dashboard
┌──────────────────┐
│ coupon_revenue │
│ always = $0 │
│ (no error shown) │
└──────────────────┘Il diagramma illustra il modello di propagazione: il team del Servizio Ordini aggiunge coupon_id al loro database. Se aggiornano anche lo schema degli eventi Kafka per includere coupon_idLa pipeline di analisi deve essere aggiornata per poterla utilizzare. Se lo schema Kafka è ancora alla versione 1, il campo non raggiunge mai la pipeline. Se la pipeline viene aggiornata ma il modello della dashboard di BI non viene aggiornato, il campo esiste nel data warehouse ma è assente dal report. Questa discrepanza può introdurre una perdita di dati silenziosa in corrispondenza di uno qualsiasi dei quattro punti critici, e ogni punto critico richiede un diverso meccanismo di rilevamento.
I guasti silenziosi delle pipeline, le dashboard obsolete, le derive dello schema e i set di dati incompleti sono diventati importanti rischi operativi negli ambienti dati aziendali moderni. Gli stack di dati moderni si guastano più rapidamente rispetto agli ambienti tradizionali, con trasformazioni interrotte, errori di aggiornamento e corruzione silenziosa dei dati che si propagano lungo le pipeline molto prima che i team rilevino i problemi manualmente.
La proprietà "silenziosa" è ciò che rende costoso il drift dello schema distribuito. Un errore che produce un'eccezione viene rilevato e corretto. Una modifica che produce silenziosamente valori errati non viene rilevata fino a quando una decisione aziendale basata su tali valori non produce una conseguenza visibile.
Metodi di rilevamento per strato
Il rilevamento della deriva dello schema richiede strumenti e tecniche diversi per ogni livello di un sistema distribuito:
Livello di database e data warehouse
Il livello di rilevamento più maturo. Le tabelle INFORMATION_SCHEMA presenti in ogni database e data warehouse principale forniscono un'istantanea dei metadati interrogabile:
sql
-- Detect structural schema changes since a baseline snapshot
-- Run daily; alert when new differences appear
WITH current_schema AS (
SELECT
table_name,
column_name,
data_type,
is_nullable,
column_default,
ordinal_position
FROM information_schema.columns
WHERE table_schema = 'production'
),
baseline AS (
-- Previous snapshot stored in schema_baseline table
SELECT * FROM schema_monitoring.schema_baseline
WHERE snapshot_date = CURRENT_DATE - 1
)
SELECT
'ADDED' AS change_type,
c.table_name,
c.column_name,
c.data_type,
CURRENT_DATE AS detected_date
FROM current_schema c
LEFT JOIN baseline b
ON c.table_name = b.table_name
AND c.column_name = b.column_name
WHERE b.column_name IS NULL
UNION ALL
SELECT
'REMOVED' AS change_type,
b.table_name,
b.column_name,
b.data_type,
CURRENT_DATE
FROM baseline b
LEFT JOIN current_schema c
ON b.table_name = c.table_name
AND b.column_name = c.column_name
WHERE c.column_name IS NULL
UNION ALL
SELECT
'TYPE_CHANGED' AS change_type,
c.table_name,
c.column_name,
c.data_type || ' (was: ' || b.data_type || ')' AS data_type,
CURRENT_DATE
FROM current_schema c
JOIN baseline b
ON c.table_name = b.table_name
AND c.column_name = b.column_name
WHERE c.data_type <> b.data_type;Strumenti che automatizzano questo schema: test dello schema dbt, previsioni delle colonne di Great Expectations, monitoraggio dello stato di salute delle tabelle con il metodo Monte Carlo, monitoraggio della deriva dello schema di Acceldata.
Livello di streaming degli eventi
Gli argomenti Kafka utilizzano registri di schemi (Confluent Schema Registry, AWS Glue Schema Registry, Apicurio) per gestire l'evoluzione degli schemi Avro, Protobuf e JSON. Il registro impone regole di compatibilità al momento della pubblicazione:
YAML
# Confluent Schema Registry: compatibility rule configuration
# Applied per topic; enforces at producer registration time
compatibility:
BACKWARD:
# New schema can read data written with old schema
# Safe: consumers can be updated after producers
allows: add_optional_fields, remove_fields_with_defaults
blocks: rename_fields, change_types, add_required_fields
FORWARD:
# Old schema can read data written with new schema
# Safe: consumers can be deployed before producers
allows: add_required_fields, rename_with_aliases
blocks: remove_fields_used_by_consumers
FULL:
# Both backward and forward compatible
# Strictest: ensures zero-downtime evolution
allows: add_optional_fields_with_defaults
blocks: everything_elseIl registro degli schemi non impedisce la deriva semantica: un campo il cui nome e tipo rimangono invariati, ma il cui significato è cambiato, supera i controlli di compatibilità. Per la validazione semantica è necessario eseguire test di contratto (test Pact, test AsyncAPI).
Livello API
Esistono quattro approcci fondamentalmente diversi per rilevare le discrepanze nello schema delle API: confronto tra specifiche, monitoraggio tra specifiche e realtà, monitoraggio tra realtà e realtà e rilevamento basato sul traffico. La maggior parte della confusione in questo ambito deriva dal confronto tra strumenti che adottano approcci diversi.
Per le API di servizio interne in un'architettura a microservizi, il test dei contratti guidato dal consumatore (Pact) è l'approccio più affidabile: ogni consumatore specifica il contratto che richiede al produttore, i contratti vengono verificati rispetto all'implementazione del produttore in CI e qualsiasi modifica che violi il contratto di un consumatore fa fallire la suite di test del produttore prima del deployment.
Il confine del sistema Legacy: dove la deriva diventa invisibile
Ciascuno degli approcci di rilevamento descritti sopra funziona per i sistemi che espongono i metadati dello schema tramite interfacce interrogabili: INFORMATION_SCHEMA, registri degli schemi, specifiche OpenAPI. Al confine tra i sistemi mainframe legacy e le moderne piattaforme dati, queste interfacce non esistono.
Un programma COBOL che produce un file flat ogni notte per essere utilizzato da una pipeline ETL cloud definisce uno schema implicito nella logica di input e output dei descrittori di file (FD). Lo "schema" del file flat, ovvero le posizioni dei byte, i tipi di dati, i campi decimali impacchettati COMP-3 e le strutture REDEFINES, risiede nel codice sorgente COBOL e non in alcun registro o archivio di metadati che i moderni strumenti di osservabilità possano interrogare.
cobolo
*> This FD entry IS the schema contract for the nightly extract
*> Any change here constitutes schema drift for the downstream ETL
FD CUSTOMER-EXTRACT-FILE
LABEL RECORDS ARE STANDARD
RECORD CONTAINS 350 CHARACTERS.
01 CUSTOMER-EXTRACT-REC.
05 CUST-ID PIC 9(10). *> Bytes 1-10
05 CUST-NAME PIC X(40). *> Bytes 11-50
05 CUST-BALANCE PIC S9(11)V99 COMP-3. *> Bytes 51-57 (packed)
05 CUST-STATUS-CD PIC X(2). *> Bytes 58-59
05 CUST-OPEN-DATE PIC 9(8). *> Bytes 60-67: YYYYMMDD
05 FILLER PIC X(283). *> Bytes 68-350
Se il team COBOL cambia CUST-BALANCE da PIC S9(11)V99 COMP-3 a PIC S9(13)V99 COMP-3Aggiungendo due cifre di precisione per gestire valori di saldo più elevati, il campo si espande da 7 a 8 byte in formato decimale compresso. Ogni campo dopo il byte 50 si sposta di una posizione. Il file flat letto dalla pipeline ETL ora ha tutti i campi dopo CUST-BALANCE in posizioni di byte errate. La pipeline ETL non produce un errore; legge i byte 51-57 come CUST-BALANCE e interpreta il byte successivo (che ora è il primo byte della rappresentazione espansa di CUST-BALANCE) come parte di CUST-STATUS-CD. La pipeline viene eseguita. I numeri sono errati. Non viene attivato alcun avviso di deriva dello schema.
Questa è la classe più pericolosa di deriva dello schema negli ambienti aziendali: modifiche strutturali nei sistemi legacy che si propagano silenziosamente attraverso interfacce di file flat senza alcun meccanismo di rilevamento a nessuna delle due estremità.
Tre caratteristiche rendono la deriva dei confini preesistenti particolarmente pericolosa:
Lo schema è invisibile agli strumenti di osservabilità. Monte Carlo non può connettersi a un file VSAM. Acceldata non può interrogare una voce FD. L'unico modo per rilevare la modifica è confrontare il codice sorgente COBOL con una versione precedente, un'operazione di analisi del codice, non di monitoraggio dei dati.
La propagazione è silenziosa. Le interfacce di file flat non convalidano la struttura dei record; leggono i byte. Una modifica alla disposizione dei byte produce valori errati, non errori.
L'impatto è ampio. Un copybook COBOL incluso da 300 programmi è uno schema condiviso da 300 programmi. Una modifica al copybook, equivalente a un'istruzione ALTER TABLE in DDL, influisce simultaneamente su tutti e 300 i programmi, e ogni programma che utilizza a valle un dataset prodotto da uno qualsiasi di questi 300 programmi eredita la modifica.
Contratti di schema: formalizzare ciò che di solito è implicito
La soluzione strutturale al problema della deriva dello schema consiste nel rendere espliciti i contratti impliciti, definendo cos'è lo schema, chi ne dipende e quali modifiche sono consentite, prima che una modifica venga apportata, anziché dopo che ha causato un malfunzionamento.
| Strato di contratto | Cosa governa | Strumenti | Equivalente legacy |
|---|---|---|---|
| DDL del database | Struttura della tabella, tipi di colonna, vincoli | Liquibase, Flyway, Atlas | Script di migrazione DDL di DB2 |
| Schema degli eventi | Struttura del flusso di eventi/Kafka | Registro degli schemi confluenti, Apicurio | Non applicabile (il file flat non ha registro) |
| contratto API | Aspettative relative all'interfaccia REST/gRPC | OpenAPI, Pact, AsyncAPI | Non applicabile (l'interfaccia file non ha specifiche) |
| Qualità dei dati | Distribuzione dei valori, freschezza, volume | Grandi speranze, test dbt | Non applicabile (nessun framework di test nativo) |
| contratto formato file | Disposizione dei byte del file flat, posizioni dei campi | Voce FD COBOL (fonte di verità) | Controllo delle versioni del manuale |
La voce "Controllo versione del copybook" nella colonna "Equivalente legacy" rappresenta il meccanismo pratico per la gestione dell'evoluzione dello schema COBOL: trattare il copybook come un artefatto versionato con un processo di approvazione delle modifiche, mantenere un registro dei programmi che includono ciascun copybook e richiedere un'analisi d'impatto prima che qualsiasi modifica al copybook venga approvata.
Flusso di lavoro per l'approvazione delle modifiche al manuale:
- Lo sviluppatore propone una modifica a
CUSTMSTR.CPY - L'analisi d'impatto identifica ogni programma che include
CUSTMSTR.CPY(analisi statica) - Ogni file flat prodotto da questi programmi viene identificato come un evento di modifica dello schema.
- Ogni utente a valle di quei file flat viene avvisato
- Vengono eseguiti test di validazione da parte dei consumatori sul nuovo layout
- La modifica verrà approvata solo quando tutti i consumatori avranno confermato la compatibilità.
Questo flusso di lavoro rispecchia il modello di applicazione della compatibilità del registro degli schemi, applicato al livello COBOL laddove non esiste un registro degli schemi nativo.
Architettura di monitoraggio per la deriva dello schema distribuito
Un'architettura completa per il monitoraggio delle derive dello schema copre tutti e quattro i tipi di deriva su tutti i livelli del sistema:
Database snapshot dello schema. Memorizza uno snapshot giornaliero dei metadati INFORMATION_SCHEMA di ogni tabella, di ogni versione dello schema degli eventi registrati, di ogni versione delle specifiche API e (per i sistemi legacy) di ogni versione del copybook. Il database snapshot rappresenta la base di riferimento rispetto alla quale viene confrontato lo stato corrente.
Pipeline di rilevamento delle modifiche. I processi di confronto giornalieri vengono eseguiti sul database snapshot, rilevando aggiunte, rimozioni, modifiche di tipo e modifiche di vincolo a ogni livello monitorato. Le modifiche ad alta gravità, le modifiche di tipo non retrocompatibili, le rimozioni di colonne e le aggiunte di campi obbligatori attivano avvisi immediati. Le modifiche a bassa gravità, come le aggiunte di colonne che ammettono valori nulli e le modifiche agli indici, generano notifiche di avviso.
Registro dell'impatto sui consumatori. Un catalogo che mappa ogni artefatto dello schema ai suoi consumatori noti: quali pipeline leggono da quali tabelle, quali servizi consumano quali argomenti Kafka, quali processi ETL elaborano quali file flat. Quando viene rilevata una modifica dello schema, il registro dell'impatto sui consumatori determina il raggio d'azione, quanti consumatori sono interessati e quali sono i più critici.
Suite di test contrattuali. Test automatizzati che verificano le ipotesi del consumatore sugli schemi del produttore. Vengono eseguiti su ogni implementazione che coinvolge un servizio di produzione dati. L'implementazione fallisce se viene violato un contratto da cui dipende un consumatore registrato.
Monitoraggio dei confini legacy. Per i sistemi mainframe: confronto del copybook con controllo di versione, monitoraggio della definizione del dataset JCL e convalida del formato dei file flat rispetto allo schema definito nella voce FD del programma di produzione. Questo livello richiede l'analisi del codice anziché il monitoraggio dei dati, rilevando le modifiche nel codice sorgente COBOL che costituiscono modifiche dello schema per i consumatori a valle.
Il monitoraggio programmato è più importante di quanto molti team credano. Le linee guida di Acceldata sull'analisi programmata delle derive raccomandano confronti automatici con una baseline stabile con cadenza settimanale o bisettimanale e sottolineano esplicitamente che attendere controlli ad hoc dopo un errore non è sufficiente. Nello specifico, per il monitoraggio dei limiti dei sistemi legacy, la cadenza dovrebbe corrispondere al programma di implementazione di COBOL: qualsiasi rilascio di un copybook in produzione dovrebbe attivare un'analisi immediata dell'impatto sullo schema, anziché attendere il successivo confronto programmato.
Come SMART TS XL Affronta il problema della deriva dello schema negli ambienti legacy
SMART TS XL Affronta la lacuna di rilevamento al confine del sistema legacy, ovvero il livello in cui si fermano i moderni strumenti di osservabilità e dove le derive di schema più pericolose rimangono inosservate.
La funzionalità di analisi statica del codice analizza ogni voce FD COBOL, membro COPY e clausola SELECT per produrre una rappresentazione strutturata di ogni artefatto dello schema nell'ambiente legacy. Quando questa analisi viene eseguita su due versioni del codebase, prima e dopo un'implementazione, le differenze costituiscono il registro delle modifiche dello schema legacy: quali copybook sono cambiati, quali definizioni di campo sono cambiate, quali erano i layout prima e dopo. Questo è il confronto dello snapshot dello schema applicato al livello COBOL.
La mappatura delle dipendenze delle applicazioni fornisce il registro dell'impatto sui consumatori per gli schemi legacy: quali programmi includono ciascun copybook, quali programmi producono quali dataset di file flat, quali job JCL richiamano quali programmi. Quando il registro delle modifiche dello schema identifica un copybook modificato, la mappa delle dipendenze genera immediatamente l'elenco dei consumatori, ovvero ogni programma che include il copybook e ogni file flat a valle prodotto da tali programmi. Questo è il calcolo del raggio d'azione che determina se una modifica al copybook è una modifica interna a basso rischio o un evento ad alto rischio che interessa centinaia di programmi e decine di consumatori a valle.
La funzionalità di analisi dell'impatto converte il raggio d'azione dell'esplosione in un ambito di bonifica strutturato: per ogni utente identificato dalla mappa delle dipendenze, quali modifiche sono necessarie per adattarsi al nuovo schema e in quale sequenza devono essere applicate? Per gli utenti che passano da sistemi legacy a moderni, ovvero le pipeline ETL che leggono file flat prodotti da programmi COBOL, l'analisi dell'impatto identifica le modifiche specifiche alla posizione dei campi e al tipo di dati che la configurazione di mappatura delle colonne della pipeline ETL deve essere aggiornata per riflettere.
La funzionalità di ricerca aziendale rende interrogabile l'individuazione degli artefatti dello schema: è possibile trovare ogni programma che legge un campo in una specifica posizione di byte (identificando i consumatori che saranno interessati da una modifica del layout), ogni copybook che definisce un campo specifico (identificando l'artefatto dello schema che deve essere versionato e sottoposto a controllo delle modifiche), ogni programma che produce output in un dataset specifico (identificando i produttori le cui modifiche allo schema devono attivare notifiche ai consumatori). Questa funzionalità di ricerca supporta sia il flusso di lavoro di governance proattiva dello schema sia l'indagine sugli incidenti successivi alla modifica.
Per le organizzazioni che gestiscono modernizzazione dell'eredità programmi che includono la migrazione dei dati mainframe verso piattaforme moderne, SMART TS XLL'analisi dello schema fornisce la documentazione dello schema sorgente richiesta dagli strumenti di migrazione, ovvero le definizioni complete e aggiornate delle voci FD e le strutture del copybook che definiscono cosa sono effettivamente i dati, non solo cosa erano quando è stata scritta la specifica di migrazione originale.
Il contratto che nessuno ha scritto è pur sempre un contratto
Il problema della deriva dello schema nei sistemi distribuiti non è nuovo. Si tratta di un problema di vecchia data, reso più difficile dalla risoluzione grazie all'architettura distribuita, che ha reso più complessa l'applicazione dei contratti di schema nei sistemi monolitici (l'amministratore di database centrale, il singolo team applicativo, la codebase unificata). Questa problematica è stata ora distribuita tra decine di servizi indipendenti, ognuno dei quali prende decisioni sensate individualmente, ma con una visibilità incompleta su tutti i consumatori a valle.
La soluzione non è ricentralizzare l'autorità sullo schema. È piuttosto rendere espliciti i contratti impliciti, registrarli in sistemi in grado di confrontare lo stato attuale con la baseline, applicare le regole di compatibilità ai confini in cui vengono introdotte le modifiche e monitorare le violazioni ai confini in cui le modifiche si propagano. Per i sistemi moderni, gli strumenti per questo scopo esistono e stanno migliorando rapidamente. Per i sistemi legacy al confine con le piattaforme moderne, il divario in termini di strumenti è reale e significativo: il formato di file flat che costituisce un contratto di schema per una pipeline ETL cloud è invisibile a qualsiasi strumento di osservabilità moderno, a meno che il codice sorgente COBOL che lo definisce non venga analizzato e versionato come artefatto di schema.
Il pannello di controllo che mostrava un calo del 23% nell'acquisizione di clienti non era errato nei dati ricevuti. Era errato nell'interpretazione dei dati, perché lo schema che definiva il significato dei dati era cambiato in un punto di confine in cui non era registrato alcun contratto e non era in funzione alcun sistema di monitoraggio. Quel confine, ovunque si trovi in un sistema distribuito, sia esso legacy o moderno, è il punto che i programmi di rilevamento delle derive di schema devono raggiungere.
