Data Engineering Interview Questions: Data Lake vs Warehouse vs Lakehouse

A data lake ingests data in its original form, such as files, blobs, and logs, without requiring a predefined schema. Transformation and schema enforcement are deferred until the data is queried, which is called schema-on-read. The options describing cleaned, modeled tables or schema-before-write describe a data warehouse, which uses schema-on-write, and the single proprietary format option is not a property of data lakes.

A data lakehouse merges the two architectures: data is stored in open formats on a lake (cheap, flexible), while a metadata or table layer adds the transactional integrity, schema management, and query performance that a warehouse traditionally provides. The card tests recall of that definition, so the back states the lake-side storage traits and the warehouse-side capabilities it adds.

A traditional data warehouse uses schema-on-write: data is extracted, transformed, and validated against a predefined structure before it lands in the warehouse, so everything stored is structured and conformed. The other three options describe data lakes, which keep raw data in native formats (including unstructured media) on cheap object storage and defer schema until read time.

The name 'lakehouse' signals the blend: the 'lake' part provides the flexible, open-format storage layer, and the 'warehouse' part provides the transactional (ACID), schema-enforcement, and governance features layered on top of that storage.

Data warehouses came first: the approach was formalized in the 1980s and 1990s by Bill Inmon and Ralph Kimball for structured analytics. The term 'data lake' was coined around 2010 for storing large volumes of raw, mostly unstructured data. The 'lakehouse' concept, which combines lake-style storage with warehouse-style management, was popularized around 2020 by Databricks. So the historical order is data warehouse, then data lake, then data lakehouse.

A data lake accepts any data type, including unstructured binary files like images, video, and audio, and keeps them in their original format. A traditional warehouse expects structured, schema-defined tables, so it handles those media files poorly. The other three options (structured relational rows, star-schema fact tables, and OLAP cubes) are the classic workloads a warehouse is designed for, so they are not the answer.

A data lake is defined by centralized storage of data in its native format, including structured, semi-structured, and unstructured data, typically on low-cost object storage, with schema applied on read rather than enforced on ingest. A data warehouse stores curated structured data under a predefined schema (schema-on-write), a data mart is a subject-specific subset of structured warehouse data, and an operational relational database is built for transactional workloads on structured, schema-enforced tables. Only the data lake matches the raw, schema-flexible, object-storage-based description.

A data lake stores raw data in its native format and uses schema-on-read, so structure is applied when the data is queried rather than when it is written. A data warehouse, by contrast, enforces schema-on-write and stores structured, pre-modeled data. The question asks for the architecture that has the raw, native-format, schema-on-read property, which is the data lake.

A lakehouse combines ACID transactions with open table formats on cheap object storage, supports BI and ML workloads against the same data, and adds warehouse-style management such as schema enforcement and time travel directly on lake storage. Requiring a proprietary engine load describes the traditional warehouse model that the lakehouse avoids, and banning unstructured data contradicts the lake heritage the lakehouse keeps, so neither is a defining characteristic.

The statement is false. Traditional data warehouses use schema-on-write: data is extracted, transformed, and modeled (for example, into star or snowflake schemas) through ETL pipelines before it is stored. Keeping raw data in its native format and applying structure only when a query runs (schema-on-read) is the defining characteristic of a data lake, not a traditional warehouse.

A data warehouse stores structured, pre-modeled data using schema-on-write and ETL pipelines. This distinguishes it from a data lake, which stores raw data in native formats using schema-on-read. The 'enterprise-wide' qualifier separates a warehouse from a department-scoped data mart.

Schema-on-read is the data lake model: raw data is stored in native format and structure is applied at query time. Schema-on-write is the data warehouse model: data is validated and transformed to a predefined schema at ingest time before it enters the warehouse. The key distinction is therefore when the schema is enforced, either when the data is read or when it is written, which determines where validation cost and data-quality guarantees land in the pipeline.

Data warehouses date to the 1980s and 1990s, built for structured reporting and business intelligence on curated relational data. Data lakes appeared in the 2010s, driven by big data platforms that could store large volumes of unstructured and semi-structured data cheaply. Lakehouses emerged in the late 2010s and 2020s as a response to the lake's lack of reliability, adding ACID transactions and schema enforcement on top of lake storage. So the order is warehouse, then lake, then lakehouse.

A traditional data lake keeps data in open formats on object storage but offers no transactional guarantees, no schema-on-write enforcement, and limited metadata management. A lakehouse adds a transactional metadata layer, implemented by table formats such as Delta Lake, Apache Iceberg, or Apache Hudi, that records commits and schemas over those same files. This is what enables ACID commits, schema enforcement, and time travel without copying data into a proprietary storage engine.

A data lakehouse adds a transactional metadata layer, such as Delta Lake, Apache Iceberg, or Apache Hudi, over open-format files that already sit in object storage. That layer provides ACID upserts, time travel, and schema enforcement without copying the data into a separate proprietary store, which is exactly what the scenario requires. A plain data lake stores files cheaply but has no transactional guarantees or built-in schema enforcement. A traditional data warehouse provides ACID and schema management but normally requires ingesting data into its own managed storage engine, which contradicts the no-migration constraint. A data mart is a small aggregated subset for reporting and does not address ACID upserts on raw lake data.

Three architectural differences are key. First, a lakehouse stores data in open file formats (Parquet, ORC) on commodity object storage, whereas a traditional warehouse typically uses a vendor-controlled proprietary storage engine. Second, a lakehouse serves both BI/SQL analytics and ML/data-science workloads from the same storage layer, while a traditional warehouse is optimized primarily for SQL-based analytical querying. Third, an open table-format metadata layer (Delta, Iceberg, Hudi) lets multiple independent compute engines read and write the same data copy, unlike a warehouse that generally exposes data only through its own SQL engine. The claim that a lakehouse eliminates all ETL is false: lakehouses reduce unnecessary data movement and duplication but still require ingestion, cleansing, and transformation pipelines.

The keyed statement names the two mechanisms that solve the two problems. Delta Lake's transaction log records each commit atomically and points readers at a fixed set of immutable Parquet files, so a Spark query keeps a consistent snapshot even while an upstream job writes new files. Because the open table is registered in a catalog, BI engines can read the same data directly, so the copy to Snowflake and the 4-hour ETL cycle are no longer needed and dashboards see committed data immediately. The other statements fail on concrete points: locking files and caching results do not provide the consistency or freshness guarantees described, Delta Lake stores data as Parquet rather than a proprietary row format, and copying to HDFS or running ETL more often keeps the duplicated pipeline that the lakehouse removes.

The sample answer covers all three required parts. (1) The transaction log records, per commit, which data files were added and removed, which defines a versioned snapshot. (2) Writers serialize through optimistic concurrency control: each writes immutable data files first, then attempts a conditional (put-if-absent or compare-and-swap) publish of the next log version; on a version collision it re-reads the log, checks for logical conflicts, and retries. (3) Snapshot isolation and time travel hold because each version references an immutable set of data files, and those files stay on storage while a retained snapshot references them; they are only physically deleted by vacuum or snapshot expiration, so readers pinned to a version are unaffected by concurrent commits.

The data files must exist before the commit can reference them, so writing them comes before the commit attempt. The conditional write to the transaction log is the commit point, and it fails only if another writer advanced the log version. A retry is only triggered by a failed conditional write, so re-reading the log and retrying comes last. Each adjacent pair has a strict dependency, so the order is total.

A lakehouse satisfies all four requirements because an open table format such as Delta Lake or Apache Iceberg adds a transaction log and metadata layer on top of the Parquet files already in S3. That layer provides ACID commits and schema enforcement on writes, while indexing, statistics, and caching support performant BI SQL, all on open storage. A plain data lake fails because it offers schema-on-read with no transactional guarantees on writes. A proprietary managed warehouse may meet requirements 1 through 3, but its closed storage violates requirement 4. Streaming CDC is an ingestion concern and cannot by itself provide ACID table semantics or schema enforcement.

Iceberg's commit atomicity rests on one atomic operation: the catalog swaps its pointer from the current metadata file to a newly written metadata file. The data files and the new metadata file are written first, and none is reachable until the pointer changes. The compare-and-swap succeeds only if the pointer still references the expected old metadata, so concurrent writers cannot silently overwrite each other. Because object stores guarantee per-object atomicity, the metadata file is either fully present or absent, so readers see either the old or the new snapshot. No two-phase commit, distributed lock across files, or multipart upload is needed for cross-file atomicity.

The question asks for a comparison grounded in Hudi's mechanics: COW rewrites the base file group on each update, giving high write amplification and reads that touch only consolidated base files; MOR appends updates to delta log files, giving cheap writes but read-time merging whose cost grows until compaction folds the logs into a new base file. The workload recommendation follows directly from this trade-off: write-heavy streaming upserts favour MOR, while read-heavy workloads with rare updates favour COW. A strong answer names the file group, the log files, the read-time merge, and compaction, and does not claim that either design is free.

Delta Lake uses optimistic concurrency control. Each writer reads the current table version from the _delta_log, writes its new Parquet files to storage, then attempts to atomically append a new version entry to the transaction log. If the table version has advanced since the read (because another writer committed first), the commit fails on a version-conflict check and the writer must retry from scratch—re-reading data, re-writing files, and re-attempting the commit. This is the standard Delta Lake protocol and the statement is true.

The catalog points to the current table metadata file (a .metadata.json file), which holds the snapshot list and the current-snapshot ID. A commit writes a new metadata file and swaps the catalog pointer atomically, so readers see either the old or the new state. Each snapshot references a manifest list, and the manifest files it points to contain one entry per data file with column-level statistics (lower/upper bounds, null counts) and partition values. Query planners use these manifest entries to skip data files that cannot match a filter. The first blank is 'metadata' and the second is 'manifest'.

The three correct statements are: lakehouses store data in open columnar formats like Parquet or ORC on object storage, while traditional warehouses use proprietary internal formats; the decoupled storage-and-compute model lets several engines (Spark, Trino, Flink) read the same table files, which proprietary warehouses generally do not allow; and lakehouses achieve ACID guarantees through a metadata layer (Delta log, Iceberg catalog, Hudi timeline) over object-store files, whereas a warehouse handles transactions inside its own storage engine. The statement claiming strictly stronger consistency is false: optimistic concurrency control gives comparable, not stronger, guarantees than warehouse locking, and it tends to perform worse under heavy write contention. The statement that lakehouses fully eliminate a raw lake is too absolute, since lakehouses reduce but do not replace a raw lake for all unstructured or schemaless use cases.