You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@beam.apache.org by "Ismaël Mejía (Jira)" <ji...@apache.org> on 2021/01/19 14:27:00 UTC

[jira] [Commented] (BEAM-11658) Add Snappy compression and decompression support

    [ https://issues.apache.org/jira/browse/BEAM-11658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17267921#comment-17267921 ] 

Ismaël Mejía commented on BEAM-11658:
-------------------------------------

There is definitively support for Snappy in Beam's dependencies and as part of the support for Avro and Parquet, there is also a Snappy Coder so probably what is missing is a way to match .snappy files into the given (de)compressor. [https://github.com/apache/beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/io/Compression.java]
BEAM-6365 can definitely be useful as a reference to see how to do it.

 

> Add Snappy compression and decompression support
> ------------------------------------------------
>
>                 Key: BEAM-11658
>                 URL: https://issues.apache.org/jira/browse/BEAM-11658
>             Project: Beam
>          Issue Type: New Feature
>          Components: sdk-java-core
>            Reporter: Andrei Balici
>            Priority: P2
>
> Snappy is a compression/decompression library. It does not aim for maximum compression, or compatibility with any other compression library; instead, it aims for very high speeds and reasonable compression. For instance, compared to the fastest mode of zlib, Snappy is an order of magnitude faster for most inputs, but the resulting compressed files are anywhere from 20% to 100% bigger.
>  
> Many data pipelines will have as input files .snappy compressed, and these currently have to be read by creating custom DoFn(s).
>  
> It would be nice to see Beam support this out of the box, as it does currently for LZO. Snappy usually is faster than algorithms in the same class (e.g. LZO, LZF, QuickLZ, etc.) while achieving comparable compression ratios, so I see no reason leaving this out.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)