Skip to content

AWS Glue visual etl: Issues while overwriting files on s3

0

I am building a Lakehouse solution using aws glue visual etl. When writing the dataset using the target s3 node in visual editor, there is no option to specify writemode() to overwrite When i checked in the generated script, it shows .append() as default glue behaviour, and i am shocked to say there is no option to change that behaviour.Tried with different file format like parquet/iceberg, same issue

This is leading to duplicates in the silver and ultimately impacting all downstream layers. Has anyone faced this issue and figured out a solution And doing changes directly in the spark scripts is my last option!!

asked 8 months ago143 views

1 Answer
0

Root cause (by design behavior) In AWS Glue Visual ETL, the S3 target node defaults to append() semantics and does not currently expose a configurable write mode (overwrite) in the visual editor. This is intentional: Visual ETL is optimized for incremental pipelines and avoids destructive operations by default. As a result, every run appends data, which can lead to duplicates in downstream (silver/gold) layers.

Why this happens The generated Spark script is opinionated and managed by the visual abstraction. Even when using formats like Parquet or Iceberg, the visual S3 target still emits append logic unless custom code is introduced.

Recommended mitigation patterns 1. Use a custom Spark transform Insert a custom transform node and explicitly control the write logic, e.g. mode("overwrite"), partition overwrite, or conditional deletes. This is the most flexible and supported approach. 2. Pre-clean the S3 prefix Add a pre-action (Lambda or Glue job step) to delete the target S3 prefix before writing. This preserves Visual ETL while enforcing overwrite semantics. 3. Leverage table formats correctly For Iceberg/Hudi, manage overwrite or merge semantics at the table level (e.g., overwrite partitions, MERGE INTO) rather than relying on the visual S3 target defaults. 4. Architectural guidance Use Visual ETL primarily for bronze / incremental ingestion. For deterministic overwrite logic in silver layers, script-based Glue jobs or table-format–managed writes are a better fit.

Summary This is not a bug but a design limitation of Glue Visual ETL. When overwrite semantics are required, introducing a custom transform or managing writes at the table level is the recommended and supported pattern.

answered 8 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.