DAS-C01 · Question #27
A university intends to use Amazon Kinesis Data Firehose to collect JSON-formatted batches of water quality readings in Amazon S3. The readings are from 50 sensors scattered across a local lake…
The correct answer is B. Partition the data by year, month, and day. D. Store the data in Apache Parquet format using Snappy compression. Amazon Athena charges based on the amount of data scanned per query, so two strategies most significantly reduce costs: (D) Apache Parquet with Snappy compression is a columnar storage format - Athena only reads the specific columns requested rather than entire rows…
Question
A university intends to use Amazon Kinesis Data Firehose to collect JSON-formatted batches of water quality readings in Amazon S3. The readings are from 50 sensors scattered across a local lake. Students will query the stored data using Amazon Athena to observe changes in a captured metric over time, such as water temperature or acidity. Interest has grown in the study, prompting the university to reconsider how data will be stored. Which data format and partitioning choices will MOST significantly reduce costs? (Choose two.)
Options
- AStore the data in Apache Avro format using Snappy compression.
- BPartition the data by year, month, and day.
- CStore the data in Apache ORC format using no compression.
- DStore the data in Apache Parquet format using Snappy compression.
- EPartition the data by sensor, year, month, and day.
How the community answered
(46 responses)- A17% (8)
- B48% (22)
- C9% (4)
- E26% (12)
Explanation
Amazon Athena charges based on the amount of data scanned per query, so two strategies most significantly reduce costs: (D) Apache Parquet with Snappy compression is a columnar storage format - Athena only reads the specific columns requested rather than entire rows, dramatically reducing data scanned. Snappy compression further reduces file sizes without excessive CPU overhead during decompression. Parquet consistently provides 50-90% cost reduction over raw JSON for Athena workloads. (B) Partitioning by year, month, and day enables Athena partition pruning - when students query for a specific time range, Athena skips entire partitions outside that range, scanning far less data. Option E (partitioning by sensor first) is suboptimal because the primary query pattern is temporal ('changes over time'), not per-sensor. Option A (Avro) is row-based and inefficient for Athena. Option C (ORC without compression) is less efficient than Parquet with Snappy.
Topics
Community Discussion
No community discussion yet for this question.