3. AWS Glue Catalog 实战：从架构到权限管理

Glue Data Catalog 是 AWS 湖仓体系里的「元数据中心」。说白了，它就是一个托管版的 Hive Metastore，但跟 EMR、Redshift、Athena 这些服务做了深度绑定。我最早接触它的时候，觉得不就是个表结构存储吗？后来踩了几个坑才发现，它的爬网程序、权限模型和集成方式，每个环节都有不少讲究。

3.1 Glue Data Catalog 架构

Glue Catalog 的核心组件其实不复杂，但理解它的分层结构很重要。我个人习惯把它拆成三层来看：

  • 存储层：底层用 Amazon Aurora 存元数据，包括数据库、表、分区、表属性、Schema 版本等。这部分对用户透明，你不需要关心具体存在哪。
  • API 层：提供标准的 Hive Metastore 兼容接口（Thrift API），也提供 Glue 自己的 REST API。EMR、Athena、Redshift Spectrum 都是通过这层来读写元数据。
  • 治理层：包括爬网程序（Crawler）、数据目录同步（Catalog Sync）、基于 Lake Formation 的细粒度权限控制。这部分是 Glue Catalog 区别于自建 Hive Metastore 的关键。

关键点：Glue Catalog 是 Region 级别的服务，每个 Region 独立。跨 Region 访问元数据需要额外配置，我建议尽量把计算和 Catalog 放在同一个 Region，延迟会低很多。

下面这张图展示了 Glue Catalog 在 AWS 湖仓体系中的位置：

Glue Data Catalog 架构与集成关系 Glue Data Catalog 元数据存储 · API · 治理 S3 数据湖 RDS / JDBC 其他数据源 Crawler（爬网程序）— 自动发现 Schema 并写入 Catalog Amazon EMR Amazon Athena Redshift Spectrum Lake Formation

3.2 爬网程序配置

爬网程序（Crawler）是 Glue Catalog 的「自动扫描仪」。它会遍历你的数据源，推断 Schema，然后把表结构写入 Catalog。我在项目中见过很多人直接跑默认配置，结果分区表没识别出来，或者数据类型推断错了。

3.2.1 核心配置项

配置项 说明 我的建议
数据源类型 S3、JDBC、DynamoDB 等 S3 最常用，注意选对路径前缀
包含/排除模式 支持 glob 模式过滤文件 一定要配排除模式，避免扫描临时文件
分区策略 按目录结构自动推断分区 建议开启，但注意分区层级别超过 5 层
Schema 更新 追加新列、更新类型等 生产环境选「追加新列」，别选覆盖
输出目标 指定 Catalog 数据库 每个 Crawler 对应一个库，别混用

小技巧：如果数据是 Parquet 格式，Crawler 会从文件元数据中读取 Schema，比从 CSV 推断准确得多。我一般建议数据入湖时统一转成 Parquet，这样 Crawler 几乎不会出错。

3.2.2 爬网程序配置示例

下面是一个通过 AWS CLI 创建 Crawler 的示例。注意我加了 Exclusions 参数，用来跳过临时文件和隐藏目录：

aws glue create-crawler \
  --name "sales-data-crawler" \
  --role "arn:aws:iam::123456789012:role/GlueCrawlerRole" \
  --database-name "sales_db" \
  --targets '{
    "S3Targets": [
      {
        "Path": "s3://my-data-lake/sales/",
        "Exclusions": ["**_tmp/**", "**_SUCCESS", "**.crc"]
      }
    ]
  }' \
  --schema-change-policy '{
    "UpdateBehavior": "LOG",
    "DeleteBehavior": "LOG"
  }' \
  --configuration '{
    "Version": 1.0,
    "CrawlerOutput": {
      "Partitions": { "AddOrUpdateBehavior": "InheritFromTable" }
    }
  }'

避坑指南：我曾经因为没配 Exclusions，Crawler 把 Spark 作业的临时文件也扫进去了，结果表里多出几百个无意义的分区。后来我养成了习惯——每个 Crawler 必须配排除模式，至少把 _tmp、_SUCCESS、.crc 排除掉。

3.3 与 EMR 集成

EMR 集成 Glue Catalog 是最常见的场景。你只需要在创建 EMR 集群时指定 --use-glue-catalog，或者把 hive.metastore.glue.catalogid 配好就行。

3.3.1 配置方式

用 EMR 命令行创建集群时，加上这个参数：

aws emr create-cluster \
  --name "EMR with Glue Catalog" \
  --release-label emr-6.15.0 \
  --applications Name=Spark Name=Hive \
  --ec2-attributes SubnetId=subnet-xxx \
  --instance-groups InstanceGroupType=MASTER,InstanceCount=1,InstanceType=m5.xlarge \
  --configurations '[{
    "Classification": "hive-site",
    "Properties": {
      "hive.metastore.client.factory.class": "com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory"
    }
  }]'

配好之后，你在 Spark SQL 或 Hive 里建表，元数据直接写到 Glue Catalog。其他 EMR 集群、Athena 都能看到同一张表。

经验之谈：我建议把 Glue Catalog 作为 EMR 的默认 Metastore，而不是用自带的 Derby 或 MySQL。这样你换集群、扩缩容，表结构不会丢。之前有个项目因为用了 EMR 自带的 Metastore，集群终止后元数据全没了，重建表花了两天。

3.4 与 Redshift 集成

Redshift 通过 Redshift Spectrum 查询 Glue Catalog 里的外部表。说白了，就是 Redshift 只负责计算，数据还在 S3 上，元数据走 Glue。

3.4.1 创建外部 Schema

CREATE EXTERNAL SCHEMA spectrum_sales
FROM DATA CATALOG
DATABASE 'sales_db'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftSpectrumRole'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

创建成功后，你就可以在 Redshift 里直接查询 Glue Catalog 里的表了：

SELECT region, SUM(amount)
FROM spectrum_sales.orders
WHERE dt >= '2024-01-01'
GROUP BY region;

注意：Redshift Spectrum 查询会扫描 S3 数据，费用按扫描量算。我建议在 Glue Catalog 里做好分区裁剪，查询时带上分区条件，能省不少钱。

3.5 与 Athena 集成

Athena 是 Glue Catalog 的「原生搭档」。你不需要任何额外配置，Athena 默认就用 Glue Catalog 作为元数据存储。建表、查询、删除，全走 Glue。

举个例子，在 Athena 里创建一张基于 S3 的外部表：

CREATE EXTERNAL TABLE IF NOT EXISTS sales_db.orders (
  order_id STRING,
  customer_id STRING,
  amount DOUBLE,
  dt STRING
)
PARTITIONED BY (dt)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
LOCATION 's3://my-data-lake/sales/orders/';

表创建后，Athena、EMR、Redshift Spectrum 都能看到它。这就是 Glue Catalog 的「一次建表，多处查询」能力。

避坑指南：Athena 查询超时或报错时，先检查 Glue Catalog 里的表分区是否和 S3 路径一致。我曾经遇到一个情况：Crawler 跑完后分区路径写错了，Athena 查出来全是空结果。排查了半天才发现是分区元数据的问题。

3.6 权限管理

Glue Catalog 的权限管理有两种方式：传统 IAM 策略和 Lake Formation 细粒度权限。我建议新项目直接用 Lake Formation，控制粒度更细。

3.6.1 IAM 策略基础

最基本的，你需要给计算引擎（EMR、Athena）授予 Glue Catalog 的读取权限：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "glue:GetDatabase",
        "glue:GetDatabases",
        "glue:GetTable",
        "glue:GetTables",
        "glue:GetPartition",
        "glue:GetPartitions"
      ],
      "Resource": "*"
    }
  ]
}

3.6.2 Lake Formation 细粒度权限

Lake Formation 可以控制到「某个用户只能查某张表的某几列」。配置步骤大致如下：

  1. 在 Lake Formation 里注册 Glue Catalog 的数据湖位置（S3 路径）。
  2. 创建 Lake Formation 权限策略，指定数据库、表、列级别权限。
  3. 将策略附加到 IAM 角色或用户。
  4. 在计算引擎（如 Athena）中，通过该角色查询，自动应用权限过滤。

关键点：Lake Formation 的列级权限是「透明过滤」的。用户查不到没授权的列，但查询语法不需要改。我有个金融客户就用这个功能，不同团队只能看到自己负责的字段，效果很好。

3.6.3 权限模型对比

维度 IAM 策略 Lake Formation
粒度 库/表级别 库/表/列/行级别
配置复杂度 低 中
审计能力 弱 强（自带审计日志）
适用场景 小团队、简单权限 多团队、合规要求高

我的建议：如果团队少于 10 人，权限需求简单，用 IAM 策略就够了。如果涉及跨部门、合规审计，直接上 Lake Formation。别想着先凑合用 IAM 以后再迁移——我见过一个项目迁移 Lake Formation 时，因为历史权限策略太乱，花了三周才理清楚。

嗯，Glue Catalog 的实战内容差不多就这些。从架构到爬网程序配置，再到与三大计算引擎的集成，最后是权限管理——每个环节都有一些「看起来简单但容易踩坑」的地方。你只要把 Crawler 的排除模式、分区策略、权限模型这几个关键点抓好，Glue Catalog 用起来会顺手很多。

← 上一章 📖 返回目录 下一章 →