Sample questions
Pe File Formats Table FormatsDifficulty 1
A team stores an 80-column table in Parquet and runs analytical queries that read only 3-4 columns at a time. Why does Parquet fit this access pattern well?
- aIt stores values column by column, so only requested column chunks are read✓
- bIt stores every field as plain text, making all columns equally fast to parse
- cIt requires the entire row to be deserialized even if only one column is needed
- dIt only supports reading the first column of a file, not arbitrary columns
Explanation:Parquet is a columnar format; data for each column is stored contiguously in column chunks, so a reader can skip chunks for columns that aren't requested, unlike row-oriented formats that must read whole records.
Pe File Formats Table FormatsDifficulty 1
An ingestion job appends one complete new record at a time and rarely reads back individual columns. Which storage layout fits this pattern more naturally?
- aColumnar, because column chunks can be appended independently without touching other columns
- bRow-oriented, since a full record can be written contiguously✓
- cColumnar, because dictionary encoding makes every write faster than any row format
- dRow-oriented, because it prevents the file from ever growing in size
Explanation:Row-oriented formats (e.g., Avro) store a full record together, which suits workloads that write or read entire records; columnar formats optimize for reading subsets of columns across many rows, not for appending single full records efficiently.
Pe File Formats Table FormatsDifficulty 1
In the Parquet file format, what is a row group?
- aA single compressed value stored inside a dictionary page
- bA directory of files partitioned by a date column
- cRows stored horizontally, one column chunk per column✓
- dThe footer section that lists the file's schema
Explanation:A row group is a horizontal partition of the file's rows; within a row group, each column has its own column chunk holding that column's values for those rows.
Pe File Formats Table FormatsDifficulty 1
What does a Parquet file's footer primarily contain?
- aSchema plus row-group/chunk metadata and stats✓
- bThe uncompressed raw values of every row in the file
- cA separate copy of the dictionary page for every column
- dThe Spark job configuration used to write the file
Explanation:The footer stores the file's schema and metadata describing row groups and column chunks — including per-column statistics — which readers use to plan which parts of the file to read.
Pe File Formats Table FormatsDifficulty 2
Parquet column chunks can carry min/max statistics in their metadata. How do query engines typically use these statistics?
- aTo decide which compression codec was used for the column
- bTo decide the physical order of columns inside a row group
- cTo rebuild the dictionary page if it was dropped
- dTo skip a row group when the filter can't match it✓
Explanation:If a query filters on a column and a row group's min/max range can't satisfy the predicate, the engine can skip reading that row group entirely — this is often called predicate pushdown or row-group skipping.
Pe File Formats Table FormatsDifficulty 1
Compared to gzip, what is the typical trade-off of using the snappy compression codec in Parquet?
- aSnappy compresses much smaller than gzip but is far slower to decompress
- bSnappy is faster but usually produces a larger file than gzip✓
- cSnappy and gzip always produce identical file sizes and speeds
- dSnappy can only be used with row-oriented formats, not Parquet
Explanation:Snappy favors speed over compression ratio, while gzip typically compresses tighter at the cost of more CPU time — a classic speed-vs-ratio trade-off between codecs.