Creating a custom Operator

Airflow allows you to create new operators to suit the requirements of you or your team. This extensibility is one of the many features which make Apache Airflow powerful.

You can create any operator you want by extending the airflow.models.baseoperator.BaseOperator

There are two methods that you need to override in a derived class:

  • Constructor - Define the parameters required for the operator. You only need to specify the arguments specific to your operator. You can specify the default_args in the DAG file. See Default args for more details.

  • Execute - The code to execute when the runner calls the operator. The method contains the Airflow context as a parameter that can be used to read config values.

Note

When implementing custom operators, do not make any expensive operations in the __init__ method. The operators will be instantiated once per scheduler cycle per task using them, and making database calls can significantly slow down scheduling and waste resources.

Let’s implement an example HelloOperator in a new file hello_operator.py:

  1. from airflow.models.baseoperator import BaseOperator
  4. class HelloOperator(BaseOperator):
  5.     def __init__(self, name: str, **kwargs) -> None:
  6.         super().__init__(**kwargs)
  7.         self.name = name
  9.     def execute(self, context):
  10.         message = f"Hello {self.name}"
  11.         print(message)
  12.         return message

Note

For imports to work, you should place the file in a directory that is present in the PYTHONPATH env. Airflow adds dags/, plugins/, and config/ directories in the Airflow home to PYTHONPATH by default. e.g., In our example, the file is placed in the custom_operator/ directory. See Modules Management for details on how Python and Airflow manage modules.

You can now use the derived custom operator as follows:

  1. from custom_operator.hello_operator import HelloOperator
  3. with dag:
  4.     hello_task = HelloOperator(task_id="sample-task", name="foo_bar")

You also can keep using your plugins folder for storing your custom operators. If you have the file hello_operator.py within the plugins folder, you can import the operator as follows:

  1. from hello_operator import HelloOperator

If an operator communicates with an external service (API, database, etc) it’s a good idea to implement the communication layer using a Hooks. In this way the implemented logic can be reused by other users in different operators. Such approach provides better decoupling and utilization of added integration than using CustomServiceBaseOperator for each external service.

Other consideration is the temporary state. If an operation requires an in-memory state (for example a job id that should be used in on_kill method to cancel a request) then the state should be keep in the operator not in a hook. In this way the service hook can be completely state-less and whole logic of an operation is in one place - in the operator.

Hooks

Hooks act as an interface to communicate with the external shared resources in a DAG. For example, multiple tasks in a DAG can require access to a MySQL database. Instead of creating a connection per task, you can retrieve a connection from the hook and utilize it. Hook also helps to avoid storing connection auth parameters in a DAG. See Managing Connections for how to create and manage connections and Provider packages for details of how to add your custom connection types via providers.

Let’s extend our previous example to fetch name from MySQL:

  1. class HelloDBOperator(BaseOperator):
  2.     def __init__(self, name: str, mysql_conn_id: str, database: str, **kwargs) -> None:
  3.         super().__init__(**kwargs)
  4.         self.name = name
  5.         self.mysql_conn_id = mysql_conn_id
  6.         self.database = database
  8.     def execute(self, context):
  9.         hook = MySqlHook(mysql_conn_id=self.mysql_conn_id, schema=self.database)
  10.         sql = "select name from user"
  11.         result = hook.get_first(sql)
  12.         message = f"Hello {result['name']}"
  13.         print(message)
  14.         return message

When the operator invokes the query on the hook object, a new connection gets created if it doesn’t exist. The hook retrieves the auth parameters such as username and password from Airflow backend and passes the params to the airflow.hooks.base.BaseHook.get_connection(). You should create hook only in the execute method or any method which is called from execute. The constructor gets called whenever Airflow parses a DAG which happens frequently. And instantiating a hook there will result in many unnecessary database connections. The execute gets called only during a DAG run.

User interface

Airflow also allows the developer to control how the operator shows up in the DAG UI. Override ui_color to change the background color of the operator in UI. Override ui_fgcolor to change the color of the label. Override custom_operator_name to change the displayed name to something other than the classname.

  1. class HelloOperator(BaseOperator):
  2.     ui_color = "#ff0000"
  3.     ui_fgcolor = "#000000"
  4.     custom_operator_name = "Howdy"
  5.     # ...

Templating

You can use Jinja templates to parameterize your operator. Airflow considers the field names present in template_fields for templating while rendering the operator.

  1. class HelloOperator(BaseOperator):
  3.     template_fields: Sequence[str] = ("name",)
  5.     def __init__(self, name: str, world: str, **kwargs) -> None:
  6.         super().__init__(**kwargs)
  7.         self.name = name
  8.         self.world = world
  10.     def execute(self, context):
  11.         message = f"Hello {self.world} it's {self.name}!"
  12.         print(message)
  13.         return message

You can use the template as follows:

  1. with dag:
  2.     hello_task = HelloOperator(
  3.         task_id="task_id_1",
  4.         name="{{ task_instance.task_id }}",
  5.         world="Earth",
  6.     )

In this example, Jinja looks for the name parameter and substitutes {{ task_instance.task_id }} with task_id_1.

The parameter can also contain a file name, for example, a bash script or a SQL file. You need to add the extension of your file in template_ext. If a template_field contains a string ending with the extension mentioned in template_ext, Jinja reads the content of the file and replace the templates with actual value. Note that Jinja substitutes the operator attributes and not the args.

  1. class HelloOperator(BaseOperator):
  3.     template_fields: Sequence[str] = ("guest_name",)
  4.     template_ext = ".sql"
  6.     def __init__(self, name: str, **kwargs) -> None:
  7.         super().__init__(**kwargs)
  8.         self.guest_name = name

In the example, the template_fields should be ['guest_name'] and not ['name']

Additionally you may provide template_fields_renderers a dictionary which defines in what style the value from template field renders in Web UI. For example:

  1. class MyRequestOperator(BaseOperator):
  2.     template_fields: Sequence[str] = ("request_body",)
  3.     template_fields_renderers = {"request_body": "json"}
  5.     def __init__(self, request_body: str, **kwargs) -> None:
  6.         super().__init__(**kwargs)
  7.         self.request_body = request_body

In the situation where template_field is itself a dictionary, it is also possible to specify a dot-separated key path to extract and render individual elements appropriately. For example:

  1. class MyConfigOperator(BaseOperator):
  2.     template_fields: Sequence[str] = ("configuration",)
  3.     template_fields_renderers = {
  4.         "configuration": "json",
  5.         "configuration.query.sql": "sql",
  6.     }
  8.     def __init__(self, configuration: dict, **kwargs) -> None:
  9.         super().__init__(**kwargs)
  10.         self.configuration = configuration

Then using this template as follows:

  1. with dag:
  2.     config_task = MyConfigOperator(
  3.         task_id="task_id_1",
  4.         configuration={"query": {"job_id": "123", "sql": "select * from my_table"}},
  5.     )

This will result in the UI rendering configuration as json in addition to the value contained in the configuration at query.sql to be rendered with the SQL lexer.

../_images/template_field_renderer_path.png

Currently available lexers:

  • bash

  • bash_command

  • doc

  • doc_json

  • doc_md

  • doc_rst

  • doc_yaml

  • doc_md

  • hql

  • html

  • jinja

  • json

  • md

  • mysql

  • postgresql

  • powershell

  • py

  • python_callable

  • rst

  • sql

  • tsql

  • yaml

If you use a non-existing lexer then the value of the template field will be rendered as a pretty-printed object.

Add template fields with subclassing

A common use case for creating a custom operator is for simply augmenting existing template_fields. There might be a situation is which an operator you wish to use doesn’t define certain parameters as templated, but you’d like to be able to dynamically pass an argument as a Jinja expression. This can easily be achieved with a quick subclassing of the existing operator.

Let’s assume you want to use the HelloOperator defined earlier:

  1. class HelloOperator(BaseOperator):
  3.     template_fields: Sequence[str] = ("name",)
  5.     def __init__(self, name: str, world: str, **kwargs) -> None:
  6.         super().__init__(**kwargs)
  7.         self.name = name
  8.         self.world = world
  10.     def execute(self, context):
  11.         message = f"Hello {self.world} it's {self.name}!"
  12.         print(message)
  13.         return message

However, you’d like to dynamically parameterize world arguments. Because the template_fields property is guaranteed to be a Sequence[str] type (i.e. a list or tuple of strings), you can subclass the HelloOperator to modify the template_fields as desired easily.

  1. class MyHelloOperator(HelloOperator):
  3.     template_fields: Sequence[str] = (*HelloOperator.template_fields, "world")

Now you can use MyHelloOperator like this:

  1. with dag:
  2.     hello_task = MyHelloOperator(
  3.         task_id="task_id_1",
  4.         name="{{ task_instance.task_id }}",
  5.         world="{{ var.value.my_world }}",
  6.     )

In this example, the world argument will be dynamically set to the value of an Airflow Variable named “my_world” via a Jinja expression.

For your operator, you can Define an extra link that can redirect users to external systems. For example, you can add a link that redirects the user to the operator’s manual.

Sensors

Airflow provides a primitive for a special kind of operator, whose purpose is to poll some state (e.g. presence of a file) on a regular interval until a success criteria is met.

You can create any sensor your want by extending the airflow.sensors.base.BaseSensorOperator defining a poke method to poll your external state and evaluate the success criteria.

Sensors have a powerful feature called 'reschedule' mode which allows the sensor to task to be rescheduled, rather than blocking a worker slot between pokes. This is useful when you can tolerate a longer poll interval and expect to be polling for a long time.

Reschedule mode comes with a caveat that your sensor cannot maintain internal state between rescheduled executions. In this case you should decorate your sensor with airflow.sensors.base.poke_mode_only(). This will let users know that your sensor is not suitable for use with reschedule mode.

An example of a sensor that keeps internal state and cannot be used with reschedule mode is airflow.providers.google.cloud.sensors.gcs.GCSUploadSessionCompleteSensor. It polls the number of objects at a prefix (this number is the internal state of the sensor) and succeeds when there a certain amount of time has passed without the number of objects changing.