CSV vs JSON vs Parquet for analytics

WHAT THIS TESTS This evaluates whether you understand how physical file format drives query performance, IO, and cost in a data lake.

A GOOD ANSWER COVERS CSV is a simple, human-readable, row-oriented text format with no types and no built-in compression, so every query must read the entire file including columns it does not need, and it cannot represent nested data well. JSON is also row-oriented and self-describing, handling nested and semi-structured data, but it is verbose, repeats keys on every record, and is expensive to parse and scan at scale. Parquet and ORC are columnar binary formats: they store values column by column, apply efficient compression and encoding per column, carry a schema and types, and embed min and max statistics per row group so query engines can skip blocks that cannot match a predicate. For analytical queries that select a few columns and filter, columnar formats read far less data, decompress efficiently, and prune irrelevant blocks, which slashes scan cost on engines billed by bytes scanned. For analytics, choose Parquet or ORC. CSV or JSON still make sense for ingestion landing zones, interchange, or when humans must read the file.

COMMON WRONG ANSWERS Defaulting to CSV for large analytical workloads because it is familiar, ignoring scan cost. Believing JSON is efficient because it is structured. Thinking columnar formats are slower because they are binary. Forgetting predicate pushdown and column pruning, the real performance levers.

LIKELY FOLLOW-UPS What is predicate pushdown. How does partitioning complement file format. Parquet versus ORC differences.

ONE CONCRETE EXAMPLE Converting a 1 TB CSV dataset to partitioned Parquet lets an Athena query that selects three of fifty columns and filters by date read a small fraction of the bytes, returning faster and costing a fraction of the CSV scan.