NCA-ADS - Data Manipulation and Preparation (23% of the exam) - Section 1.3
Build GPU-accelerated ETL workflows.
Design ETL workflows that move data through extract, transform, and load stages on the GPU to reduce end-to-end processing time. Apply RAPIDS libraries to replace CPU-bound transformation steps and sustain throughput at scale.
ETL
Practice question for this objective
lock_openFree sampleData Manipulation and Preparationmedium
A data engineer is building an ETL workflow that extracts a 30 GB Parquet file, applies several column-wise transformations, and loads the result into a downstream feature store. She wants the extract, transform, and load steps to all run on the GPU so the data is read straight into device memory and stays there until written back out. Which approach keeps the workflow GPU-resident end to end and avoids repeated host-device copies?
ARead the Parquet file with pandas, convert the resulting frame to cuDF for the transformations, then convert the result back to pandas before writing the Parquet output.
BRead the Parquet file with cuDF, move the frame to host memory with a to_pandas conversion for the transformations, then move it back to the GPU only for the final write.
CRead the Parquet file with cuDF, then run the transformations through a NumPy code path by extracting the underlying arrays to host memory, and write the output with cuDF.
DRead the Parquet file with the cuDF reader so the data lands directly in GPU memory, perform the transformations with cuDF operations, then write back with the cuDF Parquet writer, never converting to a pandas DataFrame in between.check_circle Correct
A GPU-resident ETL pipeline reads, transforms, and writes entirely through cuDF so data never round-trips to host memory. cuDF performs the read, the column-wise transforms, and the write all in device memory using GPU kernels. Any conversion to pandas or NumPy forces the data back across the PCIe bus to the host, so avoiding those conversions is what keeps the extract-transform-load flow on the GPU.
Why A is wrong: This is tempting because cuDF and pandas share an API, but reading with pandas places data on the host and each conversion forces a host-device copy, so the workflow is not GPU-resident across the extract and load steps.
Why B is wrong: Doing the transformations on the host throws away the GPU acceleration during the most compute-heavy stage and adds two transfers, defeating the goal of keeping the data on the device throughout.
Why C is wrong: NumPy operates on host arrays, so pulling the columns out to NumPy copies them off the GPU for the transform stage, reintroducing exactly the host-device movement the engineer is trying to eliminate.
Why D is correct: cuDF reads Parquet straight into device memory, its vectorised operations execute on the GPU, and its writer serialises from device memory, so the data never round-trips to host between extract, transform, and load.
Answers that look right on this material and are not. Each one is a distractor from a different question in the NCA-ADS bank for this domain.
Reading with pandas.read_parquet, converting to a cuDF DataFrame with cudf.from_pandas, transforming in cuDF, then converting back to pandas before writing
errorWhy it is wrong: Converting to pandas before writing forces a device-to-host copy at the end of the pipeline, which reintroduces exactly the host-device transfer overhead that GPU ETL is designed to eliminate.
GPU ETL will be faster because cuDF parallelises all join operations regardless of data volume
errorWhy it is wrong: Parallelism provides a benefit only when there is enough data to keep the GPU's thousands of cores busy; a 200-row table is too small to saturate GPU resources, so the overhead of transferring data and launching kernels will exceed any compute gain.
Load the whole dataset into a single cuDF DataFrame and rely on cuDF to automatically spill the overflow to host memory whenever the device runs out of room during the aggregation.
errorWhy it is wrong: Plain cuDF expects the working set to fit in device memory and does not transparently page a single oversized frame through host memory, so attempting to load 240 GB into one cuDF frame fails before the aggregation begins.