Data Quality Gates
Don't train on what you wouldn't hand to a reviewer
Quality gates are automated assertions on datasets — schema, nulls, ranges, counts, distributions — that run before training or serving trusts the data. Garbage in, gates out.
What you will learn
- Write schema, completeness and distribution assertions
- Run quality gates inside pipelines before training
- Design gates that fail loudly but stay maintainable
What is this?
Data quality gates are executable assertions about a dataset — schema matches, row counts in range, null rates below thresholds, distributions within tolerance — run automatically when data arrives. A failing gate blocks the pipeline at the source rather than letting corrupt data poison a model.
Why do you need it?
- Real pipelines inflate: schema silently gains columns, nulls explode, a unit-mix bug flips a value into space.
- Fail earlier = fail cheaper: blocking at ingestion beats debugging a strange model a week later.
- Gates are contracts: data owners promise properties, consumers rely on them.
- Automated checks scale to dozens of datasets without per-pipeline babysitting.
Mental model
The quality inspector at a factory gate
Data quality gates
Parts that fail inspection never enter the assembly line. A data gate is the same choke point: a batch that fails schema or distribution checks never enters training.
How it works
- Checks are defined declaratively: schema, uniqueness, range, null-rate, min/max row count.
- A validator (Great Expectations, Soda, custom asserts) runs against the incoming dataset.
- Results compare against thresholds and a baseline reference dataset.
- Failures raise log/alert and either block or quarantine the data.
- Passing data advances, and the checks themselves are versioned with the dataset.
A data quality gate between ingestion and training.
In production
- A nightly feature build gates on row count ±10% and null_rate < 2%; a halved file alerts immediately.
- A currency-conversion fix changes a column's unit; a range check catches values 1000× too big.
- A data-quality suite runs in the same CI job as the model, so 'data changed' and 'model has context'.
Best practices
- Start with 5 high-value assertions; expand only when they earn their keep.
- Compare each batch against a baseline reference, not just hard-coded ranges.
- Fail the pipeline loudly (nonzero exit / alert), never silently patch in training.
- Review gate failures weekly; a gate that never fires is a gate nobody reads.
Common mistakes
- Thousands of brittle checks that fail daily and get ignored.
- Gates added post-hoc that nobody enforces in CI.
- Warn-only gates that quietly pass corrupted data (warn = not enforced).
- Hardcoded ranges that rot as the business grows legitimately.
Debugging tips
- Gate failed on distribution? Compare against baseline and diff columns that moved.
- Check passes locally but fails in CI? Row ordering and float precision often differ.
- Flaky row-count check? Make the window and recency explicit (e.g., last 7 days), not absolute totals.
Interview checkpoint
Hands-on lab
- Implement schema, null-rate and range checks in a reusable validator
- Run the validator against good and corrupt inputs
- Wire the gate to a nonzero exit so pipelines halt on failure
Write a Data Quality Gate
25 min · intermediate
Quick quiz
A nightly check flags the row count at 30% of normal. Best practice is to:
A 'warn only' quality gate is equivalent to no gate for catching bad data.