cuDF is a GPU DataFrame library for loading, joining, aggregating, filtering, and otherwise manipulating data. This tutorial provides a quick intro to the pandas-like library and its most commonly-used functionality.
Introduction to cuDF and Dask-cuDF
Modeled after 10 Minutes to Pandas, this is a short introduction to cuDF and Dask-cuDF, geared mainly for new users.
What are these Libraries?
cuDF is a Python GPU DataFrame library (built on the Apache Arrow columnar memory format) for loading, joining, aggregating, filtering, and otherwise manipulating tabular data using a DataFrame style API.
Dask is a flexible library for parallel computing in Python that makes scaling out your workflow smooth and simple. On the CPU, Dask uses Pandas to execute operations in parallel on DataFrame partitions.
Dask-cuDF extends Dask where necessary to allow its DataFrame partitions to be processed by cuDF GPU DataFrames as opposed to Pandas DataFrames. For instance, when you call dask_cudf.read_csv(...), your cluster’s GPUs do the work of parsing the CSV file(s) with underlying cudf.read_csv().
When to use cuDF and Dask-cuDF
If your workflow is fast enough on a single GPU or your data comfortably fits in memory on a single GPU, you would want to use cuDF. If you want to distribute your workflow across multiple GPUs, have more data than you can fit in memory on a single GPU, or want to analyze data spread across many files at once, you would want to use Dask-cuDF.
Object Creation
Creating a cudf.Series and dask_cudf.Series.
Creating a cudf.DataFrame and a dask_cudf.DataFrame by specifying values for each column.
Creating a cudf.DataFrame from a pandas Dataframe and a dask_cudf.Dataframe from a cudf.Dataframe.
Note that best practice for using Dask-cuDF is to read data directly into a dask_cudf.DataFrame with something like read_csv (discussed below).
Viewing Data
Viewing the top rows of a GPU dataframe.
Sorting by values.
Selection
Getting
Selecting a single column, which initially yields a cudf.Series or dask_cudf.Series. Calling compute results in a cudf.Series (equivalent to df.a).
Selection by Label
Selecting rows from index 2 to index 5 from columns 'a' and 'b'.
Selection by Position
Selecting via integers and integer slices, like numpy/pandas. Note that this functionality is not available for Dask-cuDF DataFrames.
You can also select elements of a DataFrame or Series with direct index access.
Boolean Indexing
Selecting rows in a DataFrame or Series by direct Boolean indexing.
Selecting values from a DataFrame where a Boolean condition is met, via the query API.
You can also pass local variables to Dask-cuDF queries, via the local_dict keyword. With standard cuDF, you may either use the local_dict keyword or directly pass the variable via the @ keyword. Supported logical operators include >, <, >=, <=, ==, and !=.
Using the isin method for filtering.
MultiIndex
cuDF supports hierarchical indexing of DataFrames using MultiIndex. Grouping hierarchically (see Grouping below) automatically produces a DataFrame with a MultiIndex.
This index can back either axis of a DataFrame.
Accessing values of a DataFrame with a MultiIndex. Note that slicing is not yet supported.
Missing Data
Missing data can be replaced by using the fillna method.
Operations
Stats
Calculating descriptive statistics for a Series.
Applymap
Applying functions to a Series. Note that applying user defined functions directly with Dask-cuDF is not yet implemented. For now, you can use map_partitions to apply a function to each partition of the distributed dataframe.
Histogramming
Counting the number of occurrences of each unique value of variable.
String Methods
Like pandas, cuDF provides string processing methods in the str attribute of Series. Full documentation of string methods is a work in progress. Please see the cuDF API documentation for more information.
Concat
Concatenating Series and DataFrames row-wise.
Join
Performing SQL style merges. Note that the dataframe order is not maintained, but may be restored post-merge by sorting by the index.
Append
Appending values from another Series or array-like object.
Grouping
Like pandas, cuDF and Dask-cuDF support the Split-Apply-Combine groupby paradigm.
Grouping and then applying the sum function to the grouped data.
Grouping hierarchically then applying the sum function to grouped data.
Grouping and applying statistical functions to specific columns, using agg.
Transpose
Transposing a dataframe, using either the transpose method or T property. Currently, all columns must have the same type. Transposing is not currently implemented in Dask-cuDF.
Time Series
DataFrames supports datetime typed columns, which allow users to interact with and filter data based on specific timestamps.
Categoricals
DataFrames support categorical columns.
Accessing the categories of a column. Note that this is currently not supported in Dask-cuDF.
Accessing the underlying code values of each categorical observation.
Converting Data Representation
Pandas
Converting a cuDF and Dask-cuDF DataFrame to a pandas DataFrame.
Numpy
Converting a cuDF or Dask-cuDF DataFrame to a numpy ndarray.
Converting a cuDF or Dask-cuDF Series to a numpy ndarray.
Arrow
Converting a cuDF or Dask-cuDF DataFrame to a PyArrow Table.
Getting Data In/Out
CSV
Writing to a CSV file.
Reading from a csv file.
Reading all CSV files in a directory into a single dask_cudf.DataFrame, using the star wildcard.
Parquet
Writing to parquet files, using the CPU via PyArrow.
Reading parquet files with a GPU-accelerated parquet reader.
Writing to parquet files from a dask_cudf.DataFrame using PyArrow under the hood.
Dask Performance Tips
Like Apache Spark, Dask operations are lazy. Instead of being executed at that moment, most operations are added to a task graph and the actual evaluation is delayed until the result is needed.
Sometimes, though, we want to force the execution of operations. Calling persist on a Dask collection fully computes it (or actively computes it in the background), persisting the result into memory. When we're using distributed systems, we may want to wait until persist is finished before beginning any downstream operations. We can enforce this contract by using wait. Wrapping an operation with wait will ensure it doesn't begin executing until all necessary upstream operations have finished.
The snippets below provide basic examples, using LocalCUDACluster to create one dask-worker per GPU on the local machine. For more detailed information about persist and wait, please see the Dask documentation for persist and wait. Wait relies on the concept of Futures, which is beyond the scope of this tutorial. For more information on Futures, see the Dask Futures documentation. For more information about multi-GPU clusters, please see the dask-cuda library (documentation is in progress).
First, we set up a GPU cluster. With our client set up, Dask-cuDF computation will be distributed across the GPUs in the cluster.
Persisting Data
Next, we create our Dask-cuDF DataFrame and apply a transformation, storing the result as a new column.
Because Dask is lazy, the computation has not yet occurred. We can see that there are twenty tasks in the task graph and we've used about 800 MB of memory. We can force computation by using persist. By forcing execution, the result is now explicitly in memory and our task graph only contains one task per partition (the baseline).
Because we forced computation, we now have a larger object in distributed GPU memory.
Wait
Depending on our workflow or distributed computing setup, we may want to wait until all upstream tasks have finished before proceeding with a specific function. This section shows an example of this behavior, adapted from the Dask documentation.
First, we create a new Dask DataFrame and define a function that we'll map to every partition in the dataframe.
This function will do a basic transformation of every column in the dataframe, but the time spent in the function will vary due to the time.sleep statement randomly adding 1-60 seconds of time. We'll run this on every partition of our dataframe using map_partitions, which adds the task to our task-graph, and store the result. We can then call persist to force execution.
However, some partitions will be done much sooner than others. If we had downstream processes that should wait for all partitions to be completed, we can enforce that behavior using wait.
With wait, we can safely proceed on in our workflow.