Orchestration

데이터 엔지니어링 파이프라인에서 dbt와 Airflow는 종종 함께 사용된다. 여기서 자주 마주하는 설계 결정이 있다: dbt를 Airflow와 어떻게 함께 실행할 것인가? dbt를 별도의 컨테이너에서 실행하고 API나 CLI 호출로 오케스트레이션할 것인가? 아니면 dbt를 Airflow의 Docker 컨테이너 안에서 직접 실행할 것인가? 둘 다 실험해본 결과, dbt를 Airflow 컨테이너 안에서 실행하는 방식을 선호한다. 이유는 다음과 같다. ✅ 하나의 컨테이너 = 하나의 환경 Airflow DAG가 동일한 컨테이너 안에서 dbt 명령어를 직접 실행한다. 이를 통해 다음이 보장된다: 동일한 Python 버전 동일한 dbt 버전 동일한 의존성 버전 (dbt 패키지, 어댑터) 컨테이너 간 네트워킹 이슈 없음 별도의 컨테이너로 분리할 경우 다음을 관리해야 한다: ...

Airflow 조금 만지다 보면, 대부분 이렇게 서비스가 나뉘어 돌아가는 걸 보게 됩니다. airflow-init airflow-scheduler airflow-webserver “이걸 굳이 왜 이렇게 쪼개?” 라는 생각이 들 수 있는데요. 이게 바로 실전 운영 방식입니다. 1️⃣ airflow-init — 준비 담당 다른 이름으로 airflow-db-migrate 나 airflow-bootstrap 이라고 부르기도 합니다. 딱 한 번만 실행되는 프로세스입니다. 하는 일: airflow db upgrade → DB 스키마 최신화 (DB 구조 최신으로 맞춰줌) 최초 admin 유저 생성 중요 포인트: 이건 계속 도는 서비스가 아닙니다. 할 일 다 하면 바로 종료 (exit code 0). ...