jargon

Subjects·8 topics·203 terms

Data engineering

Pipelines, streams, warehouse modelling, file formats, data quality and what a query costs.

Start with these 55, in order

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

All of data engineering

Every term in this subject, 203 of them, grouped into 8 topics. Each topic is a track of its own.

Every pipeline starts with somebody else's database that was never designed to be read by you. This is the vocabulary of getting rows out of it repeatedly, without asking permission each time and without melting the thing you are reading from.

Batch has one clock. A stream has two, and almost every confusing streaming bug is the gap between them: the moment something happened and the moment your code found out. These are the words for that gap and for what you are allowed to do while you wait.

A warehouse schema is a user interface for people writing SQL under time pressure. The vocabulary here is thirty years old and still the fastest way to settle an argument about why a dashboard is double-counting.

Underneath every lakehouse is a folder of files, and most of its performance and most of its failures come from how those files are written. Knowing these words is the difference between tuning a query and guessing at one.

The code is the easy part. This is the vocabulary of the thing that runs it every night, of what happens when one run fails, and of finding out what else is now wrong because it did.

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.

Two people quote different revenue figures and both are right, because the number was defined twice. Half of this cluster is about that; the other half is about the rows you are legally not allowed to keep.

Warehouse compute is billed by what you read, so data layout is a budget decision rather than a tuning detail. These are the words for why one query costs pennies and the same answer costs four hundred pounds.