Uh oh!
There was an error while loading. Please reload this page.
[SPARK-14098][SQL] Generate Java code that gets a float/double value in each column of CachedBatch when DataFrame.cache() is called - #11956
[SPARK-14098][SQL] Generate Java code that gets a float/double value in each column of CachedBatch when DataFrame.cache() is called#11956kiszk wants to merge 50 commits into
Conversation
SparkQA
commented
Mar 25, 2016
Test build #54165 has finished for PR 11956 at commit
|
SparkQA
commented
Mar 25, 2016
Test build #54168 has finished for PR 11956 at commit
|
SparkQA
commented
Mar 25, 2016
Test build #54178 has finished for PR 11956 at commit
|
SparkQA
commented
Mar 31, 2016
Test build #54583 has finished for PR 11956 at commit
|
SparkQA
commented
Mar 31, 2016
Test build #54604 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 2, 2016
Test build #54756 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 10, 2016
Test build #55487 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 12, 2016
Test build #55637 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 12, 2016
Test build #55639 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 12, 2016
Test build #55643 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 13, 2016
Test build #55725 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 13, 2016
Test build #55733 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 14, 2016
Test build #55837 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 16, 2016
Test build #56016 has finished for PR 11956 at commit
|
kiszk
commented
Apr 17, 2016
Jenkins, retest this please |
SparkQA
commented
Apr 17, 2016
Test build #56036 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 17, 2016
Test build #56058 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 18, 2016
Test build #56093 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 19, 2016
Test build #56203 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 19, 2016
Test build #56236 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 19, 2016
Test build #56237 has finished for PR 11956 at commit
|
SparkQA
commented
Apr 19, 2016
Test build #56255 has finished for PR 11956 at commit
|
kiszk
commented
Apr 20, 2016
Jenkins, retest this please |
SparkQA
commented
Jul 7, 2016
Test build #61919 has finished for PR 11956 at commit
|
SparkQA
commented
Jul 9, 2016
Test build #62019 has finished for PR 11956 at commit
|
kiszk
commented
Jul 27, 2016
Hi @davies could you please take a look at this since Spark 2.0.0 has been successfully released? |
kiszk
commented
Jul 27, 2016
@rxin, could you please review this? |
kiszk
commented
Aug 2, 2016
kiszk
commented
Aug 8, 2016
@davies, I hope that you have some bandwidth to review PRs. Could you please review this, too? |
kiszk
commented
Aug 15, 2016
@davies could you please review this? |
davies
commented
Aug 15, 2016
@kiszk I'm sorry that I do not have the bandwidth to review this, https://github.com/apache/spark/pull/13899/files sounds like an easier approach (have not looked into the details), how do you think of these two? |
@davies, thank you for your comment. I hope that you will have bandwidth soon since Spark 2.0 was released. In particular, generated code for reading a column is almost the same. I listed up how these two approaches does three features. this PR does the same thing.
I like to simplify my PR by using the idea in the PR. For example, I can throw away new files I have the following questions:
What do you think? |
kiszk
commented
Aug 22, 2016
@davies Would it be possible to share your opinions regarding these design questions among us? |
a-roberts
commented
Aug 22, 2016
@hvanhovell@marmbrus@srowen I see this PR has been open since the 25th of March and provides substantial performance improvements as mentioned above without introducing functional regressions, as leading SQL/community members what do you guys think? |
srowen
commented
Aug 22, 2016
I'm not qualified to comment as I tend to ignore SQL unless it's a simple and easy to evaluate change. |
kiszk
commented
Aug 29, 2016
@davies Could you please share your great opinions regarding these design questions among our community while we know you are busy? |
davies
commented
Aug 29, 2016
@kiszk The current implementation use ByteBuffer and smart compression algorithms, it too slow to build the in-memory cache, make it useless. So we'd like to improve the performance of building phase also. This PR is built for current representation, which may be throwed away in future, so I'd not rush to merge this PR, or spent to much time to review the details. PR #13899 could be in the right direction, but need to double-check that by more benchmarks. In order to have better memory efficiency, we could use MEMORY_AND_SER storage level and compress the underlying array with LZ4 when serializing the ColumnVector. |
davies
commented
Aug 29, 2016
cc @rxin |
@davies Thank you for sharing your valuable thought. I understand the future direction. I will implement this direction by using this PR or another PR. While the future roadmap may consume more memory, the performance will be improved. The compression will be applied only when What benchmark programs do you want to use to double-check this roadmap? |
davies
commented
Aug 29, 2016
We could compress them in memory with MEMORY_AND_DISK_SER, this could be controlled by a flag. |
kiszk
commented
Aug 30, 2016
Thank you for your clarification. Here is a good summary for me. |
kiszk
commented
Aug 30, 2016
kiszk
commented
Sep 2, 2016
I saw PR #13899. I understood there are two design points for now. Hopefully, no more points :)
For 1, current ColumnarBatch is not serializable. |
Current PR #13899 does not support a case that an element is null.
|
SparkQA
commented
Jan 10, 2017
Test build #71153 has finished for PR 11956 at commit
|
SparkQA
commented
Feb 28, 2017
Test build #73611 has finished for PR 11956 at commit
|
gatorsmile
commented
Oct 28, 2017
@kiszk Is this still the issue? I knew you are working on the related part now. |
kiszk
commented
Oct 28, 2017
Thank you for pointing it out. #18747 implemented this feature. |
What changes were proposed in this pull request?
This PR generates Java code to get a float/double value of each column from CachedBatch when DataFrame.cache() is called. This is done in whole stage code generation.
When DataFrame.cache() is called, data is stored as column-oriented storage (columnar cache) in CachedBatch. This PR avoid conversion from column-oriented storage to row-oriented storage.
This PR handles only float and double that are stored in a column without compression. Another PR will handle other primitive types that may be stored in a column in a compressed format. This is for ease of review by reducing the size of PR
This PR consists of two parts.
decompress()method. CachedBatch consists of multiple ByteBuffer arrays. A ByteBuffer is just passed to generated code.This PR generates Java code for columnar cache only if types in all columns, which are accessed in operations, are primitive
This PR improves performance of aggregate sum by 3.8x - 5.2x. This benchmark is available at here
Performance results:
Motivating example:
Generated code
How was this patch tested?
Tested existing test suites
added test suites for operations to dataframe generated by df.cache().