AWS Glue Schema Registry - AWS Glue
SchemasRegistriesCompatibilidad y control de versiones de esquemasBibliotecas Serde de código abiertoCuotas del Schema Registry

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

AWS Glue Schema Registry

nota

El registro de esquemas de AWS Glue no se admite en la consola de AWS Glue en las siguientes regiones: Asia Pacífico (Yakarta) y Medio Oriente (EAU).

AWS Glue Schema Registry es una nueva característica que le permite descubrir, controlar y evolucionar de forma centralizada esquemas de flujo de datos. Un esquema define la estructura y el formato de un registro de datos. Con AWS Glue Schema Registry, puede administrar y aplicar esquemas en sus aplicaciones de streaming de datos mediante integraciones convenientes con Apache Kafka, Amazon Managed Streaming for Apache Kafka, Amazon Kinesis Data Streams, Amazon Managed Service para Apache Flink y AWS Lambda.

El registro de esquemas AWS Glue admite el formato de datos AVRO (v1.10.2), el formato de datos JSON con formato de esquemas JSON para el esquema (especificaciones Draft-04, Draft-06 y Draft-07) con la validación de esquema JSON mediante el método biblioteca de Everit, y admite los búferes de protocolo (Protobuf) en las versiones proto2 y proto3 sin soporte para extensions o groups, y el lenguaje Java, con otros formatos de datos e idiomas que estarán disponibles en el futuro. Las características soportadas incluyen compatibilidad, fuentes de esquemas mediante metadatos, registro automático de esquemas, compatibilidad con IAM y compresión ZLIB opcional para reducir el almacenamiento y la transferencia de datos. AWS Glue Schema Registry no precisa servidor y es gratuito.

El uso de un esquema como contrato de formato de datos entre productores y consumidores conduce a una mejor gobernanza de los datos, datos de mayor calidad y permite que los consumidores de datos sean resistentes a los cambios posteriores compatibles.

Schema Registry permite que sistemas dispares compartan un esquema para la serialización y la deserialización. Por ejemplo, suponga que tiene un productor y un consumidor de datos. El productor conoce el esquema cuando publica los datos. Schema Registry proporciona un serializador y deserializador para determinados sistemas como Amazon MSK o Apache Kafka.

Para obtener más información, consulte Cómo funciona Schema Registry.

Temas

Schemas

Un esquema define la estructura y el formato de un registro de datos. Un esquema es una especificación versionada para publicación, consumo o almacenamiento de confianza de datos.

En este esquema de ejemplo para Avro, el formato y la estructura están definidos por el diseño y los nombres de campos, y el formato de los nombres de campos está definido por los tipos de datos (por ejemplo, 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" 
                    }
                ]
            }
        }
    ]
}

En este ejemplo de esquema JSON Draft-07 para JSON, el formato está definido por la organización del 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
		}
	}
}

En este ejemplo de Protobuf, el formato se define mediante laversión 2 del lenguaje de búferes de protocolo (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;
}

Registries

Un registro es un contenedor lógico de esquemas. Los registros le permiten organizar sus esquemas, así como administrar el control de acceso para sus aplicaciones. Un registro tiene un nombre de recurso de Amazon (ARN) que le permite organizar y establecer diferentes permisos de acceso a las operaciones de esquema dentro del registro.

Puede utilizar el registro predeterminado o crear tantos registros nuevos como sea necesario.

  • RegistryName: [cadena]

    • RegistrYarn: [AWS ARN]

    • CreatedTime: [marca de tiempo]

    • UpdatedTime: [marca de tiempo]

  • SchemaName: [cadena]

    • SchemaArn: [AWS ARN]

    • DataFormat: [Avro, Json o Protobuf]

    • Compatibilidad: [por ejemplo, BACKWARD (HACIA ATRÁS), BACKWARD_ALL (HACIA ATRÁS_TODO), FORWARD (HACIA ADELANTE), FORWARD_ALL (HACIA ADELANTE_TODO), FULL (COMPLETO), FULL_ALL (COMPLETO_TODO), NONE (NINGUNO), DISABLED (DESACTIVADO)]

    • Status: [por ejemplo, PENDING (PENDIENTE), AVAILABLE (DISPONIBLE), DELETING (ELIMINACIÓN)]

    • SchemaCheckPoint: [entero]

    • CreatedTime: [marca de tiempo]

    • UpdatedTime: [marca de tiempo]

  • SchemaVersion: [cadena]

    • SchemaVersionNumber: [entero]

    • Status: [por ejemplo, PENDIENTE, DISPONIBLE, ELIMINACIÓN, ERROR]

    • SchemaDefinition: [cadena, valor: JSON]

    • CreatedTime: [marca de tiempo]

  • SchemaVersionMetadata: [lista]

    • MetadataKey: [cadena]

    • MetadataInfo

    • MetadaValue: [cadena]

    • CreatedTime: [marca de tiempo]

Compatibilidad y control de versiones de esquemas

Cada esquema puede tener varias versiones. El control de versiones se rige por una regla de compatibilidad que se aplica a un esquema. Schema Registry contrasta las solicitudes para registrar nuevas versiones de esquema con esta regla antes de que puedan tener éxito.

Una versión de esquema marcada como punto de verificación se utiliza para determinar la compatibilidad de registrar nuevas versiones de un esquema. Cuando se crea un esquema por primera vez, el punto de verificación predeterminado será la primera versión. A medida que el esquema evoluciona con más versiones, puede utilizar CLI/SDK para cambiar el punto de control a una versión de un esquema mediante la herramienta API UpdateSchema que cumple con un conjunto de restricciones. En la consola, la edición de la definición de esquema o el modo de compatibilidad cambiará el punto de control a la última versión de forma predeterminada.

Los modos de compatibilidad permiten controlar cómo los esquemas pueden o no evolucionar con el tiempo. Estos modos forman el contrato entre las aplicaciones que producen y consumen datos. Cuando se envía una nueva versión de un esquema al registro, la regla de compatibilidad aplicada al nombre del esquema se utiliza para determinar si se puede aceptar la nueva versión. Existen ocho modos de compatibilidad: NONE (NINGUNO), DISABLED (DESACTIVADO), BACKWARD (HACIA ATRÁS), BACKWARD_ALL (HACIA ATRÁS_TODO), FORWARD (HACIA ADELANTE), FORWARD_ALL (HACIA ADELANTE_TODO), FULL (COMPLETO), FULL_ALL (COMPLETO_TODO).

En el formato de datos Avro, los campos pueden ser opcionales u obligatorios. Un campo opcional es aquel en el que el Type incluye nulo. Los campos obligatorios no tienen nulo como Type.

En el formato de datos Protobuf, los campos pueden ser opcionales (incluso repetidos) u obligatorios en la sintaxis proto2, mientras que todos los campos son opcionales (incluidos los repetidos) en la sintaxis proto3. Todas las reglas de compatibilidad se determinan en función de la comprensión de las especificaciones de los búferes de protocolo, así como en función de las pautas en la documentación sobre búferes de protocolo de Google.

  • NONE (NINGUNO): no se aplica ningún modo de compatibilidad. Puede utilizar esta opción en escenarios de desarrollo o si no conoce los modos de compatibilidad que desea aplicar a los esquemas. Cualquier nueva versión que se agregue será aceptada sin someterse a una comprobación de compatibilidad.

  • DISABLED (DESACTIVADO): esta opción de compatibilidad impide el control de versiones de un esquema en particular. No se pueden agregar nuevas versiones.

  • BACKWARD (HACIA ATRÁS): se recomienda esta opción de compatibilidad ya que permite a los consumidores leer tanto la versión actual como la anterior del esquema. Puede utilizar esta opción para comprobar la compatibilidad con la última versión del esquema, al eliminar campos o agregar campos adicionales. Un caso de uso típico para HACIA ATRÁS es cuando la aplicación se ha creado para el esquema más reciente.

    AVRO

    Por ejemplo, suponga que tiene un esquema definido por nombre (obligatorio), apellido (obligatorio), email (obligatorio) y número de teléfono (opcional).

    Si la siguiente versión del esquema elimina el campo de email obligatorio, esto se registraría correctamente. La compatibilidad HACIA ATRÁS requiere que los consumidores puedan leer la versión actual y anterior del esquema. Sus consumidores podrán leer el nuevo esquema a medida que se ignora el campo de email adicional de los mensajes antiguos.

    Si tiene una nueva versión de esquema propuesta que agrega un campo obligatorio, por ejemplo, código postal, esto no se registrará correctamente con la compatibilidad HACIA ATRÁS. Los consumidores de la nueva versión no podrían leer mensajes antiguos antes de cambiar el esquema, ya que les faltará el campo de código postal obligatorio. Sin embargo, si el campo de código postal se estableció como opcional en el nuevo esquema, entonces la versión propuesta se registraría correctamente, ya que los consumidores pueden leer el esquema anterior sin el campo de código postal opcional.

    JSON

    Por ejemplo, supongamos que tiene una versión de esquema definida por nombre (opcional), apellido (opcional), email (opcional) y número de teléfono (opcional).

    Si la siguiente versión de esquema agrega la propiedad opcional de número de teléfono, esto se registraría correctamente siempre y cuando la versión original del esquema no permita ninguna propiedad adicional al configurar el campo additionalProperties en falso. La compatibilidad HACIA ATRÁS requiere que los consumidores puedan leer la versión actual y anterior del esquema. Sus consumidores podrán leer los datos producidos con el esquema original en el que la propiedad del número de teléfono no existe.

    Si tiene una nueva versión de esquema propuesta que agrega la propiedad de número de teléfono opcional, esto no se registrará correctamente con la compatibilidad HACIA ATRÁS, cuando la versión del esquema original establezca el campo additionalProperties a verdadero, es decir, cuando permita cualquier propiedad adicional. Los consumidores de la nueva versión no podrían leer mensajes antiguos antes de cambiar el esquema, ya que no pueden leer datos con propiedad de número de teléfono en un tipo diferente, por ejemplo cadena en lugar de número.

    PROTOBUF

    Por ejemplo, suponga que tiene una versión de esquema definida por un mensaje Person con first name (obligatorio), last name (obligatorio), email (obligatorio) y phone number (opcional) en la sintaxis proto2.

    En forma semejante a las situaciones de AVRO, si la siguiente versión del esquema elimina el campo de email obligatorio, esto se registraría correctamente. La compatibilidad HACIA ATRÁS requiere que los consumidores puedan leer la versión actual y anterior del esquema. Sus consumidores podrán leer el nuevo esquema a medida que se ignora el campo de email adicional de los mensajes antiguos.

    Si tiene una nueva versión de esquema propuesta que agrega un campo obligatorio, por ejemplo, zip code, esto no se registrará correctamente con la compatibilidad CON VERSIONES ANTERIORES. Los consumidores de la nueva versión no podrían leer mensajes antiguos antes de cambiar el esquema, ya que les faltará el campo de zip code obligatorio. Sin embargo, si el campo de zip code se estableció como opcional en el nuevo esquema, entonces la versión propuesta se registraría correctamente, ya que los consumidores pueden leer el esquema anterior sin el campo de zip code opcional.

    En caso de un caso de uso de gRPC, agregar un nuevo servicio RPC o un método RPC es un cambio compatible con versiones anteriores. Por ejemplo, suponga que tiene una versión de esquema definida por un servicio RPC MyService con dos métodos RPC, Foo y Bar.

    Si la próxima versión de esquema añade un nuevo método RPC llamado Baz, esto se registraría correctamente. Los consumidores podrán leer los datos producidos con el esquema original según la compatibilidad CON VERSIONES ANTERIORES desde el método RPC Baz recientemente agregado es opcional.

    Si tiene una nueva versión de esquema propuesta que agrega un método RPC existente Foo, esto no se registrará correctamente con la compatibilidad CON VERSIONES ANTERIORES. Los consumidores de la nueva versión no podrían leer mensajes antiguos antes del cambio de esquema, ya que no pueden entender ni leer datos con el método RPC inexistente Foo en una aplicación de gRPC.

  • BACKWARD_ALL (HACIA ATRÁS_TODO): esta opción de compatibilidad permite a los consumidores leer tanto la versión actual como todas las versiones anteriores del esquema. Puede utilizar esta opción para comprobar la compatibilidad con la última versión del esquema cuando elimine campos o agregue campos adicionales.

  • FORWARD (HACIA ADELANTE): esta opción de compatibilidad permite a los consumidores leer tanto la versión actual como la inmediatamente siguiente del esquema, pero no necesariamente versiones posteriores. Puede utilizar esta opción para comprobar la compatibilidad con la última versión del esquema cuando elimine campos o agregue campos adicionales. Un caso de uso típico de HACIA ADELANTE es cuando la aplicación se ha creado para un esquema anterior y debe poder procesar un esquema más reciente.

    AVRO

    Por ejemplo, supongamos que tiene una versión de esquema definida por nombre (obligatorio), apellido (obligatorio), email (opcional).

    Si tiene una nueva versión de esquema que agrega un campo obligatorio, p. ej., número de teléfono, esto se registraría correctamente. La compatibilidad HACIA ADELANTE requiere que los consumidores puedan leer los datos producidos con el nuevo esquema utilizando la versión anterior.

    Si tiene una sugerencia de una versión de esquema que elimina el campo obligatorio de nombre, esto no se registrará correctamente con la compatibilidad HACIA ADELANTE. Los consumidores de la versión anterior no podrían leer los esquemas propuestos, ya que les falta el campo obligatorio de nombre. Sin embargo, si el campo de nombre original era opcional, entonces el nuevo esquema propuesto se registraría correctamente, ya que los consumidores pueden leer datos basados en el nuevo esquema que no incluye el campo opcional de nombre.

    JSON

    Por ejemplo, supongamos que tiene una versión de esquema definida por nombre (opcional), apellido (opcional), email (opcional) y número de teléfono (opcional).

    Si tiene una nueva versión de esquema que elimina la propiedad opcional de número de teléfono, esto se registraría correctamente siempre y cuando la nueva versión del esquema no permita ninguna propiedad adicional al configurar el campo additionalProperties en falso. La compatibilidad HACIA ADELANTE requiere que los consumidores puedan leer los datos producidos con el nuevo esquema utilizando la versión anterior.

    Si tiene una sugerencia de una versión de esquema que elimina la propiedad opcional de número de teléfono, esto no se registraría correctamente con la compatibilidad HACIA ADELANTE cuando la nueva versión del esquema establece el campo additionalProperties a verdadero, es decir, permite cualquier propiedad adicional. Los consumidores de la versión anterior no podrían leer los esquemas propuestos, ya que podrían tener la propiedad de número de teléfono en un tipo diferente, por ejemplo cadena en lugar de número.

    PROTOBUF

    Por ejemplo, suponga que tiene una versión de esquema definida por un mensaje Person con first name (obligatorio), last name(obligatorio) y email (opcional) en la sintaxis proto2.

    De manera semejante a las situaciones de AVRO, si tiene una nueva versión de esquema que agrega un campo obligatorio, p. ej., phone number, esto se registraría correctamente. La compatibilidad HACIA ADELANTE requiere que los consumidores puedan leer los datos producidos con el nuevo esquema utilizando la versión anterior.

    Si tiene una sugerencia de una versión de esquema que elimina el campo obligatorio de first name, esto no se registrará correctamente con la compatibilidad CON VERSIONES FUTURAS. Los consumidores de la versión anterior no podrían leer los esquemas propuestos, ya que les falta el campo obligatorio de first name. Sin embargo, si el campo de first name original era opcional, entonces el nuevo esquema propuesto se registraría correctamente, ya que los consumidores pueden leer datos basados en el nuevo esquema que no incluye el campo opcional de first name.

    En caso de un caso de uso de gRPC, quitar un servicio RPC o un método RPC es un cambio compatible con versiones futuras. Por ejemplo, suponga que tiene una versión de esquema definida por un servicio RPC MyService con dos métodos RPC, Foo y Bar.

    Si la próxima versión del esquema elimina el método RPC existente denominado Foo, esto se registraría correctamente según la compatibilidad CON VERSIONES FUTURAS, ya que los consumidores pueden leer los datos producidos con el nuevo esquema utilizando la versión anterior. Si tiene una sugerencia de una nueva versión de esquema que agrega un método RPC de Baz, esto no se registrará correctamente con la compatibilidad CON VERSIONES FUTURAS. Los consumidores de la versión anterior no podrían leer los esquemas propuestos, ya que les falta el método RPC de Baz.

  • FORWARD_ALL (HACIA ADELANTE_TODO): esta opción de compatibilidad permite a los consumidores leer datos escritos por los productores de cualquier nuevo esquema registrado. Puede utilizar esta opción cuando necesite agregar campos o eliminar campos opcionales, y comprobar la compatibilidad con todas las versiones de esquema anteriores.

  • FULL (COMPLETO): esta opción de compatibilidad permite a los consumidores leer los datos escritos por los productores con la versión inmediatamente anterior o siguiente del esquema, pero no necesariamente versiones anteriores o posteriores. Puede utilizar esta opción para comprobar la compatibilidad con la última versión del esquema cuando elimine campos o agregue campos adicionales.

  • FULL_ALL (COMPLETO_TODO): esta opción de compatibilidad permite a los consumidores leer los datos escritos por los productores con todas las versiones de esquema anteriores. Puede utilizar esta opción para comprobar la compatibilidad con todas las versiones anteriores del esquema, cuando agregue o elimine campos opcionales.

Bibliotecas Serde de código abierto

AWS proporciona bibliotecas Serde de código abierto como marco para serializar y deserializar datos. El diseño de código abierto de estas bibliotecas permite que las aplicaciones y marcos de código abierto comunes soporten estas bibliotecas en sus proyectos.

Para obtener más detalles sobre cómo funcionan las bibliotecas de Serde, consulte Cómo funciona Schema Registry.

Cuotas del Schema Registry

Las cuotas, también conocidas como límites en AWS, son el valor máximo de los recursos, acciones y elementos de su cuenta de AWS. Los siguientes son los límites flexibles para el Schema Registry en AWS Glue.

Pares de clave-valor de metadatos de la versión del esquema

Puede tener hasta 10 pares clave-valor por SchemaVersion por región de AWS.

Puede ver o establecer los pares de metadatos clave-valor con las API Acción QuerySchemaVersionMetadata (Python: query_schema_version_metadata) o Acción PutSchemaVersionMetadata (Python: put_schema_version_metadata).

Los siguientes son los límites invariables para el Schema Registry en AWS Glue.

Registries

Puede tener hasta 100 registros por región de AWS para esta cuenta.

SchemaVersion

Puede tener hasta 10 000 versiones de esquema por región de AWS para esta cuenta.

Cada esquema nuevo crea una nueva versión de esquema, por lo que teóricamente puede tener hasta 10 000 esquemas por cuenta por región, si es que cada esquema tiene una sola versión.

Cargas de esquema

Hay un límite de tamaño de 170 KB para las cargas de esquema.