Serverless ETL Concepts
Serverless ETL Concepts
Glue is serverless Spark (plus lightweight Python-shell jobs) wrapped around the Data Catalog. You get crawlers that infer schema, an authoring environment (Glue Studio), job bookmarks for incremental state, and triggers — no clusters to size or patch.
Fit it to the workload: batch transforms over S3 data measured in minutes to hours with SQL/Spark logic. Choose Lambda when the job is short and simple (15-minute timeout ceiling, limited memory). Choose EMR when you need heavy custom clusters, specific Hadoop ecosystem versions, or tightly tuned instances. Glue bills per DPU-hour consumed during the run, so cost tracks data volume and complexity, not idle time.
Jobs, Catalog, and Bookmarks
Jobs, Catalog, and Bookmarks
A typical job reads a cataloged table, transforms, and writes Parquet:
args = getResolvedOptions(sys.argv, ["JOB_NAME"])
job = Job(context)
job.init(args["JOB_NAME"], args)
df = spark.read.table("raw_events")
df.filter("status = 'ok'") \
.write.mode("append") \
.parquet("s3://lake/curated/events/")
job.commit()
Job bookmarks remember which input keys were processed, so the next run picks up only new files — job.commit() advances that state. Trigger runs from S3 notifications via EventBridge, and keep table metadata in sync by having the sink update the catalog or re-running a crawler after writes.
Pitfalls and Operations
Pitfalls and Operations
Schema drift is the top failure: a new column or type change makes reads fail or silently null data — resolve with explicit mappings (DynamicFrame ResolveChoice/ApplyMapping) or by freezing schemas upstream. Bookmarks only advance on a successful commit; a crash mid-job reprocesses the batch on the next run, so downstream writes must be idempotent or you double-count.
Parallel workers routinely emit thousands of small output files — coalesce or repartition before writing. Missing IAM permissions on S3 prefixes or KMS keys surface as opaque AccessDenied at task level. Tune worker count to data size: too many DPUs on a small job burns money on coordination overhead.
Quiz
1. What is the main purpose of Glue job bookmarks?
2. A Glue job fails before job.commit(). What happens on the next run?
3. When should you pick Lambda instead of Glue?
Flashcards
Question
Glue Data Catalog
Click to reveal answer
Answer
Central Hive-compatible schema store Athena/EMR/Spectrum query against.
Question
Job bookmark
Click to reveal answer
Answer
Per-job state of processed input keys; advances on commit; reset to reprocess.
Question
Crawler
Click to reveal answer
Answer
Scans S3/JDBC, infers schema, writes table + partition metadata to the catalog.
Question
DPU-hour billing
Click to reveal answer
Answer
Glue bills compute actually used during the run — tune workers to data size.
Question
Lambda vs Glue line
Click to reveal answer
Answer
Lambda: ≤15 min simple jobs. Glue: Spark-scale ETL with catalog and bookmarks.
Revision Notes
Key Takeaways
- 1. Glue = serverless Spark + Data Catalog + incremental bookmarks
- 2. Commit-based bookmark semantics force idempotent downstream writes
- 3. Schema drift and small files are the two operational headaches to design against
Interview Tips
- • Explain exactly when a bookmark advances and what a failed commit implies for reruns
- • Compare Glue, Lambda, and EMR by job length, ecosystem needs, and billing model
Cheat Sheet
Glue: serverless Spark + catalog. Bookmarks advance on commit only → idempotent sinks. Crawler → catalog + partitions. Bill per DPU-hour: right-size workers, coalesce output, handle schema drift.