Amazon DEA-C01: 数据编目和元数据管理 — 学习指南

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

属于 Amazon Data Engineer Associate DEA-C01 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

该领域涵盖了使数据在 AWS 数据平台中可发现、可查询和可治理的元数据层。有效的编目和元数据管理可以减少分析工作的阻力，并确保下游消费者能够找到 Schema、分区、访问策略和数据血缘。此领域的 AWS 服务——Glue Data Catalog、Glue Schema Registry、Lake Formation、Athena 集成和 DataBrew——为数据发现、Schema 演进、治理和分析提供了互补的工具。理解这些服务如何交互、它们的配置细节以及典型的故障模式，对于保障运营可靠性和安全性至关重要。

AWS Glue Data Catalog 结构和操作

Glue Data Catalog 是一个区域性的、集中的元数据存储库，用于存储数据库、表、分区、连接和用户定义的分类器。其核心要素包括：

• 数据库：一个逻辑容器（使用 aws cli：aws glue create-database –database-input Name=analytics_db）。
• 表：描述一个数据集（SerDe、输入/输出格式、列、tableType EXTERNAL_TABLE）。您可以通过控制台、Glue API 或 CloudFormation 创建/更新；例如：aws glue create-table –database-name analytics_db –table-input file://table.json。
• 分区：分区键值与 S3 前缀之间的映射；分区可由 Glue 爬网程序（aws glue start-crawler –name my-crawler）管理，或通过（aws glue batch-create-partition）显式添加。

操作模式：

• 用于发现的爬网程序：为不断变化的 S3 布局安排爬网程序，选择分类器顺序（CSV/JSON/Parquet），并设置爬网程序策略以进行增量更新。
• 编程方式控制：当有事件驱动的 S3 数据到达时，优先使用 Glue API 或 Lambda 添加分区，而不是完全依赖爬网程序。
• 目录复制：Glue Data Catalog 是区域性的。对于多区域读取，可以考虑在每个区域运行爬网程序、构建自动化来复制元数据，或使用资源链接模式；设计决策取决于成本、一致性需求和跨区域查询模式。

决策标准：

• 当需要 Schema 检测且数据格式是异构的时，使用爬网程序；对于严格的 Schema 以及大容量、可预测的数据集，使用显式创建表的方式。
• 对于高频率的小文件到达场景，使用 batch-create-partition 或基于 Lambda 的分区管理，以避免爬网程序延迟并降低 Glue API 成本。

Schema 发现和演进

Schema Registry 和 Glue Schema 支持 Avro、JSON 和 Protobuf，适用于流式处理和长期的生产者/消费者契约。关键功能包括：

• 通过控制台或 CLI 注册 Schema（aws glue create-schema –schema-name orders –data-format AVRO –compatibility BACKWARD）。
• 兼容性模式：BACKWARD（消费者可以读取新数据）、FORWARD（新消费者可以读取旧数据）和 FULL（两者兼可）。根据消费者部署模式进行选择。
• Schema 强制执行：对于流式处理，将注册表与 Kinesis Data Streams、MSK 或 Kafka 客户端以及 AWS SDK 集成，以使用嵌入的 Schema 版本和验证进行序列化/反序列化。

实际配置和演进模式：

• 对于拥有众多消费者的 Avro 格式，使用 BACKWARD 兼容性以允许添加带有默认值的新字段；避免破坏性的字段移除。
• 对于跨团队的严格契约演进，要求 FULL 兼容性，并通过运行 Schema 验证的 CI 步骤来控制 Schema 变更。
• 对于字段可选且 Schema 易变的 JSON 格式，使用带有宽松默认值的 Schema 演进，但在目录中对元数据进行版本控制，以防止消费者在不知情的情况下发生故障。

决策标准：

• 当处理流式事件以及多个消费者需要一个规范的 Schema 时，使用 Schema Registry。对于批处理数据集，当其格式（Parquet/ORC）支持读取时推断 Schema 时，使用 Glue 表的 Schema。
• 通过评估您是否控制所有消费者（可以协调 FORWARD 模式）或需要安全的增量式变更（选择 BACKWARD 模式）来选择兼容性模式。

使用 Lake Formation 进行数据血缘和治理

Lake Formation 构建于 Glue Data Catalog 之上，提供精细化访问控制、审计和数据血缘控制。核心功能包括：

• LF-Tags：应用于数据库、表和列的基于标签的访问控制。在 Lake Formation 中创建 LF-Tags，分配键值对，然后通过基于标签的授权而不是基于资源的授权，向 IAM 主体授予权限。
• 列级控制：使用 LF-Tags 来屏蔽或限制列；在 Lake Formation 控制台中或使用 aws lakeformation grant-permissions 配置列级权限。
• 血缘和审计：启用 CloudTrail 和 Glue 作业指标以捕获 ETL 作业的血缘；使用 Glue 作业书签和目录中的作业书签元数据来跟踪已处理的数据。

配置模式：

• 定义一小组一致的 LF-Tag 键（例如, sensitivity:public/private/PII），并在创建表时或通过 Glue 爬网程序，使用爬网程序配置或后处理代码来自动添加标签。
• 通过 Lake Formation 委派管理员角色来委派管理权限，并向分析团队授予 Lake Formation 权限，同时限制 IAM 级别的 S3 访问。

决策标准：

• 当您需要在众多消费者之间进行集中的、列级的和基于标签的控制，并且治理/可审计性是强制要求时，使用 Lake Formation。
• 如果您的访问控制需求很简单（存储桶级别），IAM+S3 策略可能就足够了；若需要与目录集成的精细化控制，则使用 Lake Formation。

Athena 与 Glue catalog 集成

Athena 依赖 Glue Data Catalog 获取元数据。常见的集成点和操作要点包括：

• 分区处理：Athena 从 Glue catalog 读取分区。当新的 S3 分区被添加时，您必须更新 catalog。选项如下：
  • 从 Athena 运行 MSCK REPAIR TABLE db.table;；或使用带有该 SQL 的 aws athena start-query-execution 来刷新在表位置下发现的分区。
  • 在 S3 PUT 事件上使用 aws glue batch-create-partition 以编程方式添加分区（推荐用于事件驱动的流程）。
  • 通过设置 projection.enabled=true、projection.year.type=integer、projection.month.range=1 和 projection.year.range=2018,2026 等表属性来使用分区投影——这完全避免了 Glue 查找，对于非常大的分区数量至关重要。
• 查询性能和成本权衡：
  • 分区投影消除了 Glue API 调用，并为大量小分区显著降低了延迟，但要求分区命名具有确定性。
  • MSCK REPAIR TABLE 对于偶尔的临时数据到达很简单，但对于大型数据集可能会很慢。

Glue DataBrew 补充：

• 使用 DataBrew 进行无代码的分析和转换；将 DataBrew 指向 Glue Catalog 表或 S3 路径，运行分析作业，创建配方，并将输出发布回 S3 或作为新的 Glue 表。
• 当需要复杂的 Spark 逻辑时，使用 DataBrew 进行探索性质量检查，并生成转换，以便后续在 Glue ETL 中进行生产化。

决策标准：

• 当分区数量众多且遵循可预测的模式（基于日期/数字）时，使用分区投影。
• 对于事件驱动的近实时摄取，使用编程方式更新 Glue 分区。
• 仅在偶尔进行数据回填或自动化不可用时运行 MSCK REPAIR TABLE。

常见陷阱与决策标准

• Athena 查询因 S3 数据到达后 Glue 分区未更新而失败：避免仅依赖 crawlers；应为偶尔的更新运行 MSCK REPAIR TABLE，在 S3 事件上调用 aws glue batch-create-partition，或为大型可预测分区集实施分区投影。
• 选择错误的 schema registry 兼容性模式会破坏消费者：对于增量变更和消费者稳定性，选择 BACKWARD；当生产者必须与旧版消费者保持兼容时，选择 FORWARD；当双向都必须安全时，选择 FULL；在 CI 中根据消费者 schema 验证变更。
• 假设 Glue Data Catalog 是全局的：该 catalog 是区域性的。对于跨区域访问，需设计复制方案或在目标区域运行 catalog；不要假设 Glue 元数据会自动跨区域可用。
• 授予了 IAM S3 访问权限但未授予 Lake Formation 权限：Athena 和 Lake Formation 强制执行 catalog 级别的权限；除了任何 IAM 策略外，务必授予 Lake Formation 权限（以及在使用时授予 LF-Tags）。
• 分区粒度过细：使用太多微小的分区会损害查询计划和元数据开销；倾向于使用更粗的粒度（例如按天而不是按分钟分区）或使用分区投影。
• 忽略 DataBrew 角色权限：DataBrew 作业需要一个具有 Glue 和 S3 权限的服务角色；如果数据集已加密，请确保该角色拥有 Glue:GetTable、S3 读/写以及 kms:Decrypt 权限。

实际问题：用例场景

Acme Retail 公司每小时接收销售文件到 S3，这些文件按日期/小时分区。分析师在 Athena 中查询这些数据；数据加载后，用户发现查询失败且结果陈旧，因为分区在 Glue Data Catalog 中不可见。

1. 实施一个 S3 PUT 事件通知来调用一个 Lambda 函数，该函数调用 aws glue batch-create-partition 以立即注册新分区。
2. 对于旧数据或数据回填，安排一个 Athena 查询来运行 MSCK REPAIR TABLE db.sales_hourly;；或针对已知范围运行一个目标明确的 aws glue batch-create-partition。
3. 如果分区遵循严格的日期/小时命名约定，请在 Glue 表上启用分区投影（设置 projection.enabled=true 并定义年/月/日/小时属性）以消除 catalog 刷新成本。
4. 为表的敏感度添加 LF-Tags，并授予分析师 Lake Formation 权限，以便 Athena 查询被允许并受到治理。
5. 在预生产环境中使用 Glue DataBrew 来分析新的每小时文件，以捕获 schema 漂移；如果发现 schema 变更，请在 Glue Schema Registry 中注册新的 schema 版本，并在生产部署前验证其兼容性。

基本原理：自动分区注册或分区投影消除了导致 Athena 查询中断的元数据延迟；将其与 Lake Formation 治理相结合可确保安全访问，而由 DataBrew 驱动的分析可以及早捕获 schema 漂移，同时 Glue Schema Registry 保护流式和批处理消费者免受不兼容的 schema 变更的影响。

← 数据存储和数据湖架构 · 所有领域 · 数据转换和处理 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →