Compare a data warehouse, data lake, and lakehouse
Tests your grasp of data architectures for BI vs. ML workloads. Contrast warehouses (structured) and lakes (raw), then explain how a lakehouse adds ACID/schema features to a lake's storage. A red flag is confusing schema-on-write vs. schema-on-read.
What's really being asked
This question assesses your understanding of the evolution of data platforms. The interviewer wants to see if you can articulate the specific trade-offs between data warehouses and data lakes, particularly regarding data structure, cost, and typical use cases (BI vs. ML). It also tests your knowledge of modern hybrid architectures like the lakehouse and the specific technologies that enable them.
The full answer
A strong answer first defines each component. A data warehouse is for structured, processed data, optimized for fast BI queries (schema-on-write). A data lake is for raw, semi-structured, and unstructured data, offering low-cost, scalable storage for data science and ML (schema-on-read). Second, explain the problem: organizations often end up with two separate, costly, and siloed systems. Third, introduce the lakehouse as the solution that combines the low-cost, flexible storage of a data lake with the data management and transactional features of a warehouse. Fourth, mention the key enabling technologies: Apache Spark for scalable processing, Delta Lake for ACID transactions and schema enforcement on top of the lake, and a governance layer like Unity Catalog for unified access control and lineage tracking.
The mistakes people make
A major red flag is simply describing the systems without comparing their trade-offs. For example, just saying "warehouses are for BI, lakes are for ML" without explaining why (schema, data structure, cost). Another mistake is failing to explain the "how" of a lakehouse. A weak answer says it "combines the best of both" without naming the specific technologies like Delta Lake that provide ACID transactions or schema enforcement on top of raw files in a lake. Finally, confusing schema-on-read (lake) with schema-on-write (warehouse) is a fundamental error.
What usually comes next
Be prepared for questions like: "When would you still recommend a traditional data warehouse over a lakehouse?", "Describe the 'medallion architecture' often used in a lakehouse.", or "How does a technology like Delta Lake actually implement ACID transactions on top of a file system?".
A concrete example
Imagine an e-commerce company. A traditional data warehouse might store cleaned, aggregated sales data for daily BI reports on revenue. A data lake would store raw clickstream data (JSON events) from the website for ML models that predict customer churn. A lakehouse architecture allows them to do both in one system. Raw clickstream data lands in the lake. It's then refined into structured tables (using Delta Lake) for both the BI team's revenue dashboards and the data science team's churn models, all governed by a single system, providing a single source of truth.
Interview question
What is the primary benefit of adopting a lakehouse architecture compared to maintaining separate data warehouse and data lake systems?
- a.It provides a unified platform that supports both structured BI and raw data ML workloads with enhanced data governance.Correct
- b.It is designed exclusively for real-time streaming data processing, making traditional batch processing obsolete.
- c.It enforces a strict schema-on-write approach for all ingested data, ensuring data quality from the start.
- d.It eliminates the need for any data transformation, allowing all analytics directly on raw data.
Why? this is the answer
The card states that a lakehouse solves the problem of 'two separate, costly, and siloed systems' by combining the flexibility of a data lake with the data management and transactional features of a warehouse, supporting both BI and ML workloads. Option C is incorrect because while lakehouses add schema enforcement for refined data, they do not enforce a strict schema-on-write for all raw ingested data, which typically uses schema-on-read.
Just read this? Test yourself on what you have been reading.
Read the original → docs.databricks.com
- #data architecture
- #data lake
- #data warehouse
- #analytics
- #big data
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on data architecture — each one lists the topics its interview covers.
See open roles