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

61–70 of 85 posts

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

#61

Post by threeseed »

winwang wrote: post #54
threeseed wrote: post #52

Earlier quoted context omitted.

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

a) Enterprises have almost entirely moved away from self-hosting software. GCP Marketplace is fine but I would probably also look at a Kubernetes option as many companies have GKE clusters.

b) It won't be 5x faster though and I wrongly recommend you don't take a marketing attitude when selling this type of software. Because it will be mostly technical engineers and architects deciding on this and we aren't stupid. I have run GPU accelerated Spark clusters for years for enterprise companies and you will be able to accelerate the query part of the pipeline but that's like 20% of what a typical job does.

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

#62

Post by winwang »

threeseed wrote: post #61
winwang wrote: post #54

Earlier quoted context omitted.

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

a) Enterprises have almost entirely moved away from self-hosting software. GCP Marketplace is fine but I would probably also look at a Kubernetes option as many companies have GKE clusters. b) It won't be 5x faster though and I wrongly recommend you don't take a marketing attitude when selling this type of software. Because it will be mostly technical engineers and architects deciding on this and we aren't stupid. I…

a) Since being fully-managed is one of my value props, that's probably better for us.

b) Of course I'm only accelerating the Spark/query part. Not sure what you mean. And in that case, I took a query which was 44 minutes on BigQuery and ran it with a "comparable" cluster on ParaQuery in 5.5 minutes. Perf is slightly variable, so maybe it's 40 minutes vs 6 minutes. In that case, ParaQuery would still be 6.5x faster, and >2x cheaper. That being said, it was just a benchmark ETL query with some random data (50b rows), and these things do vary between workloads.

So yeah, without knowing more about the use case you're talking about, hard to say. Even Nvidia has a hard time optimizing certain TPS-DS queries btw, so it's not like I can just 5x anything!

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

#63

Post by mritchie712 »

threeseed wrote: post #46
mritchie712 wrote: post #28

> they're saving over 60% off of their BigQuery bill how big is their data? A lot of BigQuery users would be surprised to find they don't need BigQuery. This[0] post (written by founding engineer of BigQuery) has a bit of hyperbole, but this part is inline with my experience: > A couple of years ago I did an analysis of BigQuery queries, looking at customers spending more than $1000 / year. 90% of queries processed l…

> 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…

> No they wouldn't.

haha, you're giving people way too much credit. Tons of people make bad software purchasing decisions. It's hard, people make mistakes.

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

#65

Post by winwang »

latchkey wrote: post #59
winwang wrote: post #58

Earlier quoted context omitted.

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…

Thanks for the link! Not the first time I came across it, but it's a good one.

If I had to bet on the longer term, I think that something like Mojo will win out -- a programming language (mostly) agnostic to the underlying vector processor hardware. Similar to how Rust can target various SIMD implementations, though I've only dabbled in that.

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

#67

Post by andygrove »

Congrats on the launch!

I contributed to the NVIDIA Spark RAPIDS project for ~4 years and for the past year have been contributing to DataFusion Comet, so I have some experience in Spark acceleration and I have some questions!

1. Given the momentum behind the existing OSS Spark accelerators (Spark RAPIDS, Gluten + Velox, DataFusion Comet), have you considered collaborating with and/or extending these projects? All of them are multi-year efforts with dedicated teams. Both Spark RAPIDS and Gluten + Velox are leveraging GPUs already.

2. You mentioned that "We're fully compatible with Spark SQL (and Spark)." and that is very impressive if true. None of the existing accelerators claim this. Spark compatibility is notoriously difficult with Spark accelerators built with non-JVM languages and alternate hardware architectures. You have to deal with different floating-point implementations and regex engines, for example.

Also, Spark has some pretty quirky behavior. Do you match Spark when casting the string "T2" to a timestamp, for example? Spark compatibility has been pretty much the bulk of the work in my experience so far.

Providing acceleration at the same time as guaranteeing the same behavior as Spark is difficult and the existing accelerators provide many configuration options to allow users to choose between performance and compatibility. I'm curious to hear your take on this topic and where your focus is on performance vs compatibility.

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

#68

Post by winwang »

andygrove wrote: post #67

Congrats on the launch! I contributed to the NVIDIA Spark RAPIDS project for ~4 years and for the past year have been contributing to DataFusion Comet, so I have some experience in Spark acceleration and I have some questions! 1. Given the momentum behind the existing OSS Spark accelerators (Spark RAPIDS, Gluten + Velox, DataFusion Comet), have you considered collaborating with and/or extending these projects? All of…

1. Yes! Would love to contribute back to these projects, since I am already using RAPIDS under the hood. My general goal is to bring GPU acceleration to more workloads. Though, as solo founder, I am finding it difficult to have any time for this at the moment, haha.

2. Hmm, maybe I should mention that we're not "accelerating all operations" -- merely compatible. Spark-RAPIDS has the goal of being byte-for-byte compatible unless incompatible ops are specifically allowed. But... you might be right about that kind of quirk. Would not be surprising, and reminds me of checking behavior between compilers.

I'd say the default should be a focus on compatibility, and work through any extra perf stuff with our customers. Maybe a good quick way to contribute back to open source is to first upstream some tests?

Thanks for your great questions :)

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

#70

Post by debarshri »

It reminds me of Hadoop days, where the data would be stored in the HDFS and you would use mapreduce to process it. However, the concept was to send computation to the location of the data.

This really make sense. I might be a little out of touch. I wonder, do you incur transfer cost when you data is in buckets and you process by bringing data to the compute.

Post reply on HN