Suppose one team fetches event data while several others need to analyze it. Giving each team its own ingestion pipeline duplicates API requests and risks inconsistent results. Running downstream DAGs on fixed schedules is also brittle: they may run before fresh data arrives or when nothing has changed. A consumer DAG instead runs in response to an update to an asset it uses. section 4.1 section 4.2
An asset is a reference identified by a URI or string ID, such as `file:///data/events_01`; the ID does not make Airflow inspect the file. The producer marks the task that updates the data as having that asset in its `outlets`. The consumer places the same asset in its DAG `schedule`. When the producer emits an asset event, Airflow can trigger the consumer without requiring the producer to maintain a list of downstream DAGs. section 4.2 section 4.3
Calculate statistics when events arrive
Define `events_dataset = Asset("file:///data/events_01")`. Set `outlets=[events_dataset]` on the producer’s event-fetching task, then set `schedule=[events_dataset]` on the statistics DAG. The producer can keep its daily schedule; the consumer runs when that task updates the asset. This configuration lets another team add its own consumer by referencing the same asset. section 4.3 section 4.4
An asset-triggered run does not have the time-based scheduling parameters that a daily consumer might previously have used to choose an input file. Use `triggering_asset_events` to inspect the event and, when appropriate, its producing DAG run’s logical date. Producers can also attach information in an event’s `extra` field. If a producer run did not change the asset, it can skip the downstream update rather than trigger unnecessary work. section 4.4 section 4.9
For a consumer that combines multiple inputs:
- Put both assets in `schedule=[asset_1, asset_2]`. By default, a run waits until each input asset has received at least one event; their update order does not matter. section 4.7
- Select each asset’s event separately from `triggering_asset_events` when constructing its input path. The consumer can then read both files and combine them before calculating statistics. section 4.7
- Do not assume the asset condition matches corresponding time intervals in upstream DAGs: asset scheduling does not account for their scheduling semantics. Use conditional asset expressions for other trigger relationships, or combine asset- and time-based scheduling when periodic runs are also needed. section 4.9
Figure 4.11 Every star icon indicates an asset update for either the first or second data set. Only when both data sets have been updated is a DAG run for our consumer DAG triggered. The order in which the assets are updated doesn’t matter.
The update timeline makes the default two-asset condition visible: the consumer starts only after both assets have been updated. section 4.7
