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.
Note
AWS Glue Le registre des schémas n'est pas pris en charge dans les régions suivantes de la AWS Glue console : Asie-Pacifique (Jakarta), Europe (Zurich) et Moyen-Orient (Émirats arabes unis).
Le AWS Glue Le registre des schémas 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 Registre de schémas, 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
Le registre des 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 pour le schéma (spécifications Draft-04, Draft-06 et Draft-07) avec validation du schéma JSON à l'aide de la bibliothèque Everitextensions 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 compatibilité IAM et la compression ZLIB en option 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 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 des schémas.
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 schéma JSON 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.
|
|
|
|
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
additionalPropertiessur 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
additionalPropertiessur 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
Personavecfirst name(obligatoire),last name(obligatoire),email(obligatoire) et le champphone 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émentaireemaildes 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 requiszip code. Toutefois, si le champzip codea é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 facultatifzip 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
MyServiceavec deux méthodes RPC,FooetBar.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éeBazest 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 inexistanteFoodans 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
additionalPropertiessur 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
additionalPropertiessur 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
Personavec des champsfirst 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 obligatoirefirst nameest absent. Toutefois, si le champfirst 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 facultatiffirst nameest 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
MyServiceavec deux méthodes RPC,FooetBar.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 RPCBaz, 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 RPCBaz.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 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. Les limites souples suivantes s'appliquent au registre des 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
Les limites suivantes sont strictes 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.
