MLOps & Data Engineering

Module 8 of 18

Module 8: Data Lakes & Lakehouses

5 min read889 words
What you'll learn
Explain what a data lake isCompare lakes and warehousesUnderstand the "lakehouse" ideaRecognize the risk of a "data swamp"

"A warehouse wants clean, structured data. A lake takes everything — raw, messy, any format — and sorts it out later. The lakehouse blends both."

Level: Intermediate · Time: ~3 days · Prerequisites: Module 7

Learning Objectives

By the end of this module, you will be able to:

  • Explain what a data lake is
  • Compare lakes and warehouses
  • Understand the "lakehouse" idea
  • Recognize the risk of a "data swamp"

1. What Is a Data Lake?

A data lake stores vast amounts of raw data in any format — structured tables, JSON logs, images, video, audio — usually in cheap cloud object storage. You don't have to define a schema up front; you dump it in now and decide how to use it later ("schema-on-read").

Explain like I'm new: A warehouse is a tidy pantry where everything is labeled and shelved before it goes in. A lake is a giant walk-in fridge where you toss everything as-is and organize it when you cook. The lake is flexible and cheap; the pantry is fast to serve from.

2. Lake vs Warehouse

Data LakeData Warehouse
DataRaw, any formatCleaned, structured
SchemaOn read (later)On write (up front)
CostVery cheap storageMore expensive
Best forML, raw archives, flexibilityFast business analytics

Neither is "better" — they serve different needs, which is why many companies use both.

3. Why Lakes Matter for ML

Machine learning loves raw data — images, text, logs — often in formats warehouses don't handle well. Lakes store all of it cheaply, keeping the full raw history so you can re-process it with new ideas later. That flexibility is gold for data science and ML.

Concept: Warehouses throw away detail to stay tidy; lakes keep everything. For ML, that preserved raw detail is often exactly what you need to engineer new features or train new models.

Consider an image-classification team. They can't store millions of raw photos in a warehouse — warehouses are built for rows and columns, not JPEGs. A lake holds those photos cheaply, alongside their labels and metadata. When the team invents a new idea (say, cropping faces before training), they reach back into the original full-resolution images and re-process them. A warehouse-only shop would have thrown that raw detail away long ago.

4. The Lakehouse

Why choose? A lakehouse (Databricks/Delta Lake, Apache Iceberg) adds warehouse-like structure, reliability, and fast SQL on top of cheap lake storage — one platform for both raw data and clean analytics.

Concept: The lakehouse is the modern convergence: the low cost and flexibility of a lake with the reliability and query speed of a warehouse. It's why the old "lake vs warehouse" debate is fading.

Historically teams ran both a lake and a separate warehouse, copying data between them and maintaining two systems — expensive and error-prone, with the two often disagreeing. The lakehouse adds a transactional table layer on top of plain lake files, so the same storage can hold raw data and answer fast, reliable SQL queries. You get one copy of the data, one system to govern, and fewer chances for the lake and warehouse versions of the truth to drift apart.

5. Avoiding the Data Swamp

A lake's flexibility is also its danger. Dump data in with no organization, catalog, or governance, and it becomes a data swamp — a murky dump nobody can find anything in or trust.

Common mistake: Treating "schema-on-read" as "no organization ever." Without a data catalog, naming conventions, and governance (Module 10), a lake rots into a swamp. Flexibility still needs discipline.

What separates a healthy lake from a swamp is usually not the technology but the habits around it: consistent folder structures (by source and date), a catalog that records what each dataset is and who owns it, and clear rules about who can write where. Picture a warehouse full of unlabeled boxes versus one with a searchable inventory. Same building, wildly different usefulness. The lakehouse trend partly exists because it bakes some of this discipline in by default.

✅ Checkpoint

  1. How does a data lake differ from a warehouse in how it handles schema?
  2. Why are lakes valuable for machine learning?
  3. What is a "data swamp" and how do you avoid one?

Answers: 1) A lake uses schema-on-read (store raw now, structure later); a warehouse uses schema-on-write (structure up front). 2) They cheaply store raw data in any format and keep full history for re-processing and feature engineering. 3) A disorganized, untrustworthy lake — avoided with cataloging, naming conventions, and governance.

Key Takeaway: A data lake stores raw data of any format cheaply with schema-on-read, complementing the structured warehouse. Lakes are ideal for ML because they preserve raw detail and history. The lakehouse merges both — lake economics with warehouse reliability and SQL. But lakes need discipline: without cataloging and governance, they degrade into unusable data swamps.

Further Learning

Part of "MLOps & Data Engineering." Original content for this learning platform.