Registre de schémas AWS Glue

Note

Le Registre de schémas AWS Glue n'est pas pris en charge dans les régions suivantes de la console AWS Glue  : Asie-Pacifique (Jakarta) et Moyen-Orient (EAU).

Le registre de schémas AWS Glue est une nouvelle fonction qui vous permet de découvrir, de contrôler et de faire évoluer de manière centralisée les schémas de flux de données. Un schéma définit la structure et le format d'un enregistrement de données. Avec AWS Glue Schema Registry, vous pouvez gérer et appliquer des schémas sur vos applications de streaming de données à l'aide d'intégrations pratiques avec Apache Kafka Amazon Managed Streaming for Apache Kafka, Amazon Kinesis Data Streams, Amazon Managed Service pour Apache Flink et. AWS Lambda

AWS Glue Schema Registry prend en charge le format de données AVRO (v1.10.2), le format de données JSON avec format de schéma JSON pour le schéma (spécifications Draft-04, Draft-06 et Draft-07) avec la validation de schéma JSON, à l'aide de la bibliothèque Everit, de Protocol Buffers (Protobuf) versions proto2 et proto3, sans la prise en charge des extensions ou des groups et la prise en charge du langage Java, avec d'autres formats de données et de langages à venir. Les fonctions prises en charge incluent la compatibilité, l'utilisation de schémas via des métadonnées, l'enregistrement automatique des schémas, la compatibilité IAM et la compression ZLIB facultative pour réduire le stockage et le transfert de données. AWS Glue Le registre de schémas est sans serveur et son utilisation est gratuite.

L'utilisation d'un schéma comme contrat de format de données entre applications producteur et consommateur conduit à une meilleure gouvernance des données, à une meilleure qualité des données, et permet aux applications consommateur de données d'être résilientes face aux changements compatibles en amont.

Le registre de schémas permet aux systèmes disparates de partager un schéma pour la sérialisation et la désérialisation. Par exemple, supposons que vous ayez un producteur et un consommateur de données. Le producteur connaît le schéma lorsqu'il publie les données. Le registre de schémas fournit un sérialiseur et un désérialiseur pour certains systèmes tels qu'Amazon MSK ou Apache Kafka.

Pour plus d’informations, consultez Fonctionnement du registre de schémas.

Rubriques

• Schémas
• Registres
• Gestion des versions et compatibilité des schémas
• Bibliothèques Serde en open source
• Quotas du registre des schémas
• Fonctionnement du registre de schémas
• Démarrer avec le registre de schémas
• Intégration au registre de schémas AWS Glue
• Migration d'un registre de schémas tiers vers le registre de schémas AWS Glue

Schémas

Un schéma définit la structure et le format d'un enregistrement de données. Un schéma est une spécification versionnée pour la publication, la consommation ou le stockage des données fiables.

Dans cet exemple de schéma pour Avro, le format et la structure sont définis par la disposition et les noms de champs, tandis que le format des noms de champs est défini par les types de données (par exemple, 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" 
                    }
                ]
            }
        }
    ]
}

Dans cet exemple JSON Schema Draft-07 pour JSON, le format est défini par l'organisation du schéma 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
		}
	}
}

Dans cet exemple pour Protobuf, le format est défini par la version 2 du langage 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;
}

Registres

Un registre est un conteneur logique de schémas. Les registres vous permettent d'organiser vos schémas, ainsi que de gérer le contrôle des accès pour vos applications. Un registre possède un Amazon Resource Name (ARN) qui vous permet d'organiser et de définir différentes autorisations d'accès aux opérations de schéma dans le registre.

Vous pouvez utiliser le registre par défaut ou créer autant de registres que nécessaire.

RegistryName: [chaîne] RegistryArn: [AWS ARN] CreatedTime: [horodatage] UpdatedTime: [horodatage]

SchemaName: [chaîne] SchemaArn: [AWS ARN] DataFormat: [Avro, Json ou Protobuf] Compatibility : [par ex., BACKWARD, BACKWARD_ALL, FORWARD, FORWARD_ALL, FULL, FULL_ALL, NONE, DISABLED] Status : [par ex., PENDING, AVAILABLE, DELETING] SchemaCheckpoint: [entier] CreatedTime: [horodatage] UpdatedTime: [horodatage]

SchemaVersion: [chaîne] SchemaVersionNumber: [entier] Status : [par ex., PENDING, AVAILABLE, DELETING, FAILURE] SchemaDefinition: [chaîne, valeur : JSON] CreatedTime: [horodatage]

SchemaVersionMetadata: [liste] MetadataKey: [chaîne] MetadataInfo MetadataValue: [chaîne] CreatedTime: [horodatage]

Gestion des versions et compatibilité des schémas

Chaque schéma peut avoir plusieurs versions. La gestion des versions est régie par une règle de compatibilité appliquée à un schéma. Les demandes d'enregistrement de nouvelles versions de schéma sont vérifiées par rapport à cette règle par le registre de schémas avant qu'elles ne puissent aboutir.

Une version de schéma qui est marquée comme point de contrôle est utilisée pour déterminer la compatibilité de l'enregistrement de nouvelles versions d'un schéma. Lorsqu'un schéma est créé pour la première fois, le point de contrôle par défaut sera la première version. Au fur et à mesure que le schéma évolue avec d'autres versions, vous pouvez utiliser la CLI/le SDK pour modifier le point de contrôle en version d'un schéma à l'aide de l'API UpdateSchema qui adhère à un ensemble de contraintes. Dans la console, la modification de la définition du schéma ou du mode de compatibilité modifiera le point de contrôle vers la dernière version par défaut.

Les modes de compatibilité vous permettent de contrôler la manière dont les schémas peuvent ou ne peuvent pas évoluer au fil du temps. Ces modes constituent le contrat entre les applications produisant et consommant des données. Lorsqu'une nouvelle version d'un schéma est envoyée au registre, la règle de compatibilité appliquée au nom du schéma est utilisée pour déterminer si la nouvelle version peut être acceptée. Il existe huit modes de compatibilité : NONE, DISABLED, BACKWARD, BACKWARD_ALL, FORWARD_ALL, FULL, FULL_ALL.

Au format de données Avro, les champs peuvent être facultatifs ou obligatoires. Un champ facultatif est celui dans lequel le champ Type inclut une valeur null. Les champs obligatoires n'ont pas de valeur nulle comme Type.

Dans le format de données Protobuf, les champs peuvent être facultatifs (y compris ceux répétés) ou obligatoires dans la syntaxe proto2, tandis que tous les champs sont facultatifs (y compris ceux répétés) dans la syntaxe proto3. Toutes les règles de compatibilité sont déterminées en fonction de la compréhension des spécifications de Protocol Buffers, ainsi que des directives de la Documentation Protocol Buffers de Google .

• NONE (AUCUN) : aucun mode de compatibilité ne s'applique. Vous pouvez utiliser ce choix dans les scénarios de développement ou si vous ne connaissez pas les modes de compatibilité que vous souhaitez appliquer aux schémas. Toute nouvelle version ajoutée sera acceptée sans faire l'objet d'un contrôle de compatibilité.

• DISABLED (DÉSACTIVÉ) : ce choix de compatibilité empêche la gestion des versions pour un schéma particulier. Aucune nouvelle version ne peut être ajoutée.

• BACKWARD (DESCENDANT) : ce choix de compatibilité est recommandé, car il permet aux applications consommateur de lire à la fois la version actuelle et la version précédente du schéma. Vous pouvez utiliser ce choix pour vérifier la compatibilité par rapport à la version précédente du schéma lorsque vous supprimez des champs ou ajoutez des champs facultatifs. Un cas d'utilisation typique pour BACKWARD (DESCENDANT) est lorsque votre application a été créée pour le schéma le plus récent.

  AVRO

  Par exemple, supposons que vous avez un schéma défini par le prénom (obligatoire), le nom (obligatoire), l'adresse électronique (obligatoire) et le numéro de téléphone (facultatif).

  Si votre prochaine version de schéma supprime le champ d'adresse électronique requis, l'enregistrement s'effectue correctement. La compatibilité BACKWARD (DESCENDANT) exige que les applications consommateur soient en mesure de lire la version actuelle et précédente du schéma. Vos applications consommateur seront en mesure de lire le nouveau schéma, car le champ d'adresse électronique supplémentaire des anciens messages est ignoré.

  Si vous avez proposé une nouvelle version de schéma qui ajoute un champ obligatoire, par exemple, le code postal, elle ne s'enregistrerait pas avec la compatibilité BACKWARD (DESCENDANT). Vos applications consommateur sur la nouvelle version ne seraient pas en mesure de lire les anciens messages avant la modification du schéma, car elles ne disposent pas du champ de code postal requis. Toutefois, si le champ de code postal a été défini comme facultatif dans le nouveau schéma, la version proposée s'enregistrerait avec succès, car les applications consommateur peuvent lire l'ancien schéma sans le champ de code postal facultatif.

  JSON

  Par exemple, supposons que vous avez une version de schéma définie par le prénom (facultatif), le nom de famille (facultatif), l'adresse électronique (facultatif) et le numéro de téléphone (facultatif).

  Si votre prochaine version de schéma ajoute la propriété de numéro de téléphone facultative, elle s'enregistrera avec succès tant que la version de schéma d'origine n'autorise aucune propriété supplémentaire en définissant le champ additionalProperties sur false. La compatibilité BACKWARD (DESCENDANT) exige que les applications consommateur soient en mesure de lire la version actuelle et précédente du schéma. Vos applications consommateur seront en mesure de lire les données produites avec le schéma d'origine où la propriété de numéro de téléphone n'existe pas.

  Si vous avez une proposition de nouvelle version de schéma qui ajoute la propriété de numéro de téléphone facultative, elle ne s'enregistrerait pas correctement avec la compatibilité BACKWARD (DESCENDANT) lorsque la version de schéma d'origine définit le champ additionalProperties sur true, à savoir autoriser toute propriété supplémentaire. Vos applications consommateur sur la nouvelle version ne seraient pas en mesure de lire les anciens messages avant le changement de schéma, car elles ne peuvent pas lire les données avec la propriété de numéro de téléphone dans un type différent, par exemple une chaîne au lieu d'un numéro.

  PROTOBUF

  Par exemple, imaginez que vous avez une version de schéma définie par un message Person avec first name (obligatoire), last name (obligatoire), email (obligatoire) et le champ phone number (facultatifs) sous la syntaxe proto2.

  Similaire aux scénarios AVRO, si la version de schéma suivante supprime le champ requis email, l'enregistrement s'effectue correctement. La compatibilité BACKWARD (DESCENDANT) exige que les applications consommateur soient en mesure de lire la version actuelle et précédente du schéma. Les consommateurs seront en mesure de lire le nouveau schéma, car le champ supplémentaire email des anciens messages est ignoré.

  Si vous avez proposé une nouvelle version de schéma qui ajoute un champ obligatoire, par exemple, zip code, l'enregistrement ne s'effectue pas correctement avec la compatibilité DESCENDANTE. Les consommateurs sur la nouvelle version ne seraient pas en mesure de lire les anciens messages avant la modification du schéma, car ils ne disposent pas du champ requis zip code. Toutefois, si le champ zip code a été défini comme facultatif dans le nouveau schéma, l'enregistrement de la version proposée s'effectue correctement, car les consommateurs peuvent lire l'ancien schéma sans le champ facultatif zip code.

  Dans le cas d'un cas d'utilisation de gRPC, l'ajout d'un nouveau service RPC ou d'une nouvelle méthode RPC est une modification de compatibilité descendante. Par exemple, imaginez que vous avez une version de schéma définie par un service RPC MyService avec deux méthodes RPC, Foo et Bar.

  Si la version de schéma suivante ajoute une nouvelle méthode RPC appelée Baz, l'enregistrement s'effectue correctement. Les consommateurs seront en mesure de lire les données produites avec le schéma d'origine, en fonction de la compatibilité DESCENDANTE, car la nouvelle méthode RPC ajoutée Baz est facultative.

  Si vous avez proposé une nouvelle version de schéma qui supprime la méthode RPC existante Foo, l'enregistrement ne s'effectue pas correctement avec la compatibilité DESCENDANTE. Les consommateurs sur la nouvelle version ne seraient pas en mesure de lire les anciens messages avant la modification du schéma, car ils ne peuvent pas comprendre et lire les données avec la méthode RPC inexistante Foo dans une application gRPC.

• BACKWARD_ALL (DESCENDANT_TOUT) : ce choix de compatibilité permet aux applications consommateur de lire à la fois la version actuelle et toutes les versions antérieures du schéma. Vous pouvez utiliser ce choix pour vérifier la compatibilité avec toutes les versions de schéma précédentes lorsque vous supprimez des champs ou ajoutez des champs facultatifs.

• FORWARD (ASCENDANT) : ce choix de compatibilité permet aux applications consommateur de lire à la fois la version actuelle et les versions suivantes du schéma, mais pas nécessairement les versions ultérieures. Vous pouvez utiliser ce choix pour vérifier la compatibilité avec la dernière version de schéma lorsque vous ajoutez des champs ou supprimez des champs facultatifs. Un cas d'utilisation typique pour FORWARD (ASCENDANT) est lorsque votre application a été créée pour un schéma précédent et devrait être capable de traiter un schéma plus récent.

  AVRO

  Par exemple, supposons que vous avez une version de schéma définie par le prénom (obligatoire), le nom (obligatoire) et l'adresse électronique (facultatif).

  Si vous disposez d'une nouvelle version de schéma qui ajoute un champ obligatoire ; par exemple, un numéro de téléphone, l'enregistrement s'effectue correctement. La compatibilité FORWARD (ASCENDANT) exige que les applications consommateur puissent lire les données produites avec le nouveau schéma à l'aide de la version précédente.

  Si vous avez une version de schéma proposée qui supprime le champ de prénom obligatoire, elle ne s'enregistrerait pas avec la compatibilité FORWARD (ASCENDANT). Vos applications consommateur sur la version précédente ne seraient pas en mesure de lire les schémas proposés, car elles ne disposent pas du champ de prénom obligatoire. Toutefois, si le champ de prénom était initialement facultatif, le nouveau schéma proposé s'enregistrerait correctement, car les applications consommateur peuvent lire des données basées sur le nouveau schéma qui ne dispose pas du champ de prénom facultatif.

  JSON

  Par exemple, supposons que vous avez une version de schéma définie par le prénom (facultatif), le nom de famille (facultatif), l'adresse électronique (facultatif) et le numéro de téléphone (facultatif).

  Si vous disposez d'une nouvelle version de schéma qui supprime la propriété de numéro de téléphone facultative, elle s'enregistrera avec succès tant que la nouvelle version de schéma n'autorise aucune propriété supplémentaire en définissant le champ additionalProperties sur false. La compatibilité FORWARD (ASCENDANT) exige que les applications consommateur puissent lire les données produites avec le nouveau schéma à l'aide de la version précédente.

  Si vous avez une proposition de version de schéma qui supprime la propriété de numéro de téléphone facultative, elle ne s'enregistrerait pas correctement avec la compatibilité FORWARD (ASCENDANT) lorsque la nouvelle version de schéma définit le champ additionalProperties sur true, à savoir autoriser toute propriété supplémentaire. Vos applications consommateur sur la version précédente ne seraient pas en mesure de lire les schémas proposés, car elles pourraient avoir la propriété de numéro de téléphone dans un type différent, par exemple une chaîne au lieu d'un numéro.

  PROTOBUF

  Par exemple, imaginez que vous avez une version de schéma définie par un message Person avec des champs first name (obligatoire), last name (obligatoire), email (facultatif) sous la syntaxe proto2.

  Similaire aux scénarios AVRO, si vous disposez d'une nouvelle version de schéma qui ajoute un champ obligatoire ; par exemple phone number, l'enregistrement s'effectue correctement. La compatibilité FORWARD (ASCENDANT) exige que les applications consommateur puissent lire les données produites avec le nouveau schéma à l'aide de la version précédente.

  Si vous avez une version de schéma proposée qui supprime le champ obligatoire first name, l'enregistrement ne s'effectue pas correctement avec la compatibilité ASCENDANTE. Les consommateurs sur la version précédente ne seraient pas en mesure de lire les schémas proposés, car le champ obligatoire first name est absent. Toutefois, si le champ first name était initialement facultatif, l'enregistrement du nouveau schéma proposé s'effectue correctement, car les consommateurs peuvent lire des données basées sur le nouveau schéma où le champ facultatif first name est absent.

  Dans le cas d'un cas d'utilisation de gRPC, la suppression d'un service RPC ou d'une méthode RPC est une modification de compatibilité ascendante. Par exemple, imaginez que vous avez une version de schéma définie par un service RPC MyService avec deux méthodes RPC, Foo et Bar.

  Si la version de schéma suivante supprime la méthode RPC existante nommée Foo, l'enregistrement s'effectue correctement en fonction de la compatibilité ASCENDANTE, car les consommateurs peuvent lire les données produites avec le nouveau schéma à l'aide de la version précédente. Si vous avez une nouvelle version de schéma proposée qui ajoute une méthode RPC Baz, l'enregistrement ne s'effectue pas correctement avec la compatibilité ASCENDANTE. Les consommateurs sur la version précédente ne seraient pas en mesure de lire les schémas proposés, car ils ne disposent pas de la méthode RPC Baz.

• FORWARD_ALL (ASCENDANT_TOUT) : ce choix de compatibilité permet aux applications consommateur de lire les données écrites par les applications producteur de tout nouveau schéma enregistré. Vous pouvez utiliser ce choix lorsque vous devez ajouter des champs ou supprimer des champs facultatifs, et vérifier la compatibilité avec à toutes les versions de schéma précédentes.

• FULL (COMPLET) : ce choix de compatibilité permet aux applications consommateur de lire les données écrites par les applications producteur en utilisant la version précédente ou suivante du schéma, mais pas les versions antérieures ou ultérieures. Vous pouvez utiliser ce choix pour vérifier la compatibilité avec la dernière version de schéma lorsque vous ajoutez ou supprimez des champs facultatifs.

• FULL_ALL (COMPLET_TOUT) : ce choix de compatibilité permet aux applications consommateur de lire les données écrites par les applications producteur utilisant toutes les versions de schéma précédentes. Vous pouvez utiliser ce choix pour vérifier la compatibilité par rapport à toutes les versions de schéma précédentes lorsque vous ajoutez ou supprimez des champs facultatifs.

Bibliothèques Serde en open source

AWS fournit des bibliothèques Serde open source comme framework pour la sérialisation et la désérialisation des données. La conception open source de ces bibliothèques permet aux applications et aux cadres open source communs de prendre en charge ces bibliothèques dans leurs projets.

Pour plus de détails sur le fonctionnement des bibliothèques Serde, veuillez consulter Fonctionnement du registre de schémas.

Quotas du registre des schémas

Les quotas, également appelés limites dans AWS, sont les valeurs maximales pour les ressources, les actions et les éléments de votre AWS compte. Voici des limites logicielles pour le registre de schémas dans AWS Glue.

Paires clé-valeur des métadonnées de version de schéma

Vous pouvez avoir jusqu'à 10 paires clé-valeur SchemaVersion par région. AWS

Vous pouvez afficher ou définir les paires de métadonnées clé-valeur à l'aide des API QuerySchemaVersionMetadata action (Python : query_schema_version_metadata) ou PutSchemaVersionMetadata action (Python : put_schema_version_metadata).

Voici des limites matérielles pour le registre de schémas dans AWS Glue.

Registres

Vous pouvez avoir jusqu'à 100 registres par AWS région pour ce compte.

SchemaVersion

Vous pouvez avoir jusqu'à 10 000 versions de schéma par AWS région pour ce compte.

Chaque nouveau schéma crée une nouvelle version du schéma. Vous pouvez donc théoriquement avoir jusqu'à 10 000 schémas par compte et par région, si chaque schéma ne possède qu'une seule version.

Charges utiles de schéma

Il existe une limite de taille de 170 Ko pour les charges utiles de schéma.