Glue Data Catalog 10 万+ 表规模元数据搜索实测：GetTables Expression 真实语义、并行策略与 Glue job vs 纯脚本成本对比
内容性质：基于公开 API 的黑盒行为实测（2026-07，cn-north-1，500 库 / 100,120 表模拟环境），结论可对客户分享。文中耗时/费用为该实测环境数据，不构成 SLA 承诺。
概述
客户常见需求：在 10 万+ 张表的 Glue Data Catalog 里按关键字模糊搜表（表名或列名），或批量导出指定库全部表的 schema。本文用 500 库 / 100,120 表（含 2 万表的倾斜大库）的真实环境实测回答四个问题：
GetTables的Expression参数到底是什么语义、能不能省 API 调用；- 这种任务怎么并行、数据倾斜（个别库表数远超其它库）怎么办；
- 用 Glue job 还是纯 Python 脚本，耗时和成本差多少；
- 会不会被 API 限流。
一句话结论：这是 API 密集型任务而非计算密集型，Spark 分布式算力用不上；单机多线程脚本（16 线程）比 Glue Spark 作业更快且近零成本；Glue job 的价值只在托管调度/日志/免运维，如需托管建议用 Python Shell（0.0625 DPU）而非 Spark 作业。
一、GetTables Expression 实测语义（文档没写清的部分）
官方文档只说 Expression 是 "filter pattern"，具体语义靠实测：
| 实测输入 | 结果 | 结论 |
|---|---|---|
*aliyun* | 命中所有含 aliyun 的表名 | glob 风格，* = 任意子串 |
*ALIYUN* | 空 | Expression 大小写敏感 |
.*aliyun.* | 同 *aliyun* | 正则风格也接受（内部 glob→Java 正则转换） |
a* / [ab]* | 前缀/字符类命中 | 前缀过滤可用 |
*k1*|*k2*|*k3* | 三个关键字的并集 | 顶层 | 是多模式 OR，一次调用命中多个关键字 |
.*(k1|k2).* | InvalidInputException: Unclosed group | 括号分组不可用（服务端做 *→.* 文本替换后正则爆炸） |
配套发现：Glue 表名存储时强制小写（建表名 dwd_ALIYUN_users 落库变 dwd_aliyun_users）。所以"不区分大小写搜索"只需把关键字 lower()，天然满足；Expression 的大小写敏感在表名场景实际无害。
二、最重要的发现：Expression 是"后过滤"，不减少分页次数
对 2 万表的单库实测三种拉取方式：
| 方式 | 分页次数 | 耗时 |
|---|---|---|
| 无 Expression 全量拉取 | 200 页 | 35.4s |
PaginationConfig={"PageSize": 1000} | 仍 200 页 | 36.7s（PageSize 无效，每页固定 ~100） |
| `Expression="k1 | k2 | k3"`（命中仅 200 张） |
即：无论过滤命中多少，分页次数恒等于 全库表数 ÷ 100。Expression 的收益是每页只回传命中行（响应体极小），实测省约 2/3 时间——值得用，但别指望它减少 API 调用量。
由此推出一个反模式警告：想用前缀 Expression（a*、b*…37 个首字符）把大库切成 shard 并行拉取是行不通的——每个 shard 都会全库扫一遍分页。实测 2 万表库：37 个前缀 shard 产生 7,943 次 API 调用（串行只要 200 次），8 并发耗时 136.8s，反而比串行 35.4s 慢 4 倍。并发越高越糟（37 并发 182.4s）。
三、并行策略与数据倾斜
- 单库分页游标（NextToken）只能顺序取 → 并行粒度的最小单位是"库"，库内无法并行（前缀切分已证伪）。
- 因此总耗时下限 = 最大库的串行分页时间：2 万表 ≈ 35s；若 10 万表集中在一个库，≈ 3 分钟，加任何计算资源都无法缩短。
- 唯一能做的优化：把已知的大库排在任务列表最前，优先调度，避免它成为长尾。
四、Glue Spark 作业 vs 纯 Python 脚本（同逻辑同数据实测）
任务：全账号 507 库关键字搜表（命中 1,034 张）+ 10 库共 32,470 表 schema 导出。
| 配置 | 端到端耗时 | DPU-秒 | 单次费用（¥3.021/DPU-时，cn-north-1） |
|---|---|---|---|
| Glue 5.0 G.1X × 2 | 383s | 767 | ≈ ¥0.64 |
| Glue 5.0 G.1X × 5 | 156s（含 Spark 启动 ~35s） | 780 | ≈ ¥0.66 |
| Glue 5.0 G.1X × 10 | 290s* | 2906 | ≈ ¥2.44 |
| 单机脚本 16 线程（boto3 + ThreadPoolExecutor） | ~70s | — | ≈ ¥0（API 在免费额度内） |
* ×10 那轮跑的是含反模式切分的旧版代码，但与 ×5 旧版（299s）对比已说明问题：worker 翻倍，耗时不变，费用翻倍——瓶颈在 Catalog API 吞吐（实测 ~5.7 页/秒/线程），不在算力。
费用模型（可直接给客户）：
- Data Catalog API：每月前 100 万次请求免费，超出 ¥7.09/百万次。单次全账号扫描（10 万表）约 1,100 次调用，天天跑也在免费额度内。
- Data Catalog 存储：前 100 万对象免费，10 万表存储 ¥0。
- Glue job 按 DPU 时长计费（按秒、最低 1 分钟）；同逻辑放 Python Shell（0.0625 DPU）单次 < ¥0.1，是比 Spark 作业更合适的托管形态。
五、限流实测
- GetTables（读）：16~37 并发线程下用 botocore
after-call事件精确计数，0 次 ThrottlingException（7,943 次调用样本）。读场景无需担心限流，boto3Config(retries={"max_attempts": 20, "mode": "adaptive"})兜底即可。 - CreateTable（写，仅铺测试环境时相关）：24 线程 ~140 请求/秒打 10 万次，触发 358 次 SDK 自动重试 + 16 次
ConcurrentModificationException硬失败（同库高并发写冲突，属 AlreadyExists/重试可恢复类）。高并发写同一个库要预留重试与补偿逻辑。
六、Lake Formation 环境的静默漏表坑
LF 管控的 catalog 里，GetTables 对无权限的表直接不返回、不报错（部分列授权时列信息也会被裁剪）。批量元数据任务务必：
- 给执行角色全库表的
DESCRIBE元数据权限（或数据湖管理员）； - 首次运行后核对输出表总数是否符合预期，防静默遗漏。
七、推荐实现要点（Python/boto3）
glue = boto3.client("glue", config=Config(
retries={"max_attempts": 20, "mode": "adaptive"},
max_pool_connections=64))
# 需求1：多关键字 OR 搜表名（关键字 lower 即不区分大小写；限字母/数字/下划线）
expression = "|".join(f"*{k.lower()}*" for k in keywords)
# 并行粒度 = 库；ThreadPoolExecutor(16) 逐库 paginate(DatabaseName=db, Expression=expression)
# 需求2：指定库全量导出：直接逐库 paginate，大库排在列表最前
# schema 就在返回体里：StorageDescriptor.Columns + PartitionKeys，无需额外 API
注意：Expression 中 *、|、?、[] 是特殊字符，用户关键字需白名单校验（[a-z0-9_]+），含特殊字符时回退为全量拉取 + 客户端过滤。
参考
- GetTables API / Paginator：https://docs.aws.amazon.com/boto3/latest/reference/services/glue/paginator/GetTables.html
- Glue 中国区定价：https://www.amazonaws.cn/glue/pricing/
- Lake Formation 元数据权限（DESCRIBE）：https://docs.amazonaws.cn/lake-formation/latest/dg/lf-permissions-reference.html