learn-data-engineering-with-phoebe / Builder session 1 of 10
Learn Data Engineering with Phoebe · Builder track · Session 1 of 10

The lifecycle in one pipeline

Data engineering is the plumbing under every dashboard, model, and warehouse. Before you learn the pieces, you will run the whole thing once: pull Daybreak's raw coffee data from a source, land it, reshape it, and hand it on - the five-stage lifecycle in a single script, live on DuckDB in your browser. No install, no cluster, no cloud bill.

🔴 Builder track Practitioners: DE · analysts · DS · PMs Runs in your browser · DuckDB Start here
0-3 · Welcome 3-18 · The lifecycle & undercurrents 18-42 · Build-along: run all five stages 42-45 · Q&A
Part 0

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).

Live - presented in session Self-study - read after class ▶ Live pipeline - editable & runnable Official sources covered
★ What you walk out with today A mental map of the whole data engineering lifecycle (generate → ingest → store → transform → serve) and its undercurrents, a clear sense of where DE ends and the warehouse / DataOps courses begin, and a browser tab that runs a real five-stage pipeline against Daybreak - editable any time.
Part 1 · covers DLAI Intro to DE M2, Fundamentals of Data Engineering

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.

The five stages Generation source systems Ingestion b2-b3-b6 Storage b4-b7 Transform b5-b8 Serving to warehouse The undercurrents (run beneath every stage) Security + data mgmt Data architecture DataOps + orchestration Software engineering The copper undercurrent (DataOps + orchestration) is the learn-dataops course, not this one.
🔍 Click to zoom - the lifecycle this whole track walks, stage by stage
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.
Real world

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.
Part 2 · where this course sits

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.

CraftOwnsIn this Daybreak world
Data engineering (here)ingest, move, store, transform-computegetting source data reliably to the warehouse door
Data warehousingmodeling: star schema, SCD, martswhat happens to the data inside the warehouse
DataOpsorchestrate, test, monitor, deploykeeping 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.

Which verb is the task? Data engineering source to warehouse door Data warehousing facts, dimensions, marts DataOps schedule, test, monitor get it here shape it run + page Most real jobs blend all three, but the verb tells you which skill - and which course - owns the task.
🔍 Click to zoom - the verb in the task tells you which course owns it
Why we keep the lines You already built the Daybreak warehouse (star schema, SCDs, marts) in the sibling course. This course does not repeat it - it builds what feeds it. When you see "now the warehouse models this", that is your cue the DE job is done.
Part 3 · your live pipeline engine

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).

✗ order_date as VARCHAR typeof(order_date) = VARCHAR looks fine until you filter or sort normal for an app database ✓ order_date cast to DATE CAST(order_date AS DATE) filter to completed orders aggregate to daily revenue Cleaning the date is a transform step - the source hands you what it hands you, the pipeline copes.
🔍 Click to zoom - the source hands you text, the transform step makes it a date
SELECT order_id, customer_id, order_date,
       typeof(order_date) AS stored_as, status
FROM orders
LIMIT 5;
Note the mess 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.
Demo 1 of 2

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;
Real world

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.

Demo 2 of 2

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.

Homework

Try it yourself - this week ◐ 20-30 min total

Source material

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:

DLAI Introduction to Data Engineering - M2: The lifecycle and undercurrentsPart 1 · the five stages + six undercurrents, framed for building
Fundamentals of Data Engineering (Reis & Housley) - lifecycle chaptersParts 1-2 · the vocabulary and the stages-over-tools mindset
DLAI Intro to DE - M1 cloud fundamentals, M3 architecturePart 1 · touched; batch vs streaming architecture is session a3/b6
DLAI Source Systems + Ingestion - M2 ETL vs ELTDemo 1 · the extract-load spine; full ingestion patterns in b3
Check yourself

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.

Builder session 1 cheat sheet · pin this

The lifecycleGeneration → ingestion → storage → transformation → serving. Five stages, stable across every tool.
UndercurrentsSecurity, data mgmt, architecture, DataOps, orchestration, software eng - present at every stage.
DE ownsIngest, move, store, transform-compute. Getting source data reliably to the consumer.
Not DEModeling/SCD → warehouse course. Orchestration/monitoring → dataops course. SQL → sql course.
The one-sentence test"Get this here" = DE. "Shape into facts" = warehouse. "Run it at 2am, page on fail" = DataOps.
DuckDB hereReal engine in your browser: reads files, converts formats, transforms. Spark/Kafka shown as snippets.
Ingestion is the hard stageMoving bytes from sources you do not control is the slow, fragile, costly part. b2-b3-b6 live there.
Running projectBuild the pipeline that feeds Daybreak's warehouse. Next: b2, connecting to source systems.