A directed acyclic graph (DAG) represents a workflow as tasks connected by directed dependency edges. Each task is a smallest resumable unit of computation: it performs an action such as fetching data or triggering a service, then succeeds or fails as a whole. The directed edges specify which tasks must finish before successor tasks can run; the absence of loops prevents execution from falling into a dead loop. section 9.1.1
In production machine-learning systems, DAGs provide the execution order that glues automations together. A workflow can launch training when a dataset is built, monitor and transform upstream data, deploy a model after it meets acceptance criteria, or watch performance metrics and alert developers on degradation. section 1.2.2 section 9.1.1
Figure 9.1 A DAG of a sample model training workflow with multiple steps. Both ovals and diamonds are steps, but different types. The solid arrows indicate the dependencies between steps, and the dotted-line arrows represent the external web requests sent from steps.
Read the solid arrows as dependency constraints: authorization runs first; dataset building and embedding retrieval may run in parallel afterward; downstream steps wait for both required predecessors. Dotted arrows are external requests rather than DAG dependencies. section 9.1.1
A workflow definition declares the tasks, their control flow, and each task’s action and parameters. An orchestration service stores the DAG and execution history in metadata storage, schedules active workflows, dispatches ready tasks to workers, and uses shared object storage to pass task outputs to successor tasks. Centralized metadata and artifacts let the web interface, scheduler, and workers operate independently. section 9.2.1 section 9.2.2
Training and release pipeline
A practical training DAG can be expressed as data parsing → data augmentation → dataset building → training → [online evaluation, offline evaluation] → model release. The bracketed evaluations can proceed after training, while release is held until its required evaluation conditions are satisfied. The workflow can also carry a monthly schedule and an external-event trigger; a training task may invoke a model-training service through a RESTful HTTP request. section 9.2.1
Airflow implements a DAG as Python code: define the DAG and tasks, then declare task dependencies. Tasks are operators, including predefined integrations such as MySqlOperator, SimpleHttpOperator, Docker operator, and custom Python functions through PythonOperator. Its UI and CLI can inspect DAGs, list tasks, display a dependency tree, and monitor execution. section 9.3.1
When building or evaluating DAG-based orchestration, emphasize:
- Criticality, so important production work receives appropriate treatment. section 9.4
- Usability and human centricity, to reduce workflow construction, testing, and debugging costs. section 9.4
- Extensibility, task isolation, and scalability, so workflows can grow without tightly coupling execution concerns. section 9.4
