Uh oh!
There was an error while loading. Please reload this page.
[SPARK-48220][PYTHON] Allow passing PyArrow Table to createDataFrame() - #46529
[SPARK-48220][PYTHON] Allow passing PyArrow Table to createDataFrame()#46529ianmcook wants to merge 30 commits into
Conversation
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
c408d0b to
795d01aComparealippai
commented
May 14, 2024
This makes the usage so much easier, thanks! What will happen with the nanosecond timestamps? Truncated to milliseconds? |
005c4f7 to
7e34472Compare
Truncated to microseconds for now. |
alippai
commented
May 15, 2024
I wish we had ns support in spark 4.0 as Java, parquet, arrow etc uses it natively now, but that’s certainly a different discussion and MRs :) Thanks for the new API! |
5275bb2 to
4cc3ca2Compareianmcook
commented
May 30, 2024
Just rebased to master |
HyukjinKwon
commented
May 30, 2024
will merge once ci passes |
ianmcook
commented
May 31, 2024
Thanks @HyukjinKwon. After you merge I will rebase the small follow-up PR #46688 and prep it for review. |
HyukjinKwon
commented
Jun 2, 2024
Merged to master. |
### What changes were proposed in this pull request? This is a small follow-up to #46529. This adds support for some more Arrow data types: - fixed-size binary - fixed-size list - large list ### Why are the changes needed? Users who are creating Spark DataFrames from PyArrow Tables will expect it to work if their Tables contain these types of columns ### Does this PR introduce _any_ user-facing change? It will prevent an error in the case where the user has one of these types of columns in their PyArrow Table. There are no other user-facing changes. ### How was this patch tested? Tests are included. ### Was this patch authored or co-authored using generative AI tooling? No Closes#46688 from ianmcook/SPARK-48374. Authored-by: Ian Cook <ianmcook@gmail.com> Signed-off-by: Hyukjin Kwon <gurwls223@apache.org>
### What changes were proposed in this pull request? This is a small follow-up to #46529. It fixes a known issue affecting PyArrow Tables passed to `spark.createDataFrame()`. After this PR, if the user is running PyArrow 17.0.0 or higher, null values in MapArray columns containing nested fields or timestamps will be preserved. ### Why are the changes needed? Before this PR, null values in MapArray columns containing nested fields or timestamps are replaced by empty lists when a PyArrow Table is passed to `spark.createDataFrame()`. ### Does this PR introduce _any_ user-facing change? It prevents loss of nulls in the case described above. There are no other user-facing changes. ### How was this patch tested? A test is included. ### Was this patch authored or co-authored using generative AI tooling? No Closes#46837 from ianmcook/SPARK-48302. Authored-by: Ian Cook <ianmcook@gmail.com> Signed-off-by: Hyukjin Kwon <gurwls223@apache.org>
What changes were proposed in this pull request?
createDataFrame().toArrow().Why are the changes needed?
This seems like a logical next step after the addition of a
toArrow()DataFrame method in #45481.Does this PR introduce any user-facing change?
Users will have the ability to pass PyArrow Tables to
createDataFrame(). There are no changes to the parameters ofcreateDataFrame(). The only difference is thatdatacan now be a PyArrow Table.How was this patch tested?
Many tests were added, for Spark Classic and Spark Connect. I ran the tests locally with older versions of PyArrow installed (going back to 10.0).
Was this patch authored or co-authored using generative AI tooling?
No