jargon

Tracks·Data engineering·55 terms

Data Engineering

Where the numbers come from and what shapes them: ingestion, orchestration, modelling, storage and the machinery for knowing it is wrong.

Read in order · tick what you already know

  1. 01

    the dashboard renders perfectly and every number on it is from Thursday.

    Data freshness

  2. 02

    someone asked what one row means and three people in the room gave three different answers.

    Grain

  3. 03

    two dashboards show different revenue because one includes refunds and neither of them says so anywhere.

    Metric definition

  4. 04

    the vendor added three columns and renamed one over the weekend, and nobody told anybody.

    Schema drift

  5. 05

    the query returned four rows and the console says it read two point one terabytes.

    Bytes scanned

  6. 06

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

    Silent failure

  7. 07

    the report was wrong and the reason turned out to be six hops upstream in something nobody on your team owns.

    Data pipeline

  8. 08

    two systems disagree about the customer's address and you need to be able to say, without arguing, which one is allowed to be right.

    System of record

  9. 09

    the data was cleaned and reshaped by a job in the middle, and the warehouse only ever saw the tidy version.

    ETL

  10. 10

    you dumped the source table into the warehouse untouched and did all the shaping afterwards, in SQL, where everyone could read it.

    ELT

  11. 11

    nothing at all happened for twenty-three hours and then a job read the whole day at once.

    Batch processing

  12. 12

    records are handled one at a time as they land, and the job has been running without finishing for four months.

    Stream processing

  13. 13

    the job reads all four hundred million rows every night because nobody could work out which ones had changed.

    Full load

  14. 14

    each run asks the source only for rows changed since the last run, and one row updated in the same second as the cutoff is now missing forever.

    Incremental load

  15. 15

    the job stores the largest updated_at it has seen and asks for everything greater than that next time.

    High-water mark

  16. 16

    you tail the database's own replication log, so a delete and a mid-second update both come through without the source running a single extra query.

    Log-based CDC

  17. 17

    you re-ran the load after a failure and the rows updated in place instead of appearing twice.

    Upsert

  18. 18

    the same event is in the table three times because the connector retried, and you keep the latest by version per key.

    Deduplication

  19. 19

    you ran the same job three times after a failure and the output table is identical to running it once.

    Idempotent pipeline

  20. 20

    something has to decide that the transform runs only after all four extracts finished, and retry the one that did not.

    Orchestrator

  21. 21

    the pipeline is drawn as boxes with arrows, nothing points backwards, and a step waits for everything pointing at it.

    DAG

  22. 22

    the job is set to hourly, takes seventy minutes, and now two copies are running at once.

    Schedule interval

  23. 23

    the run that started at 02:00 on Tuesday is processing Monday's data, and half the confusion in the team is about which date the run is named after.

    Logical date

  24. 24

    the logic was wrong for three months, so you re-run the same job for ninety past days and hope nothing downstream notices mid-way.

    Pipeline backfill

  25. 25

    the file arrives in a bucket exactly as the vendor sent it, wrong headers and all, and nothing touches it there.

    Landing zone

  26. 26

    the supplier renamed a column overnight and you fixed it in one place instead of in forty downstream queries.

    Staging layer

  27. 27

    the same data exists three times: exactly as it arrived, cleaned and typed, and shaped for a specific report.

    Medallion architecture

  28. 28

    you stopped copying the application's tables into the warehouse and started shaping it around what happened and what it happened to.

    Dimensional modelling

  29. 29

    the table has one row per order line, a handful of numbers you can add up, and the rest is foreign keys.

    Fact table

  30. 30

    everything you would ever put in a group-by or a filter — country, product name, channel — lives in one wide, short table.

    Dimension table

  31. 31

    every dimension is one join away from the fact, so no query needs more than a single hop to get a label.

    Star schema

  32. 32

    the dimension row has a meaningless integer id of your own invention, which is why the source renumbering its customers did not break anything.

    Surrogate key

  33. 33

    you joined on the email address, and then two people changed their email and one of them was reused by a new account.

    Natural key

  34. 34

    a customer moved from Leeds to Bristol, and now you have to decide whether their orders from last year happened in Leeds or in Bristol.

    Slowly changing dimension

  35. 35

    the change closes the old dimension row with an end date and opens a new one, so the customer now has three rows and only one is current.

    SCD type 2

  36. 36

    there are no directories really, listing a prefix with a million keys is slow, and you cannot append to a file.

    Object storage

  37. 37

    everything anyone might ever need is in a bucket as files, in whatever shape it arrived, and finding the useful part is your problem.

    Data lake

  38. 38

    the data is in typed, governed tables you query in SQL, and getting anything in means agreeing a schema first.

    Data warehouse

  39. 39

    the tables are open files in a bucket and you still get transactions, schema enforcement and a rollback.

    Lakehouse

  40. 40

    the files are columnar with statistics in the footer, so the engine can skip whole chunks without reading them.

    Parquet

  41. 41

    the query reads three columns out of two hundred and only touches the bytes for those three.

    Columnar format

  42. 42

    you filtered on the partition column and the engine opened four folders instead of nine hundred.

    Partition pruning

  43. 43

    the phone was in a tunnel, so the tap happened at 14:02 and your job saw it at 16:40, and the hourly chart has to put it at 14:00.

    Event time

  44. 44

    yesterday's total went up this morning, because eight hundred events from a phone that was offline finally arrived.

    Late-arriving data

  45. 45

    the job announces that it believes nothing older than 14:30 is still coming, and closes every window that ended before then.

    Watermark

  46. 46

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

    Data quality

  47. 47

    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

  48. 48

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

    Null-rate check

  49. 49

    the number is wrong and you need to know every table between it and the source, without reading forty SQL files.

    Data lineage

  50. 50

    the source team changed a status code's meaning, the pipeline kept running, and your funnel report has been wrong since Tuesday.

    Upstream drift

  51. 51

    the source team's deploy pipeline fails if they remove a field your models depend on, because the expectation is written down and checked.

    Data contract

  52. 52

    a free-text notes column turned out to contain names and phone numbers, and it had been copied into six downstream tables.

    Personally identifiable information

  53. 53

    one dashboard refreshing every five minutes turned out to be a third of the monthly warehouse bill.

    Query cost

  54. 54

    you partitioned by customer id, there are two million customers, and now every query lists two million tiny folders.

    Partitioning strategy

  55. 55

    ninety-nine tasks finished in twenty seconds and the hundredth ran for eleven minutes, because one key has forty percent of the rows.

    Data skew