Compare a data warehouse, data lake, and lakehouse

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?".

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