You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@parquet.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2020/04/30 18:17:00 UTC
[jira] [Commented] (PARQUET-1643) Use airlift non-native
implementations for GZIP, LZ0 and LZ4 codecs
[ https://issues.apache.org/jira/browse/PARQUET-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17096844#comment-17096844 ]
ASF GitHub Bot commented on PARQUET-1643:
-----------------------------------------
dbtsai commented on pull request #671:
URL: https://github.com/apache/parquet-mr/pull/671#issuecomment-622018995
@samarthjain thanks for the work. I am looking to deploy zstd parquet into prod, but that requires new hadoop with native library support which is not practical in many prod use-cases.
Since airlift is pure Java implementation, what's the performance implications for zstd? I saw there is a benchmark for GZIP, but I don't see benchmark for other codecs.
Also, do we consider to use zstd-jin which is a Java library that packages native implementation of zstd for different platforms in jar?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
> Use airlift non-native implementations for GZIP, LZ0 and LZ4 codecs
> -------------------------------------------------------------------
>
> Key: PARQUET-1643
> URL: https://issues.apache.org/jira/browse/PARQUET-1643
> Project: Parquet
> Issue Type: Improvement
> Reporter: Samarth Jain
> Assignee: Samarth Jain
> Priority: Major
> Labels: pull-request-available
>
> [~rdblue] pointed me to [https://github.com/airlift/aircompressor] which provides non-native implementations of compression codecs. It claims to be much faster than native wrappers that parquet uses. This Jira is to track the work needed for exploring using these codecs, getting benchmark results and making changes including not needing to pool compressors and decompressors anymore. Note that this doesn't include SNAPPY since Parquet already has its own non-hadoopy implementation for it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)