An ETL job needs only 6 columns from a 90-column analytical table for a feature-engineering step. The team stores the table as Parquet and reads it with cuDF, requesting just those 6 columns. Compared with reading the same data from an equivalent row-oriented CSV, why does the columnar Parquet read transfer far less data from storage?
- AParquet keeps the entire table compressed as a single block, so the reader decompresses everything once and then discards the columns it does not need after the data is already in GPU memory.
- BParquet rows are indexed by a primary key, so the reader performs a key lookup that returns only the 6 columns for each row while ignoring the remaining columns.
- CParquet stores each column contiguously, so the reader can use column projection to fetch only the byte ranges for the 6 requested columns and skip the other 84 entirely. Correct
- DParquet caches the most frequently accessed columns in a header section, so repeated reads of the same 6 columns are served from that cache rather than from the full file body.
Why A is wrong: This is plausible because Parquet does compress data, but it describes reading the whole file and discarding afterwards, which would not reduce the bytes read from storage; the saving comes from never reading the unwanted columns at all.
Why B is wrong: Parquet has no primary-key row index that drives column selection; the column-skipping benefit comes from the physical columnar layout, not from any per-row key lookup.
Why C is correct: Parquet's columnar layout places each column in its own contiguous region with metadata describing its location, so column projection reads only the requested columns' byte ranges and skips the rest, cutting I/O.
Why D is wrong: Parquet has no frequency-based column cache in its header; the metadata records column locations to enable projection, and the I/O saving applies on the first read, not only on repeated reads.