Cloudera Data Engineering(CDE) 은 Spark 작업과 Airflow 파이프라인을 컨테이너 위에서 돌리는 서비스다. 다루는 대상이 세 층으로 나뉘며, 이 구분을 잡아 두지 않으면 배포 구조와 장애 대응이 어긋난다.
| 층 | 무엇인가 | 누가 다루나 |
|---|---|---|
| 가상 클러스터 | 격리된 컴퓨트 단위. CPU · 메모리 상한을 갖는다 | 플랫폼 관리자 |
| Job | 실행 정의. Spark 작업이거나 Airflow DAG 이다 | 데이터 엔지니어 |
| Resource | 파일 묶음. 코드 · DAG · 설정 · 파이썬 환경 | 데이터 엔지니어 |
가상 클러스터는 테넌트나 워크로드 단위로 만든다. 이름과 CPU · 메모리 상한만 정하면 생성되며, 수요에 따라 오토스케일한다. 여러 가상 클러스터가 같은 기반 인프라를 나눠 쓰되 서로 격리되므로, 기존의 고정 크기 클러스터를 나눠 쓰던 방식보다 활용률이 높다.
새 업무나 새 부서를 들일 때는 가상 클러스터를 새로 만드는 것이 기본 단위다. 상한값이 곧 비용 통제 수단이 된다.
Job 은 실행 정의다. Spark 타입이면 애플리케이션 파일과 실행 인자·튜닝 값(익스큐터 수, 드라이버 메모리, 코어)을 갖고, Airflow 타입이면 DAG 파일을 가리킨다. Python · Scala · Java 를 지원한다.
스케줄은 Airflow 가 뒤를 받친다. 화면에서 주기나 cron 식을 지정하면 그에 해당하는 DAG 이 만들어진다. 여러 Spark 작업과 Hive 작업을 이어 붙인 파이프라인도 DAG 코드로 정의할 수 있다.
실행 이력은 Job Runs 화면에 모인다. 익스큐터별 로그가 한곳에 모이고, 단계별 CPU · 메모리 사용량이 함께 표시되므로 자원을 과다 할당한 구간을 찾아 줄이는 데 쓴다.
Resource 는 Job 이 마운트해 쓰는 파일 묶음이다. 유형은 파일 묶음(files) 과 파이썬 환경(python-env) 이 있다.
핵심은 Resource 하나에 여러 Job 을 붙이는 것이 표준이라는 점이다. DAG 마다 Resource 를 1:1 로 만들면 업로드 비용이 커지고 공통 모듈을 공유하기 어렵다.
resource: airflow-dags
├── dag-sales.py
├── dag-etl.py
└── common/
이 구조에서 운영은 다음 세 가지로 정리된다.
| 하는 일 | 명령 |
|---|---|
| 코드 변경 | cde resource upload --name airflow-dags --local-path . |
| DAG 추가 | cde job create --name dag-sales --type airflow --dag-file dag-sales.py --mount-1-resource airflow-dags |
| DAG 제거 | cde job delete --name dag-sales |
cde resource delete 는 정상 운영에서 쓰지 않는다. 여러 Job 이 공유하는 자산을 지우는 것이므로 다른 Job 까지 깨진다. 이 명령이 필요해지는 경우는 상태가 꼬였을 때의 복구뿐이다.
Job 이름과 DAG 의 dag_id 는 별개 값이다. 둘을 같은 규칙으로 맞춰 두면 장애가 났을 때 대조가 쉬워진다. 환경과 버전을 이름에 넣어 두면 재배포 과정에서 이름이 겹치는 상황을 피할 수 있다.
dag-<pipeline>-<env>-<version>
CDE 는 Airflow 를 감싸 Job 중심으로 추상화한다. 그래서 Airflow UI 에서 DAG 을 지우거나 코드를 고칠 수 없고, CDE UI 와 cde job list 도 Job 만 보여 준다. 두 저장소의 상태가 어긋나면 어느 화면에서도 보이지 않는 DAG 이 남을 수 있다 — CDE Airflow Job 을 만들 수도 지울 수도 없는 증상 을 참고한다.
cde 명령 사용 전 인증 설정.python-env Resource 와 런타임 이미지.