Un registro degli schemi è un servizio centralizzato che memorizza, gestisce e convalida gli schemi utilizzati per serializzare e deserializzare i dati scambiati tramite Apache Kafka. Anziché consentire a ciascuna applicazione produttrice e consumatrice di definire i formati dei messaggi in modo indipendente, un registro degli schemi fornisce una "fonte di verità" condivisa per la struttura dei dati degli eventi.
In Kafka, gli eventi vengono spesso serializzati utilizzando formati come Apache Avro, JSON Schema o Protocol Buffers, spesso abbreviati in protobuf. Il registro degli schemi memorizza le definizioni per questi formati e assegna a ogni schema un identificatore univoco. Questo viene chiamato ID dello schema.
Quando un produttore scrive un messaggio in un argomento Kafka, in genere include l'ID dello schema insieme ai dati serializzati anziché l'embedding dell'intero schema in ogni messaggio. I consumatori di messaggi recuperano quindi lo schema corrispondente dal registro e lo utilizzano per deserializzare e interpretare correttamente i dati.
Un registro degli schemi è importante in un sistema basato sugli eventi perché aiuta a garantire che produttori e consumatori concordino sulla struttura dei dati scambiati. Ciò supporta la qualità dei dati e l'integrità dei dati.
Senza un registro centralizzato, le applicazioni dovrebbero gestire gli schemi dei messaggi in modo indipendente. Ciò aumenta il rischio di modifiche incompatibili che potrebbero causare il fallimento degli event consumer o l'interpretazione errata dei dati.
Il registro degli schemi supporta anche la cosiddetta evoluzione degli schemi. Ciò consente agli sviluppatori di modificare le strutture degli eventi nel tempo mantenendo la compatibilità con le applicazioni esistenti.
Ad esempio, spesso è possibile aggiungere un nuovo campo opzionale senza modificare il formato previsto dai consumatori esistenti di Kafka. Le regole di compatibilità aiutano a imporre modifiche sicure dello schema prima che vengano distribuite.
Resta al passo con le tendenze più importanti e interessanti del settore relative ad AI, automazione, dati e oltre con la newsletter Think. Leggi l' Informativa sulla privacy IBM.
Un altro beneficio importante è il miglioramento della governance dei dati. Gli schemi sono memorizzati in un repository centrale, il che significa che le organizzazioni possono documentare, revisionare, versionare e verificare la struttura dei loro dati di evento.
Questo approccio facilita ai team di sviluppo le seguenti attività:
Nelle piattaforme di dati moderne, un registro degli schemi può anche consentire contratti di dati tra produttori di Kafka e consumatori di Kafka. Questi contratti definiscono non solo la struttura dei dati, ma anche le aspettative su come tali dati dovrebbero evolversi nel tempo.
Validando le modifiche agli schemi prima che vengano pubblicate, un registro degli schemi può aiutare a prevenire che modifiche in fase di rottura arrivino in produzione e migliorare l'affidabilità delle architetture basate su eventi.
Un registro di schemi fornisce un meccanismo centralizzato per la gestione degli schemi di eventi, applicando la compatibilità tra tali schemi e supportando le modifiche a tali schemi.
Un registro può anche consentire agli sviluppatori di creare nuovi schemi su quelli più vecchi, creando una composizione strutturata negli schemi e standardizzando i nomi degli eventi con una strategia di nome soggetto.
Questi metodi aiutano le applicazioni a scambiare dati man mano che sistemi e requisiti cambiano.
Un registro degli schemi funziona memorizzando e gestendo gli schemi che definiscono la struttura dei dati degli eventi scambiati tra produttori e consumatori. Quando un produttore invia dati a un argomento di Kafka, serializza il messaggio secondo uno schema registrato e include informazioni che permettono di identificare lo schema corrispondente. Un consumatore può quindi utilizzare quello schema per deserializzare e interpretare correttamente il messaggio. Man mano che gli schemi cambiano nel tempo, il registro può anche applicare controlli di compatibilità alle nuove versioni degli schemi prima che vengano registrate, aiutando produttori e consumatori a continuare a lavorare con strutture dati in evoluzione.
Immagina un grande rivenditore online che dispone di più sistemi che generano e consumano dati: un sito web di e-commerce, un'app mobile, un motore di raccomandazione, un sistema di gestione dell'inventario, una piattaforma di spedizione e una piattaforma di analisi dei clienti. Ognuno di questi sistemi comunica pubblicando e consumando eventi tramite cluster Apache Kafka utilizzando Confluent Cloud e trasmette tali eventi a un data warehouse tramite Kafka Connect nella sua pipeline dati.
Ogni azione sul sito web genera molteplici eventi nei sistemi del rivenditore. Ogni volta che un cliente effettua un ordine, il sito web pubblica un evento
Diverse applicazioni a valle utilizzano lo stesso evento. Il sistema di gestione dell'inventario riserva gli articoli acquistati, il sistema di pagamento conferma la transazione e il magazzino avvia l'evasione dell'ordine. Il motore di raccomandazione aggiorna le preferenze dei clienti, la piattaforma di analisi registra la vendita e il servizio di notifica invia una conferma via email.
Inizialmente, l'evento
Ora immagina che, mesi dopo, l'azienda decida di supportare le vendite internazionali. Gli sviluppatori aggiornano il sito web in modo che ogni ordine includa ora due nuovi campi:
Senza un registro degli schemi, non esiste un meccanismo centralizzato per coordinare questo cambiamento. Alcuni consumatori di dati sugli eventi si aspettano i nuovi campi, mentre altri no. Se uno sviluppatore rinomina accidentalmente
Quindi, come potrebbe apparire lo stesso scenario con un Confluent Schema Registry per aiutare nella gestione degli schemi?
Prima di distribuire il produttore aggiornato, il team di sviluppo registra una nuova versione dello schema
Se le modifiche proposte rispettano tali regole di compatibilità, la nuova versione dello schema può essere registrata. Se una modifica viola la politica di compatibilità configurata, il registro può rifiutarla prima che le applicazioni inizino a utilizzare lo schema incompatibile.
Ciò significa che gli sviluppatori possono scoprire una modifica sostanziale dello schema durante lo sviluppo anziché dopo la distribuzione. I consumatori esistenti possono continuare a utilizzare le applicazioni con modifiche compatibili, mentre i team di sviluppo possono aggiornare gradualmente le proprie applicazioni per utilizzare i nuovi campi quando saranno pronti.
I benefici di un registro degli schemi diventano più significativi con la crescita dell'azienda. Centinaia di applicazioni sviluppate da decine di team di ingegneri potrebbero scambiare dati attraverso migliaia di tipi di eventi diversi.
Senza un registro degli schemi, ogni team dovrebbe coordinare manualmente le modifiche agli schemi utilizzando documentazione scritta a mano, riunioni o tentativi ed errori. Questo processo manuale può rallentare lo sviluppo e aumentare la probabilità che cambiamenti incompatibili arrivino in produzione.
Con un registro degli schemi attivo, gli schemi eventi diventano asset gestiti centralmente. I produttori possono pubblicare dati secondo schemi registrati, i consumatori possono utilizzare tali definizioni di schema per interpretare gli eventi in arrivo e i controlli di compatibilità possono identificare modifiche allo schema incompatibili.
I nuovi team possono anche scoprire le definizioni degli eventi esistenti invece di decodificare i formati dei messaggi, semplificando la creazione di nuove applicazioni e l'integrazione di nuovi sistemi.
Man mano che il rivenditore si espande, il registro degli schemi fornisce un modo centralizzato per gestire gli schemi di eventi in evoluzione tra produttori e consumatori.
La compatibilità dello schema determina se le applicazioni che utilizzano versioni diverse di uno schema possono continuare a scambiare e interpretare correttamente i dati man mano che gli schemi si evolvono. Le principali modalità di compatibilità sono la retrocompatibilità, la compatibilità con le versioni successive e la piena compatibilità.
Alcuni registri di schema supportano anche le versioni transitive di queste modalità di compatibilità. Invece di confrontare una nuova versione dello schema solo con la versione immediatamente precedente, i controlli di compatibilità transitivi la confrontano con tutte le versioni precedenti pertinenti. Le regole esatte di compatibilità e le modifiche consentite dello schema dipendono dal formato dello schema e dalle impostazioni di compatibilità del registro.
La compatibilità futura è utile quando i produttori più vecchi devono continuare a operare, mentre i consumatori più recenti devono elaborare i dati provenienti da tali produttori più vecchi senza interruzioni. In questa situazione, la priorità è garantire che le applicazioni appena distribuite rimangano compatibili con i messaggi che vengono ancora generati da versioni più vecchie del software produttore.
Immagina una Utility nazionale che gestisce una rete intelligente. Questa rete è composta da milioni di contatori intelligenti installati in case e aziende. Ognuna di queste pubblica eventi di consumo elettrico per Apache Kafka. Questi contatori rimangono in servizio per anni e possono ricevere aggiornamenti firmware solo durante le finestre di manutenzione programmate. Ciò significa che molti contatori continuano a produrre eventi utilizzando uno schema più vecchio molto tempo dopo il rilascio delle versioni più recenti del software.
Nel frattempo, l'utility aggiorna regolarmente le sue applicazioni centrali di monitoraggio e analytics. Una nuova versione della piattaforma di analytics introduce il supporto per informazioni aggiuntive, come metriche sulla qualità dell'energia e generazione di energia rinnovabile. Questi nuovi campi sono utili quando disponibili, ma la piattaforma deve continuare a elaborare i dati provenienti dai contatori più vecchi che non li inviano.
In questo scenario, la compatibilità con le versioni successive è più importante della compatibilità con una versione precedente, poiché i consumatori vengono aggiornati per primi, mentre molti produttori continuano a utilizzare versioni precedenti dello schema. Il nuovo software consumer deve essere in grado di leggere correttamente gli eventi scritti con schemi più vecchi, anche se questi eventi non presentano i campi appena introdotti. L'applicazione può trattare i campi mancanti come facoltativi o assegnare valori predefiniti continuando a svolgere le sue funzioni primarie.
Se la compatibilità con le versioni precedenti fosse la preoccupazione principale, gli sviluppatori si concentrerebbero sul garantire che i nuovi utenti possano leggere i dati scritti con schemi di produzione più vecchi. Tuttavia, la sfida immediata dell'organizzazione è supportare una flotta di dispositivi più vecchi e allo stesso tempo modernizzare i sistemi di elaborazione centrale.
L'utilizzo di un registro degli schemi con regole di compatibilità appropriate consente all'utility di evolvere i propri schemi eventi senza richiedere aggiornamenti simultanei del firmware a milioni di contatori distribuiti. Ciò consente un'implementazione graduale in cui produttori e consumatori possono essere aggiornati in momenti diversi, pur rimanendo entro i requisiti di compatibilità configurati dall'organizzazione.
Un registro degli schemi può supportare gli sforzi di conformità che riguardano regolamenti sulla privacy dei dati come il General Data Protection Regulation (GDPR) e il California Consumer Privacy Act (CCPA).
Sebbene un registro degli schemi non garantisca di per sé la conformità, può aiutare le organizzazioni a implementare pratiche di governance dei dati, coerenza e audit necessarie per soddisfare i requisiti normativi.
Un vantaggio fondamentale è una migliore visibilità dei dati in elaborazione.
Ogni schema di eventi è memorizzato in un repository centralizzato, che documenta i campi rappresentati nello schema. Questa risorsa fornisce informazioni sui dati esistenti, sul significato dei singoli campi e su come le applicazioni strutturano i dati che producono o utilizzano.
Questo può aiutare le organizzazioni a identificare gli schemi che contengono informazioni di identificazione personale (PII), come nomi, indirizzi e-mail o numeri di conto.
Un registro di schema può anche supportare la minimizzazione dei dati, che è un principio del GDPR.
Prima che uno schema venga approvato, sviluppatori e team di governance dei dati possono verificare se ogni campo è necessario per lo scopo aziendale previsto. Questo processo di revisione può aiutare a prevenire che le applicazioni raccolgano o condividano informazioni personali non necessarie.
La validazione dello schema può anche aiutare a prevenire modifiche non autorizzate o accidentali che introducono nuovi dati sensibili nei sistemi di produzione.
Ad esempio, se uno sviluppatore tenta di aggiungere il numero di previdenza sociale o la patente di guida di un cliente a un evento Kafka esistente, lo schema proposto può essere esaminato prima della sua implementazione.
Questo approccio crea un ulteriore punto di controllo di governance, che si affianca ai normali test delle applicazioni.
Il versioning e la cronologia dello schema offrono funzionalità di audit.
Ogni evoluzione dello schema viene registrata, permettendo alle organizzazioni di determinare quando i campi sono stati aggiunti, modificati o rimossi.
Durante un audit di conformità, questa cronologia può aiutare a dimostrare che le strutture di dati sono gestite in modo controllato e tracciabile.
Un registro di schema può anche migliorare la coerenza tra più sistemi.
Poiché produttori e consumatori si affidano a definizioni di schema condivise, le applicazioni possono interpretare i campi secondo definizioni strutturali comuni.
Questo può ridurre la gestione incoerente dei dati tra le applicazioni.
Molte organizzazioni utilizzano un registro di schema come parte dell'implementazione dei contratti dati.
Questi contratti definiscono non solo la struttura di un evento, ma anche i metadati relativi ai dati in esso contenuti.
La convalida automatica può quindi essere utilizzata per verificare se le nuove versioni dello schema continuano a soddisfare i requisiti definiti.
I registri degli schemi possono anche integrarsi con strumenti più ampi di governance dei dati e di sicurezza.
I metadati memorizzati insieme agli schemi possono essere utilizzati da sistemi come:
Un registro degli schemi può quindi costituire un componente di un'architettura di governance più ampia.
In combinazione con la crittografia, i controlli degli accessi, le politiche di conservazione dei dati e la registrazione degli audit, la gestione degli schemi può aiutare le organizzazioni a gestire il modo in cui i dati personali vengono raccolti, elaborati e condivisi.
Diverse piattaforme forniscono funzionalità di registro degli schemi per Kafka e i relativi sistemi di dati.
Il registro degli schemi confluenti è un registro di schemi specifico per Kafka ampiamente utilizzato.
Fa parte del sistema Confluent ed è disponibile sia come componente autogestito di Confluent Platform, sia come servizio gestito in Confluent Cloud..
Supporta Avro, Protobuf e JSON Schema e fornisce il controllo delle versioni degli schemi, le regole di compatibilità, la convalida e l'integrazione con i produttori e i consumatori di Kafka.
Amazon Web Services fornisce l'AWS Glue Schema Registry.
Si tratta di un registro degli schemi gestito che si integra con Apache Kafka, Amazon Managed Streaming for Apache Kafka (MSK), Amazon Kinesis, Amazon Managed Service per Apache Flink e AWS Lambda.
Supporta Avro, JSON Schema e Protobuf.
Apicurio Registry è un registro open source di schemi e artefatti API utilizzabile con Kafka.
Supporta formati come Avro, JSON Schema e Protobuf e può essere distribuito in ambienti come Kubernetes.
Apicurio offre anche compatibilità con l'API Confluent Schema Registry, che può facilitarne l'uso con applicazioni Kafka progettate attorno alle interfacce schema-registro di Confluent.
Redpanda include anche un servizio compatibile con Schema Registry come parte della sua piattaforma di streaming compatibile con Kafka.
Questo approccio può essere utile quando un'organizzazione utilizza Redpanda anziché Apache Kafka direttamente, poiché la gestione dello schema può essere fornita come parte integrante della piattaforma di streaming stessa.
Il registro Redpanda è più strettamente integrato in una piattaforma di streaming alternativa compatibile con Kafka.
No, un registro degli schemi non fa parte del software principale Apache Kafka. Kafka memorizza e trasporta records. Un registro degli schemi è un servizio separato che memorizza e gestisce gli schemi per i dati contenuti in tali record. I registri di schemi sono comunemente utilizzati insieme a Kafka per aiutare produttori e consumatori a interpretare in modo coerente i dati strutturati degli eventi.
Un ID di schema è un identificatore per una particolare definizione di schema. Una versione dello schema indica dove appare quello schema nella sequenza di versioni gestite per un particolare schema o oggetto. L'implementazione esatta varia in base al registro. Nel Confluent Schema Registry, ad esempio, un ID di schema identifica in modo univoco lo schema nel registro, mentre la versione appartiene a un soggetto. Lo stesso schema può quindi avere lo stesso ID di schema pur essendo associato a versioni diverse sotto argomenti diversi.
Un registro degli schemi memorizza e gestisce principalmente schemi leggibili da macchina utilizzati dalle applicazioni per comprendere la struttura dei dati. Può anche fornire funzionalità come il versioning dello schema e i controlli di compatibilità.
Un catalogo dati ha un obiettivo più ampio, ovvero aiutare persone e sistemi a scoprire, comprendere e gestire gli asset dati all'interno di un'organizzazione. Un catalogo può contenere descrizioni aziendali, informazioni sulla proprietà, classificazioni e altri metadati su set di dati e sistemi di dati. I registri di schema e i cataloghi dati possono quindi completarsi a vicenda. Il registro gestisce gli schemi utilizzati dalle applicazioni, mentre il catalogo fornisce informazioni più ampie sugli asset di dati dell'organizzazione.
Uno schema definisce la struttura dei dati, includendo elementi come campi e tipi di dati. Un contratto dati può includere lo schema ma anche definire aspettative più ampie tra produttori e consumatori di dati. Uno schema potrebbe essere un componente di un contratto dati, insieme a vincoli di integrità, metadati e politiche.
Il registro degli schemi giusto dipende dai requisiti tecnici di un'organizzazione e dall'architettura dati esistente. I fattori da considerare includono i formati di schema supportati dal registro, le sue regole di compatibilità, l'integrazione con Apache Kafka e altri sistemi dati, il supporto API e client, le funzionalità di sicurezza e autenticazione, e se il servizio sia gestito o autogestito.
Le organizzazioni potrebbero anche considerare come il registro supporti l'evoluzione degli schemi, la governance dei dati, i metadati e i contratti dati, nonché la sua compatibilità con i produttori, i consumatori e le pipeline di dati esistenti. Diversi prodotti di registro offrono diverse combinazioni di queste funzionalità, quindi la selezione dipende generalmente dai sistemi e dai requisiti che il registro deve supportare.