7.3 Airflow Use Cases

1️⃣ Streaming > Batch 데이터 변환, 정제 작업

Overview

streaming application 이 데이터 저장 작업을 마치면, 해당 streaming 데이터의 경로를 읽어서 Batch용 데이터 저장소(예: hadoop 의 특정 경로의 시간단위 파티셔닝 경로)로 옮기는 작업을 수행합니다.

• Case1: streaming 이 지연이 있더라도 최대 x시간 이내이라면, x시간 이전 데이터를 읽는 DAG를 만든다.

• Case2: streaming application이 하나라면 DAG를 API로 호출하는 것도 하나의 방법이다.

데이터를 확정하기 위해 필요한 추가 작업들도 같이 workflow로 구성합니다.

Background

• 파일 시스템 또는 DB상에서의 streaming 데이터는 대개 파일(데이터) 사이즈가 일정하지 않고 (hadoop block size 에 최적화되지 않고) 파일이 여러개 존재하고, 경로만으로는 해당 시간의 데이터의 확정 여부를 확인하기 어렵습니다.

• 데이터를 확정할 수 없는 데이터로 다양한 배치작업을 시작할 수 없습니다.

Effect

1. streaming 데이터의 적재 지연이나, 데이터 오류 등으로 재처리가 필요할 때 Web UI/API 호출을 통해서 특정 시점이나 기간의 데이터를 재처리 할 수 있습니다.

2. Batch 데이터의 적재 뿐만아니라 후속작업을 이어서 workflow로 구성할 수 있습니다.

   • 후속작업의 예: hive 의 add/drop partition

3. 해당 DAG에 다른 DAG들이 sensor 로 연결해서 batch 데이터 적재가 정상적으로 완료되면 후속 workflow들을 자유롭게 이어갈 수 있습니다.

2️⃣ Sensor 를 이용한 데이터 정합성 보장

Overview

• 앞서 1에서 만든 batch 작업이 끝나면, 해당 batch DAG 를 sensor 로 등록하여 해당 DAG가 성공하면, 이어져야할 후속작업을 timedelta만큼의 차이를 두고 수행합니다.

• 기본적으로 Sensor 로 모니터링하는 DAG 의 interval과 같은 경우에 사용합니다.

• 인터벌이 다른 경우, Sensor를 사용하지 않고 별도의 schedule을 사용합니다.

Background

• 서비스에서 사용하는 주요 데이터(베이스)의 경우, 사용처가 많습니다.

  • 이 경우 해당 데이터 정제작업의 완료 이후에 이어져야 할 일들이 많게는 수십개 이상이되는 경우가 생깁니다.

• 이렇게 많은 작업들이 단순히 정기적인 schedule 로 스케줄링 한다면, 데이터 지연, 데이터 처리 자원 부족등의 이유로 밀리기 시작하면 모든 작업들이 실패하거나 밀리게 됩니다.

Effect

1. 선수 작업의 지연이나 실패시 모든 후속 작업을 수동으로 재처리를 해야한다면, 재처리에 의한 부하가 커지는 경향이 있습니다.

   • (무분별하게 재처리 trigger, 중복된 재처리 등) 이것을 방지하고 graceful 하게 작업의 흐름이 이어질 수 있게 합니다.

2. airflow cluster 내에서 DAG 들 사이의 선수관계와 영향도의 파악이 선언적으로 가능합니다.

3. 2에 의해서 선수작업의 지연이나 장애시 임팩트와 사이드 이펙트 등을 한번에 확인할 수 있습니다.

3️⃣ Schedule 을 이용한 부하분산

Overview

• 같은 리소스풀에 부하가 있는 작업을 처리하는 DAG들은 모두 hourly, daily 작업이더라도 해당 interval 사이에 수행되는 시간을 schedule cron 식을 이용해서 분산합니다.

• 예를 들어 DAG1 은 매시 1분에 DAG2는 매시 11분에 DAG3 은 매시 21분에 시작되는 식입니다.

Background

• airflow는 큰 작업을 worker 내에서 처리하지 않고, 외부의 대용량 처리장치에 위임합니다.

• hourly, daily 로 처리되는 작업은 보통 같은 데이터베이스 등의 자원 또는 리소스 풀을 사용하는 경향이 있습니다.

• hourly 로 동작하는 작업이 모두 매시 0분 0초에 시작된다고 해본다면?

  • 한 시간 중 처음의 몇분 동안만 리소스를 과다하게 점유해 starvation 이 일어나서 리소스 풀의 전체의 장애나 이용중단이 있을 수 있습니다.

Effect

1. 같은 시간에 집중적인 자원 사용으로 인해 starvation이 일어나는 것을 방지할 수 있습니다.

2. 리소스풀의 자원을 skew 없이 고르게 사용할 수 있다. + 리소스 풀의 전체 utilization 을 건강하게 높일 수 있습니다.

3. airflow 의 DAG 는 schedule 식을 선언적으로 코드에 썼기 때문에 클러스터 관리자 입장에서 DAG의 선언과 Operator 의 사용을 보고 사전에/자동으로 관리할 수 있습니다.