Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#51

Post by threeseed »

Boxxed wrote: post #33

I'm surprised the GPU is a win when the data is coming from GCS. The CPU still has to touch all the data, right? Or do you have some mechanism to keep warm data live in the GPUs?

I've used GPU based Spark SQL for many years now and it sounds flashy but it's not going to make a meaningful difference for most use cases.

As you say the issue is that you have an overall process to optimise from getting the data off slow GCS onto the nodes, shuffling it which often then writes it to a slow disk before the real processing even starts then writing back to a slow GCS.

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#52

Post by threeseed »

winwang wrote: post #48
threeseed wrote: post #46

Earlier quoted context omitted.

> A lot of BigQuery users would be surprised to find they don't need BigQuery. No they wouldn't. a) BigQuery is the only managed, supported solution on GCP for SQL based analytical workloads. And they are using it because they started with GCP and then chose BigQuery. b) I have supported hundreds of Data Scientists over the years using Spark and it is nothing like BigQuery. You need to have much more awareness of how…

Hopefully, we can be another managed solution for those on GCP. And as for your second point, yep, Spark tuning is definitely annoying! BigQuery is a lot more than jusr the engine, and building a simple interface for a complicated, high-performance process is hard. That's a big reason why I made ParaQuery.

You may want to look into DataMechanics who is another YC startup who tried something similar. They were acqui-hired by NetApp.

If I remember they focused on SME space because in enterprise you will likely struggle against pre-allocated cloud spend budgets which lock companies into just using GCP services. I've worked at a dozen enterprise companies now and every one had this.

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#54

Post by winwang »

threeseed wrote: post #52
winwang wrote: post #48

Earlier quoted context omitted.

Hopefully, we can be another managed solution for those on GCP. And as for your second point, yep, Spark tuning is definitely annoying! BigQuery is a lot more than jusr the engine, and building a simple interface for a complicated, high-performance process is hard. That's a big reason why I made ParaQuery.

You may want to look into DataMechanics who is another YC startup who tried something similar. They were acqui-hired by NetApp. If I remember they focused on SME space because in enterprise you will likely struggle against pre-allocated cloud spend budgets which lock companies into just using GCP services. I've worked at a dozen enterprise companies now and every one had this.

Enterprises can deploy on their own GCP, and we're planning on releasing on GCP Marketplace.

For a similar cost, what if their pipeline were 5x faster, and they don't have to dealing with managing the deployment themselves?

Thanks for telling me about DataMechanics

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#55

Post by winwang »

latchkey wrote: post #44
winwang wrote: post #39

Earlier quoted context omitted.

Nice! I attended a hackathon by Modular last weekend where we got to play with MI300X (sponsored by AMD and Crusoe). My team made a GPU-"accelerated" BM25 in Mojo, but mostly kind of failed at it, haha. The software stack for AMD is still a bit too nascent for ParaQuery's Spark engine, but certain realtime/online workloads can definitely be programmed pretty fast. They also happen to benefit greatly from the staggeri…

Great feedback and thanks for the follow on twitter. Agreed, their software stack needs work, but thankfully that's why they are sponsoring developer events like you attended. The progress is happening fast and this is something that wasn't happening at all 6-12 months ago. It is a real shift in focus. If you have specific areas you'd like me to pass up the chain for them in order for you to build support for your en…

All the Spark GPU acceleration right now is done via the Spark-RAPIDS plugin, so HIP would somehow have to support that. Since cuDF is the core part and hipDF is a thing, it might be doable in the near future.

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#56

Post by winwang »

threeseed wrote: post #51
Boxxed wrote: post #33

I'm surprised the GPU is a win when the data is coming from GCS. The CPU still has to touch all the data, right? Or do you have some mechanism to keep warm data live in the GPUs?

I've used GPU based Spark SQL for many years now and it sounds flashy but it's not going to make a meaningful difference for most use cases. As you say the issue is that you have an overall process to optimise from getting the data off slow GCS onto the nodes, shuffling it which often then writes it to a slow disk before the real processing even starts then writing back to a slow GCS.

Not sure what your use cases are, but I haven't had too much issue seeing good gains vs bare Spark -- GCS has not been my bottleneck.

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#57

Post by latchkey »

winwang wrote: post #55
latchkey wrote: post #44

Earlier quoted context omitted.

Great feedback and thanks for the follow on twitter. Agreed, their software stack needs work, but thankfully that's why they are sponsoring developer events like you attended. The progress is happening fast and this is something that wasn't happening at all 6-12 months ago. It is a real shift in focus. If you have specific areas you'd like me to pass up the chain for them in order for you to build support for your en…

All the Spark GPU acceleration right now is done via the Spark-RAPIDS plugin, so HIP would somehow have to support that. Since cuDF is the core part and hipDF is a thing, it might be doable in the near future.

Oh, interesting! Thanks for the additional context.

This is one area where it is clear that Nvidia is a leader by not only providing the underlying kernels, but also the overall product framework integrations. One would have to port that entire plugin project over, which would probably be a ton of work to maintain.

For what it is worth, AMD just recently released two blog posts on hipDF, so at least they are putting that effort in.

https://rocm.blogs.amd.com/artificial-intelligence/cupy_hipd...

https://rocm.blogs.amd.com/artificial-intelligence/hipDF_pan...

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#58

Post by winwang »

latchkey wrote: post #57
winwang wrote: post #55

Earlier quoted context omitted.

All the Spark GPU acceleration right now is done via the Spark-RAPIDS plugin, so HIP would somehow have to support that. Since cuDF is the core part and hipDF is a thing, it might be doable in the near future.

Oh, interesting! Thanks for the additional context. This is one area where it is clear that Nvidia is a leader by not only providing the underlying kernels, but also the overall product framework integrations. One would have to port that entire plugin project over, which would probably be a ton of work to maintain. For what it is worth, AMD just recently released two blog posts on hipDF, so at least they are putting…

Thanks for the links! I'm planning on contributing kernels back to open source, so will think of a way to be vendor agnostic. As far as I understand, HIP should make that doable.

Re: Launch HN: ParaQuery (YC X25) – GPU Accelerated Spark/SQL

#59

Post by latchkey »

winwang wrote: post #58
latchkey wrote: post #57

Earlier quoted context omitted.

Oh, interesting! Thanks for the additional context. This is one area where it is clear that Nvidia is a leader by not only providing the underlying kernels, but also the overall product framework integrations. One would have to port that entire plugin project over, which would probably be a ton of work to maintain. For what it is worth, AMD just recently released two blog posts on hipDF, so at least they are putting…

Thanks for the links! I'm planning on contributing kernels back to open source, so will think of a way to be vendor agnostic. As far as I understand, HIP should make that doable.

hipify attempts to do that, but it potentially requires you to maintain two source trees, which isn't optimal. In this case, you'd want to run a CI/CD to convert your CUDA code at build time and compile that. But I think there are edge cases where that isn't possible.

As you learned at the event, Modular is trying to make it more transparent by abstracting to a whole new language (Mojo).

Another solution coming down the line which doesn't require changes to your CUDA code, nor learning a new language is: https://docs.scale-lang.com/

Post reply on HN