Re: [VOTE][SPIP] PySpark Test Framework

[Yikun Jiang]

+1

Regards,
Yikun


On Fri, Jun 23, 2023 at 6:17 AM L. C. Hsieh  wrote:

> +1
>
> On Thu, Jun 22, 2023 at 3:10 PM Xinrong Meng  wrote:
> >
> > +1
> >
> > Thanks for driving that!
> >
> > On Wed, Jun 21, 2023 at 10:25 PM Ruifeng Zheng 
> wrote:
> >>
> >> +1
> >>
> >> On Thu, Jun 22, 2023 at 1:11 PM Dongjoon Hyun 
> wrote:
> >>>
> >>> +1
> >>>
> >>> Dongjoon
> >>>
> >>> On Wed, Jun 21, 2023 at 8:56 PM Hyukjin Kwon 
> wrote:
> 
>  +1
> 
>  On Thu, 22 Jun 2023 at 02:20, Jacek Laskowski 
> wrote:
> >
> > +0
> >
> > Pozdrawiam,
> > Jacek Laskowski
> > 
> > "The Internals Of" Online Books
> > Follow me on https://twitter.com/jaceklaskowski
> >
> >
> >
> > On Wed, Jun 21, 2023 at 5:11 PM Amanda Liu <
> amandastephanie...@gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> I'd like to start the vote for SPIP: PySpark Test Framework.
> >>
> >> The high-level summary for the SPIP is that it proposes an official
> test framework for PySpark. Currently, there are only disparate open-source
> repos and blog posts for PySpark testing resources. We can streamline and
> simplify the testing process by incorporating test features, such as a
> PySpark Test Base class (which allows tests to share Spark sessions) and
> test util functions (for example, asserting dataframe and schema equality).
> >>
> >> SPIP doc:
> https://docs.google.com/document/d/1OkyBn3JbEHkkQgSQ45Lq82esXjr9rm2Vj7Ih_4zycRc/edit#heading=h.f5f0u2riv07v
> >>
> >> JIRA ticket: https://issues.apache.org/jira/browse/SPARK-44042
> >>
> >> Discussion thread:
> https://lists.apache.org/thread/trwgbgn3ycoj8b8k8lkxko2hql23o41n
> >>
> >> Please vote on the SPIP for the next 72 hours:
> >> [ ] +1: Accept the proposal as an official SPIP
> >> [ ] +0
> >> [ ] -1: I don’t think this is a good idea because __.
> >>
> >> Thank you!
> >>
> >> Best,
> >> Amanda Liu
>
> -
> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
>
>

Re: [ANNOUNCE] Apache Spark 3.4.1 released

[yangjie01]

Thanks Dongjoon ~

在 2023/6/24 10:29，“L. C. Hsieh”mailto:vii...@gmail.com>> 写入:


Thanks Dongjoon!


On Fri, Jun 23, 2023 at 7:10 PM Hyukjin Kwon mailto:gurwls...@apache.org>> wrote:
>
> Thanks!
>
> On Sat, Jun 24, 2023 at 11:01 AM Mridul Muralidharan  > wrote:
>>
>>
>> Thanks Dongjoon !
>>
>> Regards,
>> Mridul
>>
>> On Fri, Jun 23, 2023 at 6:58 PM Dongjoon Hyun > > wrote:
>>>
>>> We are happy to announce the availability of Apache Spark 3.4.1!
>>>
>>> Spark 3.4.1 is a maintenance release containing stability fixes. This
>>> release is based on the branch-3.4 maintenance branch of Spark. We strongly
>>> recommend all 3.4 users to upgrade to this stable release.
>>>
>>> To download Spark 3.4.1, head over to the download page:
>>> https://spark.apache.org/downloads.html 
>>> 
>>>
>>> To view the release notes:
>>> https://spark.apache.org/releases/spark-release-3-4-1.html 
>>> 
>>>
>>> We would like to acknowledge all community members for contributing to this
>>> release. This release would not have been possible without you.
>>>
>>>
>>> Dongjoon Hyun


-
To unsubscribe e-mail: user-unsubscr...@spark.apache.org 







-
To unsubscribe e-mail: dev-unsubscr...@spark.apache.org

Re:[ANNOUNCE] Apache Spark 3.4.1 released

[beliefer]

Thanks! Dongjoon Hyun.
Congratulation too!







At 2023-06-24 07:57:05, "Dongjoon Hyun"  wrote:

We are happy to announce the availability of Apache Spark 3.4.1!

Spark 3.4.1 is a maintenance release containing stability fixes. This
release is based on the branch-3.4 maintenance branch of Spark. We strongly
recommend all 3.4 users to upgrade to this stable release.

To download Spark 3.4.1, head over to the download page:
https://spark.apache.org/downloads.html

To view the release notes:
https://spark.apache.org/releases/spark-release-3-4-1.html

We would like to acknowledge all community members for contributing to this
release. This release would not have been possible without you.

Dongjoon Hyun

Re: [DISCUSS] SPIP: Python Data Source API

[Martin Grund]

Hey,

I would like to express my strong support for Python Data Sources even
though they might not be immediately as powerful as Scala-based data
sources. One element that is easily lost in this discussion is how much
faster the iteration speed is with Python compared to Scala. Due to the
dynamic nature of Python, you can design and build a data source while
running in a notebook and continuously change the code until it works as
you want. This behavior is unparalleled!

There exists a litany of Python libraries connecting to all kinds of
different endpoints that could provide data that is usable with Spark. I
personally can imagine implementing a data source on top of the AWS SDK to
extract EC2 instance information. Now I don't have to switch tools and can
keep my pipeline consistent.

Let's say you want to query an API in parallel from Spark using Python,
today's way would be to create a Python RDD and then implement the planning
and execution process manually. Finally calling `toDF` in the end. While
the actual code of the DS and the RDD-based implementation would be very
similar, the abstraction that is provided by the DS is much more powerful
and future-proof. Performing dynamic partition elimination, and filter
push-down can all be implemented at a later point in time.

Comparing a DS to using batch calling from a UDF is not great because, the
execution pattern would be very brittle. Imagine something like
`spark.range(10).withColumn("data",
fetch_api).explode(col("data")).collect()`. Here you're encoding
partitioning logic and data transformation in simple ways, but you can't
reason about the structural integrity of the query and tiny changes in the
UDF interface might already cause a lot of downstream issues.


Martin


On Sat, Jun 24, 2023 at 1:44 AM Maciej  wrote:

> With such limited scope (both language availability and features) do we
> have any representative examples of sources that could significantly
> benefit from providing this API,  compared other available options, such as
> batch imports, direct queries from vectorized  UDFs or even interfacing
> sources through 3rd party FDWs?
>
> Best regards,
> Maciej Szymkiewicz
>
> Web: https://zero323.net
> PGP: A30CEF0C31A501EC
>
> On 6/20/23 16:23, Wenchen Fan wrote:
>
> In an ideal world, every data source you want to connect to already has a
> Spark data source implementation (either v1 or v2), then this Python API is
> useless. But I feel it's common that people want to do quick data
> exploration, and the target data system is not popular enough to have an
> existing Spark data source implementation. It will be useful if people can
> quickly implement a Spark data source using their favorite Python language.
>
> I'm +1 to this proposal, assuming that we will keep it simple and won't
> copy all the complicated features we built in DS v2 to this new Python API.
>
> On Tue, Jun 20, 2023 at 2:11 PM Maciej  wrote:
>
>> Similarly to Jacek, I feel it fails to document an actual community need
>> for such a feature.
>>
>> Currently, any data source implementation has the potential to benefit
>> Spark users across all supported and third-party clients.  For generally
>> available sources, this is advantageous for the whole Spark community and
>> avoids creating 1st and 2nd-tier citizens. This is even more important with
>> new officially supported languages being added through connect.
>>
>> Instead, we might rather document in detail the process of implementing a
>> new source using current APIs and work towards easily extensible or
>> customizable sources, in case there is such a need.
>>
>> --
>> Best regards,
>> Maciej Szymkiewicz
>>
>> Web: https://zero323.net
>> PGP: A30CEF0C31A501EC
>>
>>
>> On 6/20/23 05:19, Hyukjin Kwon wrote:
>>
>> Actually I support this idea in a way that Python developers don't have
>> to learn Scala to write their own source (and separate packaging).
>> This is more crucial especially when you want to write a simple data
>> source that interacts with the Python ecosystem.
>>
>> On Tue, 20 Jun 2023 at 03:08, Denny Lee  wrote:
>>
>>> Slightly biased, but per my conversations - this would be awesome to
>>> have!
>>>
>>> On Mon, Jun 19, 2023 at 09:43 Abdeali Kothari 
>>> wrote:
>>>
 I would definitely use it - is it's available :)

 On Mon, 19 Jun 2023, 21:56 Jacek Laskowski,  wrote:

> Hi Allison and devs,
>
> Although I was against this idea at first sight (probably because I'm
> a Scala dev), I think it could work as long as there are people who'd be
> interested in such an API. Were there any? I'm just curious. I've seen no
> emails requesting it.
>
> I also doubt that Python devs would like to work on new data sources
> but support their wishes wholeheartedly :)
>
> Pozdrawiam,
> Jacek Laskowski
> 
> "The Internals Of" Online Books 
> Follow me on https://twitter.com/jaceklaskowski
>
> 

Re: [DISCUSS] SPIP: Python Data Source API

[Maciej]

With such limited scope (both language availability and features) do we 
have any representative examples of sources that could significantly 
benefit from providing this API,  compared other available options, such 
as batch imports, direct queries from vectorized  UDFs or even 
interfacing sources through 3rd party FDWs?


Best regards,
Maciej Szymkiewicz

Web:https://zero323.net
PGP: A30CEF0C31A501EC

On 6/20/23 16:23, Wenchen Fan wrote:
In an ideal world, every data source you want to connect to already 
has a Spark data source implementation (either v1 or v2), then this 
Python API is useless. But I feel it's common that people want to do 
quick data exploration, and the target data system is not popular 
enough to have an existing Spark data source implementation. It will 
be useful if people can quickly implement a Spark data source using 
their favorite Python language.


I'm +1 to this proposal, assuming that we will keep it simple and 
won't copy all the complicated features we built in DS v2 to this new 
Python API.


On Tue, Jun 20, 2023 at 2:11 PM Maciej  wrote:

Similarly to Jacek, I feel it fails to document an actual
community need for such a feature.

Currently, any data source implementation has the potential to
benefit Spark users across all supported and third-party clients. 
For generally available sources, this is advantageous for the
whole Spark community and avoids creating 1st and 2nd-tier
citizens. This is even more important with new officially
supported languages being added through connect.

Instead, we might rather document in detail the process of
implementing a new source using current APIs and work towards
easily extensible or customizable sources, in case there is such a
need.

-- 
Best regards,

Maciej Szymkiewicz

Web:https://zero323.net
PGP: A30CEF0C31A501EC


On 6/20/23 05:19, Hyukjin Kwon wrote:

Actually I support this idea in a way that Python developers
don't have to learn Scala to write their own source (and separate
packaging).
This is more crucial especially when you want to write a simple
data source that interacts with the Python ecosystem.

On Tue, 20 Jun 2023 at 03:08, Denny Lee 
wrote:

Slightly biased, but per my conversations - this would be
awesome to have!

On Mon, Jun 19, 2023 at 09:43 Abdeali Kothari
 wrote:

I would definitely use it - is it's available :)

On Mon, 19 Jun 2023, 21:56 Jacek Laskowski,
 wrote:

Hi Allison and devs,

Although I was against this idea at first sight
(probably because I'm a Scala dev), I think it
could work as long as there are people who'd be
interested in such an API. Were there any? I'm just
curious. I've seen no emails requesting it.

I also doubt that Python devs would like to work on
new data sources but support their wishes
wholeheartedly :)

Pozdrawiam,
Jacek Laskowski

"The Internals Of" Online Books

Follow me on https://twitter.com/jaceklaskowski




On Fri, Jun 16, 2023 at 6:14 AM Allison Wang

 wrote:

Hi everyone,

I would like to start a discussion on “Python
Data Source API”.

This proposal aims to introduce a simple API in
Python for Data Sources. The idea is to enable
Python developers to create data sources without
having to learn Scala or deal with the
complexities of the current data source APIs. The
goal is to make a Python-based API that is simple
and easy to use, thus making Spark more
accessible to the wider Python developer
community. This proposed approach is based on the
recently introduced Python user-defined table
functions with extensions to support data sources.

*SPIP Doc*:

https://docs.google.com/document/d/1oYrCKEKHzznljYfJO4kx5K_Npcgt1Slyfph3NEk7JRU/edit?usp=sharing


*SPIP JIRA*:
https://issues.apache.org/jira/browse/SPARK-44076

Looking forward to your feedback.

Thanks,
Allison






OpenPGP_signature
Description: OpenPGP digital signature