기타 필수 개념

start_date와 schedule_interval, execution_date

• Airflow에서 start_date는 실행 시작 날짜가 아니라 스케줄이 시작 되는 날짜.
• 위와 같은 경우, 1월 1일부터 하루에 한번씩 8시에 스케줄이 등록되고, 하루 뒤인 1월2일부터 execution_date가 1월 1일인 DAG가 실행된다는 것입니다. 이 execution_date는 나중에 해당 DAG를 다시 실행해도 그대로 1월 1일로 유지되는 이 DAG고유 실행 Id 같은 값입니다.
• cron 과 같은 scheduler처럼 생각하면 이 execution_date는 잘 이해가 가지 않습니다. 하지만 ETL관점에서 증분을 생각하면 이해하기 쉽습니다.
  예를 들어, execution_date가 1월 1일인 task의 경우 1월1일의 data를 가지고 ETL을 한다고 예상할수 있습니다. 1월1일 데이터는 1월2일이 되어야 모두 존재하기 때문에 Airflow는 이런 방식의 시간을 설정하고 있습니다.

💡 cron과 다른 개념이므로 주의! ETL 관점에서 생각하자!
execution_date = 예약 간격의 시작을 표시 (실행 날짜라는 말때문에 헷갈리지 말것)

 

Backfill

• 과거에 start_date를 설정하면 Airflow는 과거의 Task를 차례대로 실행하는 Backfill을 실행합니다. 간혹 "과거 언제부터 데이터를 쭈욱 빌드해주세요" 라는 요청을 받으면 과거 start_date를 잘 설정하기만 하면 빌드는 자동으로 과거부터 실행되어 편리하게 데이터를 빌드할 수 있습니다.
• 하지만 이런 동작을 원하지 않는 경우도 많이 있습니다. 그럴때는 DAG 를 선언할때 Catchup 설정을 False로 해주면 Backfill을 실행하지 않습니다.

dag = DAG(
    dag_id="test_dag",
    default_args=default_args,
    start_date=datetime(2021, 1, 1, tzinfo=kst),
    schedule_interval="0 8 * * *",
    catchUp=False,
)

 

원자성 / 멱등성

• airflow task 는 원자성과 멱등성을 지켜야한다. ⇒ 실패 태스크를 재실행할 수 있기 때문.
• 원자성
  • transaction 개념. 모든 것이 완료되거나 완료되지 않도록 보장해야함. 예를 들어 중간에 실패하면 전부 롤백돼야함.
  • 만약 트랜잭션을 묶을 수 없는 상황 (메일 전송 등)이라면 task를 분리 할 것.
• 멱등성
  • 동일한 입력으로 동일한 태스크를 여러 번 호출해도 결과가 동일해야함.