2. AWS数据治理服务地图

AWS 的数据治理能力并不是由某一个“全能服务”提供的，而是由一组职责边界清晰的服务拼装而成。理解这张服务地图的关键，不是记住每个服务的功能清单，而是回答三个问题：谁负责描述数据（元数据）、谁负责控制访问（权限与安全）、谁负责记录与验证（审计与合规）。把这三个问题分开看，就能避免把 Glue Data Catalog 当成权限系统、把 Lake Formation 当成数据目录、把 Macie 当成访问控制工具这类常见混淆。

一、元数据层：Glue Data Catalog 是“技术元数据的账本”

Glue Data Catalog 是 AWS 上最核心的元数据存储，它保存的是技术元数据：数据库、表、列名、数据类型、分区结构、SerDe 序列化信息、表在 S3 上的物理位置（Location）。Athena、Redshift Spectrum、EMR、Glue ETL 都通过它来“找到数据长什么样、在哪里”。

需要明确它的边界：Catalog 本身不存储数据，也不负责行级/列级权限。它更像一本账本，记录“有哪些表、字段是什么”。业务含义（比如 cust_id 是客户主键、phone 属于个人敏感信息）属于业务元数据，Catalog 原生并不承载，需要靠标签、分类或上层目录服务补充。

一个典型的建表元数据示例（教学示例，非实测结果）：

{
  "Name": "orders",
  "StorageDescriptor": {
    "Columns": [
      {"Name": "order_id", "Type": "string"},
      {"Name": "cust_id",  "Type": "string"},
      {"Name": "amount",   "Type": "decimal(10,2)"},
      {"Name": "phone",    "Type": "string"}
    ],
    "Location": "s3://datalake-curated/orders/"
  },
  "PartitionKeys": [{"Name": "dt", "Type": "string"}]
}

这里 phone 字段在技术元数据上只是一个 string，但它在治理语义上是敏感字段——这个“技术元数据”与“业务/安全元数据”的落差，正是后续 Lake Formation、Macie、DataZone 要填补的地方。

二、权限层：Lake Formation 是“数据湖的访问控制中枢”

Lake Formation 建立在 Glue Data Catalog 之上，提供集中式权限管理。它把权限从“每个引擎各自配置”收敛为“在 Lake Formation 里授予”。核心能力包括：

• 表/列级权限：可以只授予 orders 表的 order_id、amount 列，隐藏 phone。
• 行级过滤：通过 Data Filters 表达式，如 region = 'cn-north-1'，让不同团队只看到自己区域的数据。
• LF-Tags（标签授权）：给库表打标签（如 classification=confidential），按标签批量授权，避免逐表配置。

边界同样要清楚：Lake Formation 管的是“谁能访问哪些数据”，它不判断数据内容是否真的敏感，也不生成审计报告。它依赖 Catalog 的元数据来定位对象，依赖 IAM 来识别主体。

三、发现与敏感识别层：Macie 与 DataZone 分工不同

Macie 是敏感数据发现服务。它用机器学习与模式匹配扫描 S3 对象，识别身份证号、银行卡号、手机号等敏感信息，并给出敏感数据发现结果（Finding）。它回答的是“数据里到底有没有敏感内容”，而不是“谁能访问”。因此 Macie 的发现结果常被用来反向校验 Lake Formation 的权限是否过宽。

DataZone 则面向业务数据目录与数据产品管理。它把技术资产包装成“数据产品”，补充业务描述、负责人、订阅审批流程，让业务用户能“找到并申请”数据。它更接近“数据资产门户 + 治理流程”，而不是底层权限引擎。

四、审计与合规层：CloudTrail 与 Config

CloudTrail 记录谁在什么时候调用了什么 API，例如谁修改了 Catalog 表结构、谁调用了 Lake Formation 授权接口。它是操作审计的事实来源。

Config 记录资源配置的历史与合规状态，通过规则（Config Rules）判断资源是否符合预期，例如“S3 桶是否开启加密”“Glue 表是否缺少分类标签”。它回答的是“配置是否合规、是否发生了漂移”。

两者互补：CloudTrail 看“动作”，Config 看“状态”。

五、协作关系：一张图看清数据流与职责边界

下面这张图把上述服务按“元数据 → 权限 → 发现 → 审计”的协作链组织起来，重点表现它们之间的依赖方向与职责边界，而不是简单罗列服务名。

六、技术边界的判断准则

在实际项目中，可以用一组判断问题快速定位该用哪个服务：

把这张地图记牢，后续无论是设计数据湖权限模型、排查越权访问，还是应对合规审计，都能快速判断“该动哪个服务、不该动哪个服务”，从而避免把治理问题错误地压给某一个组件。