← 返回学习台
D1 · 摄取与转换 34%

Ch02 · Glue Jobs ETL 引擎

同样是清洗+转换，Lambda / Glue / EMR 三选一怎么选？这章用 japanese-climb 的 pack.py 当尺子。

🎯 先试试

japanese-climb 的 src/jclimb/pack.py 把抓取到的日文素材（raw/01_*.txt + transcripts/<video-id>/）转换成结构化学习包：axis.md、grid.json、vocab.md、patterns.md、knowledge.md。一次 pack 处理 ~5 个文件，~30 MB 文本，跑 PySpark-ish 的清洗+提取+分级逻辑，单次 ~3 分钟。要搬到 AWS 跑，选哪个？

💡 讲透

🎣 钩子：3 分钟、30MB——Lambda 看着也能跑啊，为啥非要 Glue？

🏠 生活类比：你要把一堆鱼变成生鱼片再上桌。
• Lambda像家用厨房的小刀：单条鱼能切，多了就累死，没冰柜、没真空机、没出餐记录。
• Glue像中央厨房：自动来鱼→洗切→分类→装盒→自动登记进库存系统，规模随订单弹。
• EMR像市场的批发处理厂：能扛十万吨，但你单点几条鱼也要请师傅、烧锅、上船——杀鸡用牛刀。
• Fargate是你租了个空厨房：所有设备、流程、记账你都得自己搞。

👶 深入浅出 ：

  • Glue Job = 托管 PySpark 引擎，按 DPU-hour 计费（1 DPU = 4 vCPU + 16GB）。规模 G.1X / G.2X / G.4X / G.8X 自选，自动扩缩。
  • 自带 Glue Catalog：写出的 Parquet 自动注册元数据，Athena/Redshift Spectrum/EMR 都能查。
  • 配套 Glue Crawler：扫 S3 上的文件，自动推断 schema 进 Catalog（你不用手动 CREATE TABLE）。
  • Job Bookmark：自动记住"上次处理到哪"，下次跑只处理增量。
graph LR S3raw[S3 raw/
日文 txt + 字幕] S3raw -->|S3:ObjectCreated| EB[EventBridge Rule] EB -->|启动| GJ[Glue Job
pack.py 改 PySpark] GJ -->|读元数据| GC[Glue Data Catalog
raw_corpus / vocab_pack 表] GJ -->|写 Parquet| S3cur[S3 curated/
vocab + patterns + knowledge] S3cur -.crawl.- CR[Glue Crawler
自动注册分区] CR --> GC S3cur -->|SQL 分析| ATH[Athena] style GJ fill:#fff4ef,stroke:#ff6f3c style GC fill:#eff8ff,stroke:#3b82f6

🎯 每个选项为什么对/错

❌ A · Lambda
时长（3min < 15min）和内存（30MB 文本 < 10GB）看着够。但你失去所有 ETL 平台能力：自动 schema 推断、Catalog 集成、DPU 扩缩、Job Bookmark 全没有。
真实后果：MVP 能跑；半年后日文素材涨到 500MB、并发要 10 个 pack 同时跑、要查"所有 N3 句型"——你得手写 S3 SDK、Parquet 库、手维护表元数据，等于从零造一个 Glue。
❌ B · EMR Serverless
它能做 Glue 的所有事且更灵活（自选 Spark 版本、装任意库）。但配置复杂度 >> Glue，最低成本高。
真实后果：30MB 的活用 EMR = 配 application、调 worker、月账单贵 2-3 倍——杀鸡用牛刀。EMR 的甜区是"PB 级数据 + 自定义 Spark"。
❌ D · ECS Fargate
能跑任意容器，但你要自己造：触发调度（什么时候启动？）、状态追踪、Catalog 集成、Schema 演化、Bookmark。
真实后果：等于绕开 Glue 自己造 Glue——长期维护噩梦。Fargate 的甜区是"常驻 API 服务"，不是批 ETL。
✅ C · Glue Job
托管 PySpark 引擎，DPU 自动扩缩，Catalog 集成开箱即用，Bookmark 支持增量。30MB / 3min 跑一次 G.1X DPU 几分钱。数据量上涨自动加 DPU 不用改代码。写出的 Parquet 自动可被 Athena 查——下次想问"哪些话题 N3 句型最多" 一行 SQL 搞定。

📌 考点速记

  • "PySpark ETL + 自动 schema + Catalog" → Glue Job
  • "大数据 + 自定义 Spark 配置 + 长跑批" → EMR
  • "< 15min + 单文件 + 简单逻辑" → Lambda
  • Crawler ≠ Job：Crawler 只扫 S3 推 schema 进 Catalog；Job 跑真正的转换
  • Job Bookmark：增量 ETL 自动跳过已处理文件（节省钱）
  • DPU 规格：G.1X = 4 vCPU/16GB ($0.44/DPU-hr)；G.2X / G.4X / G.8X 翻倍
  • Glue Streaming：可以用 Glue 跑流式 ETL（接 KDS / MSK），但 KDS+Lambda 通常更轻
  • DataBrew = Glue 的可视化数据清洗工具（无代码），考试可能问"非工程师做数据清洗" → DataBrew

🛠 回到 japanese-climb

对应代码：src/jclimb/pack.py + src/jclimb/pre_teach.py + src/jclimb/atom_catalog.py

当前实现：CLI 或 FastAPI 进程里跑 OpenAI 调用 + 文本处理，写文件到 ~/输出练习/<topic>/pack/。本地单文件流。

搬 AWS 完整链路：

  1. raw 素材落 s3://japanese-climb/raw/<topic>/
  2. S3 Event → EventBridge Rule → 启动 Glue Job
  3. Glue Job 跑 pack.py 的 PySpark 改写：UDF 调 Bedrock 抽 vocab/patterns，按难度分级，写 Parquet
  4. 输出 s3://japanese-climb/curated/<topic>/{vocab,patterns,knowledge}/year=.../month=.../
  5. Glue Crawler 自动扫 curated/ → Catalog 里有了 vocab、patterns、knowledge 表
  6. Athena 一行 SQL："找出所有 N3 级以上的句型按话题分组"——你data/curriculum/ja/ 现在要写脚本遍历，那时变成 SQL

Job Bookmark 用上之后：你新加了一个 raw 文件，Glue 只处理新文件不重跑全部——成本和时间都省。

📌 闪卡 · 进 Leitner 队列

G.1X DPU 规格？G.2X？
G.1X = 4 vCPU + 16 GB（标准 ETL）；G.2X = 8 vCPU + 32 GB（内存密集）；G.4X = 16/64；G.8X = 32/128。
Glue Job Bookmark 解决什么？
增量处理 — 自动记住"上次处理到哪个 S3 key / DB 行"，下次跑只处理新增。省钱省时间。开关：Job 配置里 Job bookmark = Enable。
Glue Crawler 跟 Glue Job 啥区别？
Crawler 只扫 S3 推断 schema注册到 Catalog，不做转换；Job 跑真正的 PySpark 转换代码。两者独立计费。
Glue DataBrew 是什么？
可视化的数据清洗工具（无代码），目标用户是数据分析师/非工程师。GUI 拖拽 250+ 转换函数，输出 Glue Job 可用。考点：题里出现"non-engineer / visual data prep" → DataBrew。

🔁 变体题

变体 1：团队把日志（gzip JSON）每天 1 TB 落 S3，要每小时清洗去重+按用户分区写 Parquet 入数据湖。最合适？

✅ B：1 TB/小时是 Glue 标准甜区。EMR on EC2 启停延迟大；Lambda 单文件几百 MB 内存就爆；Athena CTAS 是一次性查询场景不适合定时调度。

变体 2：Glue Job 跑完了，但 Athena 查不到新写入的 Parquet 数据。最可能的原因？

✅ B：分区表写入 S3 后必须把分区注册到 Catalog，否则 Athena 查不到。三种解法：① Glue Job 用 enableUpdateCatalog 自动；② 跑 MSCK REPAIR TABLE；③ Crawler 定时扫。Athena 读 Catalog 不是直接列 S3。