Engines on the lake

6 h
requires LKH-07

From your world. Athena on S3; comparing it to Trino, DuckDB and Spark on the same tables

Practice quiz with instant feedback. For a scored run that counts toward your local progress, use uv run de quiz LKH-08.

1A query on a lakehouse table is slow. In the Spark physical plan, you see the filter as a separate Filter node ABOVE the scan. The scan has no pushed predicate. What does this indicate? AThe engine pushed the filter down optimally BThe engine is reading all rows and filtering in memory — no predicate pushdown CThe table is corrupt DPartition pruning succeeded

2What is the difference between partition pruning and predicate pushdown? AThey are the same thing BPartition pruning skips whole partitions with a predicate on the partition column before it reads files. Predicate pushdown skips files/row-groups inside the partitions that it reads, with column statistics CPruning happens after pushdown DPushdown only works on Delta

3Why does an Iceberg sort order (LKH-05) improve file skipping for a filter on the sorted column? AIt compresses the data more BClustering rows by the column gives each data file tight min/max bounds, so the engine skips files whose range cannot match the predicate CIt builds a B-tree index DIt converts the table to Delta

5For a sub-second interactive BI query over a modest dataset that fits on one node, which is usually the WRONG tool and why? ADuckDB, because it is single-node BSpark, because its job startup and shuffle overhead are worse than Trino/DuckDB on small latency-sensitive queries CTrino, because it cannot read Iceberg DAthena, because it needs a cluster

7Two engines (Spark and DuckDB) run the same WHERE/GROUP BY on the same table and return different totals. What is the most likely cause? AOpen table formats guarantee that engines disagree BA logic difference in one query (filter, null handling, or type coercion). On the same committed snapshot, both engines must agree CDuckDB cannot aggregate DSpark rounds all doubles