本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
AWS Glue 架构注册表
注意
AWS Glue 控制台中的以下区域不支持 AWS Glue 架构注册表:亚太地区(雅加达)和中东(阿联酋)。
AWS Glue 架构注册表让您可以集中发现、控制和演变数据流架构。架构定义了数据记录的结构和格式。借助 AWS Glue 架构注册表,您可以使用与 Apache Kafka、Amazon Managed Streaming for Apache Kafka
架构注册表支持 AVRO (v1.10.2) 数据格式、采用适用于架构(规范 Draft-04、Draft-06 和 Draft-07)的 JSON 架构格式extensions
或 groups
)以及 Java 语言支持,对其他数据格式和语言的支持也将推出。支持的功能包括兼容性、通过元数据获取架构、架构自动注册、IAM 兼容性,以及可选的的 ZLIB 压缩(用来减少存储和数据传输)。架构注册表属于无服务器服务,可以免费使用。
将架构用作创建者和使用者之间的数据格式合同,这样可以改进数据治理,提高数据质量,并使数据使用者能够适应兼容的上游更改。
架构注册表允许分散的系统共享序列化和反序列化的架构。例如,假设您拥有数据创建者和使用者。创建者在发布数据时知道架构。架构注册表为某些系统(如 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),允许您组织和设置注册表中架构操作的不同访问权限。
您可以根据需要使用默认注册表或创建任意数量的新注册表。
|
|
|
|
架构版本控制和兼容性
每个架构都可以有多个版本。版本控制由应用于架构的兼容性规则控制。在新架构版本的注册请求成功之前,架构注册表将根据此规则检查请求。
标记为检查点的架构版本用于确定注册架构新版本的兼容性。首次创建架构时,默认检查点将是第一个版本。随着架构发展为更多版本,您可以使用 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 库
AWS 提供开源 Serde 库,作为序列化和反序列化数据的框架。这些库的开源设计允许通用的开源应用程序和框架,以在其项目中支持这些库。
有关 Serde 库工作原理的更多详细信息,请参阅架构注册表的工作原理。
架构注册表的配额
配额,也称为 AWS 中的限制,是 AWS 账户中资源、操作和项目的最大值。以下是 AWS Glue 中架构注册表的软限制。
架构版本的元数据键值对数
每个 AWS 区域的每个 SchemaVersion 最多可以有 10 个键值对。
您可以使用 QuerySchemaVersionMetadata 操作(Python:query_schema_version_metadata) 或者 PutSchemaVersionMetadata 操作(Python:put_schema_version_metadata) API 查看或设置键值元数据对。
以下是 AWS Glue 中架构注册表的硬限制。
注册表
此账户在每个 AWS 区域最多可以有 100 个注册表。
SchemaVersion
此账户在每个 AWS 区域最多可以有 1 万个架构版本。
每个新架构都会创建一个新的架构版本,因此假设每个架构只有一个版本,则理论上每个区域每个账户最多可有 1 万个架构。
架构负载
架构负载的大小限制为 170KB。