데이터 플랫폼의 Workflow 관리하기
데이터플랫폼의 크기와 복잡도가 커짐에 따라 workflow를 손쉽게 관리하는 툴의 필요성은 점점 더 커집니다. 데이터를 ETL하는 것 부터 그 이후 여러 로직을 처리할 수 있는 흐름을 한눈에 보아야 에러 관리 등이 편하기 때문에 이에 대한 요구가 커지는 것입니다.
이에 여러 workflow관리 프레임워크가 나와있습니다.
그 중 Airflow와 Oozie에 대해서 살펴보려 합니다. 여러 문서들을 살펴보니 전체적으로 Airflow의 인기가 더 좋아보입니다. 그 이유도 함께 알아보겠습니다.
Airflow
Airflow는 Python코드로 workflow를 build하고 run 하는 플랫폼으로 DAG로 task들을 표현합니다.
여기서 task는 서로 dependency를 가지고 있어 관리해야하는 data flow 입니다.
Task 사이의 dependency를 DAG( Directed Acyclic Graph )로 관리하는데 실행 순서나 에러가 났을 때 어떻게 해야하는지 등을 표현합니다.
Task는 무엇을 해야하는지 즉 패치해야하는 데이터가 무엇인지, 분석을 실행하는지 등을 나타냅니다.
Airflow의 컴포넌트는 아래와 같습니다.
- Scheduler에서 workflow를 스케쥴링하고 실행하며 task들이 실행될 수 있게 executor에 task 를 넘겨줍니다.
- Executor는 task를 실행하는 곳인데요, 디폴트는 scheduler 내에서 직접 실행하지만 보통은 Workers로 task를 넘겨주는 방식으로 활용합니다.
- Webserver는 DAG와 task의 동작을 검사, 실행, 디버그하는 등의 인터페이스를 제공합니다.
- Folder of DAG files에는 scheduler, executor(workers를 포함) 관련 파일이 저장되어 있습니다.
- Metadata database는 scheduler, executor, webserver가 상태를 저장하는 곳입니다.
DAG는 세가지 타입으로 이루어져 있는데요,
- Operators : DAG를 빠르게 구성하기 위해 미리 정의된 요소입니다.
- Sensors : Operator의 subclass로 외부의 이벤트를 사용할 수 있습니다.
- TaskFlow : task로 만들기 위해서 사용하는 파이썬의 데코레이터입니다.
Operator나 Sensor 등으로 하나의 task를 만드는 것입니다.
task를 만들기 위해 다양한 Operator를 제공하는데요 BashOperator, PythonOperator, EmailOperator등 이름을 보아도 어떤 일을 하는지 알 수 있는 Operator들이 많이 존재합니다.
이와 같은 Operator와 Sensor가 외부에서 가져온 event를 활용하여 task를 만듭니다.
DAG는 여러번 실행되도록 설계하며 동시에 실행할 수도 있습니다. 실행되는 간격과 종속성을 지정해주면 됩니다.
Oozie
Hadoop의 Job을 관리하기 위한 스케쥴링 시스템입니다. 이 또한 DAG로 이루어져 있습니다. 언어는 Airflow와 다르게 XML을 사용합니다. Hadoop이나 PIG와 같은 원격시스템에서 작업을 시작하는데 작업이 완료되면 Oozie를 콜백하고 이후에 다음 작업을 진행하는 방식입니다.
Oozie는 workflow, Coordinator, Bundle, 속성 파일을 작성하여 사용합니다.
- Workflow : DAG에 정렬된 작업 모음입니다. Oozie의 work flow는 두가지 노드로 구성되어있습니다.
- Control flow node : work의 시작과 끝, fail을 정의하고 workflow의 decision, fork join등을 관리하는 메카니즘을 제공합니다.
- Action node : 어떤 workflow가 계산/처리 작업을 실행하게 하는 메커니즘을 제공합니다.
- Coordinator : workflow를 실행하기 위한 종속성 검사에 사용됩니다. 반복적이고 위존성이 있는 workflow 작업들을 정의하고 실행합니다.
- Bundle : coordinator를 처리하는 응용 프로그램 파이프라인 생성기 입니다.
공통점
DAG 사이에 제어종속성이 있기 때문에 첫번째 작업이 완료될 때 까지 두번쨰 작업을 실행할 수 없습니다.
spark, pig, hive, mapreduce와 같은 여러 다른 활동들을 그룹화하여 관리할 수 있습니다.
차이점
Oozie는 Airflow에 비해
종속성에 대한 유연성이 떨어집니다.
Task 또한 fs, Pig, Hive, ssh 작업 및 shell 작업과 같이 Oozie에서 허용되는 작업들만 실행할 수 있습니다.
모든 작업은 맵리듀스 형태입니다.
작업은 시간기반으로 진행됩니다. 이벤트리스너가 따로 없습니다.
Airflow는 Oozie에 비해
작업 실패만 보여주는게 아니라 추적할 수 있게끔 UI가 되어있습니다.
동적 파이프라인을 생성할 수 있습니다.
이벤트 기반으로 워크플로를 진행할 수 있습니다.
작업들의 동시성이 증가되면 새로운 job이 추가되지 않을 수 있습니다.
확장성이 뛰어나 관리할 부분이 더 많고 파일 저장을 일일이 신경써야 합니다.
결론
여러 기업들이 Jenkins나 Oozie 등에서 Airflow로 이동하는 경향이 두드러지는 듯 합니다. 내용을 조사하다보니 아무래도 Airflow의 확장성이 더 크고 유연하며 파이썬 코드이기 때문에 더욱 활용하기 편해보입니다. Web UI도 Oozie보다는 Airflow가 편하다고들 합니다. 다음에 기회가 되면 Airflow의 코드를 살펴보도록 하겠습니다.
레퍼런스
https://www.godaddy.com/engineering/2018/11/15/developer-view-oozie-vs-airflow/