AWS GlueSchemaregistrierung - AWS Glue
SchemataRegistrierungenSchema-Versioning und -KompatibilitätOpen-Source-SerDe-BibliothekenKontingente in Schema Registry

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

AWS GlueSchemaregistrierung

Anmerkung

AWS GlueDie Schemaregistrierung wird in den folgenden Regionen der AWS Glue Konsole nicht unterstützt: Asien-Pazifik (Jakarta) und Naher Osten (UAE).

Mit der AWS Glue Schemaregistrierung können Sie Datenstromschemas zentral ermitteln, steuern und weiterentwickeln. Ein Schema definiert die Struktur und das Format eines Datensatzes. Mit der AWS Glue Schemaregistrierung können Sie Schemas in Ihren Datenstreaming-Anwendungen mithilfe praktischer Integrationen mit Apache Kafka, Amazon Kinesis Data Streams Amazon Managed Streaming for Apache Kafka, Amazon Managed Service for Apache Flink und verwalten und durchsetzen. AWS Lambda

Die Schemaregistry unterstützt das Datenformat AVRO (v1.10.2), das JSON Datenformat mit dem JSONSchemaformat für das Schema (Spezifikationen Draft-04, Draft-06 und Draft-07) mit JSON Schemavalidierung mithilfe der Everit-Bibliothek, die Protocol Buffers (Protobuf) -Versionen proto2 und proto3 ohne Unterstützung für extensions oder groups und die Java-Sprachunterstützung mit weiteren Datenformaten und Sprachen, die noch folgen werden. Zu den unterstützten Funktionen gehören Kompatibilität, Schemabeschaffung über Metadaten, automatische Registrierung von Schemas, IAM Kompatibilität und optionale ZLIB Komprimierung zur Reduzierung von Speicherplatz und Datenübertragung. Die Schemaregistrierung ist serverlos und kann kostenlos verwendet werden.

Die Verwendung eines Schemas als Datenformat-Vertrag zwischen Produzenten und Verbrauchern führt zu einer verbesserten Daten-Governance sowie einer höheren Datenqualität und ermöglicht Datenkonsumenten, resistent gegen kompatible Upstream-Änderungen zu sein.

Die Schemaregistrierung ermöglicht es unterschiedlichen Systemen, ein Schema für die Serialisierung und Deserialisierung gemeinsam zu nutzen. Angenommen Sie haben einen Produzenten und Verbraucher von Daten. Der Produzent kennt das Schema, wenn er die Daten veröffentlicht. Die Schema Registry stellt einen Serializer und Deserializer für bestimmte Systeme wie Amazon oder Apache Kafka bereit. MSK

Weitere Informationen finden Sie unter So funktioniert die Schemaregistrierung.

Themen

Schemata

Ein Schema definiert die Struktur und das Format eines Datensatzes. Ein Schema ist eine versionierte Spezifikation für zuverlässige Datenveröffentlichung, -nutzung oder -speicherung.

In diesem Beispielschema für Avro werden Format und Struktur durch die Layout- und Feldnamen definiert, und das Format der Feldnamen wird durch die Datentypen definiert (z. B.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" 
                    }
                ]
            }
        }
    ]
}

In diesem Beispiel für JSON Schema draft-07 für JSON wird das Format von der Schemaorganisation definiert. 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
		}
	}
}

In diesem Beispiel für Protobuf wird das Format durch Version 2 der Protocol Buffers Sprache (proto2) definiert.

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;
}

Registrierungen

Eine Registry ist ein logischer Container mit Schemata. Eine Registry ermöglicht Ihnen, Ihre Schemata zu organisieren und die Zugriffskontrolle für Ihre Anwendungen zu verwalten. Eine Registrierung hat einen Amazon-Ressourcennamen (ARN), mit dem Sie verschiedene Zugriffsberechtigungen für Schemaoperationen innerhalb der Registrierung organisieren und festlegen können.

Sie können die Standard-Registry verwenden oder so viele neue Registries erstellen, wie nötig.

Hierarchie der AWS Glue Schema Registry

  • RegistryName: [Zeichenfolge]

    • RegistryArn: [AWS ARN]

    • CreatedTime: [Zeitstempel]

    • UpdatedTime: [Zeitstempel]

  • SchemaName: [Zeichenfolge]

    • SchemaArn: [AWS ARN]

    • DataFormat: [Avro, Json oder Protobuf]

    • Kompatibilität: [z. B. BACKWARD, BACKWARD _ALL, _FORWARD,, FORWARD _ALL,FULL,FULL] ALL NONE DISABLED

    • Status: [z. B. PENDING,AVAILABLE,DELETING]

    • SchemaCheckpoint: [Ganzzahl]

    • CreatedTime: [Zeitstempel]

    • UpdatedTime: [Zeitstempel]

  • SchemaVersion: [Zeichenfolge]

    • SchemaVersionNumber: [Ganzzahl]

    • Status: [z. B. PENDING, AVAILABLEDELETING,FAILURE]

    • SchemaDefinition: [Zeichenfolge, Wert:JSON]

    • CreatedTime: [Zeitstempel]

  • SchemaVersionMetadata: [Liste]

    • MetadataKey: [Zeichenfolge]

    • MetadataInfo

    • MetadataValue: [Zeichenfolge]

    • CreatedTime: [Zeitstempel]

Schema-Versioning und -Kompatibilität

Jedes Schema kann mehrere Versionen haben. Das Versioning wird durch eine Kompatibilitätsregel geregelt, die auf ein Schema angewendet wird. Anforderungen zur Registrierung neuer Schemaversionen werden von der Schema Registry anhand dieser Regel geprüft, bevor sie durchgeführt werden.

Eine Schemaversion, die als Checkpoint markiert ist, wird verwendet, um die Kompatibilität der Registrierung neuer Versionen eines Schemas zu ermitteln. Wenn ein Schema zum ersten Mal erstellt wird, ist der Standard-Checkpoint die erste Version. Wenn sich das Schema mit mehr Versionen weiterentwickelt, können Sie den Checkpoint mithilfe vonCLI/SDKin eine Version eines Schemas ändern UpdateSchemaAPI, die einer Reihe von Einschränkungen entspricht. Wenn Sie die Schemadefinition oder den Kompatibilitätsmodus in der Konsole bearbeiten, wird der Checkpoint standardmäßig auf die neueste Version geändert.

Mit Kompatibilitätsmodi können Sie steuern, wie sich Schemata im Lauf der Zeit entwickeln können oder nicht. Diese Modi bilden den Vertrag zwischen Anwendungen, die Daten erzeugen und Anwendungen, die Daten verbrauchen. Wenn eine neue Version eines Schemas an die Registrierung übermittelt wird, wird anhand der auf den Schemanamen angewendeten Kompatibilitätsregel ermittelt, ob die neue Version akzeptiert werden kann. Es gibt 8 Kompatibilitätsmodi:NONE,DISABLED,BACKWARD, BACKWARD _ALL, FORWARD _ FORWARDALL, FULL _. FULL ALL

Im Avro-Datenformat können Felder optional oder erforderlich sein. Ein optionales Feld ist ein Feld, in dem Type null enthält. Erforderliche Felder haben keine NULL-Werte als Type.

Im Protobuf-Datenformat können Felder in der Proto2-Syntax optional (einschließlich wiederholt) oder erforderlich sein, während in der Proto3-Syntax alle Felder optional (einschließlich wiederholt) sind. Alle Kompatibilitätsregeln werden auf der Grundlage des Verständnisses der Protokollpufferspezifikationen sowie der Leitlinien der Dokumentation zu Google Protocol Buffers bestimmt.

  • NONE: Es gilt kein Kompatibilitätsmodus. Sie können diese Option in Entwicklungsszenarien verwenden, oder wenn Sie die Kompatibilitätsmodi, die Sie auf Schemata anwenden möchten, nicht kennen. Jede neue Version, die hinzugefügt wird, wird ohne Kompatibilitätsprüfung akzeptiert.

  • DISABLED: Diese Kompatibilitätsoption verhindert die Versionierung für ein bestimmtes Schema. Es können keine neuen Versionen hinzugefügt werden.

  • BACKWARD: Diese Kompatibilitätsoption wird empfohlen, da Benutzer damit sowohl die aktuelle als auch die vorherige Schemaversion lesen können. Sie können diese Option verwenden, wenn Sie Felder löschen oder optionale Felder hinzufügen und die Kompatibilität mit der vorherigen Schemaversion überprüfen möchten. Ein typischer Anwendungsfall BACKWARD ist, wenn Ihre Anwendung für das neueste Schema erstellt wurde.

    AVRO

    Angenommen Sie haben ein Schema mit Vorname (erforderlich), Nachname (erforderlich), E-Mail (erforderlich) und Telefonnummer (optional) erstellt.

    Wenn Ihre nächste Schemaversion das erforderliche E-Mail-Feld entfernt, würde dies erfolgreich registriert werden. BACKWARDKompatibilität setzt voraus, dass Verbraucher die aktuelle und vorherige Schemaversion lesen können. Ihre Verbraucher können das neue Schema lesen, da das zusätzliche E-Mail-Feld aus alten Nachrichten ignoriert wird.

    Wenn Sie eine vorgeschlagene neue Schemaversion haben, die ein erforderliches Feld, z. B. die Postleitzahl, hinzufügt, würde dies nicht erfolgreich mit BACKWARD Kompatibilität registriert werden. Verbraucher der neuen Version könnten alte Nachrichten vor der Schemaänderung nicht lesen, da ihnen das erforderliche PLZ-Feld fehlt. Wenn das PLZ-Feld jedoch im neuen Schema als optional festgelegt wurde, würde sich die vorgeschlagene Version erfolgreich registrieren, da Verbraucher das alte Schema ohne das optionale PLZ-Feld lesen können.

    JSON

    Angenommen Sie haben eine Schemaversion mit Vorname (optional), Nachname (optional), E-Mail (optional) und Telefonnummer (optional).

    Wenn Ihre nächste Schemaversion die optionale Telefonnummereigenschaft hinzufügt, würde dies erfolgreich registriert werden, solange die ursprüngliche Schemaversion keine zusätzlichen Eigenschaften zulässt und das additionalProperties-Feld auf „False“ festlegt. BACKWARDKompatibilität setzt voraus, dass Verbraucher die aktuelle und die vorherige Schemaversion lesen können. Ihre Verbraucher können Daten lesen, die mit dem ursprünglichen Schema erstellt wurden, in dem die Telefonnummereigenschaft nicht existiert.

    Wenn Sie eine vorgeschlagene neue Schemaversion haben, die die optionale Eigenschaft Telefonnummer hinzufügt, würde diese nicht erfolgreich mit BACKWARD Kompatibilität registriert werden, wenn die ursprüngliche Schemaversion das additionalProperties Feld auf true setzt, d. h. jede zusätzliche Eigenschaft erlaubt. Ihre Verbraucher mit der neuen Version könnten alte Nachrichten vor der Schemaänderung nicht lesen, da sie keine Daten mit der Telefonnummereigenschaft als anderen Typ lesen können, z. B. „Zeichenfolge“ statt „Ganzzahl“.

    PROTOBUF

    Angenommen, Sie haben ein Schema mit einer Nachricht Person mit den Feldern first name (erforderlich), last name (erforderlich), email (erforderlich) und phone number (optional) unter proto2-Syntax definiert.

    Ähnlich wie in AVRO anderen Szenarien würde die Registrierung erfolgreich sein, wenn Ihre nächste Schemaversion das erforderliche email Feld entfernt. BACKWARDKompatibilität setzt voraus, dass Verbraucher die aktuelle und vorherige Schemaversion lesen können. Ihre Verbraucher können das neue Schema lesen, da das zusätzliche email-Feld aus alten Nachrichten ignoriert wird.

    Wenn Sie beispielsweise eine vorgeschlagene neue Schemaversion haben, die ein erforderliches Feld hinzufügtzip code, würde diese nicht erfolgreich mit BACKWARD Kompatibilität registriert werden. Verbraucher der neuen Version könnten alte Nachrichten vor der Schemaänderung nicht lesen, da ihnen das erforderliche zip code-Feld fehlt. Wenn das zip code-Feld jedoch im neuen Schema als optional festgelegt wurde, würde sich die vorgeschlagene Version erfolgreich registrieren, da Verbraucher das alte Schema ohne das optionale zip code-Feld lesen können.

    Im Falle eines RPC G-Anwendungsfalls ist das Hinzufügen eines neuen RPC Dienstes oder einer neuen RPC Methode eine abwärtskompatible Änderung. Nehmen wir beispielsweise an, Sie haben eine Schemaversion, die durch einen RPC Dienst MyService mit zwei RPC Methoden Foo und Bar definiert ist.

    Wenn Ihre nächste Schemaversion eine neue RPC aufgerufene Methode hinzufügtBaz, würde diese erfolgreich registriert werden. Ihre Benutzer können Daten, die mit dem ursprünglichen Schema erstellt wurden, je nach BACKWARD Kompatibilität lesen, da die neu hinzugefügte RPC Methode optional Baz ist.

    Wenn Sie eine vorgeschlagene neue Schemaversion haben, die die bestehende RPC Methode entferntFoo, würde diese Methode nicht erfolgreich mit BACKWARD Kompatibilität registriert werden. Ihre Benutzer der neuen Version wären nicht in der Lage, alte Nachrichten vor der Schemaänderung zu lesen, da sie mit der nicht existierenden RPC Methode Foo in einer RPC G-Anwendung keine Daten verstehen und lesen können.

  • BACKWARD_ ALL: Diese Kompatibilitätsoption ermöglicht es Verbrauchern, sowohl die aktuelle als auch alle vorherigen Schemaversionen zu lesen. Sie können diese Option verwenden, wenn Sie Felder löschen oder optionale Felder hinzufügen und die Kompatibilität mit allen vorherigen Schemaversionen überprüfen möchten.

  • FORWARD: Diese Kompatibilitätsoption ermöglicht es Verbrauchern, sowohl die aktuelle als auch die nachfolgenden Schemaversionen zu lesen, aber nicht unbedingt spätere Versionen. Sie können diese Option verwenden, wenn Sie Felder hinzufügen oder optionale Felder löschen und die Kompatibilität mit der vorherigen Schemaversion überprüfen möchten. Ein typischer Anwendungsfall FORWARD ist, wenn Ihre Anwendung für ein früheres Schema erstellt wurde und in der Lage sein sollte, ein neueres Schema zu verarbeiten.

    AVRO

    Angenommen Sie haben ein Schema mit Vorname (erforderlich), Nachname (erforderlich) und E-Mail (optional) erstellt.

    Wenn Sie eine neue Schemaversion haben, die ein erforderliches Feld hinzufügt, z. B. Telefonnummer, würde dies erfolgreich registriert werden. FORWARDKompatibilität setzt voraus, dass Verbraucher Daten, die mit dem neuen Schema erstellt wurden, mithilfe der vorherigen Version lesen können.

    Wenn Sie eine vorgeschlagene Schemaversion haben, die das erforderliche Feld für den Vornamen löscht, würde dies nicht erfolgreich mit FORWARD Kompatibilität registriert werden. Verbraucher mit der vorherigen Version könnten die vorgeschlagenen Schemata nicht lesen, da ihnen das erforderliche Vornamenfeld fehlt. Wenn das Feld für den Vornamen ursprünglich optional war, würde das vorgeschlagene neue Schema erfolgreich registriert werden, da die Verbraucher Daten basierend auf dem neuen Schema lesen können, die nicht über das optionale Feld Vorname verfügen.

    JSON

    Angenommen Sie haben eine Schemaversion mit Vorname (optional), Nachname (optional), E-Mail (optional) und Telefonnummer (optional).

    Wenn Sie eine neue Schemaversion haben, die die optionale Telefonnummereigenschaft entfernt, würde dies erfolgreich registriert werden, solange die neue Schemaversion keine zusätzlichen Eigenschaften zulässt und das additionalProperties-Feld auf „False“ festlegt. FORWARDKompatibilität setzt voraus, dass Verbraucher Daten, die mit dem neuen Schema erstellt wurden, mithilfe der vorherigen Version lesen können.

    Wenn Sie eine vorgeschlagene Schemaversion haben, die die optionale Telefonnummereigenschaft löscht, würde dies nicht erfolgreich mit FORWARD Kompatibilität registriert werden, wenn die neue Schemaversion das additionalProperties Feld auf true setzt, d. h. jede zusätzliche Eigenschaft erlaubt. Ihre Verbraucher mit der vorherigen Version könnten die vorgeschlagenen Schemata nicht lesen, da diese die Telefonnummereigenschaft als anderen Typ haben könnten, z. B. „Zeichenfolge“ statt „Ganzzahl“.

    PROTOBUF

    Angenommen, Sie haben ein Schema mit einer Nachricht Person mit den Feldern first name (erforderlich), last name (erforderlich) und email (optional) unter proto2-Syntax definiert.

    Ähnlich wie bei AVRO Szenarien würde eine neue Schemaversion, die z. B. ein erforderliches Feld hinzufügtphone number, erfolgreich registriert. FORWARDKompatibilität erfordert, dass Verbraucher Daten, die mit dem neuen Schema erstellt wurden, mithilfe der vorherigen Version lesen können.

    Wenn Sie eine vorgeschlagene Schemaversion haben, die das erforderliche first name Feld löscht, würde diese nicht erfolgreich mit FORWARD Kompatibilität registriert werden. Verbraucher mit der vorherigen Version könnten die vorgeschlagenen Schemata nicht lesen, da ihnen das erforderliche Feld first name fehlt. Wenn das Feld first name ursprünglich optional war, würde das vorgeschlagene neue Schema erfolgreich registriert werden, da die Verbraucher Daten basierend auf dem neuen Schema lesen können, die nicht über das optionale Feld first name verfügen.

    Im Fall eines RPC G-Anwendungsfalls ist das Entfernen eines RPC Dienstes oder einer RPC Methode eine vorwärtskompatible Änderung. Nehmen wir beispielsweise an, Sie haben eine Schemaversion, die durch einen RPC Dienst MyService mit zwei RPC Methoden Foo und Bar definiert ist.

    Wenn Ihre nächste Schemaversion die bestehende RPC Methode mit dem Namen löschtFoo, würde diese entsprechend der FORWARD Kompatibilität erfolgreich registriert werden, da die Benutzer die mit dem neuen Schema erstellten Daten mithilfe der vorherigen Version lesen können. Wenn Sie eine neue Schemaversion vorgeschlagen haben, die eine RPC Methode hinzufügtBaz, würde diese nicht erfolgreich mit FORWARD Kompatibilität registriert werden. Ihre Benutzer der vorherigen Version könnten die vorgeschlagenen Schemas nicht lesen, da ihnen die RPC Methode Baz fehlt.

  • FORWARD_ ALL: Diese Kompatibilitätsoption ermöglicht es Verbrauchern, Daten zu lesen, die von Herstellern jedes neuen registrierten Schemas geschrieben wurden. Sie können diese Option verwenden, wenn Sie Felder hinzufügen oder optionale Felder löschen und die Kompatibilität mit allen vorherigen Schemaversionen überprüfen möchten.

  • FULL: Diese Kompatibilitätsoption ermöglicht es Verbrauchern, Daten zu lesen, die von Produzenten mit der vorherigen oder nächsten Version des Schemas geschrieben wurden, jedoch nicht mit früheren oder späteren Versionen. Sie können diese Option verwenden, wenn Sie optionale Felder hinzufügen oder löschen und die Kompatibilität mit der vorherigen Schemaversion überprüfen möchten.

  • FULL_ ALL: Diese Kompatibilitätsoption ermöglicht es Verbrauchern, Daten zu lesen, die von Produzenten unter Verwendung aller vorherigen Schemaversionen geschrieben wurden. Sie können diese Option verwenden, wenn Sie optionale Felder hinzufügen oder löschen und die Kompatibilität mit allen vorherigen Schemaversionen überprüfen möchten.

Open-Source-SerDe-Bibliotheken

AWS stellt Open-Source-Serde-Bibliotheken als Framework für die Serialisierung und Deserialisierung von Daten bereit. Das Open-Source-Design dieser Bibliotheken ermöglicht gängige Open-Source-Anwendungen und Frameworks, diese Bibliotheken in ihren Projekten zu unterstützen.

Weitere Details zur Funktionsweise der SerDe-Bibliotheken finden Sie unter So funktioniert die Schemaregistrierung.

Kontingente in Schema Registry

Kontingente, auch Limits genannt AWS, sind die Höchstwerte für die Ressourcen, Aktionen und Elemente in Ihrem Konto. AWS Im Folgenden finden Sie weiche Grenzwerte für Schema Registry in AWS Glue.

Metadaten-Schlüssel-Wert-Paare pro Schemaversion.

SchemaVersion Pro Region können Sie bis zu 10 Schlüssel-Wert-Paare verwenden. AWS

Sie können die Schlüssel-Wert-Metadatenpaare mithilfe von oder anzeigen oder festlegen. QuerySchemaVersionMetadata Aktion (Python: query_schema_version_metadata) PutSchemaVersionMetadata Aktion (Python: put_schema_version_metadata) APIs

Im Folgenden finden Sie weiche Grenzwerte für Schema Registry in AWS Glue.

Registrierungen

Sie können bis zu 100 Registrierungen pro AWS Region für dieses Konto einrichten.

SchemaVersion

Sie können bis zu 10000 Schemaversionen pro AWS Region für dieses Konto haben.

Jedes neue Schema erstellt eine neue Schemaversion, sodass Sie theoretisch bis zu 10000 Schemas pro Konto und Region haben können, wenn jedes Schema nur eine Version hat.

Schema-Nutzlasten

Es gibt eine Größenbeschränkung von 170 KB für Schema-Nutzlasten.