Compare data warehouses and data lakes. How does a lakehouse merge benefits?

WHAT THIS TESTS: Whether you understand the architectural tradeoffs between structured analytics and flexible storage, and if you can explain how modern metadata layers bridge the gap without simply repeating vendor slogans. Interviewers want to see that you grasp schema-on-write versus schema-on-read, cost structures, workload isolation, and governance boundaries.

A GOOD ANSWER COVERS: First, the warehouse side: it uses schema-on-write, enforces ACID transactions, serves low-latency BI, and provides strong governance, but it typically runs on expensive proprietary storage and struggles with unstructured or semi-structured data. Second, the lake side: it stores raw data cheaply on object storage like S3 or ADLS, uses schema-on-read for flexibility, and supports ML and streaming, but it historically lacked transactions, schema enforcement, and fine-grained governance. Third, the lakehouse merge: it keeps cheap object storage as the foundation and adds an ACID metadata layer such as Delta Lake on top, enabling schema enforcement, time travel, and transactional guarantees while still allowing schema evolution. Fourth, practical benefits: decoupled compute from storage, a single source of truth for both BI and ML, unified governance through tools like Unity Catalog, and incremental refinement via medallion architecture layers.

COMMON WRONG ANSWERS: Calling a lakehouse pure marketing without naming a concrete technology like Delta Lake, Iceberg, or Hudi. Claiming warehouses cannot handle any unstructured data, or that lakes automatically provide ACID guarantees. Describing the lakehouse as just a warehouse sitting next to a lake instead of a unified metadata layer over object storage. Ignoring the cost difference between proprietary warehouse storage and commodity object storage.

LIKELY FOLLOW-UPS: How does Delta Lake actually implement ACID transactions on object storage? When would you still choose a dedicated data warehouse over a lakehouse? How do you handle streaming ingestion into a medallion architecture? What are the performance tradeoffs of querying a lakehouse versus a purpose-built warehouse for sub-second BI? How does schema evolution work in practice without breaking downstream dashboards?

ONE CONCRETE EXAMPLE: Imagine a retail company ingesting clickstream JSON, order CSVs, and inventory parquet into S3. In a pure warehouse, the JSON would need heavy transformation before loading, and storage costs would scale linearly with vendor pricing. In a pure lake, data scientists could read raw JSON freely, but BI analysts would see inconsistent schemas and duplicate records. In a lakehouse, the raw JSON lands in bronze Delta tables with schema enforcement, gets cleansed into silver tables with deduplication and type safety, and finally aggregates into gold tables optimized for BI and ML. Unity Catalog tracks lineage across all three layers, and Apache Spark jobs run on decoupled compute clusters, keeping storage cheap while serving both dashboards and model training from the same tables.