Esquemas Registros Versionamento e compatibilidade de esquema Bibliotecas Serde de código aberto Cotas do registro do esquemas

Registro de esquemas do AWS Glue

nota

O registro de esquemas do AWS Glue não é compatível com o console do AWS Glue nas seguintes regiões: Ásia-Pacífico (Jacarta) e Oriente Médio (EAU).

Com o registro de esquemas do AWS Glue, você pode descobrir, controlar e evoluir centralmente esquemas de fluxo de dados. O esquema define a estrutura e o formato de um registro de dados. Com o registro de esquemas do AWS Glue, você pode gerenciar e aplicar esquemas em suas aplicações de fluxo de dados usando integrações convenientes com o Apache Kafka, Amazon Managed Streaming for Apache Kafka, Amazon Kinesis Data Streams, Amazon Managed Service for Apache Flink e AWS Lambda.

O registro de esquemas oferece suporte ao formato de dados AVRO (v1.10.2), ao formato de dados JSON com formato de esquema JSON para o esquema (especificações Draft-04, Draft-06 e Draft-07) com validação do esquema JSON usando a biblioteca Everit,Protocol Buffers (Protobuf) versões proto2 e proto3 sem suporte a extensions ou groups e suporte à linguagem Java, com outros formatos de dados e linguagens por vir. Os recursos com suporte incluem compatibilidade, fornecimento de esquema via metadados, registro automático de esquemas, compatibilidade com o IAM e compactação ZLIB opcional para reduzir o armazenamento e a transferência de dados. O registro de esquemas do O registro de esquemas é uma solução sem servidor e de uso gratuito.

O uso de um esquema como um contrato de formato de dados entre produtores e consumidores leva a uma melhor governança e maior qualidade dos dados, e ainda permite que os consumidores de dados sejam resilientes a alterações upstream compatíveis.

O registro de esquemas permite que sistemas diferentes compartilhem um esquema para serialização e desserialização. Por exemplo, suponha que você tenha um produtor e consumidor de dados. O produtor conhece o esquema quando publica os dados. O registro de esquemas fornece um serializador e desserializador para determinados sistemas, como Amazon MSK ou Apache Kafka.

Para ter mais informações, consulte Como o registro de esquemas funciona.

Tópicos

Esquemas

O esquema define a estrutura e o formato de um registro de dados. Um esquema é uma especificação versionada para publicação, consumo ou datastore confiáveis.

Neste esquema de exemplo para Avro, o formato e a estrutura são definidos pelo layout e nomes de campo, e o formato dos nomes de campo é definido pelos tipos de dados (por exemplo,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" 
                    }
                ]
            }
        }
    ]
}

Neste exemplo de esquema JSON Draft-07 para JSON, o formato é definido pela organização do esquema 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
		}
	}
}

Neste exemplo para Protobuf, o formato é definido pela versão 2 da linguagem 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;
}

Registros

Um registro é um contêiner lógico de esquemas. Os registros permitem que você organize seus esquemas, bem como gerencie o controle de acesso para suas aplicações. Um registro tem um nome do recurso da Amazon (ARN) para permitir que você organize e defina diferentes permissões de acesso para operações de esquema dentro do registro.

Você pode usar o registro padrão ou criar quantos novos registros forem necessários.

Hierarquia do registro de esquemas do AWS Glue
RegistryName: [string] RegistryArn: [ARN da AWS] CreatedTime: [carimbo de data e hora] UpdatedTime: [carimbo de data e hora]
SchemaName: [string] SchemaArn: [ARN da AWS] DataFormat: [Avro, Json ou Protobuf] Compatibility: [ex.: BACKWARD, BACKWARD_ALL, FORWARD, FORWARD_ALL, FULL, FULL_ALL, NONE, DISABLED] Status: [ex.: PENDING, AVAILABLE, DELETING] SchemaCheckpoint: [inteiro] CreatedTime: [carimbo de data e hora] UpdatedTime: [carimbo de data e hora]
SchemaVersion: [string] SchemaVersionNumber: [inteiro] Status: [ex.: PENDING, AVAILABLE, DELETING, FAILURE] SchemaDefinition: [string, Valor: JSON] CreatedTime: [carimbo de data e hora]
SchemaVersionMetadata: [lista] MetadataKey: [string] MetadataInfo MetadaValue: [string] CreatedTime: [carimbo de data e hora]

Versionamento e compatibilidade de esquema

Cada esquema pode ter várias versões. O versionamento é regido por uma regra de compatibilidade aplicada em um esquema. As solicitações para registrar novas versões do esquema são verificadas quanto a essa regra pelo registro de esquemas antes de serem bem-sucedidas.

Uma versão de esquema que está marcada como um ponto de verificação é usada para determinar a compatibilidade em registrar novas versões de um esquema. Quando um esquema é criado pela primeira vez, o ponto de verificação padrão é a primeira versão. À medida que o esquema evolui com mais versões, você pode usar a CLI/SDK para alterar o ponto de verificação para uma versão de um esquema usando a API UpdateSchema que adere a um conjunto de restrições. No console, editar a definição do esquema ou o modo de compatibilidade alterará o ponto de verificação para a versão mais recente por padrão.

Os modos de compatibilidade permitem controlar como os esquemas podem ou não evoluir ao longo do tempo. Esses modos formam o contrato entre aplicações que produzem e consomem dados. Quando uma nova versão de um esquema é enviada para o registro, a regra de compatibilidade aplicada ao nome do esquema é usada para determinar se a nova versão pode ser aceita. Existem oito modos de compatibilidade: NONE (Nenhum), DISABLED (Desabilitado), BACKWARD (Anterior), BACKWARD_ALL (Todas as anteriores), FORWARD (Próxima), FORWARD_ALL (Todas as próximas), FULL (Completo), FULL_ALL (Completo total).

No formato de dados Avro, os campos podem ser opcionais ou obrigatórios. Um campo opcional é aquele em que o Type inclui nulo. Campos obrigatórios não possuem nulo como o Type.

No formato de dados Protobuf, os campos podem ser opcionais (inclusive repetidos) ou obrigatórios na sintaxe proto2, enquanto todos os campos são opcionais (inclusive repetidos) na sintaxe proto3. Todas as regras de compatibilidade são determinadas com base no entendimento das especificações de Protocol Buffers, bem como na orientação da Documentação do Google Protocol Buffers.

NONE (Nenhum): nenhum modo de compatibilidade se aplica. Você pode usar essa opção em cenários de desenvolvimento ou se não souber os modos de compatibilidade que deseja aplicar aos esquemas. Qualquer nova versão adicionada será aceita sem ser submetida a uma verificação de compatibilidade.
DISABLED (Desabilitado): essa opção de compatibilidade impede o versionamento de um esquema específico. Nenhuma nova versão pode ser adicionada.
BACKWARD (Anterior): essa opção de compatibilidade é recomendada, pois permite que os consumidores de dados leiam a versão atual e anterior do esquema. Você pode usar essa opção para verificar a compatibilidade com a versão anterior do esquema ao excluir campos ou adicionar campos opcionais. Um caso de uso típico para BACKWARD (Anterior) é quando sua aplicação é criada para o esquema mais recente.

AVRO

Por exemplo, suponha que você tenha um esquema definido pelo nome (obrigatório), sobrenome (obrigatório), e-mail (obrigatório) e número de telefone (opcional).

Se a próxima versão do esquema removesse o campo de e-mail obrigatório, isso seria registrado com êxito. A compatibilidade BACKWARD (Anterior) requer que os consumidores sejam capazes de ler a versão atual e anterior do esquema. Seus consumidores poderão ler o novo esquema, pois o campo de e-mail extra de mensagens antigas será ignorado.

Se você tivesse uma nova versão de esquema proposta que adicionasse um campo obrigatório, por exemplo, CEP, isso não seria registrado com êxito com a compatibilidade BACKWARD (Anterior). Seus consumidores na nova versão não conseguiriam ler mensagens antigas antes da alteração do esquema, pois elas não teriam o campo CEP necessário. No entanto, se o campo CEP fosse definido como opcional no novo esquema, a versão proposta seria registrada com sucesso, pois os consumidores poderiam ler o esquema antigo sem o campo de CEP opcional.

JSON

Por exemplo, suponha que você tenha uma versão do esquema definida pelo nome (opcional), sobrenome (opcional), e-mail (opcional) e número de telefone (opcional).

Se a próxima versão do esquema adicionasse a propriedade de número de telefone opcional, isso seria registrado com êxito, desde que a versão do esquema original não permitisse nenhuma propriedade adicional definindo o campo additionalProperties como false. A compatibilidade BACKWARD (Anterior) requer que os consumidores sejam capazes de ler a versão atual e anterior do esquema. Seus consumidores poderão ler dados produzidos com o esquema original onde a propriedade de número de telefone não existe.

Se você tiver uma nova versão de esquema proposta que adiciona a propriedade de número de telefone opcional, isso não é registrado com êxito com a compatibilidade BACKWARD (Anterior) quando a versão original do esquema define o campo additionalProperties como true, ou seja, permitindo qualquer propriedade adicional. Seus consumidores na nova versão não conseguiriam ler mensagens antigas antes da alteração do esquema, pois não podem ler dados com a propriedade número de telefone em um tipo diferente, por exemplo string em vez de número.

PROTOBUF

Por exemplo, suponha que você tenha uma versão do esquema definida por uma Mensagem Person com campos first name (obrigatório), last name (obrigatório), email (obrigatório) e phone number (opcional) sob sintaxe proto2.

Semelhante a cenários AVRO, se a próxima versão do esquema removesse o campo de email obrigatório, isso seria registrado com êxito. A compatibilidade BACKWARD (Anterior) requer que os consumidores sejam capazes de ler a versão atual e anterior do esquema. Seus consumidores poderão ler o novo esquema, pois o campo de email extra de mensagens antigas será ignorado.

Se você tivesse uma nova versão de esquema proposta que adicionasse um campo obrigatório, por exemplo, zip code, isso não seria registrado com êxito com a compatibilidade BACKWARD (Anterior). Seus consumidores na nova versão não conseguiriam ler mensagens antigas antes da alteração do esquema, pois elas não teriam o campo zip code necessário. No entanto, se o campo zip code fosse definido como opcional no novo esquema, a versão proposta seria registrada com sucesso, pois os consumidores poderiam ler o esquema antigo sem o campo de zip code opcional.

No caso de um caso de uso gRPC, adicionar novo serviço RPC ou método RPC é uma alteração compatível com versões anteriores. Por exemplo, suponha que você tenha uma versão do esquema definida por um serviço RPC MyService com dois métodos RPC Foo e Bar.

Se a próxima versão do esquema adicionar um novo método RPC chamado Baz, isso seria registrado com sucesso. Seus consumidores poderão ler dados produzidos com o esquema original de acordo com a compatibilidade BACKWARD pois o método RPC recém-adicionado Baz é opcional.

Se você tivesse uma nova versão de esquema proposta que removesse o método PRC existente Foo, isso não seria registrado com êxito com a compatibilidade BACKWARD. Seus consumidores na nova versão não conseguiriam ler mensagens antigas antes da alteração do esquema, pois não conseguem entender e ler dados com o método RPC Foo inexistente em uma aplicação gRPC.
BACKWARD_ALL (Todas as anteriores): essa opção de compatibilidade é recomendada, pois permite que os consumidores de dados leiam a versão atual e todas as anteriores do esquema. Você pode usar essa opção para verificar a compatibilidade com todas as versões anteriores do esquema ao excluir campos ou adicionar campos opcionais.
FORWARD (Próxima): essa opção de compatibilidade permite que os receptores de dados leiam a versão atual e as versões subsequentes do esquema, mas não necessariamente versões mais recentes. Você pode usar essa opção para verificar a compatibilidade com a última versão do esquema ao adicionar campos ou excluir campos opcionais. Um caso de uso típico para FORWARD (Próxima) é quando sua aplicação é criada para um esquema anterior e deve ser capaz de processar um esquema mais recente.

AVRO

Por exemplo, suponha que você tenha uma versão do esquema definida pelo nome (obrigatório), sobrenome (obrigatório) e e-mail (opcional).

Se você tivesse uma nova versão do esquema que adicionasse um campo obrigatório, por exemplo, número de telefone, isso seria registrado com sucesso. A compatibilidade FORWARD (Próxima) requer que os consumidores sejam capazes de ler dados produzidos com o novo esquema usando ainda a versão anterior.

Se você tivesse uma nova versão de esquema proposta que excluísse o campo de nome obrigatório, isso não seria registrado com êxito com a compatibilidade FORWARD (Posterior). Seus consumidores na versão anterior não seriam capazes de ler os esquemas propostos, pois eles não teriam o campo de nome obrigatório. No entanto, se o campo de nome fosse originalmente opcional, então o novo esquema proposto seria registrado com sucesso, pois os consumidores poderiam ler dados com base no novo esquema que não tem o campo de nome opcional.

JSON

Por exemplo, suponha que você tenha uma versão do esquema definida pelo nome (opcional), sobrenome (opcional), e-mail (opcional) e número de telefone (opcional).

Se a próxima versão do esquema removesse a propriedade de número de telefone opcional, isso seria registrado com êxito, desde que a versão do esquema original não permitisse nenhuma propriedade adicional definindo o campo additionalProperties como false. A compatibilidade FORWARD (Próxima) requer que os consumidores sejam capazes de ler dados produzidos com o novo esquema usando ainda a versão anterior.

Se você tiver uma versão de esquema proposta que exclui a propriedade número de telefone opcional, isso não é registrado com êxito com a compatibilidade FORWARD (Próxima) quando a nova versão do esquema define o campo additionalProperties como true, ou seja, permitindo qualquer propriedade adicional. Seus consumidores na versão anterior não conseguiriam ler mensagens antigas antes da alteração do esquema, pois não poderiam ler dados com a propriedade número de telefone em um tipo diferente, por exemplo string em vez de número.

PROTOBUF

Por exemplo, suponha que você tenha uma versão do esquema definida por uma Mensagem Person com campos first name (obrigatório), last name (obrigatório) e email (opcional) sob sintaxe proto2.

Semelhante a cenários AVRO, se você tivesse uma nova versão do esquema que adicionasse um campo obrigatório, por exemplo, phone number, isso seria registrado com sucesso. A compatibilidade FORWARD (Próxima) requer que os consumidores sejam capazes de ler dados produzidos com o novo esquema usando ainda a versão anterior.

Se você tivesse uma nova versão de esquema proposta que excluísse o campo de first name, isso não seria registrado com êxito com a compatibilidade FORWARD. Seus consumidores na versão anterior não seriam capazes de ler os esquemas propostos, pois eles não teriam o campo de first name obrigatório. No entanto, se o campo de first name fosse originalmente opcional, então o novo esquema proposto seria registrado com sucesso, pois os consumidores poderiam ler dados com base no novo esquema que não tem o campo de first name opcional.

No caso de um caso de uso gRPC, remover um serviço RPC ou método RPC é uma alteração compatível com o encaminhamento. Por exemplo, suponha que você tenha uma versão do esquema definida por um serviço RPC MyService com dois métodos RPC Foo e Bar.

Se a próxima versão do esquema excluir o método RPC existente chamado Foo, isso seria registrado com sucesso de acordo com a compatibilidade FORWARD, pois os consumidores podem ler dados produzidos com o novo esquema usando a versão anterior. Se você tivesse uma nova versão de esquema proposta que adicionasse o método RPC Baz, isso não seria registrado com êxito com a compatibilidade FORWARD. Seus consumidores na versão anterior não seriam capazes de ler os esquemas propostos, pois eles não teriam o método RPC Baz ausente.
FORWARD_ALL (Todas as próximas): essa opção de compatibilidade permite que os consumidores leiam dados escritos por produtores de qualquer novo esquema registrado. Você pode usar essa opção quando precisar adicionar campos ou excluir campos opcionais e verificar a compatibilidade com todas as versões anteriores do esquema.
FULL (Completo): essa opção de compatibilidade permite que os consumidores leiam dados gravados por produtores usando a versão anterior ou seguinte do esquema, mas não versões anteriores ou posteriores. Você pode usar essa opção para verificar a compatibilidade com a última versão do esquema ao adicionar ou remover campos opcionais.
FULL_ALL (Completo total): essa opção de compatibilidade permite que os receptores de dados leiam dados gravados por produtores usando todas as versões de esquema anteriores. Você pode usar essa opção para verificar a compatibilidade com todas as versões anteriores do esquema ao adicionar ou remover campos opcionais.

Bibliotecas Serde de código aberto

A AWS fornece bibliotecas Serde de código aberto como um framework para serialização e desserialização de dados. O design de código aberto dessas bibliotecas permite que aplicações e frameworks comuns de código aberto ofereçam suporte a elas em seus projetos.

Para obter mais detalhes sobre como as bibliotecas Serde funcionam, consulte Como o registro de esquemas funciona.

Cotas do registro do esquemas

As cotas, também conhecidas como limites na AWS, são os valores máximos para recursos, ações e itens na sua conta da AWS. A seguir estão os limites flexíveis para o registro de esquemas no AWS Glue.

Pares de chave-valor de metadados de versão de esquema

Você pode ter até dez pares de chave-valor por SchemaVersion por região da AWS.

Você pode visualizar ou definir os pares de metadados de chave-valor usando o Ação QuerySchemaVersionMetadata (Python: query_schema_version_metadata) ou APIs do Ação PutSchemaVersionMetadata (Python: put_schema_version_metadata).

A seguir estão os limites rígidos para o registro de esquemas no AWS Glue.

Registros

É possível ter até 100 registros por região da AWS para esta conta.

SchemaVersion

É possível ter até 10.000 versões de esquema por região da AWS para esta conta.

Cada novo esquema cria uma nova versão do esquema, portanto você poderá, teoricamente, ter até 10.000 esquemas por conta por região, se cada esquema tiver apenas uma versão.

Cargas úteis de esquema

Há um limite de tamanho de 170 KB para cargas úteis de esquema.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Práticas recomendadas do Catálogo de Dados

Como funciona

Registro de esquemas do AWS Glue

nota

Tópicos

Esquemas

Registros

Versionamento e compatibilidade de esquema

AVRO

JSON

PROTOBUF

AVRO

JSON

PROTOBUF

Bibliotecas Serde de código aberto

Cotas do registro do esquemas

Pares de chave-valor de metadados de versão de esquema

Registros

SchemaVersion

Cargas úteis de esquema