Apache Parquet File Anatomy: Row Groups, Column Chunks, Pages, and Metadata Explained 🧱📦

If you use Spark, Athena, Iceberg, Snowflake, DuckDB, or Pandas, you’ve probably worked with Parquet hundreds of times. But most of us first learn Parquet as a simple rule of thumb: it’s columnar, compressed, and great for analytics . That’s true, but it leaves out the most interesting part — why Parquet performs so well in the first place. Under the hood, a Parquet file is not just a blob of compressed data. It has a deliberate internal structure made of row groups, column chunks, pages, and footer metadata , and that structure is exactly what enables column pruning, predicate pushdown, and efficient scans in modern query engines. In this post, we’ll break down the anatomy of a Parquet file from the file boundary all the way down to individual pages, and then connect those pieces back to the real-world performance behavior you see in Spark, Iceberg, and Athena. Why Parquet matters ⚡ Most analytical queries do not read every column and every row. They usually select a subset of columns