BlazingSQL is Now Open Source (opens in new tab)

Thats a great question. The answer is two-fold.

Early on when we first started playing around with General Processing on GPU's we had Nvidia cards to begin with and I started looking at the apis that were available to me.

The CUDA ones were easier for me to get started, had tons of learning content that Nvidia provided, and were more performant on the cards that I had at the time compared to other options. So we built up lots of expertise in this specific way of coding for GPUS. We also found time and time again that it was faster than opencl for what we were trying to do and the hardware available to us on cloud providers was Nvidia GPUs.

The second answer to this question is that blazingsql is part of a greater ecosystem. rapids.ai and the largest contributor by far is Nvidia. We are really happy to be working with their developers to grow this eco system and that means that the technology will probably be CUDA only unless we somehow program "backends" like they did with thrust but that would be eons away from now.

CUDA has two APIs:

1. The runtime api (libcudart.so)

2. The driver api (libcuda.so).

The driver api is very close to the opencl api and is very low level. Most people use the CUDA runtime api which is vastly more convenient. The main difficulty with OpenCl and the driver api is that you have to manually load GPU code onto the device which then returns a handle. You generally have to load the code onto every device which means multiple handles for the same function. This makes executing kernel quiet a lot of work. The runtime api does this all automatically which make programming with CUDA quiet easy since launching a kernel is basically a function call. The CUDA rutime also automatically handles context creation which is another time saver.

When I first learned OpenCL I was shocked at how difficult is was to simply write a simple vector add program since there was all this additional code loading, creating contexts, etc. The setup / boiler plate was greater than the actually code itself.

It basically boils down to convenience in my opinion. Couple this with the fact the NVIDIA generally has the most powerful and energy efficient cards and it's no surprise they took the market.

Also! We have a guy in Lima pushing out some GIS work into cuDF and BlazingSQL too.

+1, this is very cool, but would love for the BlazingDB team to show benchmarks here

We worked with the team early on it. In turn, that means it's inside one of the powertools at gov, bank, etc. teams, even if most of the users don't quite know what a GPU DB is :) We do GPU visual graph analytics over event data (security, fraud, customer 360, ...). We use for a bunch: interactive sub-100ms timebars, histograms, etc. Any full-table compute stuff you'd do in pandas, sql, spark, etc. Any UI interaction like a filter can trigger tons of queries, and w/ GPUs, that means they can quickly compute all sorts of things.

The reason Graphistry picked BlazingSQL is it fit in as part of our approach of end-to-end GPU services that compose by sharing in-memory Apache Arrow format columnar data. When the Blazing team aligned on Nvidia RAPIDS more deeply than the other 2nd-wave GPU analytics engines, it made the most sense as an embedded compute dependency. Going forward, that means Blazing can focus on making a great SQL engine, and we know the rate of their GPU progress won't be pegged to their team but to RAPIDS. A surprise win over just cudf (python) was eliminating most of the constant overheads (10ms->1ms / call), and looking forward, seems like an easier path to multi/many-GPU vs. cudf (dask).

We should share a tech report at some point - bravo to the team!

GPU memory is expensive but a big as #@$% computer is even more expensive. When we show comparisons to things like spark we are doing so use cost basis. So if we say something like we are x times faster than this technology on this workload what we did was launch clusters that have similar costs. Total cost of ownership is also reduced by the fact that the engine itself is totally ephemeral. You can turn it off and on within seconds.

This is a Distributed SQL engine not a database. We store no data. You store your data in HDFS, S3, posix, NFS etc. We allow you to query directly from these filesystems of the file formats you have already. You can look here to see the file formats cudf supports. https://github.com/rapidsai/cudf/tree/branch-0.9/cpp/src/io

You can try it out yourself here https://colab.research.google.com/drive/1r7S15Ie33yRw8cmET7_...

Or use dockerhub https://hub.docker.com/r/blazingdb/blazingsql/

The benefits are.

Greatly increased processing capacities. We can just perform orders of magnitudes more instructions per second than a cpu with the gpus we are using.

Decompression and parsing of formats like CSV and parquet happens in the GPU orders of magnitude faster than the best cpu alternatives.

You can take the output of your queries and provide it to machine learning jobs with zero copy ipc and get the results back the same way. We are all about interoperability with the rapidsai eco system.

Check out https://www.omnisci.com/learn/resources/gpu-database

In summary, you get snappy, interactive query speeds on large data sets. I've ran that locally and the results are pretty amazing compared to Postgres or even Tableau in-memory.

I'm personally more excited about GPUs in stream processing; its just quite a natural fit: https://github.com/rapidsai/cudf

CUDA by itself brings easy-to-run parallel algorithms. It's not of much value for databases unless you have a proper infrastructure set up to use it correctly. Same is true for columnar aspects, for example.

People have been building columnar databases to do analytics quickly. GPUs (with CUDA) can run analytics operations (think join, group by, math, sorting) on columnar data in a much more efficient manner. They're designed for operations on vectors, which columns are.

We've been doing this ourselves too with SQream DB: https://sqream.com. It's an enterprise data warehouse with GPU acceleration. We use CUDA exclusively too.

See https://wiki.postgresql.org/images/6/65/Pgopencl.pdf

Also from 4 years ago

https://news.ycombinator.com/item?id=10151632

PG-Strom is a GPU accelerator extension for PostgreSQL which has been around for a few years now. I have not tried it myself... http://heterodb.github.io/pg-strom/

PartiQL is a query language, based in SQL and extended to be more natural with unstructured and nested data. It can be used with various database and querying engines.

BlazingDB/SQL is a querying engine, more similar to Presto or Apache Drill, and specializes in using GPUs for processing power.

Yeah, we were totally ignorant on PartiQL until your post. Although now looking at it, looks boss! Totally agrees with many of our theses, and there looks to be a lot to glean from this project as well.

No. We hadn't heard of what PartiQL was before you wrote that message. At least I hadn't. I am the CTO of blazingsql

This is an interesting comparison I wouldn't have thought of. But yes, PartiQL does have a similar feel to this announcement, though without GPU-acceleration, the processing speed might be several orders of magnitude slower

> BlazingSQL is built entirely on top of cuDF and cuIO.

Yes.

Yes to be more specific it works on cuda 9.2 and 10.0 at the moment like the rest of the rapidsai eco system.