Why is Parquet a good fit for analytical workloads?
Whether the candidate understands what a file format stores beyond the values — layout, statistics, encodings — and can explain what those let a reader skip.
The situation behind the question
Interviewers ask this because it happened to them.
A team is landing daily extracts as gzipped CSV in object storage. Queries scan everything, cost is climbing, and someone suggests switching to Parquet. Nobody in the room can say what would actually improve.
A strong answer
Flags
Green flags
- Reasons about physical layout — row groups, column chunks, footers, statistics — rather than repeating that columnar is faster.
- Names the conditions under which each benefit does not materialise, especially selecting every column and high-cardinality data.
- Connects sort order to compression ratio, which is the observation that separates understanding from recitation.
- Mentions that Parquet is a poor choice for row-at-a-time reads and for write-heavy small-batch ingestion.
Red flags
- "Parquet is just compressed CSV." The compression is the least interesting part; the layout and the statistics are what let a reader skip work it would otherwise do.
- "
SELECT *is fine in analytics." Selecting every column is precisely the case where columnar layout buys nothing, and in a model that other models read it also propagates every upstream schema change downstream. - Quotes a size or speed ratio as though it were a property of the format rather than of the data, the query and the encoding.
- Cannot name a workload where Parquet is the wrong choice.
Follow-ups
Where the conversation goes if the first answer holds up.
- Your Parquet files are a few kilobytes each because the ingest writes one per micro-batch. What happens to query planning, and what do you do about it?
- When would you choose Avro instead, and what specifically does it do better?
- A column is a high-cardinality identifier. What happens to dictionary encoding, and does that change how you would lay the table out?