Dask builds a task graph lazily; a scheduler evaluates its nodes across computing resources. If no scheduler is configured, Dask selects a default based on the collection. A Dask data frame, for example, uses the multithreaded scheduler by default. section 10.3
import dask
from dask.base import get_scheduler
import dask.dataframe as dd
df = dd.read_csv("FY2016-STC-Category-Table.csv")
print(get_scheduler(collections=[df]).__module__)
Use get_scheduler on a collection to inspect which scheduler will execute its task graph. For this data frame, the reported module is dask.threaded. section 10.3
Choose the execution setup to suit the job:
- Use the single-threaded scheduler for debugging or profiling: sequential execution removes concurrency from the investigation. section 10.3
- Use the distributed scheduler to run on one machine or across machines. On one machine it supports threads or multiple processes; deployments also include HPC clusters, SSH connections, and cloud providers. section 10.3
- Treat worker count and threads per worker as workload choices, not universal defaults. NumPy-heavy work may benefit from letting NumPy manage threading rather than adding worker-level threads. section 10.3.1
In dask.distributed, one centralized scheduler assigns tasks to workers, which execute them. A client connects to the scheduler to submit work and inspect the deployment. The scheduler’s dashboard shows computation performance; workers have their own dashboards and monitoring processes. section 10.3.1
dask-scheduler --port 8786 --dashboard-address 8787
Start a scheduler with an explicit task port and dashboard address, then start workers against that port. Running every component locally makes the architecture visible without requiring a cluster. section 10.3.1
A scheduler in concurrency can also mean the mechanism behind preemption: interrupting one task so another can run. Do not assume that Dask’s choice of where to evaluate task-graph nodes describes a preemption policy. section 3.0 section 10.3











