Athena queries on a large S3 dataset are slow and expensive. What usually helps most?
Why A is the answer
Convert to partitioned Parquet
Columnar formats and partitions reduce what Athena has to scan, which improves both cost and speed.
In detail
- Partitioned Parquet means Athena reads far less data.
- Athena charges by data scanned.
Use case
An illustrative scenario, not a real incident.
A team runs Athena over CSV files and scans terabytes. Partitioned Parquet lets one query read a fraction of that.
See it in different ways
flowchart LR A["Raw CSV"] --> B["Convert to Parquet"] B --> C["Partition by date"] C --> D["Queries scan less data"]
stateDiagram-v2 [*] --> RawCsv RawCsv --> Parquet: columnar, compressed Parquet --> Partitioned: by date Partitioned --> Compacted: fewer small files Compacted --> [*]
flowchart LR S0["CSV on S3"] --> S1["Convert to Parquet"] --> S2["Partition by date"] --> S3["Athena reads less"]
Key point: Scan less to pay less.
Why the other options are wrong
- B. Store the data as larger CSV files
- Larger CSV makes it worse.
- C. Move the data to EBS
- Athena reads from S3.
- D. Increase Lambda memory
- Lambda is unrelated.