[ETL] Airflow DAG 이슈 해결 Operator Executor

데이터 파이프라인(DAG)의 수가 많아지면?

• 데이터 품질 이슈
• 데이터 리니지 이슈
• 라이브러리/모듈 충돌 이슈
  • 개발환경과 프로덕션 환경을 동일하게 유지
  • Docker to the rescue
  • Dag 혹은 Task 코드를 독립된 공간안에서 각자 실행

태스크나 DAG 코드를 Docker Image로 만들어서 Docker Container 형태로 실행

Docker image: 소프트웨어 실행할 때 필요한 dependent한 라이브러리의 집합

Docker Container: 이를 위한 분리된 공간

• Worker의 부족
  • Scale Up
  • Scale Out: 클라우드 서비스 사용
  • K8s(쿠버네티스, 공용서버 클러스터) 와 같은 컨테이너 기술 사용: 탄력적 환경에서 이용

전용 워커노드를 두는 게아니라 K8s에서 필요한 대로 동적으로 할당하여 사용
Container Orchestration 서비스 => K8s

• 낮은 Server Utilization (Worker 서버들 관리와 활용도 이슈)
  • 공용 서버 클러스터를 충분하게 만들어 놓고 필요할 때마다 ondemand 형식으로 사용하고 반납하면utilization 향상 가능

 

Airflow에서 해결하는 방법

1. Airflow Operator로 KubernetesPodOperator를 사용
2. Airflow Operator로 DockerOperator를 사용
3. Airflow Executor를 사용

→ 위의 과정을 수행하기 위해 Docker와 K8s 필요

 

Airflow Operator?

Operator 레벨은 airflow에서 데이터 파이프라인이라 불리는 DAG의 집합체, DAG Task

Airflow Excutor?

Task들을 관리하고 수행하는 역할을 수행-> 병렬 혹은 일렬 수행인가? 어떤 worker에서 실행할지 등

다양한 수의 Executor 타입이 존재

• Sequential Executor: 디폴트로 설치, Sqlite와 같은 싱글스레드 DB에서만 사용가능, 병렬성 지원 안됌, 직렬로 한번에 하나씩
• Local Executor: 다수의 쓰레드 지원, 병렬 실행가능, worker node가 하나뿐(airflow master node)
• Celery Executor: worker노드가 하나 이상 있는 경우, Scalable하게 Scale-out
• Kubernetes Executor: docker이미지로 구현되어있어야 함
• LocalKubernetesExcutor: Local + Kubernetes 두개 다 지원
• CeleryKubernetesExcutor: Celery + Kubernetes 두개 다 지원