NCA-ADS - Data Manipulation and Preparation (23% of the exam) - Section 1.7
Use Parquet storage for data.
Use Parquet as a columnar storage format to achieve efficient compression and fast predicate pushdown when reading large datasets. Recognise why Parquet outperforms CSV for repeated analytical reads and how it integrates with cuDF and Dask workflows.
Parquet
Practice question for this objective
lock_openFree sampleData Manipulation and Preparationmedium
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.check_circle 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.
Parquet's columnar layout lets a reader project only the needed columns, reading their byte ranges and skipping the rest to cut I/O. Because Parquet writes each column as a contiguous chunk and records its offset in the file metadata, a reader asking for a subset of columns fetches only those byte ranges. A row-oriented CSV interleaves every column on each line, so the reader must scan all of them to extract any subset, forcing far more I/O.
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.
Answers that look right on this material and are not. Each one is a distractor from a different question in the NCA-ADS bank for this domain.
CSV, because its plain-text rows are easy to append to and every consumer can parse them without a schema.
errorWhy it is wrong: CSV carries no schema, so types must be inferred and can drift, it is row-oriented so partial-column reads still parse every field, and it is uncompressed text; it is familiar and easy to append to but fails all three stated requirements.
Row-group sorting, which places related rows contiguously on disk
errorWhy it is wrong: Row-group sorting improves predicate pushdown efficiency but does not reduce the number of columns that must be read from disk; all column data within each row group is still present and must be skipped manually.
Parquet files are human-readable plain text, so the pipeline parses them faster than the binary CSV encoding that cuDF uses.
errorWhy it is wrong: This reverses reality: CSV is the human-readable text format and Parquet is a binary format. The claim that Parquet is plain text and CSV is binary is simply wrong, though it superficially sounds like a parsing advantage.