Airflow DAG는 Jinja Macro 로 구현돼 있는, 사전 정의된 값들을 가져다가 사용함으로써 좀 더 다이나믹하게 구현할 수 있다.
그 중에서도 execution_date
를 가장 자주 사용하게 되는데 이 매크로는 DagRun, TaskInstance 가 instantiated 될 때 값이 정해지면서 특정 인스턴스에 정해진 날짜 값을 갖게 해주기 때문에 추후 재작업 등을 하는데 용이하게 쓰인다.
그런데 이 execution_date
에 들어가는 값이 schedule_interval
에 의해 활성화된 작업 시점과 값이 달라서 처음 Airflow에 입문하게 되면 뭐가 뭔지 정말 헷갈리는데 스택오버플로우 링크 에 설명이 잘 돼 있다.
한줄로 정리하자면,
처리할 데이터 범위가 모두 유효해지는 때가 작업이 시작되는 시점이고 해당 데이터 범위의 가장 빠른 시점이 execution_date 값이다.
작업 시점은 cron 표현식으로 만들어지는데 그 작업의 이름은 데이터를 기준으로 해당 데이터의 가장 빠른 시점을 갖고 가기 때문에 헷갈리게 되는거같다.
Airflow Common Pitfalls 문서에 보면 Airflow는 실시간 데이터 처리 보다는 ETL, 배치 처리 작업에 적합한 스케줄러로 설계되었기 때문이라고 하는데 이런 스케줄러는 보통 스냅샷이나 로그 데이터를 많이 다루기 때문인 것 같다.
그래서 로그 데이터를 예를 들어 보자면,
2020/04/16 일자 로그를 처리하는 작업이 있다고 했을때, 2020/04/16 00:00:00
시점부터 2020/04/16 23:59:59
시점까지의 데이터를 대상으로 하고 이 데이터는 2020/04/17 00:00:00
시점에 비로소 모든 데이터가 준비가 된다. 그래서 작업이 실행되는, 데이터 처리가 가능한 시점인 2020/04/17 00:00:00
시점은 schedule_interval 에서 만들어지고 실제 처리 작업의 이름과 execution_date 값은 데이터를 기준으로 2020/04/16 00:00:00
값을 갖게 된다.
주 단위, 월 단위 작업을 보면 확실히 이해를 할 수 있는데
먼저 주단위 작업으로 매주 월요일 오전 9:00 시에 실행되는 작업을 cron expression으로 0 9 * * 1
와 같이 정의 했다면 해당 작업은 2020/09/07 09:00:00
, 2020/09/14 09:00:00
, 2020/09/21 09:00:00
시점에 각각 실행될 것이다.
해당 시점에 시작된 작업들은 그 전 주의 데이터들을 처리하게 될 것인데 작업 시작 시점별 execution_date, ds 값을 정리하면 다음과 같다.
작업 시작 시점 | 데이터 처리 범위 | execution_date | ds |
---|---|---|---|
2020/09/07 09:00:00 | 2020/08/31 09:00:00 ~ 2020/09/07 08:59:59 | 2020/08/31 09:00:00 | 2020-08-31 |
2020/09/14 09:00:00 | 2020/09/07 09:00:00 ~ 2020/09/14 08:59:59 | 2020/09/07 09:00:00 | 2020-09-07 |
2020/09/21 09:00:00 | 2020/09/14 09:00:00 ~ 2020/09/21 08:59:59 | 2020/09/14 09:00:00 | 2020-09-14 |
월단위 작업으로 매월 2일 오전 8시 10분에 실행되는 작업을 10 8 2 * *
와 같이 설정했다면 다음과 같이 매크로 값이 설정된다.
작업 시작 시점 | 데이터 처리 범위 | execution_date | ds |
---|---|---|---|
2020/08/02 08:10:00 | 2020/07/02 08:10:00 ~ 2020/08/02 08:09:59 | 2020/07/02 08:10:00 | 2020-08-02 |
2020/09/02 08:10:00 | 2020/08/02 08:10:00 ~ 2020/09/02 08:09:59 | 2020/08/02 08:10:00 | 2020-08-02 |