File formats that make or break training: Parquet, ORC, CSV, JSON

Lesson 1 of 5 in Ingesting and Storing Training Data.

Nearly every Domain 1 scenario opens the same way: data is sitting somewhere, in some shape, and a training job or an Athena query has to read it. The file format decides three things — how much data an engine must read (row versus columnar layout), whether many workers can read one file in parallel (splittability), and how well it compresses.

Row formats (CSV, JSON Lines) store complete records together: to total one column you still read every byte of every row. Columnar formats (Parquet, ORC) store each column's values together, typed, with min/max statistics per internal chunk — a query that touches 3 of 300 columns reads roughly 1% of the file, and chunks whose statistics rule out a filter are skipped without being read at all.

The four formats the exam actually asks about
Format	Layout	Schema & types	Splittability & compression	Reach for it when
CSV	Row	None — everything is a string until parsed	Splittable uncompressed; gzip makes it one unsplittable stream	Simple interchange; several SageMaker built-ins expect header-less CSV with the target in the first column
JSON Lines	Row	Self-describing, handles nesting	Splits by line; a single giant JSON document does not	API/log exports, nested records — and fine-tuning datasets for Bedrock are JSONL
Parquet	Columnar	Embedded schema, typed columns	Compressed per column chunk (e.g. Snappy) and still parallel — row groups split	Athena / Glue / EMR analytics and feature engineering: read only the columns you need
ORC	Columnar	Embedded schema, typed columns	Compressed internally; stripes split	Same niche as Parquet; strongest inside Hive/Presto-heavy estates

Training and analytics want different things. Analytics is "scan a few columns of everything" — columnar wins outright, which is why Athena and Glue jobs get faster and cheaper the moment CSV becomes Parquet (Athena bills by bytes scanned, so reading 3 columns instead of 300 is a direct cost lever). Training is usually "read every row of the features you kept," which plain CSV or JSONL serves fine — and some consumers require it: several SageMaker built-in algorithms take CSV with no header row and the target in the first column, and Bedrock fine-tuning takes JSONL prompt–completion pairs.

The working pattern: do feature engineering in Parquet on S3, then emit the final training file in whatever the algorithm or framework expects.

Horizontal bar chart comparing gigabytes read for a query that references 10 of 400 columns on a hypothetical 100 GB table. Uncompressed CSV reads all 100 GB. Gzipped CSV reads about 25 GB, but as one unsplittable stream that still contains every column. Parquet with column pruning reads about 2.5 GB — roughly the 10-of-400 share of the table.

What a query touching 10 of 400 columns must read from a hypothetical 100 GB table, by format. Row layouts carry every column of every row; gzip shrinks the stored bytes but still reads all columns through a single unsplittable stream; columnar Parquet prunes down to the named columns. (illustrative — source: Amazon Athena — columnar storage formats)

Key terms: Apache Parquet

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.