Airflow 맛보기

ETL Model의 한계ETL은 Batch에서 주로 사용되는 파이프라인을 추상화한 모델하지만 sequential한 작업에서만 적용 가능함(복잡한 DAG에서 사용하기 어려움)하나의 작업이 하나의 머신에서만 동작하므로 물리적인 스케일의 한계가 존재(Spring Batch

Airflow 공식 문서의 Running Airflow in Docker 섹션을 기반으로 설치, 개인 실습용으로 단일 노드(VM)을 띄워 진행함OS : Centos-7.94 cores, 16G ram (최소 사양 4G ram)hostname : airflow.examp

Airflow 설치시, 기본으로 구성된 turorial DAG를 살펴보자하나의 Python파일로 DAG를 선언이때, task가 구동되는 context와 script가 선언된 context가 다를 수 있음에 주의서로 다른 worker는 상호 간 통신이 불가능하지만, 이를

Instantiate a DAG Task를 저장할 DAG 개체가 필요 여기서는 DAG의 고유 식별자 역할을 하는 dag_id를 정의하는 문자열을 전달 예제에서는 default args를 전달하고 DAG에 대한 1일 간격의 schedule을 정의 DAG 인식

Operators Operator는 airflow가 완료될 task 단위를 정의 모든 Operator는 Base Operator에서 상속, 여기에는 task를 실행하는 데 필요한 모든 인수(ex. logical_date)가 포함됨 각 Operator는 완료 중인

이미 지난 날짜를 기준으로 재처리 하는 작업을 의미로그 파일을 바탕으로 데이터베이스에 상태를 기록depends_on_past=True를 사용하여, 이전 작업 인스턴스의 성공여부에 따라 종속성을 부여할 수 있음 (a → b → c 라면 이전 작업의 a가 성공해야 다음 작

개별 Task에서 사용할 수 있는 외부 데이터에 대해 알아보자admin의 variable에서 추가, 삭제Task에서 참조할 수 있는 클러스터 변수variable 이용한 사용jinja template외부 Database 등의 연결Web-UI에서 등록위 코드처럼 호출할 수