Support ZSTD - #254
Conversation
|
PTAL @jerqi |
Codecov Report
@@ Coverage Diff @@
## master #254 +/- ##
============================================
- Coverage 59.71% 59.56% -0.15%
- Complexity 1377 1381 +4
============================================
Files 166 171 +5
Lines 8918 8983 +65
Branches 853 859 +6
============================================
+ Hits 5325 5351 +26
- Misses 3318 3353 +35
- Partials 275 279 +4
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
|
|
||
| int uncompressedLen = compressedBlock.getUncompressLength(); | ||
| if (uncompressedData == null || uncompressedData.capacity() < uncompressedLen) { | ||
| uncompressedData = ByteBuffer.allocate(uncompressedLen); |
There was a problem hiding this comment.
In original implementation, the bytebuffer will be destoryed and recreate. So to avoid the frequent GC, it use the offheap-bytebuffer.
And in this PR, we will recycle the bytebuffer, so I think it's no need to use the off-heap memory now. Maybe we should add the off-heap support in the next PR.
There was a problem hiding this comment.
PTAL @jerqi . This is the different with the original implementation.
|
Should we add the document? |
Done |
|
|
||
| int uncompressedLen = compressedBlock.getUncompressLength(); | ||
| if (uncompressedData == null || uncompressedData.capacity() < uncompressedLen) { | ||
| uncompressedData = ByteBuffer.allocate(uncompressedLen); |
|
Can you provide the test report of JVM memory usage? |
| return builder.stringConf(); | ||
| } | ||
|
|
||
| public static RssConf toRssConf(SparkConf sparkConf) { |
There was a problem hiding this comment.
Why change conf design in this ZSTD PR?
There was a problem hiding this comment.
I want to make compressorFactory accessed by MR and Spark to create concrete codec which will be initialized by specified conf, so it will have two choice.
- Use the shareable RssConf like this PR
- Introduce the extra config bean of compression (I think there is no need to do so)
Besides, I want to refactor the code of MR/Spark client conf entry, this PR is to do some partial work. Please refer to #200
|
Updated @frankliee |
|
Gentle ping @frankliee @jerqi |
|
Do u have any other concerns? Please let me know @jerqi @frankliee |
|
|
||
| package org.apache.uniffle.common.compression; | ||
|
|
||
| public interface Compressor { |
There was a problem hiding this comment.
Do we need to merge Compressor and Decompressor into one interface "Codec" like hadoop ?
It is more concise and avoid to mix different pair of Compressor and Decompressor.
@jerqi @zuston
There was a problem hiding this comment.
Let me do a simple review about hadoop codec.
There was a problem hiding this comment.
I dont find co/decompressor mixed in Hadoop one interface.
There was a problem hiding this comment.
I mean the compress/decompress could share the same interface for the user.
For example, CompressionCodec has createOutputStream (for compress) and createInputStream (for decompress).
There was a problem hiding this comment.
So you mean that I need to create similar Zstd/LZ4CompressionCodec to implement the Compressor and Decompressor interface?
If that, it will make hard to init the corresponding var for specific compressor or decompressor, like the this.lz4Factory = LZ4Factory.fastestInstance();.
Please let me know if i'm wrong
There was a problem hiding this comment.
You can only provide a Codec instead of CompressionFactory, which hides the inner compressor and decompressor.
The user could directly use Codec to compress or decompress data, so that the user does not need to use compressor and decompressor directly.
There was a problem hiding this comment.
I propose the new commit according to your idea, 866b642
Do I get your point? @frankliee
There was a problem hiding this comment.
I prefer this style
abstract class Codec {
private static class Compressor {}
private static class deCompressor{}
private getCompressor() // for init lazily
private getDeCompressor()
public compress()
public deCompress()
}
ZSTDCodec extends Codec {}
LZ4Codec extends Codec {}
There was a problem hiding this comment.
Emm.... OK. I will obey this project style.
|
PTAL @jerqi |
This problem will be fixed in the next PR. We could merge this firstly. I have updated latest commit, could u help review @frankliee @jerqi . If having any problem, I think I could do quick fix in this weekend. Latest commit changelog:
|
|
Gentle ping @jerqi @frankliee |
|
Updated @frankliee . Could you help review again? |
|
LGTM, thanks for your contributions. |
### What changes were proposed in this pull request? This PR adds the support of snappy compression/decompression based on the example of #254. ### Why are the changes needed? Add a new feature. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? UT






What changes were proposed in this pull request?
Why are the changes needed?
ZSTD has a good tradeoff between compression ratio and de/compress speed. For reducing the shuffle-data stored size, it's necessary to support this compression algorithm.
Does this PR introduce any user-facing change?
Yes
How was this patch tested?
Manual tests and UTs