[Airflow] TO-BE Batch job 프로세스 개선 - 2) 거버넌스, 표준, 형상 관리, 자동화, 프로세스 단축

BigData/Apache Airflow

[Airflow] TO-BE Batch job 프로세스 개선 - 2) 거버넌스, 표준, 형상 관리, 자동화, 프로세스 단축

스파이디웹 2024. 6. 22. 12:24

728x90

포스트는 총 3개로 나뉘어 진행되며, 이번 포스트가 2번째 포스트입니다.

1. [Airflow] TO-BE Batch job 프로세스 개선 - 1) Airflow on k8s 이전 (AWS EKS)

https://spidyweb.tistory.com/543

2. [Airflow] TO-BE Batch job 프로세스 개선 - 2) 거버넌스, 표준, 형상 관리, 자동화, 프로세스 단축

https://spidyweb.tistory.com/544

3. [Airflow] TO-BE Batch job 프로세스 개선 - 3) DAG 이전 및 이슈 정리

https://spidyweb.tistory.com/545

1. 표준과 자동화

기존의 Airflow DAGs는 다양한 사용자로부터 다양한 코드 포멧과 스타일에 따라 python file명부터해서 DAG 명칭, DAG의 내용, 사용하는 Operator까지 전부 다양하게 존재했습니다.(SQL을 실행시키는데, SQL파일, PythonOperator 이중에서도 SQL쿼리, 프로시저) 등 다양하게 사용되었습니다.

결국 이러한 관리도 사람이 관리하는 것이고, 사람이 이어받는 것이기 때문에 표준화와 자동화의 중요성이 증대되었습니다.

표준 및 자동화가 필요한 목록

코드 포맷
Python file 명칭
DAG 명칭
사용하는 Operator
DAG의 template
source 일원화

1) 코드 포멧

다양한 사람이 코드를 작성하다 보니 다양한 indent 스타일과 괄호 사용등 일정하지 않은 포맷이 있었습니다.

따라서, git commit이전에 black 라이브러리를 통해 강제로 black formatting이 되도록 .pre-commit-config.yaml를 추가하였습니다.

black이란?

pip install black으로 설치
Python 코드를 자동으로 포맷팅해주는 도구
기본적으로 PEP 8 스타일 가이드라인을 따르지만, 몇 가지 면에서 PEP 8과 차이가 있을 수 있음

black 사용법

# 파일이 바뀌는지 확인
black --check 파일이름.py
# 특정 파일에 대해서 blakc 적용
black 파일이름.py
# 모든 하위 파일에 대해서 black 적용
black .

git commit 전에 black을 검사하고 실행

#.pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v3.4.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
      - id: check-added-large-files
  - repo: https://github.com/psf/black
    rev: 24.4.2
    hooks:
      - id: black
        language_version: python3

2) python file명칭, DAG 명칭

다들 일정한 규칙없이 python file과 DAG명명을 하여 중구난방으로 관리되고 있었습니다.

따라서

최소한의 폴더의 구분과, 플랫폼구분, 그리고 명칭만 봐도 스케줄 주기를 파악할 수 있게끔 구성하였습니다.
python file과 DAG명칭을 동일하게 하여 파이썬파일과 DAG가 혼동되지 않도록 일종의 명명규칙(거버넌스를 구축하였습니다.)

ex)

{platform}-{workload}-{schedule}-{version}-{sequence}

3) source의 일원화

source 또한 다양한 테이블로 부터 마트를 만들기 때문에, 관리의 대상이였습니다.

xAPI라는 표준체계에 맞게 이력성 데이터들을 하나의 테이블에 2개의 파티션(source, date)로 나누어 통일화 시켰습니다.

따라서 하나의 테이블로부터 마트가 생성되게끔 구성하였습니다.

4) DAG 생성 자동화(DagFactory)

각각 사용하는 Operator도 다름
필요없는 library들이 너무많이 import되어 있음
처음 DAG를 만드는 입문자에게는 DAG를 만드는 것 자체가 어려움

위와 같은 문제들을 해결하기 위해서, DagFactory(일종의 BoilerPlate) 유틸을 개발했습니다.

마련해둔 몇 가지의 template 선택을 시작으로,

사용자가 필요한 정보들을 대화식으로 받아서 DAG가 원하는 폴더에 입력한 값으로 자동으로 생성되게끔 구성하였습니다.

5) SQL 개발과 동시에 Airflow에 배치적용

마트를 개발할 때, SQL를 배치 스케줄링에 적용하는 것 처럼 개발을 하면, commit & push만으로 바로 배치 스케줄링을 적용할 수 있지 않을까? 라는 생각에 시작된 SQL(Redshift target) 제출 유틸을 개발했습니다.

SELECT col1, $바인딩변수
FROM DB.TABLE
WHERE date = $바인딩변수;

위와 같은 SQL에 대해서 바인딩변수를 인식하여, 실제 날짜값, 혹은 변수값으로 치환 된채로 redshift에 쿼리를 날 릴 수 있게 되어 사용자는 아래 5가지만 신경 쓰면 되게 끔 구성하여 개발 프로세스를 단축하였습니다.

SQL파일 저장
SQL파일 명 입력
사용할 변수명 입력(binding 변수)
scheduling 및 task 의존 관계 설정
git commit & push

뿐만 아니라, SQL파일의 형상 관리까지 되는 이점을 확인 할 수 있었습니다.

* 더 적용해야 될 것 *

DAG 명명규칙은 강제되지 않기에, 명명규칙을 따르지 않은 DAG에 대해서는 어떻게 검출해낼 것인지에 대해서도 고민
너무 많이 생기는 SQL에 대해서 어떻게 관리를 할 것인지?(현재는 workload단위 폴더로 구분하여 저장)

728x90