A finance office drops nightly CSV budget extracts into Amazon S3. Analysts complain Athena queries scan too much data and run slowly. Which approach best improves analytic performance for those ad-hoc SQL workloads?

Converting nightly CSV budget extracts into columnar Parquet with AWS Glue ETL is the strongest analytic performance lever for Athena because Parquet stores data by column, supports efficient compression, and lets Athena read only the columns and row groups needed for each SQL predicate instead of scanning entire CSV blobs. For a finance office running ad-hoc queries over municipal budget files, that conversion typically cuts scanned bytes and latency dramatically. Keeping the CSV files unchanged and only raising Athena’s concurrent query limit does not reduce per-query scan cost or I/O; concurrency may even amplify the bill if each query still scans bloated text files. Copying every CSV into Amazon EFS and querying with shell scripts on a single EC2 instance abandons serverless lake analytics for a fragile, single-host pattern that will not scale with analyst concurrency. Storing each night’s CSV as one unpartitioned ZIP archive in S3 Glacier Instant Retrieval worsens queryability: Athena is not designed to treat Glacier ZIP dumps as an interactive lake format, and lack of partitioning plus archive packaging fights selective reads. Exam caveat: also partition by date/department when possible and register tables in the Glue Data Catalog; conversion alone helps, but partition pruning multiplies the gain. Operational check: compare Athena Data scanned before/after Parquet conversion on the same finance query, confirm Glue job SLAs finish before morning analyst windows, and validate row counts between CSV sources and Parquet outputs.