Amazon Glue 架构注册表 - Amazon Glue
架构注册表架构版本控制和兼容性开源 Serde 库架构注册表的配额
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

Amazon Glue 架构注册表

注意

Amazon Glue 控制台中的以下区域不支持 Amazon Glue 架构注册表：亚太地区（雅加达）和中东（阿联酋）。

Amazon Glue 架构注册表是一项新功能，允许您集中发现、控制和演变数据流架构。架构定义了数据记录的结构和格式。借助 Amazon Glue Schema Registry，您可以通过与 Apache Kafka、Amazon Kinesis Data Streams Amazon Managed Streaming for Apache Kafka、适用于 Apache Flink 的亚马逊托管服务等的便捷集成，在数据流应用程序上管理和强制实施架构。Amazon Lambda

Amazon Glue 架构注册表支持 AVRO (v1.10.2) 数据格式、采用适用于架构（规范 Draft-04、Draft-06 和 Draft-07）且已使用 Everit 库 验证的 JSON 架构的 JSON 架构格式的 JSON 数据格式、协议缓冲区 (Protobuf) 版本 proto2 和 proto3（不支持 extensions 或 groups）和 Java 语言支持以及其他即将推出的数据格式和语言。支持的功能包括兼容性、通过元数据获取架构、架构自动注册、IAM 兼容性，以及可选的用以减少存储的 ZLIB 压缩和数据传输。Amazon Glue架构注册表无服务器，可以自由使用。

将架构用作创建者和使用者之间的数据格式合同，这样可以改进数据治理，提高数据质量，并使数据使用者能够适应兼容的上游更改。

架构注册表允许不同的系统共享序列化和反序列化的架构。例如，假设您拥有数据创建者和使用者。创建者在发布数据时知道架构。架构注册表为某些系统（如 Amazon MSK 或 Apache Kafka）提供序列化程序和反序列化程序。

有关更多信息，请参阅 架构注册表的工作原理。

主题

架构

架构定义了数据记录的结构和格式。架构是用于可靠数据发布、使用或存储的版本化规范。

在 Avro 的此示例架构中，格式和结构由布局和字段名称定义，字段名称的格式由数据类型（例如，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" 
                    }
                ]
            }
        }
    ]
}

在此示例 JSON 架构 Draft-07 中，格式由 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
		}
	}
}

在此示例中，Protobuf 的格式由协议缓冲区语言版本 2（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;
}

注册表

注册表是架构的逻辑容器。注册表允许您组织架构以及管理应用程序的访问控制。注册表具有 Amazon Resource Name（ARN），允许您组织和设置注册表中架构操作的不同访问权限。

您可以根据需要使用默认注册表或创建任意数量的新注册表。

  • RegistryName: [字符串]

    • RegistryArn: [Amazon ARN]

    • CreatedTime: [时间戳]

    • UpdatedTime: [时间戳]

  • SchemaName: [字符串]

    • SchemaArn: [Amazon ARN]

    • DataFormat: [Avro、Json 或 Protobuf]

    • Compatibility: [eg。BACKWARD, BACKWARD_ALL, FORWARD, FORWARD_ALL, FULL, FULL_ALL, NONE, DISABLED]

    • Status: [eg。PENDING, AVAILABLE, DELETING]

    • SchemaCheckpoint: [整数]

    • CreatedTime: [时间戳]

    • UpdatedTime: [时间戳]

  • SchemaVersion: [字符串]

    • SchemaVersionNumber: [整数]

    • Status: [eg。PENDING, AVAILABLE, DELETING, FAILURE]

    • SchemaDefinition: [字符串，值：JSON]

    • CreatedTime: [时间戳]

  • SchemaVersionMetadata: [清单]

    • MetadataKey: [字符串]

    • MetadataInfo

    • MetadataValue: [字符串]

    • CreatedTime: [时间戳]

架构版本控制和兼容性

每个架构都可以有多个版本。版本控制由应用于架构的兼容性规则控制。在新架构版本的注册请求成功之前，架构注册表将根据此规则检查请求。

标记为检查点的架构版本用于确定注册架构新版本的兼容性。首次创建架构时，默认检查点将是第一个版本。随着架构发展为更多版本，您可以使用 CLI/SDK 将检查点更改为架构版本，使用遵守一组约束条件的 UpdateSchema API。在控制台中，编辑架构定义或兼容性模式会默认将检查点更改为最新版本。

兼容性模式允许您控制架构随时间发展或不能发展的方式。这些模式构成了生成和使用数据的应用程序之间的契约。将架构的新版本提交到注册表时，应用于架构名称的兼容性规则将用于确定是否可以接受新版本。有 8 种兼容性模式：NONE、DISABLED、BACKWARD、BACKWARD_ALL、FORWARD、FORWARD_ALL、FULL、FULL_ALL。

在 Avro 数据格式中，字段可能是可选字段或必填字段。可选字段是指 Type 包含 null 的字段。必填字段不会将 null 视为 Type。

在 Protobuf 数据格式中，字段可以是可选字段（包括重复字段），也可以在 proto2 语法中为必填字段，而在 proto3 语法中，所有字段均为可选字段（包括重复字段）。所有兼容性规则均基于对协议缓冲区规范以及来自 Google 协议缓冲区文档指南的了解。

  • NONE：不适用兼容模式。您可以在开发场景或者在不知道要应用于架构的兼容性模式时使用此选项。无需进行兼容性检查，接受添加的任何新版本。

  • DISABLED：此兼容性选项可防止对特定架构进行版本控制。无法添加新版本。

  • BACKWARD：建议使用此兼容性选项，因为它允许使用者读取架构的最新版本和上一个版本。当您需要删除字段或添加可选字段时，您可以使用此选项检查所有先前架构版本的兼容性。BACKWD 的典型使用案例是针对最近的架构创建应用程序时。

    AVRO

    例如，假定您有一个由名字（必填）、姓氏（必填）、电子邮件地址（必填）和电话号码（可选）定义的架构。

    如果您的下个架构版本删除了必填的电子邮件地址字段，这意味着注册成功。BACKWARD 兼容性要求使用者能够读取当前和以前的架构版本。您的使用者将能够读取新架构，因为旧邮件中的额外电子邮件地址字段将被忽略。

    如果您有建议的新架构版本添加了必填字段（例如邮政编码），这将无法成功注册 BACKWARD 兼容性。新版本的使用者将无法在架构更改之前读取旧邮件，因为他们缺少必需的邮政编码字段。但是，如果在新架构中将邮政编码字段设置为可选，则建议的版本将成功注册，因为使用者可以在没有可选邮政编码字段的情况下读取旧架构。

    JSON

    例如，假定您具有由名字（可选）、姓氏（可选）、电子邮件地址（可选）和电话号码（可选）定义的架构版本。

    如果您的下一个架构版本添加了可选的电话号码属性，则只要原始架构版本将 additionalProperties 字段设置为 False 以禁止任何附加属性，就能成功注册。BACKWARD 兼容性要求使用者能够读取当前和以前的架构版本。您的使用者将能够读取不存在电话号码属性的原始架构生成的数据。

    如果您有建议的新架构版本添加了可选的电话号码属性，则当原始架构版本将 additionalProperties 字段设置为 True，即允许任何附加属性时，这样将无法成功注册 BACKWARD 兼容性。新版本的使用者无法在架构更改之前读取旧邮件，因为他们无法读取具有不同类型的电话号码属性的数据，例如字符串而不是数字。

    PROTOBUF

    例如，假设您有一个由 Message（邮件）Person 定义的架构版本，其中 proto2 语法下包含 first name（必填字段）、last name（必填字段）、email（必填字段）和 phone number（可选字段）。

    与 AVRO 使用场景相似，如果您的下个架构版本删除了必填的 email 字段，这意味着注册成功。BACKWARD 兼容性要求使用者能够读取当前和以前的架构版本。您的使用者将能够读取新架构，因为旧邮件中的额外 email 字段将被忽略。

    如果您有建议的新架构版本添加了必填字段（例如 zip code），这将无法成功注册 BACKWARD 兼容性。新版本的使用者将无法在架构更改之前读取旧邮件，因为他们缺少必需的 zip code 字段。但是，如果在新架构中将 zip code 字段设置为可选，则建议的版本将成功注册，因为使用者可以在没有可选 zip code 字段的情况下读取旧架构。

    对于 gRPC 使用案例，添加新的 RPC 服务或 RPC 方法是一种向后兼容更改。例如，假设您拥有由 RPC 服务 MyService（包含两种 RPC 方法 Foo 和 Bar）定义的架构版本。

    如果您的下一个架构版本添加了名为 Baz 的新 RPC 方法，则这会成功注册。您的使用者将能够读取由原始架构根据 BACKWARD 兼容性生成的数据，因为新添加的 RPC 方法 Baz 是可选的。

    如果您有建议的新架构版本删除了现有的 PC 方法 Foo，这将无法成功注册 BACKWARD 兼容性。新版本的使用者无法读取架构更改之前的旧邮件，因为他们无法通过 gRPC 应用程序中不存在的 RPC 方法 Foo 了解和读取数据。

  • BACKWARD_ALL：此兼容性选项允许使用者读取架构的最新版本和所有先前版本。当您需要删除字段或添加可选字段时，您可以使用此选项检查所有先前架构版本的兼容性。

  • FORWARD：此兼容性选项允许使用者读取当前和下一个架构版本，但不一定是更高版本。当您添加字段或删除可选字段时，您可以使用此选项检查上一个架构版本的兼容性。FORDE 的一个典型使用案例是，您的应用程序是为之前的架构创建的，并且应该能够处理最新架构。

    AVRO

    例如，假定您有一个由名字（必填）、姓氏（必填）、电子邮件地址（可选）定义的架构。

    如果您有新的架构版本添加了必填字段（例如电话号码），这将成功注册。FORWARD 兼容性要求使用者能够使用先前版本读取新架构生成的数据。

    如果您有建议的架构版本删除了必填名字字段，这将无法成功注册 FORWARD 兼容性。先前版本的使用者将无法读取建议的架构，因为他们缺少必填的名称字段。但是，如果名字字段最初是可选的，则建议的新架构将成功注册，因为使用者可以根据没有可选名字字段的新架构读取数据。

    JSON

    例如，假定您具有由名字（可选）、姓氏（可选）、电子邮件地址（可选）和电话号码（可选）定义的架构版本。

    如果您的新架构版本删除了可选的电话号码属性，则只要新架构版本将 additionalProperties 字段设置为 False，不允许任何附加属性，则这样就会成功注册。FORWARD 兼容性要求使用者能够使用先前版本读取新架构生成的数据。

    如果您有建议的架构版本删除了可选的电话号码属性，则当新架构版本将 additionalProperties 字段设置为 True，即允许任何附加属性时，这样将无法成功注册 FORWARD 兼容性。先前版本的使用者无法读取建议的架构，因为他们可能有不同类型的电话号码属性，例如字符串而不是数字。

    PROTOBUF

    例如，假设您有一个由 Message（邮件）Person 定义的架构版本，其中 proto2 语法下包含 first name（必填字段）、last name（必填字段）和 email（可选字段）。

    与 AVRO 使用场景相似，如果您有新的架构版本添加了必填字段（例如 phone number），这将成功注册。FORWARD 兼容性要求使用者能够使用先前版本读取新架构生成的数据。

    如果您有建议的架构版本删除了必填 first name 字段，这将无法成功注册 FORWARD 兼容性。先前版本的使用者将无法读取建议的架构，因为他们缺少必填的 first name 字段。但是，如果 first name 字段最初是可选的，则建议的新架构将成功注册，因为使用者可以根据没有可选 first name 字段的新架构读取数据。

    对于 gRPC 使用案例，删除 RPC 服务或 RPC 方法是一种向前兼容更改。例如，假设您拥有由 RPC 服务 MyService（包含两种 RPC 方法 Foo 和 Bar）定义的架构版本。

    如果您的下一个架构版本删除了名为 Foo 的现有 RPC 方法，这将根据 FORWARD 兼容性成功注册，因为使用者可以使用先前版本读取新架构生成的数据。如果您有建议的架构版本添加了 RPC 方法 Baz，这将无法成功注册 FORWARD 兼容性。先前版本的使用者将无法读取建议的架构，因为他们缺少 RPC 方法 Baz。

  • FORWARD_ALL：此兼容性选项允许使用者读取任何新注册架构的创建者写入的数据。当您需要添加字段或删除可选字段以及检查所有先前架构版本的兼容性时，您可以使用此选项。

  • FULL：此兼容性选项允许使用者读取创建者使用先前版本或下一版本的架构写入的数据，但不是早期版本或更高版本的创建器写入的数据。当您添加或删除可选字段时，您可以使用此选项检查上一个架构版本的兼容性。

  • FULL_ALL：此兼容性选项允许创建者读取使用所有架构先前版本的创建器写入的数据。当您添加或删除可选字段时，您可以使用此选项检查所有先前架构版本的兼容性。

开源 Serde 库

Amazon 提供开源 Serde 库作为序列化和反序列化数据的框架。这些库的开源设计允许通用的开源应用程序和框架，以在其项目中支持这些库。

有关 Serde 库工作原理的更多详细信息，请参阅架构注册表的工作原理。

架构注册表的配额

配额（也称为中的 Amazon限制）是您 Amazon 账户中资源、操作和项目的最大值。以下是 Amazon Glue 中架构注册表的软限制。

架构版本的元数据键值对数

每个区域最多可以有 10 个键值对 SchemaVersion 。 Amazon

您可以使用 QuerySchemaVersionMetadata 操作（Python：查询架构版本元数据） 或者 PutSchemaVersionMetadata 操作（Python：put_schema_version_metadata） API 查看或设置键值元数据对。

以下是 Amazon Glue 中架构注册表的硬限制。

注册表

此账户每个 Amazon 区域最多可以有 100 个注册表。

SchemaVersion

对于此账户，每个 Amazon 区域最多可以有 10000 个架构版本。

每个新架构都会创建一个新的架构版本，因此，如果每个架构只有一个版本，则理论上每个区域每个账户最多可以有 10000 个架构。

架构负载

架构负载的大小限制为 170KB。