A data engineer is processing a 200 GB Parquet dataset on a four-GPU node. Each GPU has 40 GB of VRAM. The engineer creates a dask_cudf DataFrame by reading the dataset with dask_cudf.read_parquet and then calls a group-by aggregation. The aggregation does not execute immediately. What triggers actual computation and causes the Dask scheduler to dispatch work to the GPU workers?
- AAssigning the dask_cudf DataFrame to a Python variable
- BReading the Parquet files with dask_cudf.read_parquet, which loads data eagerly into GPU memory across all workers
- CPrinting the dask_cudf DataFrame object, which forces Dask to resolve all partitions so the repr can be displayed
- DCalling the compute method on the resulting dask_cudf DataFrame Correct
Why A is wrong: Assignment is a Python name-binding operation and has no effect on Dask scheduling; the task graph remains unevaluated and no GPU work is dispatched at that point.
Why B is wrong: dask_cudf.read_parquet records a read step in the task graph but does not load data eagerly; actual I/O and GPU placement happen only when computation is triggered, which is the key characteristic of Dask lazy execution.
Why C is wrong: Printing a dask_cudf DataFrame displays a high-level metadata repr without executing the full task graph; only a subset of metadata may be resolved, so this does not reliably trigger complete distributed computation across workers.
Why D is correct: dask_cudf operations build a lazy task graph; compute is the explicit trigger that instructs the Dask scheduler to execute all pending graph nodes across the available GPU workers and return a materialised cuDF result.