The vocabulary the exam assumes

Lesson 3 of 4 in The Data Service Map.

A data-engineering exam does not define its own terms. It assumes them, and then builds the deciding clause of a question out of one. A stem that says "the source emits continuously and the window must publish within thirty seconds" has told you it is unbounded and given you a freshness budget; a stem that says "duplicate rows appeared after the retry" has told you it is an idempotency question and not a transport question. If the word does not mean anything precise to you, the clause reads as background.

So this lesson is the shortest route to the rest of the path. Eight pairs do most of the work, and each one is a pair on purpose: knowing bounded only helps if you can say what changes when the data is unbounded.

Bounded / unbounded — can you read all of it, or only a window of it?
At-least-once / exactly-once — will a record arrive twice, and whose problem is that?
Row / columnar — are a record’s fields together, or a column’s values together?
OLTP / OLAP — many small keyed operations, or few enormous scans?
Schema-on-read / schema-on-write — does a bad record fail at ingestion, or surface three weeks later in a report?
ETL / ELT — is the data shaped before it lands, or after?
Lake / warehouse / lakehouse — who owns the storage, and what guarantees come with it?
Event time / processing time — when it happened, or when you saw it?

Each pair, the clause in a stem that signals it, and the mistake made by a reader who skims past the word.
The distinction	The clause that signals it	What you get wrong if you miss it
Bounded vs unbounded	"A nightly export" versus "events arrive continuously"; a window; a retention period.	You compare a stream processor with a batch job on cost, when the shape of the data had already eliminated one of them.
At-least-once vs exactly-once	"Duplicate rows appeared"; "after the retry"; "the consumer restarted".	You go looking for a delivery setting that would stop duplicates, instead of making the destination safe to write twice.
Row vs columnar	"CSV" or "JSON" against "Parquet"; "the query selects three of forty columns".	You tune the engine or add capacity, when the fix is the file format and costs one conversion job.
OLTP vs OLAP	"Single-digit millisecond lookup by customer id" versus "aggregate three years of history".	You pick the store you know rather than the store the access pattern demands, and both options look defensible.
Schema-on-read vs on-write	"The source added a field"; "the load failed"; "the report shows nulls that were not there last month".	You treat a schema change as a query bug, and fix the symptom in the report instead of the contract at the boundary.
ETL vs ELT	"Mask the identifiers before they land" versus "we need a column nobody kept".	You propose transforming in flight when the requirement needs the raw data retained, or the reverse.
Lake vs warehouse vs lakehouse	"Several engines read the same data"; "row-level updates"; "complex joins with high concurrency".	You answer with a product name instead of noticing that the requirement for atomic updates over open files is what picks the table format.
Event time vs processing time	"Devices upload when they reconnect"; "yesterday’s totals changed overnight"; "after a replay the numbers differ".	You aggregate on the clock of the machine that handled the record, which is easy, defensible-sounding and quietly wrong.

Key terms: Bounded data, Unbounded data, At-least-once delivery, Exactly-once processing, Idempotency, Columnar storage, Bytes scanned, Event time vs processing time

Interactive flashcard deck.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.