Uh oh!
There was an error while loading. Please reload this page.
[SPARK-3294][SQL] Eliminates boxing costs from in-memory columnar storage - #2327
[SPARK-3294][SQL] Eliminates boxing costs from in-memory columnar storage#2327liancheng wants to merge 13 commits into
Conversation
There was a problem hiding this comment.
This change is submitted separately in #2325 as this PR may take longer time to finish.
SparkQA
commented
Sep 9, 2014
QA tests have started for PR 2327 at commit
|
SparkQA
commented
Sep 9, 2014
QA tests have finished for PR 2327 at commit
|
aarondav
commented
Sep 9, 2014
Out of curiosity, does this also eliminate boxing for nested data types? |
liancheng
commented
Sep 9, 2014
No, unlike Parquet, currently our in-memory columnar format doesn't support complex nested objects well. They are just serialized by Kryo and stored as opaque byte arrays. |
marmbrus
commented
Sep 10, 2014
@aarondav to expand on that, as soon as there is any nesting all of our clever tricks for eliminating allocations go out the window. We can probably improve this in future releases. |
5cacd9a to
97bbc4eCompareSparkQA
commented
Sep 10, 2014
QA tests have started for PR 2327 at commit
|
SparkQA
commented
Sep 10, 2014
QA tests have finished for PR 2327 at commit
|
liancheng
commented
Sep 10, 2014
ok to test |
SparkQA
commented
Sep 10, 2014
QA tests have started for PR 2327 at commit
|
SparkQA
commented
Sep 10, 2014
QA tests have finished for PR 2327 at commit
|
liancheng
commented
Sep 11, 2014
test this please |
SparkQA
commented
Sep 11, 2014
QA tests have started for PR 2327 at commit
|
SparkQA
commented
Sep 11, 2014
QA tests have started for PR 2327 at commit
|
SparkQA
commented
Sep 11, 2014
QA tests have finished for PR 2327 at commit
|
SparkQA
commented
Sep 11, 2014
Tests timed out after a configured wait of |
liancheng
commented
Sep 11, 2014
@marmbrus Please help review this one. |
SparkQA
commented
Sep 11, 2014
QA tests have started for PR 2327 at commit
|
SparkQA
commented
Sep 11, 2014
QA tests have finished for PR 2327 at commit
|
marmbrus
commented
Sep 11, 2014
I need to look this over still, but want to remove WIP? |
There was a problem hiding this comment.
This style is going to go away in 2.12 or 2.13 I think. Should be :Unit =
marmbrus
commented
Sep 11, 2014
Nice speed ups. I think they might be even more pronounced when there are multiple threads fighting for the GC. Minor comments only. Will merge after they are addressed. |
SparkQA
commented
Sep 13, 2014
QA tests have started for PR 2327 at commit
|
SparkQA
commented
Sep 13, 2014
QA tests have finished for PR 2327 at commit
|
marmbrus
commented
Sep 13, 2014
Thanks! I've merged this to master. |
This is a major refactoring of the in-memory columnar storage implementation, aims to eliminate boxing costs from critical paths (building/accessing column buffers) as much as possible. The basic idea is to refactor all major interfaces into a row-based form and use them together with
SpecificMutableRow. The difficult part is how to adapt all compression schemes, esp.RunLengthEncodingandDictionaryEncoding, to this design. Since in-memory compression is disabled by default for now, and this PR should be strictly better than before no matter in-memory compression is enabled or not, maybe I'll finish that part in another PR.UPDATE This PR also took the chance to optimize
HiveTableScanbySpecificMutableRowto avoid boxing cost, andWritableunwrapper functions a head of time to avoid per row pattern matching and branching costs.TODO
Eliminate boxing costs in(left to future PRs)RunLengthEncodingEliminate boxing costs in(left to future PRs)DictionaryEncoding(seems not easy to do without specializingDictionaryEncodingfor every supported column type)Micro benchmark
The benchmark uses a 10 million line CSV table consists of bytes, shorts, integers, longs, floats and doubles, measures the time to build the in-memory version of this table, and the time to scan the whole in-memory table.
Benchmark code can be found here. Script used to generate the input table can be found here.
Speedup:
Hive table scanning + column buffer building: 18.74%
The original benchmark uses 1K as in-memory batch size, when increased to 10K, it can be 28.32% faster.
In-memory table scanning: 7.95%
Before:
After: