Data engineering·topic 6 of 8
Quality, tests and knowing it is wrong
A broken service pages you. Broken data does not — it simply arrives, gets averaged into a number and shows up in a board deck. These are the terms for catching it first, and for the conversation after you did not.
Read in order · tick what you already know
- 01
nothing errored, every job is green, and the number on the board is wrong by eleven percent.
Data quality
- 02
you split 'the data is bad' into six specific claims, and it turns out only one of them is actually true.
Data quality dimensions
- 03
the transform ships with a check that this column is never null, and the check runs against real output every night rather than against a fixture.
Data test
- 04
you write down that this column should be between zero and one hundred and that ninety-nine percent of rows should have an email, and it is checked automatically.
Data expectation
- 05
the failed check stops the pipeline so the bad numbers never reach the dashboard, and someone gets paged instead.
Blocking data test
- 06
the load succeeded and inserted eleven rows, where every previous day inserted about four hundred thousand.
Volume anomaly
- 07
the column has been two percent null for a year, this morning it is sixty percent, and nothing else changed.
Null-rate check
- 08
the key you have been treating as unique turns out to have four hundred duplicates, which is why the join inflated the total.
Uniqueness test
- 09
the same event is in the table three times because the connector retried, and you keep the latest by version per key.
Deduplication
- 10
eight thousand fact rows point at a customer id that does not exist in the customer dimension.
Referential integrity check
- 11
the average order value did not change but the shape did, because a whole segment of small orders stopped arriving.
Distribution check
- 12
you count the rows in the source and in the warehouse for the same period and prove that the numbers agree.
Row-count reconciliation
- 13
before merging, you run both versions of the model and see that exactly nine hundred rows differ, all in one region.
Data diff
- 14
every task is green, the run took its usual eleven minutes, and it processed zero rows.
Silent failure
- 15
the numbers were wrong from Tuesday 02:00 until someone noticed on Thursday afternoon, and that gap is the thing worth measuring.
Data downtime
- 16
last quarter's published figures change after a backfill, and somebody has to tell the people who already presented them.
Restatement
- 17
you get told that a table's volume, freshness and schema look unusual without anyone having written a test for that table.
Data observability
- 18
the table is wrong and the question 'who owns this' takes two days and three Slack channels to answer.
Data ownership
- 19
some tables are marked as certified with tests and an owner, and the rest are clearly labelled as somebody's experiment.
Trust threshold