CSV vs JSON vs Parquet for analytics
file format tradeoffs.
CSV and JSON are row-based, human-readable, and bulky; columnar Parquet/ORC compress well and read only needed columns; choose columnar for analytics.
defaulting to CSV for large analytical workloads.
What's really being asked
This evaluates whether you understand how physical file format drives query performance, IO, and cost in a data lake.
The full answer
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.
The mistakes people make
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.
What usually comes next
What is predicate pushdown. How does partitioning complement file format. Parquet versus ORC differences.
A 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.
Interview question
Why does a columnar format like Parquet outperform CSV for a query selecting a few columns with a filter?
- a.Parquet files are always physically smaller regardless of content
- b.CSV cannot be stored in a data lake
- c.Parquet is human-readable so engines parse it faster
- d.It reads only needed columns and skips blocks using embedded statisticsCorrect
Why? this is the answer
Columnar storage lets engines read just the requested columns and prune row groups via min/max statistics, cutting IO. Parquet is binary, not human-readable, and the savings come from access pattern, not a guaranteed smaller size in all cases.
Just read this? Test yourself on what you have been reading.
Read the original → learn.microsoft.com
- #cloud
- #parquet
- #file-formats
- #data-lake
- #analytics
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on cloud — each one lists the topics its interview covers.
See open roles