Schemi Registri Controllo delle versioni e compatibilità degli schemi Librerie Serde open source Quote del registro degli schemi

AWS GlueRegistro degli schemi

Nota

AWS GlueSchema Registry non è supportato nelle seguenti regioni della AWS Glue console: Asia Pacifico (Giacarta) e Medio Oriente (UAE).

Il registro AWS Glue Schema consente di individuare, controllare ed evolvere centralmente gli schemi dei flussi di dati. Uno schema definisce la struttura e il formato di un registro di dati. Con il registro AWS Glue Schema, puoi gestire e applicare gli schemi sulle tue applicazioni di streaming di dati utilizzando comode integrazioni con Apache Kafka, Amazon Kinesis Amazon Managed Streaming for Apache KafkaData Streams, Amazon Managed Service for Apache Flink e. AWS Lambda

Il registro Schema supporta il formato dati AVRO (v1.10.2), il formato JSON dati con il formato JSON Schema per lo schema (specifiche Draft-04, Draft-06 e Draft-07) con la convalida JSON dello schema utilizzando la libreria Everit, le versioni Protocol Buffers (Protobuf) proto2 e proto3 senza supporto per extensions or groups e il supporto del linguaggio Java, con altri formati di dati e linguaggi a venire. Le funzionalità supportate includono compatibilità, approvvigionamento degli schemi tramite metadati, registrazione automatica degli schemi, IAM compatibilità e ZLIB compressione opzionale per ridurre l'archiviazione e il trasferimento dei dati. Il registro Schema è senza server e può essere utilizzato gratuitamente.

L'utilizzo di uno schema come contratto di formato dati tra produttori e consumer comporta una migliore governance dei dati, dati di qualità superiore e consente ai consumer di dati di essere resilienti alle modifiche upstream compatibili.

Il registro Schema consente a diversi sistemi di condividere uno schema per la serializzazione e la deserializzazione. Ad esempio, si supponga di avere un produttore e un consumer di dati. Il produttore conosce lo schema quando pubblica i dati. Lo Schema Registry fornisce un serializzatore e un deserializzatore per determinati sistemi come Amazon o Apache Kafka. MSK

Per ulteriori informazioni, consulta Come funziona il registro degli schemi.

Argomenti

Schemi

Uno schema definisce la struttura e il formato di un registro di dati. Uno schema è una specifica con versioni per la pubblicazione, il consumo o l'archiviazione dei dati in modo affidabile.

In questo schema di esempio per Avro, il formato e la struttura sono definiti dal layout e dai nomi dei campi e il formato dei nomi dei campi è definito dai tipi di dati (ad esempio, string, int).


{
    "type": "record",
    "namespace": "ABC_Organization",
    "name": "Employee",
    "fields": [
        {
            "name": "Name",
            "type": "string"
        },
        {
            "name": "Age",
            "type": "int"
        },
        {
            "name": "address",
            "type": {
                "type": "record",
                "name": "addressRecord",
                "fields": [
                    {
                        "name": "street",
                        "type": "string"
                    },
                    {
                        "name": "zipcode",
                        "type": "int" 
                    }
                ]
            }
        }
    ]
}

In questo esempio, JSON schema draft-07 per, il formato è definito dall'organizzazione Schema. JSON JSON


{
	"$id": "https://example.com/person.schema.json",
	"$schema": "http://json-schema.org/draft-07/schema#",
	"title": "Person",
	"type": "object",
	"properties": {
		"firstName": {
			"type": "string",
			"description": "The person's first name."
		},
		"lastName": {
			"type": "string",
			"description": "The person's last name."
		},
		"age": {
			"description": "Age in years which must be equal to or greater than zero.",
			"type": "integer",
			"minimum": 0
		}
	}
}

In questo esempio per Protobuf, il formato è definito dalla versione 2 del linguaggio Protocol Buffers (proto2).


syntax = "proto2";

package tutorial;

option java_multiple_files = true;
option java_package = "com.example.tutorial.protos";
option java_outer_classname = "AddressBookProtos";

message Person {
  optional string name = 1;
  optional int32 id = 2;
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    optional string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }

  repeated PhoneNumber phones = 4;
}

message AddressBook {
  repeated Person people = 1;
}

Registri

Un registro è un container logico di schemi. I registri consentono di organizzare gli schemi e gestire il controllo degli accessi per le applicazioni. Un registro dispone di un Amazon Resource Name (ARN) che consente di organizzare e impostare diverse autorizzazioni di accesso alle operazioni dello schema all'interno del registro.

È possibile utilizzare il registro di default o creare tutti i nuovi registri necessari.

Gerarchia del registro degli schemi di AWS Glue
RegistryName: [stringa] RegistryArn: [AWS ARN] CreatedTime: [timestamp] UpdatedTime: [timestamp]
SchemaName: [stringa] SchemaArn: [AWS ARN] DataFormat: [Avro, Json o Protobuf] Compatibility: (ad es. BACKWARD, BACKWARD _ALL, _FORWARD, FORWARD _ALL,FULL,] FULL ALL NONE DISABLED Status: [ad es. PENDING,AVAILABLE,DELETING] SchemaCheckpoint: [numero intero] CreatedTime: [timestamp] UpdatedTime: [timestamp]
SchemaVersion: [stringa] SchemaVersionNumber: [numero intero] Status: [ad es. PENDING,AVAILABLE,DELETING,] FAILURE SchemaDefinition: [stringa, Valore:JSON] CreatedTime: [timestamp]
SchemaVersionMetadata: [elenco] MetadataKey: [stringa] MetadataInfo MetadataValue: [stringa] CreatedTime: [timestamp]

Controllo delle versioni e compatibilità degli schemi

Ogni schema può avere più versioni. Il controllo delle versioni è regolato da una regola di compatibilità applicata a uno schema. Le richieste di registrazione di nuove versioni dello schema vengono verificate in base a questa regola dal registro degli schemi prima che possano avere esito positivo.

Una versione dello schema contrassegnata come checkpoint viene utilizzata per determinare la compatibilità della registrazione di nuove versioni di uno schema. Quando uno schema viene creato per la prima volta, il checkpoint di default sarà la prima versione. Man mano che lo schema si evolve con più versioni, è possibile utilizzareCLI/SDKper modificare il checkpoint in una versione di uno schema UpdateSchema API che rispetti una serie di vincoli. Nella console, la modifica della definizione dello schema o della modalità di compatibilità modificherà il checkpoint alla versione più recente per impostazione predefinita.

Le modalità di compatibilità consentono di controllare come gli schemi possono o non possono evolvere nel tempo. Queste modalità costituiscono il contratto tra le applicazioni che producono e consumano dati. Quando una nuova versione di uno schema viene inviata al registro, la regola di compatibilità applicata al nome dello schema viene utilizzata per determinare se la nuova versione può essere accettata. Sono disponibili 8 modalità di compatibilità:NONE,,,DISABLED, BACKWARD _BACKWARD, _ ALLFORWARD, FORWARD _. ALL FULL FULL ALL

Nel formato dati Avro, i campi possono essere facoltativi o obbligatori. Un campo facoltativo è un campo in cui il Type include null. I campi obbligatori non contengono il valore null come Type.

Nel formato dati Protobuf, i campi possono essere facoltativi (anche ripetuti) o obbligatori nella sintassi proto2, mentre tutti i campi sono facoltativi (anche ripetuti) nella sintassi proto3. Tutte le regole di compatibilità sono determinate in base alla comprensione delle specifiche di Protocol Buffers e dalle linee guida della Documentazione Google Protocol Buffers.

NONE: non si applica alcuna modalità di compatibilità. È possibile utilizzare questa opzione negli scenari di sviluppo o se non si conoscono le modalità di compatibilità da applicare agli schemi. Qualsiasi nuova versione aggiunta sarà accettata senza essere sottoposta a un controllo di compatibilità.
DISABLED: questa scelta di compatibilità impedisce il controllo delle versioni per uno schema particolare. Non è possibile aggiungere nuove versioni.
BACKWARD: Questa scelta di compatibilità è consigliata perché consente agli utenti di leggere sia la versione corrente che quella precedente dello schema. È possibile utilizzare questa opzione per verificare la compatibilità con la versione precedente dello schema quando si eliminano campi o si aggiungono campi facoltativi. Un caso d'uso tipico BACKWARD è quando l'applicazione è stata creata per lo schema più recente.

AVRO

Ad esempio, si supponga di avere uno schema definito da nome (obbligatorio), cognome (obbligatorio), e-mail (obbligatorio) e numero di telefono (facoltativo).

Se la versione successiva dello schema rimuove il campo e-mail obbligatorio, questa operazione verrebbe registrata correttamente. BACKWARDla compatibilità richiede che i consumatori siano in grado di leggere la versione corrente e precedente dello schema. I consumer potranno leggere il nuovo schema in quanto il campo dell'e-mail in più viene ignorato dai vecchi messaggi.

Se viene proposta una nuova versione dello schema che aggiunge un campo obbligatorio, ad esempio il codice postale, questa non verrebbe registrata correttamente ai fini della BACKWARD compatibilità. I consumer della nuova versione non sarebbero in grado di leggere i messaggi precedenti alla modifica dello schema, poiché mancherebbe il campo obbligatorio del codice postale. Tuttavia, se il campo del codice postale è impostato come facoltativo nel nuovo schema, la versione proposta viene registrata correttamente poiché i consumer sono in grado di leggere il vecchio schema senza il campo facoltativo del codice postale.

JSON

Ad esempio, si supponga di avere una versione dello schema definita da nome (facoltativo), cognome (facoltativo), e-mail (facoltativa) e numero di telefono (facoltativo).

Se nella versione successiva dello schema viene aggiunta la proprietà facoltativa del numero di telefono, la registrazione viene eseguita correttamente, a condizione che la versione originale dello schema non consenta proprietà aggiuntive impostando il campo additionalProperties su false. BACKWARDla compatibilità richiede che i consumatori siano in grado di leggere la versione corrente e precedente dello schema. I consumer saranno in grado di leggere i dati prodotti con lo schema originale in cui la proprietà numero di telefono non esiste.

Se è stata proposta una nuova versione dello schema che aggiunge la proprietà opzionale del numero di telefono, questa non verrebbe registrata correttamente ai fini della BACKWARD compatibilità se la versione originale dello schema impostava il additionalProperties campo su true, ossia consentiva qualsiasi proprietà aggiuntiva. I consumer della nuova versione non sarebbero in grado di leggere i messaggi precedenti alla modifica dello schema, in quanto non possono leggere i dati con la proprietà numero di telefono in un tipo differente, ad esempio come stringa anziché numero.

PROTOBUF

Ad esempio, supponiamo di avere una versione di uno schema definito da un messaggio Person con i campi first name (obbligatorio), last name (obbligatorio), email (obbligatorio), e phone number (facoltativo) sotto la sintassi proto2.

Analogamente agli AVRO scenari, se la versione successiva dello schema rimuovesse il email campo richiesto, la registrazione avverrà correttamente. BACKWARDla compatibilità richiede che i consumatori siano in grado di leggere la versione corrente e precedente dello schema. I consumer potranno leggere il nuovo schema in quanto il campo email in più viene ignorato dai vecchi messaggi.

Se è stata proposta una nuova versione dello schema che aggiunge un campo obbligatorio, ad esempiozip code, questa non verrebbe registrata correttamente con BACKWARD compatibilità. I consumer della nuova versione non sarebbero in grado di leggere i messaggi precedenti alla modifica dello schema, poiché mancherebbe il campo obbligatorio zip code. Tuttavia, se il campo zip code è impostato come facoltativo nel nuovo schema, la versione proposta viene registrata correttamente poiché i consumer sono in grado di leggere il vecchio schema senza il campo facoltativo zip code.

Nel caso di RPC utilizzo g, l'aggiunta di un nuovo RPC servizio o RPC metodo è una modifica compatibile con le versioni precedenti. Ad esempio, supponiamo di avere una versione dello schema definita da un RPC servizio MyService con due RPC metodi Foo eBar.

Se la prossima versione dello schema aggiungesse un nuovo RPC metodo chiamatoBaz, questo verrebbe registrato correttamente. I tuoi consumatori saranno in grado di leggere i dati prodotti con lo schema originale in base alla BACKWARD compatibilità poiché il RPC metodo appena aggiunto Baz è facoltativo.

Se è stata proposta una nuova versione dello schema che rimuove il RPC metodo esistenteFoo, questa non verrebbe registrata correttamente con la BACKWARD compatibilità. Gli utenti della nuova versione non sarebbero in grado di leggere i vecchi messaggi prima della modifica dello schema, poiché non possono comprendere e leggere i dati con il RPC metodo inesistente Foo in un'applicazione gRPC.
BACKWARD_ ALL: Questa scelta di compatibilità consente ai consumatori di leggere sia la versione corrente che tutte le versioni precedenti dello schema. È possibile utilizzare questa opzione per verificare la compatibilità con tutte le versioni precedenti dello schema quando si eliminano campi o si aggiungono campi facoltativi.
FORWARD: Questa scelta di compatibilità consente ai consumatori di leggere sia la versione corrente che quella successiva dello schema, ma non necessariamente le versioni successive. È possibile utilizzare questa opzione per verificare la compatibilità con l'ultima versione dello schema quando si aggiungono campi o si eliminano campi facoltativi. Un tipico caso d'uso FORWARD è quando l'applicazione è stata creata per uno schema precedente e dovrebbe essere in grado di elaborare uno schema più recente.

AVRO

Ad esempio, si supponga di avere una versione di uno schema definito da nome (obbligatorio), cognome (obbligatorio), e-mail (facoltativo).

Se si dispone di una nuova versione dello schema che aggiunge un campo obbligatorio, ad esempio il numero di telefono, la registrazione viene eseguita correttamente. FORWARDla compatibilità richiede che i consumatori siano in grado di leggere i dati prodotti con il nuovo schema utilizzando la versione precedente.

Se è stata proposta una versione dello schema che elimina il campo del nome richiesto, questa non verrebbe registrata correttamente ai fini della FORWARD compatibilità. I consumatori della versione precedente non sarebbero in grado di leggere gli schemi proposti in quanto mancherebbe il campo obbligatorio del nome. Tuttavia, se il campo del nome era originariamente facoltativo, il nuovo schema proposto verrebbe registrato correttamente poiché i consumatori potrebbero leggere i dati in base al nuovo schema che non dispone del campo facoltativo del nome.

JSON

Ad esempio, si supponga di avere una versione dello schema definita da nome (facoltativo), cognome (facoltativo), e-mail (facoltativa) e numero di telefono (facoltativo).

Se si dispone di una nuova versione dello schema in cui viene rimossa la proprietà facoltativa del numero di telefono, la registrazione viene eseguita correttamente, a condizione che la nuova versione dello schema non consenta proprietà aggiuntive impostando il campo additionalProperties su false. FORWARDla compatibilità richiede che i consumatori siano in grado di leggere i dati prodotti con il nuovo schema utilizzando la versione precedente.

Se è stata proposta una versione dello schema che elimina la proprietà opzionale del numero di telefono, questa non verrebbe registrata correttamente ai fini della FORWARD compatibilità quando la nuova versione dello schema imposta il additionalProperties campo su true, vale a dire consente qualsiasi proprietà aggiuntiva. I consumer della versione precedente non sarebbero in grado di leggere lo schema proposto, in quanto potrebbero disporre della proprietà numero di telefono in un tipo differente, ad esempio come stringa anziché numero.

PROTOBUF

Ad esempio, supponiamo di avere una versione di uno schema definito da un messaggio Person con i campi first name (obbligatorio), last name (obbligatorio), email (facoltativo) sotto la sintassi proto2.

Analogamente agli AVRO scenari, se si dispone di una nuova versione dello schema che aggiunge un campo obbligatorio, ad esempiophone number, questa verrà registrata correttamente. FORWARDla compatibilità richiede che i consumatori siano in grado di leggere i dati prodotti con il nuovo schema utilizzando la versione precedente.

Se è stata proposta una versione dello schema che elimina il first name campo richiesto, questa non verrebbe registrata correttamente con la FORWARD compatibilità. I consumatori della versione precedente non sarebbero in grado di leggere gli schemi proposti in quanto mancherebbe il campo obbligatorio first name. Tuttavia, se il campo first name era originariamente facoltativo, il nuovo schema proposto verrebbe registrato correttamente poiché i consumer potrebbero leggere i dati in base al nuovo schema che non dispone del campo facoltativo first name.

Nel caso di RPC utilizzo g, la rimozione di un RPC servizio o di un RPC metodo è una modifica compatibile con le versioni precedenti. Ad esempio, supponiamo di avere una versione dello schema definita da un RPC servizio MyService con due RPC metodi e. Foo Bar

Se la prossima versione dello schema eliminasse il RPC metodo esistente denominatoFoo, ciò verrebbe registrato correttamente in base alla FORWARD compatibilità, poiché i consumatori possono leggere i dati prodotti con il nuovo schema utilizzando la versione precedente. Se è stata proposta una nuova versione dello schema che aggiunge un RPC metodoBaz, questa non verrebbe registrata correttamente in termini di FORWARD compatibilità. Gli utenti della versione precedente non sarebbero in grado di leggere gli schemi proposti poiché non dispongono del RPC metodoBaz.
FORWARD_ ALL: Questa scelta di compatibilità consente ai consumatori di leggere i dati scritti dai produttori di qualsiasi nuovo schema registrato. È possibile utilizzare questa opzione quando è necessario aggiungere campi o eliminare campi facoltativi e verificare la compatibilità con tutte le versioni precedenti dello schema.
FULL: Questa scelta di compatibilità consente ai consumatori di leggere i dati scritti dai produttori utilizzando la versione precedente o successiva dello schema, ma non le versioni precedenti o successive. È possibile utilizzare questa opzione per verificare la compatibilità con l'ultima versione dello schema quando si aggiungono o si eliminano campi facoltativi.
FULL_ ALL: Questa scelta di compatibilità consente ai consumatori di leggere i dati scritti dai produttori utilizzando tutte le versioni precedenti dello schema. È possibile utilizzare questa opzione per verificare la compatibilità con tutte le versioni precedenti dello schema quando si aggiungono o si eliminano campi facoltativi.

Librerie Serde open source

AWS fornisce librerie Serde open source come framework per la serializzazione e la deserializzazione dei dati. La progettazione open source di queste librerie permette alle applicazioni e ai framework open source comuni di supportare queste librerie nei loro progetti.

Per ulteriori dettagli sul funzionamento delle librerie Serde, consulta Come funziona il registro degli schemi.

Quote del registro degli schemi

Le quote, note anche come limiti in, sono i valori massimi per le risorse AWS, le azioni e gli elementi presenti nell'account. AWS Di seguito sono riportati i limiti flessibili per il registro degli schemi di AWS Glue.

Coppia chiave-valore dei metadati della versione dello schema

Puoi avere fino a 10 coppie chiave-valore per regione. SchemaVersion AWS

È possibile visualizzare o impostare le coppie di metadati chiave-valore utilizzando o. QuerySchemaVersionMetadata azione (Python: query_schema_version_metadata) PutSchemaVersionMetadata azione (Python: put_schema_version_metadata) APIs

Di seguito sono riportati i limiti rigidi per il registro degli schemi di AWS Glue.

Registri

Puoi avere fino a 100 registri per regione per AWS questo account.

SchemaVersion

Puoi avere fino a 10000 versioni dello schema per AWS regione per questo account.

Ogni nuovo schema crea una nuova versione dello schema, quindi in teoria puoi avere fino a 10000 schemi per account per regione, se ogni schema ha una sola versione.

Payload dello schema

Esiste un limite di dimensioni pari a 170 KB per i payload dello schema.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Le migliori pratiche di Data Catalog

Come funziona

AWS GlueRegistro degli schemi

Nota

Argomenti

Schemi

Registri

Controllo delle versioni e compatibilità degli schemi

AVRO

JSON

PROTOBUF

AVRO

JSON

PROTOBUF

Librerie Serde open source

Quote del registro degli schemi

Coppia chiave-valore dei metadati della versione dello schema

Registri

SchemaVersion

Payload dello schema