apache / apache/parquet-java

parquet-tools merge extremely slow with block-option

Open
#2,374 5 comments 0 reactions 0 assignees View on GitHub
Component: Parquet Priority: Major Type: bug
Dominant language
Java
Stars
3.1k
Forks
1.6k
Avg merge
3d 12h
Merged PRs (30d)
33

Description

parquet-tools merge is extremely time- and memory-consuming when used with block-option.

 

The merge function builds a bigger file out of several smaller parquet-files. Used without the block-option it just concatenates the files into a bigger one without building larger row-groups. That doesn't help with query-performance-issues. With block-option, parquet-tools build bigger row-groups which improves the query-performance, but the merge-process itself is extremely slow and memory-consuming.

 

Consider a case in which you have many small parquet files, e.g. 1000 files with a size of 100kb. Merging them into one file fails on my machine because even 20GB of memory are not enough for the process (the total amount of data as well as the resulting file should be smaller than 100MB).

 

Different situation: Consider having 100 files of size 1MB. Then merging them is possible with 20GB of RAM, but it takes almoust half an hour to process, which is to much for many use-cases.

 

Is there any possibility to accelerate the merge and reduce the need of memory?

**Reporter**: [Alexander Gunkel](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=Checkito)

**Note**: *This issue was originally created as [PARQUET-1670](https://issues.apache.org/jira/browse/PARQUET-1670). Please see the [migration documentation](https://issues.apache.org/jira/browse/PARQUET-2502) for further details.*

Contributor guide

No contributing guide indexed for this repository

Research direction

Start at the parquet-tools merge entry point and reproduce the reported block-option cases: 1,000 files of 100 KB and 100 files of 1 MB. Compare runtime and memory with and without block-option; done means the block-option merge completes without excessive memory use and is substantially faster while preserving larger row-groups.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
cli, data-engineering
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.