Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Registre de schémas AWS Glue **Note** AWS GlueLe registre des schémas n'est pas pris en charge dans les régions suivantes de la AWS Glue console : Moyen-Orient (Émirats arabes unis). Le registre de schémas AWS Glue 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 le registre de schémas AWS Glue, vous pouvez gérer et appliquer des schémas à vos applications de streaming de données en utilisant des intégrations pratiques avec Apache Kafka, [Amazon Managed Streaming pour Apache Kafka](https://aws.amazon.com/msk/), [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/), [Service géré Amazon pour Apache Flink](https://aws.amazon.com/kinesis/data-analytics/) et [AWS Lambda](https://aws.amazon.com/lambda/). Le registre de schémas prend en charge le format de données AVRO (v1.11.4), le format de données JSON avec le [format de schéma JSON](https://json-schema.org/) 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](https://github.com/everit-org/json-schema), 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 fonctionnalités 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. 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 de plus amples informations, veuillez consulter [Fonctionnement du registre de schémas](schema-registry-works.md). **Topics** + [Schémas](#schema-registry-schemas) + [Registres](#schema-registry-registries) + [Gestion des versions et compatibilité des schémas](#schema-registry-compatibility) + [Bibliothèques Serde en open source](#schema-registry-serde-libraries) + [Quotas du registre des schémas](#schema-registry-quotas) + [Fonctionnement du registre de schémas](schema-registry-works.md) + [Démarrage avec le registre de schémas](schema-registry-gs.md) ## 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](https://json-schema.org/). ``` { "$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)](https://developers.google.com/protocol-buffers/docs/reference/proto2-spec). ``` 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. **Hiérarchie du registre de schémas AWS Glue** | | | --- | | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/schema-registry.html) | | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/schema-registry.html) | | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/schema-registry.html) | | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/glue/latest/dg/schema-registry.html) | ## 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 le CLI/SDK pour remplacer le point de contrôle par une version d'un schéma à l'aide de l'`UpdateSchema`API qui respecte 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 ](https://developers.google.com/protocol-buffers/docs/overview#updating). + *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](schema-registry-works.md). ## 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)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-QuerySchemaVersionMetadata) ou. [PutSchemaVersionMetadata action (Python : put\_schema\_version\_metadata)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-PutSchemaVersionMetadata) 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 version de schéma, de sorte que vous pouvez théoriquement avoir jusqu’à 10 000 schémas par compte et par région, si chaque schéma ne dispose que d’une seule version. **Charges utiles de schéma** Il existe une limite de taille de 170 Ko pour les charges utiles de schéma.