Migrate Airflow tasks
If you are just getting started with Airlift, we recommend using the new Airlift component.
Previously, we completed the "observe" stage of the Airflow migration process by encoding the assets that are produced by each task. We also introduced partitioning to those assets.
So far, we have left the Airflow code alone, but in this step, we will begin the actual migration process, which will require modifying Airflow code.
Once you have created corresponding Dagster assets for your Airflow tasks, you can proxy execution to Dagster on a per-task basis while Airflow is still controlling scheduling and orchestration. Once a task has been proxied, Airflow will kick off materializations of corresponding Dagster assets in place of executing the business logic of that task.
Create a file to track proxying state
To begin proxying tasks in an Airflow DAG, you will first need to create a file to track proxying state.
For this tutorial, in the example Airflow DAG directory, create a proxied_state
folder. In that folder, create a YAML file with the same name as the example DAG. The included example at airflow_dags/proxied_state
is used by make airflow_run
, and can be used as a template for your own proxied state files.
Given our example rebuild_customers_list
DAG with its three tasks, load_raw_customers
, run_dbt_model
, and export_customers
, your proxied_state/rebuild_customers_list.yaml
file should look like the following:
tasks:
- id: load_raw_customers
proxied: False
- id: build_dbt_models
proxied: False
- id: export_customers
proxied: False
Next, you will need to modify your Airflow DAG to make it aware of the proxied state. This is already done in the example DAG:
# Dags file can be found at tutorial_example/airflow_dags/dags.py
from pathlib import Path
from airflow import DAG
from dagster_airlift.in_airflow import proxying_to_dagster
from dagster_airlift.in_airflow.proxied_state import load_proxied_state_from_yaml
dag = DAG("rebuild_customers_list", ...)
...
# Set this to True to begin the proxying process
PROXYING = False
if PROXYING:
proxying_to_dagster(
global_vars=globals(),
proxied_state=load_proxied_state_from_yaml(Path(__file__).parent / "proxied_state"),
)
Set PROXYING
to True
or eliminate the if
statement.
The DAG will now display its proxied state in the Airflow UI. (There is some latency as Airflow evaluates the Python file periodically.)
Migrate individual tasks
In order to proxy a task, you must do two things:
- Ensure all associated assets are executable in Dagster by providing asset definitions in place of bare asset specs.
- Set the
proxied: False
status in theproxied_state
YAML folder toproxied: True
.
Any task marked as proxied will use the DefaultProxyTaskToDagsterOperator
when executed as part of the DAG. This operator will use the Dagster GraphQL API to initiate a Dagster run of the assets corresponding to the task.
The proxied file acts as the source of truth for proxied state. The information is attached to the DAG and then accessed by Dagster via the REST API.
A task which has been proxied can be easily toggled back to run in Airflow (for example, if a bug in implementation was encountered) simply by editing the file to proxied: False
.
Migrate common operators
For some common operator patterns, like our dbt
operator, Dagster supplies factories to build software-defined assets for our tasks. In fact, the @dagster_dbt.dbt_assets
decorator used earlier already backs its assets with definitions, so we can change the proxied state of the build_dbt_models
task to proxied: True
in the proxied state file:
tasks:
- id: load_raw_customers
proxied: False
- id: build_dbt_models
proxied: True
- id: export_customers
proxied: False
It may take up to 30 seconds for the proxied state in the Airflow UI to reflect this change. You must subsequently reload the definitions in Dagster via the UI or by restarting dagster dev
.
You can now run the rebuild_customers_list
DAG in Airflow, and the build_dbt_models
task will be executed in a Dagster run:
You'll note that we proxied a task in the middle of the Airflow DAG. The Airflow DAG structure and execution history is stable in the Airflow UI, but execution of build_dbt_models
has moved to Dagster.