BlazingSQL review: Fast ETL for GPU-based data science

BlazingSQL is a GPU-accelerated SQL engine built on top of the RAPIDS ecosystem. BlazingSQL allows standard SQL queries to be distributed across GPU clusters, and the results to be fed directly into GPU-accelerated visualization and machine learning libraries. Basically, BlazingSQL provides the ETL portion of an all-GPU data science workflow.

RAPIDS is a suite of open source software libraries and APIs, incubated by Nvidia, that uses CUDA and is based on the Apache Arrow columnar memory format. CuDF, part of RAPIDS, is a Pandas-like DataFrame library for loading, joining, aggregating, filtering, and otherwise manipulating data on GPUs.

For distributed SQL query execution, BlazingSQL draws on Dask, which is an open source tool that can scale Python packages to multiple machines. Dask can distribute data and computation over multiple GPUs, either in the same system or in a multi-node cluster. Dask integrates with RAPIDS cuDF, XGBoost, and RAPIDS cuML for GPU-accelerated data analytics and machine learning.

BlazingSQL is a SQL interface for cuDF, with various features to support large-scale data science workflows and enterprise datasets, including support for the dask-cudf library maintained by the RAPIDS project. BlazingSQL allows you to query data stored externally (such as in Amazon S3, Google Storage, or HDFS) using simple SQL; the results of your SQL queries are GPU DataFrames (GDFs), which are immediately accessible to any RAPIDS library for data science workloads.

The BlazingSQL code is an open source project released under the Apache 2.0 License. The BlazingSQL Notebooks site is a service using BlazingSQL, RAPIDS, and JupyterLab, built on AWS. It currently uses g4dn.xlarge instances and Nvidia T4 GPUs. There are plans to upgrade some of the larger BlazingSQL Notebooks cluster sizes to A100 GPUs in the future.

In a nutshell, BlazingSQL lets you ETL raw data directly into GPU memory as GPU DataFrames. Once you have GPU DataFrames in GPU memory, you can use RAPIDS cuML for machine learning, or convert the DataFrames to DLPack or NVTabular for in-GPU deep learning with PyTorch or TensorFlow.

BlazingSQL architecture

As we can see in the figures below, BlazingSQL integrates SQL into the RAPIDS ecosystem. The first diagram shows the BlazingSQL stack, and the second diagram shows how BlazingSQL fits with other components of the RAPIDS ecosystem.

Looking at the first diagram, BlazingSQL connects to Apache Calcite via JPype, and uses it as a SQL parser, to create a relational algebra plan from a SQL string. The Relational Algebra Engine (RAL) handles all the smarts of creating a distributed homogenous execution graph to let every worker know what it needs to process. It also helps manage query execution at runtime such as estimating memory consumption (across GPU memory, system memory, and disk memory), in order to manage queries that require out-of-core processing.

The best way to think about it is that RAL is the brains of the engine. Everything above it is a thin client, and what’s below it are compute kernels and underlying libraries.

BlazingSQL

BlazingSQL

BlazingSQL API

The Python class BlazingContext implements BlazingSQL’s API. The simplest use is for a single GPU:

from blazingsql import BlazingContext
bc = BlazingContext()

For multiple GPUs in a single node, you need to use a LocalCUDACluster:

from blazingsql import BlazingContext
from dask_cuda import LocalCUDACluster
from dask.distributed import Client
cluster = LocalCUDACluster()
client = Client(cluster)
bc = BlazingContext(dask_client = client, network_interface = 'lo')

For multiple nodes, you need to refer to a running Dask scheduler by its network address:

from blazingsql import BlazingContext
from dask.distributed import Client
client = Client('123.123.123.123:8786')
bc = BlazingContext(dask_client = client, network_interface = 'eth0')

The network interface for a cluster will vary depending on the environment. On AWS, it’s likely to be ens5. On the BlazingSQL cloud service, the correct IP address and network interface of the Dask scheduler will be filled in for you in the distributed welcome notebook.

Once you have a BlazingContext instance, you can call its methods to create, manage, and query tables:

# create table
bc.create_table('table_name', '/home/user/table_dir/*')

# define a query
query = 'select * from table_name limit 10'

# explain how the query will be executed
print(bc.explain(query))

# query table
dask_cudf = bc.sql(query)

# display results
print(dask_cudf.head())

# drop table
bc.drop_table('table_name')

Note that the distributed query processing is hidden from you. The only time you need to think about it is when you create the BlazingContext.

BlazingSQL SQL

BlazingSQL uses Apache Calcite, the industry-standard SQL parser, validator, and JDBC driver for SQL language. BlazingSQL itself implements a subset of what Calcite can handle. For example, it includes four widths of INT and FLOAT, VARCHAR, two widths of DATE, and TIMESTAMP, but no BOOLEAN, DECIMAL, CHAR, BINARY, or GEOMETRY types. It supports SELECT with most of its subclauses, but no INSERT, PIVOT, or any other DML or DDL.

You can, however, manipulate data in a CUDA DataFrame using CuDF Python APIs, and do even more if you convert to it to a Pandas DataFrame. Unfortunately, a Pandas DataFrame resides in CPU RAM, not in GPU memory.

Most of the common SQL functions for the types listed are supported, or at least mentioned in the documentation. There are CAST functions for more data types than are listed as supported; I didn’t test to see whether they work or how they fail if they don’t work.

Using the BlazingSQL Notebooks service

BlazingSQL Notebooks offers guides to all of its functionality, from creating clusters to writing SQL and Python. The BlazingSQL Notebooks main user interface has tabs for clusters, environments, credits, and documentation. Here I have not yet created any private GPU clusters, but have some credits so that I can do so.

IDG

Rapids Stable will be my default environment.

IDG

Here I’m creating a “medium” four-GPU cluster. Each node is a g4dn.xlarge instance with a T4 GPU. G4dn instances have 16 GB of memory and deliver up to 65 TFLOPs of FP16 performance, so this cluster should be capable of up to 260 TFLOPS using FP16 data, about half that using FP32 data, and about twice that using FP8 data.

IDG

Once my cluster is created and running, I can use the rocket links to launch JupiterLab, and I can also view the Dask dashboard for the cluster.

IDG

BlazingSQL examples (notebooks)

While I went through all of the introductory notebooks, I’ll only show you a few selected screenshots. The code is either Python or SQL; the SQL tends to be in Python strings, and query results are cuDF DataFrames. The next screenshot has the most interesting graphics of the bunch, and takes advantage of the Datashader visualization tool, which supports GPUs and cuDF DataFrames.

I have already loaded some NYC taxi data into a table named taxi from a CSV file. bc is a BlazingContext, pretty much as I described in the API discussion above.

IDG

Here I’ve shown a later section of the same notebook in which we’re querying the taxi data twice: x contains the features that should affect the fare, and y is the target, the fare amount we want to predict. We’re using a simple least squares linear regression model from cuML, which is essentially the same as Scikit-learn Linear Regression.

IDG

Beyond the Welcome notebook, you can run the other notebooks shown in the screenshot below. A few of them can benefit from running a private cluster, but most will run fine on a free single-GPU instance.

IDG

To summarize, BlazingSQL is a GPU-accelerated SQL engine built on top of the RAPIDS ecosystem. The BlazingSQL code is an open source project released under the Apache 2.0 License. The BlazingSQL Notebooks site is a service using BlazingSQL, RAPIDS, and JupyterLab, built on AWS.

Using Dask and a couple of lines of code, BlazingSQL and BlazingSQL Notebooks support multiple GPUs on a single node and clusters of multiple nodes. Once you’ve selected the data you want with BlazingSQL and gotten it into cuDF GPU DataFrames, you can use cuDF APIs to manipulate the data. If you encounter missing methods in cuDF, you can convert the data to a Pandas DataFrame and process it using Pandas methods in normal RAM.

You can perform some data visualization and cuML machine learning entirely in the GPU on cuDF DataFrames. You can also convert the DataFrames to DLPack or NVTabular for in-GPU deep learning.

If you are comfortable writing SQL queries and writing Python, BlazingSQL and BlazingSQL Notebooks will help you with your data science, especially the ETL phase. If you’re not, you may want to consider an AutoML solution with ETL support such as DataRobot, or a drag-and-drop machine learning system such as the Azure Machine Learning Studio.

—

Cost: Free open source. As a service, $0.75/credit, 1 credit = 1 GPU-hour.

Platform: Service runs on AWS. Open source requires Anaconda or Miniconda; Ubuntu 16.04/18.04 or CentOS 7; Nvidia Pascal+; CUDA 10.1.2 or 10.2; Python 3.7 or 3.8. Alternatively, you can use Docker with Nvidia support.