티스토리 뷰
데이터를 다루기 위해서는 다양한 데이터 변환과 조작작업을 주기적으로 수행해야 한다. 이런 행위를 단단히 줄여서 ETL (Extract, Transform, Load) 작업이라고 하는데, 이런 작업을 구성하고 스케쥴 하는 방법에 대해서는 몇년전엔 여러 플랫폼들이 혼재되어있었지만 지금은 AIRFLOW 가 결국 살아 남은거 같다.
과거에는 춘추전국 시대
사실 ETL 을 전문적으로 다루지 않는 부서에서는 Jenkins(젠킨스) 와 Spring Batch(스트림배치) 를 섞어서 주기적인 배치작업을 돌리는 경우도 많다. (Jenkins 는 빌드관리를 위한 용도인데, 희안하게 주위에 배치 스케쥴러로 쓰는 케이스를 꽤 많이 봤다)
crontab 을 쓰는것 대비 WEB UI 에서 진행상태나 로그를 확인 할 수 있기 때문에 자주 쓰였던거 같다.
그리고, 하둡플랫폼의 태동기에는 oozie 를 이용해 하둡의 잡을 관리하려는 시도도 했는데 xml 로 정의하고 생각보다 편리한 느낌은 들지 않았던거 같다. (사실상 현재 거의 안쓰는 플랫폼이 되었다고 보면된다)
그리고, 링크드인에서 만든 Azkaban 이라는 워크플로우 매니징 툴도 나왔는데 ini 설정기반으로 구성해서 zip 으로 묶어서 DAG를 구성했었는데, 개인적으로는 로직은 단순한데 DAG 가 복잡한 경우 파일관리가 조금 번거로웠던거 같다.
Python 기반으로 batch job 의 파이프라인을 구성할 수 있는 luigi 도 나왔지만, 결론적으로는 airflow 로 대동단결된 상황이다.
왜 Airflow 가 독식했을까?
개인적으로 airflow 가 선택된 가장 큰 이유는 airbnb 라는 유명한 회사에서 만들고 공개한 오픈소스라는 점도 있겠지만, 개인적으로는 2가지 기능이 가장 큰 장점으로 다가왔다.
- backfill 기능 (재배치 할때, 날짜를 지정해서 복구를 쉽게 할 수 있음)
- sensing 기능의 제공 (JOB 간 의존성을 걸때 해당 결과물을 센싱해서 대기할 수 있는 개념 존재)
배치를 크게 다루다보니, 장애 처리에 대한 문제가 항상 존재한다. airlfow 에는 backfill 이라는 개념이 존재하고, 과거시간대의 배치를 다시 돌리는게 명령어로 쉽게 적용이 가능하다. 그리고 데이터를 다룰때 A 작업이 끝나고, B 작업을 실행해야하는 형태로 데이터간 의존성이 걸려있어서 복구할때 손을 많이 타는 경우가 있는데, airlfow 에서는 보통 sensing 을 통해 작업을 대기 시킬수 있다. (hdfs 의 특정 폴더에 파일이 생성되거나, hive 의 테이블에 특정 파티션이 생성되거나 하는 상황)
이게 안되면 데이터 재집계를 할때 손이 많이 타게 되는데, 이런 개념이 존재해서 상대적으로 재배치가 수월하다.
그리고, airflow 에서는 operator 라는 개념으로 bash, hive, mysql_to_hive 같은 여러 로직을 다룰수 있는데 기본적으로 꽤 많은 operator 를 제공한것도 큰거 같다.
https://airflow.apache.org/docs/apache-airflow/stable/_api/airflow/operators/index.html
단점은 없을까?
과거에는 HA 구성문제가 있었는데 airflow 2.x 버전대가 나오면서 스케쥴러의 HA 도 구성이 가능한걸로 알고 있다.
그리고 여러 오픈소스 플랫폼들을 비교해보면 알겠지만 airflow 만큼의 완성도를 가진 녀석이 없다.
개인적으로는 DAG 를 웹에서 작성하면 좋겠다는 생각이 있었는데 커뮤니티가 커지면서
다음과 같이 editor 를 플러그인형태로 설치 하여 사용할 수 있는 방법이 생겼다.
https://github.com/andreax79/airflow-code-editor
사실상 지금 데이터 파이프라인을 구성할때 airflow 가 대세가 되버려서, 자체 개발해서 더 편하게 만들지 않는이상 선택지가 없는게 아닐까? 싶다.