airflow 3로 되면서 2.x대에 지원 중단된 패키지가 많네요..ㅠ

Question

airflow 3.x 기준에는 아래와 같이 써야할거같은데 코드가 많이 달라질까요.. 오픈소스라 매달 버전 업데이트를 하면서 코드까지 바뀌니 저같은 주니어는 따라가기 벅차네요..ㅠ SimpleHttpOperator -> HttpOperator PostgresOperator -> SQLExecuteQueryOperator

altoformula · Answer

맞습니다 ㅠㅠ Airflow 3.x로 오면서 예전 2.x 강의/블로그 코드 중에 deprecated 되거나 import path가 바뀐 것들이 꽤 있습니다. 말씀하신 방향이 맞습니다. SimpleHttpOperator -> HttpOperator PostgresOperator -> SQLExecuteQueryOperator 다만 코드 구조가 완전히 달라지는 수준은 아니고, 대부분은 Operator 이름과 import 경로, 일부 파라미터 이름을 바꾸는 정도 로 대응 가능합니다. 예를 들어 Postgres 쪽은 예전에는 이런 식이었다면: from airflow.providers.postgres.operators.postgres import PostgresOperator task = PostgresOperator( task_id="run_sql", postgres_conn_id="postgres_default", sql="sql/my_query.sql", ) Airflow 3.x 기준으로는 보통 이렇게 바꿉니다. from airflow.providers.common.sql.operators.sql import SQLExecuteQueryOperator task = SQLExecuteQueryOperator( task_id="run_sql", conn_id="postgres_default", sql="sql/my_query.sql", ) 핵심 차이는 postgres_conn_id 가 아니라 더 일반화된 conn_id 를 쓴다는 점입니다. SQLExecuteQueryOperator 는 Postgres 전용이라기보다 여러 SQL 계열 DB에서 공통으로 쓰기 위한 Operator라고 보시면 됩니다. HTTP도 비슷합니다. SimpleHttpOperator -> HttpOperator 이런 변경은 Airflow가 특정 DB/서비스 전용 Operator를 줄이고, provider/common 계열 Operator로 정리해가는 흐름이라고 보시면 됩니다. 주니어 입장에서는 정말 따라가기 힘든 게 맞습니다 . Airflow는 특히 core 버전과 provider 패키지 버전이 같이 움직이다 보니, 강의 코드와 현재 설치 버전이 달라지면 import부터 막히는 경우가 많습니다. 그래서 실무에서는 보통 이렇게 접근하시면 좋습니다. 강의는 전체 구조와 개념을 이해하는 용도로 보기 실제 코드는 현재 설치된 Airflow/provider 문서를 기준으로 import 확인하기 Operator가 deprecated 되면 “대체 Operator가 무엇인지”만 확인해서 교체하기 DAG 구조, task dependency, connection, schedule 개념은 거의 그대로 가져가기 즉, 코드 한두 줄이 바뀌었다고 강의 내용이 틀어진 것은 아니고, Airflow 생태계가 버전업되면서 표준 Operator 이름이 정리된 것으로 보시면 됩니다. 말씀 주신 부분은 중요한 변경점이라 강의 공지나 보충 자료에 Airflow 3.x 기준 migration 예시를 추가해두겠습니다. 좋은 제보 감사합니다.