How this track works
Ten sessions, one running pipeline. Daybreak - the coffee-subscription brand from learn-sql and learn-data-warehouse - has a warehouse now, but nothing reliably feeds it. That is your job this track: build the pipeline that ingests Daybreak's source data, moves it, reshapes it, and lands it ready for the warehouse. You will meet source systems (b2), ingestion patterns (b3), file formats (b4), transformation compute (b5), streaming and CDC (b6), storage engineering (b7-b8), and the reliability seam that hands off to operations (b9), then assemble it all in a capstone (b10).
The lifecycle and its undercurrents 7 min live
Joe Reis and Matt Housley framed data engineering as a lifecycle, not a tool list - and it stuck because it survives every tool that comes and goes. Five stages move data from where it is born to where it is used; a set of undercurrents runs beneath all of them. Learn this shape once and every tool you meet slots into it.
LiveThe five stages, in one breath3 min▶
Data is generated in source systems you usually do not control (an app database, an API, a stream of clicks). You ingest it - copy it out on some schedule. You store it in a shape and format built for what comes next. You transform it into something trustworthy and useful. You serve it to the consumer - a warehouse, a dashboard, a model. That is the whole job, repeated at every scale from a laptop to a petabyte.
- The stages are stable, the tools are not: Airflow, Spark, Kafka, dbt, Fivetran come and go - the five stages have held for decades. Learn the shape, not the logo.
- You rarely own generation: source systems belong to other teams. A huge part of DE craft is coping with sources you cannot change (session b2).
- Serving is the point: nobody thanks you for a clean pipeline nobody consumes. In this track, serving means feeding Daybreak's warehouse.
Why the lifecycle beats a tool list. A team hired for "Spark and Airflow" rebuilt everything two years later when the stack changed - but the lifecycle they were really doing never moved. Engineers who think in stages port their skills across every tool churn; engineers who think in tools get stranded.
Self-studyThe undercurrents, and which are ours3 min read▶
Beneath the five stages run six undercurrents: security, data management, data architecture, DataOps, orchestration, and software engineering. They are not stages - they are concerns present at every stage. This course lives in the stages and two of the undercurrents (data architecture, software engineering). The other two have their own home:
- DataOps + orchestration → learn-dataops: scheduling DAGs, CI/CD, testing, monitoring, infrastructure as code. We build pipelines; that course operates them reliably.
- Modeling + warehouse design → learn-data-warehouse: star schemas, SCDs, marts. We deliver clean data to its front door; it models what happens inside.
- What stays here: getting data out of sources, moving it, choosing formats and storage, and the compute that transforms it. The engineering of the pipe itself.
What data engineering owns 4 min live
Data engineering, data warehousing, and DataOps blur together in job ads, but they are three distinct crafts. Knowing the lines keeps you from re-learning what a sibling course already teaches - and tells you exactly where to hand work off.
| Craft | Owns | In this Daybreak world |
|---|---|---|
| Data engineering (here) | ingest, move, store, transform-compute | getting source data reliably to the warehouse door |
| Data warehousing | modeling: star schema, SCD, marts | what happens to the data inside the warehouse |
| DataOps | orchestrate, test, monitor, deploy | keeping the pipeline running in production |
LiveThe one-sentence test2 min▶
When a task lands on your desk, ask which verb it is. "Get this data here" is data engineering. "Shape it into facts and dimensions" is warehousing. "Make sure it runs at 2am and pages someone if it fails" is DataOps. Most real jobs blend all three, but the verb tells you which skill - and which course - the task belongs to.
Meet DuckDB, your pipeline in a tab 3 min live
Real pipelines run on clusters. Learning them should not need one. DuckDB is a full analytical engine that runs in your browser tab - it reads files, converts formats, moves and transforms data exactly like a production pipeline, minus the ops. Where a real stage needs Spark or Kafka (which cannot run in a browser), you will see the real code as a read-only snippet, clearly marked.
LiveYour first source read3 min▶
Below is a real, editable DuckDB engine running against Daybreak's raw source tables - the OLTP system you will ingest all track. Press ▶ Run. First run downloads the engine once (~8 MB, then cached).
SELECT order_id, customer_id, order_date,
typeof(order_date) AS stored_as, status
FROM orders
LIMIT 5;
order_date is stored as text (VARCHAR), not a real date - normal for an app database, painful for analytics. Cleaning that is a transform step. The source hands you what it hands you; the pipeline copes.
Run all five stages in one script ★ 12 min · everyone builds
The whole lifecycle, end to end, in one runnable pipeline. You will pull from the source (generation), copy orders out to a Parquet file (ingestion + storage), reshape into a clean daily table (transform), and produce the served result a warehouse would load. Every stage is one step.
Generation → Ingestion: read the raw orders source and write it to a Parquet file - the classic "extract to the lake" move.
Storage: read the data back from the file, proving it now lives outside the source system.
Transform: cast the text date, filter to completed orders, aggregate to daily revenue.
Serving: the final table is exactly what the warehouse's loader would pick up. Pipeline done.
-- GENERATION + INGESTION: extract the source to a Parquet file
COPY (SELECT * FROM orders) TO 'raw_orders.parquet' (FORMAT PARQUET);
-- STORAGE: the data now lives in a file, not the source system
CREATE TABLE landed AS SELECT * FROM 'raw_orders.parquet';
-- TRANSFORM: clean + shape for analytics
CREATE TABLE daily_revenue AS
SELECT CAST(order_date AS DATE) AS day,
count(*) AS orders,
count(*) FILTER (WHERE status = 'completed') AS completed
FROM landed
GROUP BY day;
-- SERVING: the table the warehouse would load
SELECT * FROM daily_revenue ORDER BY day LIMIT 8;
This is the shape of every pipeline you will ever build. Swap DuckDB for Spark, the local file for S3, and the manual run for an Airflow schedule, and this exact five-step spine is running at companies moving petabytes. The scale changes; the lifecycle does not. Everything in b2-b10 is one of these steps done properly.
Your turn: bend the pipeline ★ 10 min · build your own
Each editor starts from the raw source. Write the step, run it, read the error, fix it - that loop is the whole skill. All three run against Daybreak's source tables.
LiveQ1 · Ingest a different source table to Parquet3 min▶
COPY (SELECT * FROM customers) TO 'raw_customers.parquet' (FORMAT PARQUET); SELECT count(*) AS customers_landed FROM 'raw_customers.parquet';
LiveQ2 · Add a transform: revenue per channel4 min▶
SELECT o.channel,
ROUND(SUM(oi.quantity * oi.unit_price), 2) AS revenue
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
WHERE o.status = 'completed'
GROUP BY o.channel;
Self-studyQ3 · Which stage is the bottleneck?3 min▶
A thought exercise, no SQL. In Demo 1, three stages are nearly free (the data is tiny) and one would dominate at real scale. Which? Answer: ingestion - moving bytes across a network from a source you do not control is almost always the slow, fragile, expensive stage. That is why b2, b3, and b6 all live there. Transform is cheap once the data has landed.
Try it yourself - this week ◐ 20-30 min total
- Bookmark this page - the editor is your pipeline scratchpad, a real engine any time.
- Name the five lifecycle stages from memory, then map one pipeline you touch at work onto them. Which stage is missing or fragile?
- Take Demo 1's script and add a second transform table (revenue by customer plan). Serve both.
- For one data task on your plate, say the one-sentence test out loud: is it engineering, warehousing, or DataOps? Route it accordingly.
- Bring one source system you struggle to get data out of to session b2 - source systems is exactly what b2 is about.
Official sources covered
This track teaches the working core of the DeepLearning.AI Data Engineering Professional Certificate (Joe Reis) and Reis & Housley's Fundamentals of Data Engineering, run on a live engine instead of slides. Certificates, AWS labs, and videos stay on the official platforms. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · What are the five stages of the data engineering lifecycle, in order?
Data is generated in source systems, ingested (copied out), stored, transformed, then served to a consumer. The stages outlast every tool that implements them.
2 · A task says "schedule this pipeline to run nightly and alert on failure." Which craft owns it?
Scheduling, alerting, and monitoring are the DataOps undercurrent. This course builds the pipeline; DataOps operates it reliably. Knowing the line tells you where to hand off.
3 · Why frame data engineering as a lifecycle rather than a set of tools?
Tools come and go every few years; the generation-to-serving lifecycle has held for decades. Think in stages and your skills port across every stack change.