A data team writes clickstream events as Parquet files in S3 and queries them interactively with Athena. They want a compression codec that keeps decompression fast so dashboards stay responsive. Which codec should they choose?
Show answer and explanation
Answer: D
Snappy is the usual choice for Parquet data that is queried interactively. It compresses and decompresses quickly, so the engine spends less CPU per scanned byte, and Parquet's columnar encoding already keeps the stored size reasonable. Gzip gives better ratios but costs more CPU on every read, and BZIP2 is slower still.
Why the other options are wrong
- A. Gzip compresses Parquet more tightly, which lowers storage cost. Decompression is noticeably slower, and that cost is paid on every query that scans the file.
- B. BZIP2 produces small files but decompresses slowly, which hurts interactive dashboards. It is rarely the first choice for columnar analytics data.
- C. LZO is fast, but it is not the default choice for Parquet in Athena. Its support across the Glue and Athena toolchain is narrower than Snappy's, which adds friction for this team.
Exam tip. For Parquet read interactively, Snappy is the usual default; choose Gzip only when storage size matters more than query CPU.