TITLE: [MUSIC]
ALEXANDER SPIRIDONOV: Hello.
I'm Alexander Spiridonov,
a Solution Architect from NVIDIA.
I'm specializing in GPU compute acceleration.
Today, I will present
NVIDIA RAPIDS Spark plugin on Azure Synapse.
Today I will talk about NVIDIA / Synapse collaboration.
After that shortly,
about NVIDIA RAPIDS plugin.
After that, I will present two demos,
one is about Azure Synapse Visual Studio Project
and another one about XGBoost on Synapse.
The next slide is
describing on a high level our collaboration activities.
First of all, they are, of course,
including support of
the current Synapse analytics infrastructure
related to GPU and RAPIDS.
Currently, Synapse providing RAPIDS version 2112 on
Spark 3.2.1 and NVIDIA T4 as your VMs.
Second, NVIDIA and Microsoft are constantly
upgrading Synapse environment with
the latest RAPIDS releases.
For example, just recently,
RAPIDS 2112 was released in Synapse 11 to work
is decimal precision up to 38 digits, 128 bits.
Previously, we were
concentrated on ETL Synapse subsystem.
Now, we are starting to
collaborate on analytical part too.
First of all, it will help
naturally at a GPU accelerated machine
learning and deep learning working after
ETL stage on
the same Apache Spark framework running under Synapse.
We are starting on the GPU acceleration of SynapseML
and we'll extend it to the whole ETL-ML/DL pipeline.
In parallel, we are actively working
on our profiling and benchmarking tool.
Later, I will add more details about that.
Of course, we are jointly working
on providing publications and presentations,
helping our customers to
use our platforms more efficiently.
In the next several slides,
I'm adding more details about
our collaboration and our future plans.
One of the main advantages of
RAPIDS is that no quick change
will be required for end users of
Apache Spark SQL or Apache Spark.
All changes are on the physical plan level.
This slide demonstrate an example
for how RAPIDS is changing query execution.
It looks almost the same,
but GPU is working on
quality data and
physical plan operations executed on GPU.
They will have, it's hard to see,
but on the right side,
all operations they have a GPU prefix.
To finish the short review of RAPIDS,
I would like to mention scenarios that
are the most efficient with our plugin.
First of all, it's proved that
SQL with high cardinality joins,
high cardinality aggregations,
and high cardinality sorts are significantly
faster on GPU with RAPIDS compared to CPU.
The same is true for Windows operations,
especially for large Windows.
Plus compared to Spark and CPU,
RAPIDS is very efficient for transcoding.
For example, encoding Parquet and ORC, reading CSV.
The compression on gzip
is significantly faster on GPU too.
It's important to mention that CPU and
GPU code is the same in all comparisons.
Solving a data related problems
can be done through one of two ways,
Data Science or Business Analytics.
Each solution comes with its own advantages,
and choosing one depends on a lot
of factors like your data,
business needs, type of queries, and so on.
Azure Synapse meets these challenges as
the single service to provide
limitless analytics in unified experience.
This is Azure Synapse platform.
You can load your data around ETL pipelines,
store the data back in the data lake,
load them into a warehouse,
and build sophisticated pipelines
according to your business needs
without having to worry about
infrastructure at any steps of your pipeline.
Now we show you two demos.
The first one is to demonstrate how to run
predefined query against GPU
and CPU pools using Visual Studio.
The second is about running machine running
XGBoost notebooks on a Synapse using GPU and CPU.
Let's create a new project from the console application.
Next, it's called TestQuery.
It will be a predefined query against a blob storage.
Same way too. Place it in the same.
Next, select .NET Core, Create.
This is the template program.
First, we'll add required dependencies.
We will add them using NuGet packages.
The first one is Azure Core,
"Install", accept, okay it's here.
Next on this is Azure Identity, "Install",
accept.
Next will be Microsoft Synapse.
That's the last one, accept.
Now we have all dependencies,
and let's change the template.
That's the test.
Let's build it.
Success.
Now, let's run it.
First step is authentication.
Next, if we go to monitoring,
now you'll see this credit history is submitting.
Actually, if you click here,
usually you will see the Livy lock,
once it's running and after that,
you'll see the spark UI That's starting pretty slow.
Let's go back to
the lock and I already had previously the running jobs.
We'll come back and check it again later.
The text of this application is this one.
Let's go for the code.
First of all, I am using
a Synapse client from the Synapse package.
Doing some authentication
and including required packages.
After that, specifying
workspace and the pool name I'm using,
I'm running a predefined query.
It's just a SQL query and
after that setting spark configuration.
This is, again, a standard thing.
You can go to
the RAPIDS site and you will see how to set it up.
After that basic of loading RAPIDS,
because we want to use it for the GPU and after that,
it runs the query,
it's a parameter for the job.
It's extremely simple and just to
show you the communication
between Visual Studio and Synapse.
This thing is interesting.
This is the trigger
basically to enable GPU jobs or disable GPU jobs.
If it's commented, it means
RAPIDS is enabled and we're running on GPU.
But if we will uncomment this,
it will run CPU.
Let's go back to
the monitoring, still in submitting.
Let's check.
See it's already running.
Let's go back until it's finished and I will show
you the previously created runs of the same code.
This one was running on CPU,
it means RAPIDS was false in the configuration.
In here, this is the standard spark UI.
If you go to SQL and check the graph,
you will see the standard graph of these operations,
but it is not all
we talked about this in the presentation.
All operations, they don't have a GPU prefix.
It means everything is running on the CPU.
But if you go back to
our current job and
launch the history for the application.
It takes time to load the work.
Now if you go again to
the SQL and click on job,
you can see now it's running on GPU
because all translated operations are using GPU prefix.
That's basically the way to monitor and
launch job in Visual Studio against Synapse. Thank you.
Now the second demo about XGBoost on
Synapse using GPU and CPU.
First, is CPU version of XGBoost.
I'm running this on the CPU cluster.
The second one is GPU base version and I'm running
this on a previously created to a GPU cluster.
For CPU, this is launch-it.
It uses XGBoost libraries
and they currently saved in
blob storage to link the notebook.
After that, it creates the environment, these libraries.
Next in a notebook with creating label on features.
After creating a session,
this is how I'm loading a data.
It's actually very simple because
it's publicly available data
set and I'm taking only one month to run it.
After that, we need to do some conversions because
the publicly available data set
is actually not in the right structure.
Because of that, I am doing
some queries to select labels and features.
After that, for CPU version, as you know,
we need to use a vector assembler
for future columns to join them in one column.
Just finished and the last job was still running.
On the last stage,
we're doing regression fit.
This is a job,
we can see how it's running.
Once it's done, it will
output how long did it take to run.
Since this is the current time.
We will see almost all jobs finished.
In parallel, actually, we can run
the GPU version. Let's go back.
This job is done but to finish,
their training takes 72 seconds in CPU case.
Now if we go to a GPU again it's
starting a cluster and the loading again,
it's the same libraries,
but plus GPU cluster already
has RAPIDS installed that's why it will run on GPU.
The same code,
the same structure to load.
The same conversion of the data.
Even simpler, now we don't need this part
to do the vectors assembler
because the library is taking everything it sees.
Now, let's see, is it here?
We actually can go to monitoring.
Here you have these two clusters surrounding.
If you go to spark pools,
we can see how much memory
allocated, the spark application.
Let's see. GPU Dagestan,
this is the one that's currently running.
Again, we can see the status of this notebook.
If you go back to notebooks,
GPU configuration finished.
Let's go to the last stage.
This is still running.
It takes 41 seconds compared to 72 seconds on CPU.
We can see it's faster on the smaller cluster,
which has only three nodes.
That concludes the presentation.
Thank you so much for attending.
It has been an amazing collaborative experience
with Microsoft in bringing
the GPU capabilities inside Azure Synapse.
We look forward to further enhancing these capabilities
through new features and
added functionality in the future.
Thank you and have a wonderful rest of your day.