jargon

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

  1. 01

    nothing errored, every job is green, and the number on the board is wrong by eleven percent.

    Data quality

  2. 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

  3. 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

  4. 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

  5. 05

    the failed check stops the pipeline so the bad numbers never reach the dashboard, and someone gets paged instead.

    Blocking data test

  6. 06

    the load succeeded and inserted eleven rows, where every previous day inserted about four hundred thousand.

    Volume anomaly

  7. 07

    the column has been two percent null for a year, this morning it is sixty percent, and nothing else changed.

    Null-rate check

  8. 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

  9. 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. 10

    eight thousand fact rows point at a customer id that does not exist in the customer dimension.

    Referential integrity check

  11. 11

    the average order value did not change but the shape did, because a whole segment of small orders stopped arriving.

    Distribution check

  12. 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. 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. 14

    every task is green, the run took its usual eleven minutes, and it processed zero rows.

    Silent failure

  15. 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. 16

    last quarter's published figures change after a backfill, and somebody has to tell the people who already presented them.

    Restatement

  17. 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. 18

    the table is wrong and the question 'who owns this' takes two days and three Slack channels to answer.

    Data ownership

  19. 19

    some tables are marked as certified with tests and an owner, and the rest are clearly labelled as somebody's experiment.

    Trust threshold