Schémas Registres Gestion des versions et compatibilité des schémas Bibliothèques Serde en open source Quotas du registre des schémas

AWS GlueRegistre de schémas

Note

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

Le registre des AWS Glue schémas vous permet de découvrir, de contrôler et de faire évoluer les schémas de flux de données de manière centralisée. 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

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

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 des schémas permet à des 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 des schémas fournit un sérialiseur et un désérialiseur pour certains systèmes tels qu'Amazon ou Apache Kafka. MSK

Pour de plus amples informations, veuillez consulter Fonctionnement du registre des schémas.

Rubriques

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 de JSON schéma draft-07 pourJSON, le format est défini par l'JSONorganisation Schema.


{
	"$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 pour les opérations de schéma au sein du registre.

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

Hiérarchie du registre de schémas AWS Glue
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 _ ALLFORWARD, FORWARD _ALL, FULL _FULL, _ ALLNONE,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 de nouvelles versions, vous pouvez utiliser leCLI/SDKpour remplacer le point de contrôle par une version d'un schéma respectant un ensemble de contraintes. UpdateSchema API 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 8 modes de compatibilité : NONEDISABLED,BACKWARD,ALL, BACKWARD _FORWARD,ALL, FORWARD _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 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: ce choix de compatibilité empêche le versionnement d'un schéma particulier. Aucune nouvelle version ne peut être ajoutée.
BACKWARD: Ce choix de compatibilité est recommandé car il permet aux utilisateurs 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 BACKWARD est celui où 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. BACKWARDla compatibilité exige que les consommateurs 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 un code postal, cela ne sera pas correctement enregistré avec BACKWARD compatibilité. 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. BACKWARDla compatibilité exige que les consommateurs 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 proposé une nouvelle version de schéma qui ajoute la propriété optionnelle du numéro de téléphone, cela ne sera pas correctement enregistré avec BACKWARD compatibilité lorsque la version originale du schéma définit le additionalProperties champ sur true, c'est-à-dire en autorisant 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.

Comme dans le AVRO cas des scénarios, si votre prochaine version de schéma supprime le email champ obligatoire, cela sera enregistré avec succès. BACKWARDla compatibilité exige que les consommateurs 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 exemplezip code, cela ne sera pas correctement enregistré avec BACKWARD compatibilité. 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'RPCutilisation g, l'ajout d'un nouveau RPC service ou d'une nouvelle RPC méthode constitue une modification rétrocompatible. Supposons, par exemple, que vous disposiez d'une version de schéma définie par un RPC service MyService avec deux RPC méthodes Foo etBar.

Si votre prochaine version de schéma ajoute une nouvelle RPC méthode appeléeBaz, celle-ci sera enregistrée avec succès. Vos consommateurs pourront lire les données produites avec le schéma d'origine en fonction de la BACKWARD compatibilité, car la RPC méthode nouvellement ajoutée Baz est facultative.

Si vous avez proposé une nouvelle version de schéma qui supprime la RPC méthode existanteFoo, cela ne sera pas correctement enregistré avec BACKWARD compatibilité. Dans la nouvelle version, vos clients ne seront pas en mesure de lire les anciens messages avant le changement de schéma, car ils ne peuvent ni comprendre ni lire les données avec la RPC méthode inexistante Foo dans une RPC application g.
BACKWARD_ ALL : Ce choix de compatibilité permet aux consommateurs de lire à la fois la version actuelle et toutes les versions précédentes 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: Ce choix de compatibilité permet aux consommateurs de lire à la fois les versions actuelles et 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 FORWARD est celui où 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. FORWARDla compatibilité exige que les consommateurs soient en mesure de lire les données produites avec le nouveau schéma en utilisant la version précédente.

Si vous avez proposé une version de schéma qui supprime le champ de prénom requis, cela ne sera pas correctement enregistré avec FORWARD compatibilité. 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. FORWARDla compatibilité exige que les consommateurs soient en mesure de lire les données produites avec le nouveau schéma en utilisant la version précédente.

Si vous avez proposé une version de schéma qui supprime la propriété optionnelle du numéro de téléphone, elle ne sera pas correctement enregistrée avec FORWARD compatibilité lorsque la nouvelle version du schéma définit le additionalProperties champ sur true, c'est-à-dire en autorisant 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.

Comme dans les AVRO scénarios, si vous avez une nouvelle version du schéma qui ajoute un champ obligatoire, par exemplephone number, cela sera enregistré avec succès. FORWARDla compatibilité exige que les consommateurs soient en mesure de lire les données produites avec le nouveau schéma en utilisant la version précédente.

Si vous avez proposé une version de schéma qui supprime le first name champ obligatoire, cela ne sera pas correctement enregistré avec FORWARD compatibilité. 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'RPCutilisation g, la suppression d'un RPC service ou d'une RPC méthode constitue une modification compatible avec le futur. Supposons, par exemple, que vous disposiez d'une version de schéma définie par un RPC service MyService avec deux RPC méthodes Foo etBar.

Si votre prochaine version de schéma supprime la RPC méthode existante nomméeFoo, celle-ci sera correctement enregistrée conformément à la FORWARD compatibilité, car les consommateurs peuvent lire les données produites avec le nouveau schéma en utilisant la version précédente. Si vous avez proposé une nouvelle version de schéma qui ajoute une RPC méthodeBaz, celle-ci ne sera pas correctement enregistrée avec FORWARD compatibilité. Dans la version précédente, vos clients ne pourraient pas lire les schémas proposés car ils ne disposent pas de la RPC méthodeBaz.
FORWARD_ ALL : Ce choix de compatibilité permet aux consommateurs de lire les données écrites par les producteurs 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: ce choix de compatibilité permet aux consommateurs de lire les données écrites par les producteurs à l'aide de la version précédente ou suivante du schéma, mais pas des 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 : Ce choix de compatibilité permet aux consommateurs de lire les données écrites par les producteurs en 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 des 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 du QuerySchemaVersionMetadata action (Python : query_schema_version_metadata) ou. PutSchemaVersionMetadata action (Python : put_schema_version_metadata) APIs

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.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Bonnes pratiques en matière de catalogue de données

Comment ça marche

AWS GlueRegistre de schémas

Note

Rubriques

Schémas

Registres

Gestion des versions et compatibilité des schémas

AVRO

JSON

PROTOBUF

AVRO

JSON

PROTOBUF

Bibliothèques Serde en open source

Quotas du registre des schémas

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

Registres

SchemaVersion

Charges utiles de schéma