SageMaker Visual ETL Data Quality Guide

Quick answer

Add Evaluate Data Quality to a SageMaker Unified Studio Visual ETL flow when data needs DQDL checks in transit, before or between downstream transforms and writes.

The node can publish metrics to CloudWatch, write detailed results to S3, stop the job on a rule-set failure, and expose multiple outputs for custom routing. Those options need an explicit failure contract; a checked box is not an incident response plan.

Configure the transform

Place the node after the source or transformation whose output must be checked. Give each node a unique ruleset name when a job has multiple evaluation points.

Write DQDL rules for known requirements such as:

• required columns and non-null identifiers;
• row-count floors or ceilings;
• accepted value ranges;
• uniqueness;
• schema or length constraints;
• referential integrity where supported;
• domain-specific SQL checks.

Keep rule severity and owner outside the expression so operations knows whether a failure should block, quarantine, warn, or continue.

Choose outputs deliberately

AWS documents five output choices:

Output	Use
Original data	Continue the original stream or pair with a stop-on-failure policy
Evaluation results	Route rule expressions and pass/fail status to custom handling
Row-level results	Keep source rows plus rule-result columns
Failed rows	Quarantine or inspect only failed records
Passed rows	Continue only records that passed the selected row-level checks

Row-level filtering is powerful but can create silent data loss. Reconcile input, passed, failed, duplicated, and written row counts for every run.

Publish evidence

Enable CloudWatch publishing for operational metrics and alerting. Use S3 for detailed result retention when the data classification, encryption, access, lifecycle, and cost policy allow it.

Record:

• job, run, node, and ruleset version;
• source and target dataset versions;
• total, passed, failed, quarantined, and written rows;
• rule metrics and evaluation messages;
• stop or continue decision;
• retry, correction, and replay identifiers.

Do not place raw sensitive rows in a broad log destination just to simplify debugging.

Stop-on-failure tradeoff

Stopping protects downstream targets when a critical invariant fails. It can also create missed SLAs, repeated retries, duplicate writes, or partial output if the surrounding job is not designed for atomic recovery.

Before enabling it:

1. classify rules into block, quarantine, and observe;
2. test whether upstream or side outputs already committed;
3. make retries idempotent;
4. define who corrects data versus rules;
5. prove replay from the last safe point;
6. alert on both rule failure and evaluation-system failure.

Add anomaly observations without replacing rules

Profiles can learn normal behavior over repeated runs and surface anomalies. Keep fixed invariants such as non-null keys or legal value sets in DQDL. Use anomalies for unexpected statistical movement that deserves investigation.

An anomaly is not a root-cause diagnosis, does not automatically lower the quality score, and can enter the later baseline unless reviewers provide feedback.

See the profiling and anomaly guide and profiles versus rules comparison.

Frequently asked questions

What does Evaluate Data Quality do in Visual ETL?

It evaluates DQDL rules as data flows through a processing job and can output original data, rule results, row-level results, failed rows, or passed rows.

Can a Visual ETL job stop when a quality rule fails?

Yes. AWS documents a stop-job-on-ruleset-failure option. Test the exact failure, partial-output, retry, and recovery behavior before production.

Should every failed row be dropped automatically?

No. Route failed rows according to a reviewed business policy. Some failures require quarantine, correction, replay, exception handling, or upstream investigation.

Official sources

• AWS: Evaluate Data Quality transform
• AWS: In-transit versus at-rest evaluations
• AWS Glue: DQDL reference

Source check: August 19, 2026. Recheck supported rules, outputs, publishing, row-level behavior, stop semantics, permissions, encryption, retries, and costs before deployment.