DAG 과 Spark Job 소스에서 인터페이스 정의서를 만들 때, 무엇을 담아야 쓸모가 있는지 정리한다. 파이프라인이 수십 개로 늘어나면 슬라이드보다 파이프라인당 시트 하나짜리 표가 관리하기 쉽다.
정의서를 만드는 목적이 문서 제출이라면 테이블 · 컬럼 명세만으로 충분하지만, 배치 스케줄을 짜는 것이 목적이라면 그 정보로는 부족하다. 필요한 것은 "이 파이프라인을 돌리기 전에 무엇이 끝나 있어야 하는가" 다.
파이프라인 목록 시트 하나 + 파이프라인당 시트 하나로 둔다. 파이프라인 시트는 A 부터 F 까지 같은 순서를 지킨다.
| 절 | 내용 |
|---|---|
| A. 데이터 흐름 | 소스 → 타깃을 한눈에. 레이어(bronze · silver · gold · export)를 헤더 색으로 구분하고 단계마다 어떤 Job 이 처리하는지 표기 |
| B. Job 요약 | Job 마다 한 행. 순서 · 스크립트명 · 유형 · 입력 · 출력 · 의존 · 처리 요약 |
| C. 선행 의존 테이블 | 아래에서 따로 다룬다. 이 절이 핵심이다 |
| D. 테이블 · 컬럼 명세 | 테이블 · 컬럼명 · 타입 · 키/파티션 여부 · 출처(원본 / 신규 생성 / 시스템) |
| E. 인터페이스 정의 정보 | DAG 설정, Airflow Connection, 파라미터, Task 의존 관계 |
| F. 에러 처리 | 예외 상황 · 조건 · 처리 · 영향 · 심각도 |
목록 시트는 No / 파이프라인명 / DAG ID / Task 수 / 데이터 흐름 / 스케줄 정도면 된다. 파이프라인명을 앞에, DAG ID 를 뒤에 두는 편이 사람이 찾기 쉽다.
Job 이 읽고 쓰는 테이블을 나열하는 것만으로는 배치 순서를 못 짠다. 같은 DAG 안의 Task 는 어차피 순차 실행이라 문제가 없고, 진짜 위험은 다른 DAG 이나 외부 수집이 만들어 주는 테이블이다. 그래서 C 절은 DAG 내부 순서를 빼고 외부 의존만 남긴다.
| 컬럼 | 의미 |
|---|---|
| 파이프라인(DAG 명) | 소속 DAG |
| 스크립트명 | 구체적인 Spark Job |
| 선행 테이블 | 이 Job 이 읽거나 JOIN 하는 테이블 |
| 선행 DAG | 그 테이블을 채워 주는 DAG (또는 수집 도구) |
| Layer | bronze / silver / gold |
| 의존성 종류 | 외부수집 · 자기참조 · 다른 DAG 참조 |
| 용도 | 메인 소스인지 JOIN 용인지 |
| 비고 | 파티션 적재 완료 조건 등 |
의존성 종류를 세 가지로 나누는 것이 요령이다.
part_ymd)이 적재됐는지가 실제 선행 조건이다.유틸 모듈 의존도 같이 적는다. 공통 함수 패키지가 Spark 환경의 특정 경로에 배포돼 있어야 하는 경우, 테이블과 똑같이 "미리 준비돼야 하는 것" 이다.
dag_id 는 별개 값이다. 둘의 명명 규칙을 맞춰 두면 장애 때 대조가 빨라진다.