Chapter 1 — Key Takeaways (What Is Data Engineering?)

The one-page orientation. Come back to this when you need to explain the job to someone — a manager, a recruiter, a data scientist who thinks you build dashboards.

The one-sentence definition

Data engineering is moving data from where it is produced to where it is used, at a scale and reliability that lets someone downstream treat it as true.

The last clause is the engineering problem. Anyone can move data.

The six artifacts you produce

# Artifact Chapter Someone can point at
1 Landed raw data — preserved, not cleaned 9–17 "What did the source actually say?"
2 Conformed tables — documented grain, defined measures 6, 18–20 The table analysts query
3 Tests of the data — not just the code 23 A failing assertion, not a failing job
4 Schedules and dependencies 24 The DAG
5 Contracts with producers 17 A versioned schema
6 Documentation and lineage 30 Where a column came from

Produce only #1 and #4 and you have built a machine that moves bytes. That is not the job.

The asymmetry that explains everything

software service fails  ──▶  exception, 500, red graph, page      ──▶  found in seconds
data pipeline fails     ──▶  green DAG, populated table, chart    ──▶  found in a month
                             …and the numbers are wrong

"Did it run?" is the wrong question. "Is the output what it should be?" is the right one — and answering it requires deciding, in advance and in writing, what it should be.

The four questions to ask of any pipeline

  1. What happens if this runs twice? (Idempotency — Ch. 20 §20.3)
  2. What is the declared grain, and what test enforces it? (Ch. 23 §23.4)
  3. How would I know if this silently produced wrong data? (Ch. 25)
  4. What does this cost, per run and per year? (Ch. 33)

Idempotency, in one comparison

-- NOT idempotent: every run adds rows.  31 runs -> 11.4% revenue inflation.
INSERT INTO fct_order_item SELECT ... WHERE placed_at >= CURRENT_DATE - 3;

-- Idempotent: any number of runs converges to the same state.
BEGIN;
  DELETE FROM fct_order_item WHERE placed_at >= CURRENT_DATE - 3;
  INSERT INTO fct_order_item SELECT ... WHERE placed_at >= CURRENT_DATE - 3;
COMMIT;

Four ways to get it: delete-insert, merge/upsert on a natural key, partition replacement, content-addressed writes. Chapter 20 §20.3.

Who owns a wrong number

Symptom Owner
Load failed; credential rotated Data engineering
Load succeeded; data doesn't match source Data engineering
Data matches source; metric definition drifted Analytics engineering
Definition correct; conclusion doesn't follow Data science
Model degraded on correct fresh data ML engineering
Source system wrote garbage Product engineering (your problem to detect)
The BI tool is down SRE / platform

A system can be perfectly up and completely wrong. That case is yours.

The eras, and what survived each

Era Died Survived
DBA (80s–90s) One-database-for-everything Schemas as contracts, normalization, reading query plans
ETL (90s–00s) Drag-and-drop pipeline tools Kimball dimensional modeling, conformed dimensions, SCDs
Big data (05–15) Hadoop for 40 GB problems Move computation to data when data genuinely doesn't fit
Modern (15–) in progress Storage/compute separation, ELT, transformation in version control

Tools change; the lifecycle does not. Generate → ingest → store → transform → serve.

Kestrel Supply Co. — the numbers to remember

GMV FY2025 $182.0M
Orders 2,400,000 → $75.83 AOV, 6,575/day
Black Friday peak 41,300 orders — 6.28× average
Clickstream 14M events/day · 162/sec avg · 2,900/sec peak (18×)
Raw clickstream/year 4.19 TB JSON → 341 GB Parquet+zstd
Source DB PostgreSQL 16, 12 tables, 340 GB
Team 4 data engineers, 3 analysts, 2 scientists
The SLA daily_revenue fresh by 06:00 America/New_York; the CEO opens it at 06:15

The two numbers that drive architecture: the 6.28× peak ratio (elasticity) and the four-person team (can four people run this at 3am?).

The two framing incidents

Duplicate rows. Backfill with no DELETE, scheduled nightly, ran 31 days, inflated revenue 11.4%. Six monitoring checks, all green, all measuring the pipeline. Found by a finance reconciliation, diagnosed in 90 seconds on day 13 by asking whether the primary key was unique. → Test the data. Declare the grain. Ask what happens if it runs twice.

The $3,840 job. WHERE CAST(event_ts AS DATE) = '...' on a table partitioned by event_date. No pruning → 4.2 TB scanned instead of 34 GB.

before:  160 executors × 10.0 h × $2.400 = $3,840.00 / night  →  $1,401,600 / year
after:    24 executors ×  1.3 h × $2.400 =    $74.88 / night  →     $27,331 / year
                                                   51.3× reduction, $1,374,269 saved

In the plan, the tell is one line: PartitionFilters: []. → Cost is an engineering property, decided in code, in seconds, usually without noticing.

Reading a plan — look here first

FileScan parquet ...
  PartitionFilters: [ ... ]   ← empty means nothing was pruned. Check this FIRST.
  PushedFilters:    [ ... ]   ← empty means the reader read everything and filtered after.
  ReadSchema: struct<...>     ← more columns than you need means no projection pushdown.

Cost arithmetic — the frozen basis

Item Rate
Compute (r6i.8xlarge) $2.400 / node-hour
S3 Standard $0.023 / GB-month
S3 GET / PUT $0.0004 / $0.005 per 1,000
Snowflake credit $2.00
BigQuery on-demand $6.25 / TiB scanned

$$\text{job cost} = \text{nodes} \times \text{hours} \times \text{rate}$$

One basis, everywhere. Mixing bases produces two contradictory conclusions from one architecture. Full table in Appendix J.

The numbers rule

Every figure is exactly one of:

  1. A frozen anchor figure · 2. Arithmetic shown on the page · 3. Output from code you can run ·
  2. A citation.

There is no fifth category. Not "a number I remember." If none applies, write it qualitatively.

Three ways this goes wrong, in increasing order of damage: restating a figure slightly differently elsewhere; re-deriving from a printed, rounded value; reusing a number as a different quantity.

Your learning path

Path Chapters Giving up
Quick Start (6 wk) 1, 2, 3, 6, 7, 9, 11, 13, 18, 19, 23, 24, 34, 38 Streaming, distributed systems, governance, cost
Full Course (15 wk) all 40 Time
Streaming (9 wk) 1–4, 11, 14, 15, 17, 21, 25, 29, 32, 36, 38 Modeling depth, dbt, governance
Platform (11 wk) 1–5, 9, 10, 12, 24, 26–28, 30, 31, 33, 35, 38 Transformation depth

Chapter 38 is on every path. Chapter 4 is mandatory on the streaming path.

The acceptance criterion for everything you build

For any calendar month, net revenue from the gold layer equals net revenue from the source database to the cent — and every difference is explained by a documented, tested rule.

Not "the pipeline runs." The number is right, and you can prove it.