LFC Delta Lake ACID Transactions 2 — Questions and Answers
Question 1: Which component of Delta Lake serves as the source of truth for all ACID transaction history?
- The Parquet data files
- The _delta_log transaction log directory (Correct answer)
- The Spark metastore catalog
- The checkpoint manifest file
Correct answer: The _delta_log transaction log directory
The _delta_log directory stores JSON commit files that record every transaction, making it the authoritative source of truth for Delta table state.
Question 2: What concurrency control mechanism does Delta Lake use to manage simultaneous write operations?
- Pessimistic locking with row-level locks
- Optimistic concurrency control (Correct answer)
- Two-phase commit with distributed locks
- Serializable snapshot isolation with write locks
Correct answer: Optimistic concurrency control
Delta Lake uses optimistic concurrency control, where writers proceed without locks and conflicts are detected at commit time.
Question 3: When a Delta Lake transaction fails midway through writing Parquet files, what happens to the partially written data?
- It is automatically rolled back by the storage layer
- It remains as orphan files but is never referenced by the transaction log (Correct answer)
- It is immediately deleted by the Delta Lake garbage collector
- It causes corruption that requires manual repair
Correct answer: It remains as orphan files but is never referenced by the transaction log
Uncommitted Parquet files become orphan files invisible to readers; atomicity is guaranteed because the transaction log entry is only written on successful commit.
Question 4: How does Delta Lake achieve the 'I' (Isolation) property for concurrent readers during a write operation?
- Readers are blocked until the write completes
- Readers always see the latest committed snapshot regardless of in-progress writes
- Readers use MVCC to access a consistent snapshot from before the write started (Correct answer)
- Readers see partial data as Parquet files are committed one by one
Correct answer: Readers use MVCC to access a consistent snapshot from before the write started
Delta Lake uses snapshot isolation (a form of MVCC) so readers always see a consistent, point-in-time snapshot and are never blocked by concurrent writers.
Question 5: What is the default behavior in Delta Lake when two concurrent writers attempt to modify non-overlapping partitions?
- Both commits succeed because there is no conflict on the same data (Correct answer)
- One writer is rejected with a ConcurrentModificationException
- Delta Lake merges the two writes automatically
- The second write overwrites the first write silently
Correct answer: Both commits succeed because there is no conflict on the same data
Delta Lake's optimistic concurrency control allows both commits to succeed when writers touch disjoint partitions, as no actual data conflict exists.
Question 6: Which isolation level does Delta Lake's default write behavior most closely correspond to?
- Read Uncommitted
- Read Committed
- Serializable
- WriteSerializable (Correct answer)
Correct answer: WriteSerializable
Delta Lake defaults to WriteSerializable isolation, which ensures write operations are serializable while allowing reads to proceed at snapshot isolation level.
Question 7: What does the 'D' (Durability) guarantee mean in the context of Delta Lake on cloud object storage?
- Data is replicated across multiple Spark executors
- Once a transaction log entry is written to object storage, the commit survives node failures (Correct answer)
- Delta Lake maintains a hot standby replica of all data
- Durability is not guaranteed on object storage and requires external backup
Correct answer: Once a transaction log entry is written to object storage, the commit survives node failures
Durability is achieved by relying on the object storage layer's own durability guarantees (e.g., S3's 11 nines), since the transaction log commit is the final, persistent record of a completed transaction.
LFC Delta Lake ACID Transactions 2
Which component of Delta Lake serves as the source of truth for all ACID transaction history?