DWH Interview Question 5 - What is a data lake, and why put it in front of the warehouse?

Data Warehouse Interview Q&A · Question 5

In this post we are going to cover the data lake: what it is, and why so many companies put one in front of their data warehouse.

A data lake is central, low-cost storage that keeps raw data in its original format. Tables exported as files, JSON from applications, logs, images, anything. It usually lives on cloud object storage, like Amazon S3, Azure Data Lake Storage or Google Cloud Storage.

The key phrase to remember is schema-on-read. You don't define a table before the data arrives. You apply the structure when you read it. This post has no SQL demo; it is all about the ideas an interviewer expects you to explain clearly.

Question 5 of the Real DWH Question and Answers series on TechBrothersIT.

On this page

1. The interview answer
2. What goes into a data lake
3. Schema-on-write vs schema-on-read
4. Why the lake sits in front of the warehouse
5. How a well-organized lake looks
6. The data swamp
7. Follow-up questions interviewers ask

The interview answer

Say this first

A data lake is central, low-cost storage that keeps raw data in its original format: structured, semi-structured and unstructured files, usually on object storage like Amazon S3, Azure Data Lake Storage or Google Cloud Storage. Structure is applied when the data is read: schema-on-read.

What goes into a data lake

Anything the business might want to analyze later. It usually falls into three groups:

• Structured - nightly exports of database tables, such as orders.csv or customers.parquet.
• Semi-structured - JSON events from the website and mobile app, such as clicks.json, and log files from servers.
• Unstructured - images, PDFs, audio, anything a data scientist might want later.

All of it lands as files, in the format it arrived in. Storage is cheap, so teams keep years of raw history that would be too expensive to keep in a warehouse.

Schema-on-write vs schema-on-read

This is the concept interviewers always check.

A warehouse is schema-on-write. You create the table first, with its columns and types, and data must fit that shape before it is written.

Now let's say the website suddenly starts sending a new field in its click events, a coupon code:

{"user_id": 7, "page": "/cart", "clicked": "2026-03-01 10:15", "coupon": "SPRING10"}

In a schema-on-write warehouse, the new field does not fit the table. The load fails, or the field is silently dropped, until someone changes the table.

A lake is schema-on-read. The JSON file is stored exactly as it arrived, for example as clicks/2026-03-01.json, coupon and all. Nothing is rejected. The structure is applied later, by whoever reads it: Spark, Databricks, Athena or Synapse decide which fields they need at query time.

The trade-off: schema-on-read is flexible and fast to land data, but nothing checks quality on the way in. That is why curated warehouse tables still matter.

Why the lake sits in front of the warehouse

The usual flow is source systems into the lake, and the lake into the warehouse and other consumers. There are four good reasons for this:

• Extract once - instead of every pipeline querying the production database, one job copies the data to the lake, for example once a day. The sources are touched once, and stay fast.
• Many consumers - the warehouse loads from the lake with ELT into facts and dimensions, but so do data scientists in notebooks, machine learning jobs and other teams, without ever touching production.
• Replay - if a transformation had a bug last month, you still have the raw files, so you can fix the code and rebuild the warehouse tables from history.
• Archive - it is a cheap, long-term store of everything, which also helps with audits.

How a well-organized lake looks

A good lake is not one big pile of files. Most lakes are organized in zones:

• Raw - files exactly as they arrived. In Databricks this is called bronze.
• Clean - validated, de-duplicated data, also called silver.
• Curated - data shaped for business use, also called gold.

Inside each zone, data is split into folders by source, table and date. A query for one day then reads one folder instead of the whole history.

Files are usually stored as Parquet, a compressed, column-based format that analytics engines read very efficiently. And on top sits a catalog, which records what each dataset is, its schema, its owner and who may read it.

The data swamp

A lake without zones, naming rules, a catalog and owners turns into a data swamp: thousands of files nobody understands or trusts. The storage is cheap, but the data is useless if no one can find it or knows what it means.

Interview tip

Mention the data swamp and how you would prevent it. It shows you have worked with a real lake, not just read about one.

Follow-up questions interviewers ask

Is a data lake a database?

No, it is storage. Engines such as Spark, Databricks, Athena or Synapse query the files.

What is a data swamp?

A lake without zones, naming rules, a catalog and ownership, where nobody can find or trust the data.

Why Parquet?

It is a compressed, columnar file format, so analytics engines read only the columns they need.

The other common follow-up is how a lake compares to a warehouse and a lakehouse. That is exactly the next question in the series.

Key points

• Central, low-cost storage for raw data in its original format
• Any data: structured, semi-structured, unstructured
• Schema-on-read: structure is applied when the data is read
• In front of the warehouse: extract once, many consumers, replay
• Organize with zones, folders, Parquet and a catalog, or it becomes a swamp

Next in this series

Question 6 — Data lake vs warehouse vs lakehouse Data lake vs data warehouse vs lakehouse: what is the difference?

Part of the Real DWH Question and Answers series on TechBrothersIT. File names and examples on this page are invented for teaching.