NCA-ADS - Foundations of Accelerated Data Science (12% of the exam) - Section 5.5
Use distributed computing frameworks.
Use distributed computing frameworks such as Dask to partition datasets and coordinate parallel computation across multiple GPUs or nodes. Understand the scheduler model, task graph execution, and how partition size affects both memory usage and communication overhead.
Practice question for this objective
lock_openFree sampleFoundations of Accelerated Data Sciencehard
A data scientist refactors a single-GPU cuDF script to dask_cudf so it can process a Parquet dataset larger than one GPU's memory across a four-GPU node. After reading the data and chaining a filter, an assignment of a derived column, and a group-by sum, she prints the DataFrame's repr and is surprised that no GPU utilisation is observed and the output describes partitions rather than aggregated numbers. Which property of the dask_cudf execution model explains this behaviour?
Adask_cudf executes each transformation eagerly on the GPU but suppresses utilisation reporting until the final group-by has finished reducing across all of the partitions.
BThe group-by sum is unsupported in dask_cudf and silently falls back to a metadata-only placeholder, which is why only partition descriptions appear in the printed output.
Cread_parquet loaded the data into host memory, so the operations ran on the CPU and the printed object is a pandas-backed collection rather than a GPU collection.
Ddask_cudf builds a lazy task graph and defers execution until a materialising action such as compute, persist, or head is called, so chained transformations alone do not dispatch GPU work.check_circle Correct
Recognise that dask_cudf uses lazy evaluation, deferring GPU computation until a materialising action triggers the task graph. Dask, and therefore dask_cudf, separates graph construction from execution. Transformations append nodes to a task graph and return a lazy collection; only actions such as compute, persist, or head submit that graph to the scheduler, which then dispatches partition tasks to the GPU workers.
Why A is wrong: Tempting because plain cuDF is eager, but dask_cudf is lazy; the absent utilisation reflects genuine deferral, not suppressed reporting, so this is wrong.
Why B is wrong: Tempting if one assumes feature gaps, but group-by reductions are fully supported in dask_cudf; the partition repr reflects laziness, not a silent fallback.
Why C is wrong: Tempting because host-resident data would avoid GPU use, but dask_cudf.read_parquet creates GPU-backed partitions; the repr shows a lazy GPU collection, so this is wrong.
Why D is correct: Correct: dask_cudf inherits Dask's lazy evaluation model, so transformations only construct a task graph; computation runs on the GPU workers when a materialising action triggers the scheduler.
Exam traps in Foundations of Accelerated Data Science
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.
Each worker computes a complete final result for its own partitions independently, so the dominant traffic is broadcasting those finished results to a single collector worker at the end.
errorWhy it is wrong: Tempting because partitions are processed independently, but one key's rows span many partitions so per-partition results are not final; this misstates why traffic occurs and is wrong.
Dask streams the entire dataset into GPU memory in one batch by temporarily spilling excess frames to CPU RAM automatically without any partitioning.
errorWhy it is wrong: Dask does not load all data into GPU memory as a single batch. It partitions the dataset and executes work partition by partition according to a lazy task graph, so peak GPU memory pressure stays bounded by partition size, not total dataset size.
The notebook automatically detects that the source cell changed and re-runs it before executing the filter cell, ensuring the DataFrame reflects the new CSV file.
errorWhy it is wrong: Jupyter does not automatically re-run cells when their source code is modified; cells are only executed when the user explicitly runs them, so the kernel retains the state from the last manual execution.