Unnecessary getFileStatus() calls on all part-files in ParquetInputFormat.getSplits
- Langage dominant
- Java
- Étoiles
- 3.1k
- Forks
- 1.6k
- Merge moyen
- 3 j 12 h
- PR mergées (30 j)
- 33
Description
When testing Spark SQL Parquet support, we found that accessing large Parquet files located in S3 can be very slow. To be more specific, we have a S3 Parquet file with over 3,000 part-files, calling `ParquetInputFormat.getSplits` on it takes several minutes. (We were accessing this file from our office network rather than AWS.)
After some investigation, we found that `ParquetInputFormat.getSplits` is trying to call `getFileStatus()` on all part-files one by one sequentially ([here](https://github.com/apache/incubator-parquet-mr/blob/parquet-1.5.0/parquet-hadoop/src/main/java/parquet/hadoop/ParquetInputFormat.java#L370)). And in the case of S3, each `getFileStatus()` call issues an HTTP request and wait for the reply in a blocking manner, which is considerably expensive.
Actually all these `FileStatus` objects have already been fetched when footers are retrieved ([here](https://github.com/apache/incubator-parquet-mr/blob/parquet-1.5.0/parquet-hadoop/src/main/java/parquet/hadoop/ParquetInputFormat.java#L443)). Caching these `FileStatus` objects can greatly improve our S3 case (reduced from over 5 minutes to about 1.4 minutes).
Will submit a PR for this issue soon.
**Reporter**: [Cheng Lian](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=lian+cheng) / @liancheng
#### Related issues:
- [Use LRU caching for footers in ParquetInputFormat.](https://github.com/apache/parquet-java/issues/1394) (relates to)
- [Cleanup FilteringParquetRowInputFormat](https://issues.apache.org/jira/browse/SPARK-2551) (is related to)
- [Reading Parquet InputSplits dominates query execution time when reading off S3](https://issues.apache.org/jira/browse/SPARK-2119) (is related to)
- [Improve Parquet IO Performance within cloud datalakes](https://github.com/apache/parquet-java/issues/2912) (is depended upon by)
**Note**: *This issue was originally created as [PARQUET-16](https://issues.apache.org/jira/browse/PARQUET-16). Please see the [migration documentation](https://issues.apache.org/jira/browse/PARQUET-2502) for further details.*
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Piste de recherche
Commencez dans parquet-hadoop/src/main/java/parquet/hadoop/ParquetInputFormat.java, au niveau de getSplits et du chemin de récupération du footer référencé dans l’issue. Suivez la manière dont les objets FileStatus sont obtenus, puis vérifiez que getSplits ne les récupère plus séquentiellement pour chaque part-file et comparez le temps d’exécution pour S3 ou les fichiers volumineux décrit dans le rapport.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- java
- Domaine
- performance
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- Clairement spécifiée
- Accessibilité débutants
- 35/100