This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Developer Guide

All developer resources related to Parquet.

This section contains the developer specific documentation related to Parquet.

1 - Modules

The parquet-format project contains format specifications and Thrift definitions of metadata required to properly read Parquet files.

The parquet-mr project contains multiple sub-modules, which implement the core components of reading and writing a nested, column-oriented data stream, map this core onto the parquet format, and provide Hadoop Input/Output Formats, Pig loaders, and other Java-based utilities for interacting with Parquet.

The parquet-cpp project is a C++ library to read-write Parquet files.

The parquet-rs project is a Rust library to read-write Parquet files.

The parquet-compatibility project (deprecated) contains compatibility tests that can be used to verify that implementations in different languages can read and write each other’s files. As of January 2022 compatibility tests only exist up to version 1.2.0.

2 - Building Parquet

How to build Parquet

Building Java resources can be build using mvn package. The current stable version should always be available from Maven Central.

C++ thrift resources can be generated via make.

Thrift can be also code-genned into any other thrift-supported language.

3 - Contributing to Parquet

How to contribute to Parquet

Pull Requests

We prefer to receive contributions in the form of GitHub pull requests. Please send pull requests against the repository. If you’ve previously forked Parquet from its old location, you will need to add a remote or update your origin remote to Here are a few tips to get your contribution in:

  1. Break your work into small, single-purpose patches if possible. It’s much harder to merge in a large change with a lot of disjoint features.
  2. Create a JIRA for your patch on the Parquet Project JIRA.
  3. Submit the patch as a GitHub pull request against the master branch. For a tutorial, see the GitHub guides on forking a repo and sending a pull request. Prefix your pull request name with the JIRA name (ex:
  4. Make sure that your code passes the unit tests. You can run the tests with mvn test in the root directory.
  5. Add new unit tests for your code.
  6. All Pull Requests are tested automatically on GitHub Actions. TravisCI is also used to run the tests on ARM64 CPU architecture

If you’d like to report a bug but don’t have time to fix it, you can still post it to our issue tracker, or email the mailing list (


Merging a pull request requires being a comitter on the project.

How to merge a Pull request (have an apache and github-apache remote setup):

git remote add github-apache
git remote add apache

run the following command


example output:

Which pull request would you like to merge? (e.g. 34):

Type the pull request number (from and hit enter.

=== Pull Request #X ===
title   Blah Blah Blah
source  repo/branch
target  master

Proceed with merging pull request #3? (y/n):

If this looks good, type y and hit enter.

* [new branch]      master     -> PR_TOOL_MERGE_PR_3_MASTER
Switched to branch 'PR_TOOL_MERGE_PR_3_MASTER'

Merge complete (local ref PR_TOOL_MERGE_PR_3_MASTER). Push to apache? (y/n):

A local branch with the merge has been created. Type y and hit enter to push it to apache master

Counting objects: 67, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (26/26), done.
Writing objects: 100% (36/36), 5.32 KiB, done.
Total 36 (delta 17), reused 0 (delta 0)
   b767ac4..485658a  PR_TOOL_MERGE_PR_X_MASTER -> master
Restoring head pointer to b767ac4e
Note: checking out 'b767ac4e'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at b767ac4... Update
Deleting local branch PR_TOOL_MERGE_PR_X
Deleting local branch PR_TOOL_MERGE_PR_X_MASTER
Pull request #X merged!
Merge hash: 485658a5

Would you like to pick 485658a5 into another branch? (y/n):

For now just say n as we have 1 branch


Release Documentation

To create documentation for a new release of parquet-format create a new .md file under content/en/blog/parquet-format. Please see existing files in that directory as an example.

To create documentation for a new release of parquet-mr create a new .md file under content/en/blog/parquet-mr. Please see existing files in that directory as an example.

Website development and deployment


To make a change to the staging version of the website:

  1. Make a PR against the staging branch in the repository
  2. Once the PR is merged, the Build and Deploy Parquet Site job in the deployment workflow will be run, populating the asf-staging branch on this repo with the necessary files.

Do not directly edit the asf-staging branch of this repo


To make a change to the production version of the website:

  1. Make a PR against the production branch in the repository
  2. Once the PR is merged, the Build and Deploy Parquet Site job in the deployment workflow will be run, populating the asf-site branch on this repo with the necessary files.

Do not directly edit the asf-site branch of this repo

4 - Releasing Parquet

How to release Parquet


You will need: * PGP code signing keys, published in KEYS * Permission to stage artifacts in Nexus

Make sure you have permission to deploy Parquet artifacts to Nexus by pushing a snapshot:

mvn deploy

If you have problems, read the publishing Maven artifacts documentation

Release process

Parquet uses the maven-release-plugin to tag a release and push binary artifacts to staging in Nexus. Once maven completes the release, the offical source tarball is built from the tag.

Before you start the release process:

  1. Verify that the release is finished (no planned JIRAs are pending)
  2. Build and test the project
  3. Update the change log
    • Go to the release notes for the release in JIRA
    • Copy the HTML and convert it to markdown with an online converter
    • Add the content to and update formatting
    • Commit the update to

1. Run the prepare script

dev/ <version> <rc-number>

This runs maven’s release prepare with a consistent tag name. After this step, the release tag will exist in the git repository.

If this step fails, you can roll back the changes by running these commands.

find ./ -type f -name '*.releaseBackup' -exec rm {} \;
find ./ -type f -name 'pom.xml' -exec git checkout {} \;

2. Run release:perform to stage binaries

mvn release:perform

This uploads binary artifacts for the release tag to Nexus.

3. In Nexus, close the staging repository

Closing a staging repository makes the binaries available in staging, but does not publish them.

  1. Go to Nexus.
  2. In the menu on the left, choose “Staging Repositories”.
  3. Select the Parquet repository.
  4. At the top, click “Close” and follow the instructions. For the comment use “Apache Parquet [Format] ”.

4. Run the source tarball script

dev/ <version> <rc-number>

This script builds the source tarball from the release tag’s SHA1, signs it, and uploads the necessary files with SVN.

The source release is pushed to

The last message from the script is the release commit’s SHA1 hash and URL for the VOTE e-mail.

5. Send a VOTE e-mail to

Here is a template you can use. Make sure everything applies to your release.

Subject: [VOTE] Release Apache Parquet <VERSION> RC<NUM>

Hi everyone,

I propose the following RC to be released as official Apache Parquet <VERSION> release.

The commit id is <SHA1>
* This corresponds to the tag: apache-parquet-<VERSION>-rc<NUM>

The release tarball, signature, and checksums are here:

You can find the KEYS file here:

Binary artifacts are staged in Nexus here:

This release includes important changes that I should have summarized here, but I'm lazy.

Please download, verify, and test.

Please vote in the next 72 hours.

[ ] +1 Release this as Apache Parquet <VERSION>
[ ] +0
[ ] -1 Do not release this because...

Publishing after the vote passes

After a release candidate passes a vote, the candidate needs to be published as the final release.

1. Tag final release and set development version

dev/finalize-release <release-version> <rc-num> <new-development-version-without-SNAPSHOT-suffix>

This will add the final release tag to the RC tag and sets the new development version in the pom files. If everything is fine push the changes and the new tag to github: git push --follow-tags

2. Release the binary repository in Nexus

3. Copy the release artifacts in SVN into releases

First, check out the candidates and releases locations in SVN:

mkdir parquet
cd parquet
svn co candidates
svn co releases

Next, copy the directory for the release candidate the passed from candidates to releases and rename it; remove the “-rcN” part of the directory name.

cp -r candidates/apache-parquet-<VERSION>-rcN/ releases/apache-parquet-<VERSION>

Then add and commit the release artifacts:

cd releases
svn add apache-parquet-<version>
svn ci -m "Parquet: Add release <VERSION>"

4. Update

Update the downloads page on Instructions for updating the site are on the contribution page.

5. Send an ANNOUNCE e-mail to and the dev list

[ANNOUNCE] Apache Parquet release <VERSION>

I'm please to announce the release of Parquet <VERSION>!

Parquet is a general-purpose columnar file format for nested data. It uses
space-efficient encodings and a compressed and splittable structure for
processing frameworks like Hadoop.

Changes are listed at:<VERSION>/

This release can be downloaded from:

Java artifacts are available from Maven Central.

Thanks to everyone for contributing!