Skip to main content

​
5. 환경별 배포 (Targets)

​
dev / staging / prod 타겟 설정

# databricks.yml
bundle:
  name: "ecommerce-data-pipeline"

variables:
  catalog:
    default: "dev_catalog"
  warehouse_id:
    default: ""
  notification_email:
    default: "dev-team@company.com"

include:
  - "resources/*.yml"

targets:
  # 개발 환경 — 기본 타겟
  dev:
    mode: development       # 리소스 이름에 [dev 사용자명] 접두사 자동 추가
    default: true
    workspace:
      host: "https://dbc-dev.cloud.databricks.com"
    variables:
      catalog: "dev_catalog"
      warehouse_id: "aaa111bbb"

  # 스테이징 환경
  staging:
    workspace:
      host: "https://dbc-staging.cloud.databricks.com"
    variables:
      catalog: "staging_catalog"
      warehouse_id: "ccc222ddd"
      notification_email: "staging-alerts@company.com"

  # 프로덕션 환경
  prod:
    mode: production        # 실수로 destroy 시 확인 요구, run_as 강제
    workspace:
      host: "https://dbc-prod.cloud.databricks.com"
    variables:
      catalog: "prod_catalog"
      warehouse_id: "eee333fff"
      notification_email: "oncall@company.com"
    run_as:
      service_principal_name: "sp-prod-data-pipeline"

​
mode: development vs mode: production

mode동작
development리소스 이름에 [dev 사용자명] 접두사가 자동으로 붙어 개인 개발 공간 격리
productionrun_as 설정 필수, bundle destroy 시 확인 프롬프트 표시
(미설정)기본 동작, 이름 변경 없음

​
권한(Permissions) 설정

# resources/jobs.yml — 리소스별 권한
resources:
  jobs:
    daily_etl:
      name: "daily-sales-etl-${bundle.target}"
      permissions:
        - level: "CAN_MANAGE"
          group_name: "data-engineers"
        - level: "CAN_VIEW"
          group_name: "data-analysts"
        - level: "IS_OWNER"
          service_principal_name: "sp-prod-data-pipeline"

​
6. 배포 워크플로

​
배포 3단계

# 1단계: 검증 — 실제 배포 없이 설정 오류 사전 확인 (Dry Run)
databricks bundle validate

# 2단계: 배포 — 리소스 생성/업데이트
databricks bundle deploy -t staging

# 3단계: 실행 — 배포된 Job/Pipeline 즉시 실행
databricks bundle run daily_etl -t staging

# 리소스 삭제 (개발 환경 정리)
databricks bundle destroy -t dev

​
validate 출력 예시

Name: ecommerce-data-pipeline
Target: staging
Workspace:
  Host: https://dbc-staging.cloud.databricks.com
  User: data-engineer@company.com
  Path: /Workspace/Users/data-engineer@company.com/.bundle/ecommerce-data-pipeline/staging

Validation OK!

​
GitHub Actions CI/CD 연동

# .github/workflows/deploy.yml
name: Deploy Data Pipeline

on:
  push:
    branches: [main]        # main 머지 시 prod 자동 배포
  pull_request:
    branches: [main]        # PR 생성 시 staging 검증

jobs:
  validate:
    name: Validate Bundle
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    steps:
      - uses: actions/checkout@v4

      - name: Install Databricks CLI
        uses: databricks/setup-cli@main

      - name: Validate (staging)
        run: databricks bundle validate -t staging
        env:
          DATABRICKS_HOST: ${{ secrets.STAGING_DATABRICKS_HOST }}
          DATABRICKS_TOKEN: ${{ secrets.STAGING_DATABRICKS_TOKEN }}

  deploy-prod:
    name: Deploy to Production
    runs-on: ubuntu-latest
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    environment: production   # GitHub Environment 보호 규칙 적용
    steps:
      - uses: actions/checkout@v4

      - name: Install Databricks CLI
        uses: databricks/setup-cli@main

      - name: Deploy to Production
        run: |
          databricks bundle validate -t prod
          databricks bundle deploy -t prod
        env:
          DATABRICKS_HOST: ${{ secrets.PROD_DATABRICKS_HOST }}
          DATABRICKS_TOKEN: ${{ secrets.PROD_DATABRICKS_TOKEN }}
인증 방법: 프로덕션 배포에는 Personal Access Token 대신 Service Principal + OAuth M2M 인증을 사용합니다. GitHub Secrets에 DATABRICKS_CLIENT_ID, DATABRICKS_CLIENT_SECRET을 저장하고 DATABRICKS_TOKEN 대신 사용합니다.

​
7. 실전 패턴

​
7-1. 모노레포(Monorepo) 구조

여러 팀/도메인의 파이프라인을 하나의 Git 저장소에서 관리하는 패턴입니다. 
data-platform/
├── domains/
│   ├── ecommerce/
│   │   ├── databricks.yml
│   │   ├── resources/
│   │   └── src/
│   ├── marketing/
│   │   ├── databricks.yml
│   │   ├── resources/
│   │   └── src/
│   └── finance/
│       ├── databricks.yml
│       └── ...
└── shared/
    └── libraries/          # 공통 유틸리티 모듈
각 도메인 디렉토리에서 독립적으로 databricks bundle deploy를 실행합니다. GitHub Actions에서는 paths 필터로 변경된 도메인만 선택적으로 배포합니다.

​
7-2. 다중 Job 오케스트레이션

한 번들 내에서 여러 Job이 서로를 참조할 수 있습니다. 
resources:
  jobs:
    ingestion_job:
      name: "ingestion-${bundle.target}"
      tasks:
        - task_key: "run_pipeline"
          pipeline_task:
            pipeline_id: "${resources.pipelines.raw_ingest.id}"

    transformation_job:
      name: "transformation-${bundle.target}"
      # 다른 Job 완료 후 트리거하는 패턴 (run_job_task)
      tasks:
        - task_key: "transform"
          run_job_task:
            job_id: "${resources.jobs.ingestion_job.id}"

​
7-3. 대시보드 코드화

# UI에서 대시보드를 JSON으로 추출
databricks dashboards export <dashboard-id> > src/dashboards/sales_overview.lvdash.json

# 번들에 포함하여 배포
databricks bundle deploy -t prod
이렇게 하면 대시보드도 Git 이력 관리가 가능하고, 환경 간 일관된 대시보드 배포가 가능합니다.

​
7-4. include로 설정 분리

큰 프로젝트에서는 리소스 파일을 분리하여 가독성을 높입니다. 
# databricks.yml
include:
  - "resources/jobs/*.yml"
  - "resources/pipelines/*.yml"
  - "resources/dashboards/*.yml"

​
8. 장단점과 트레이드오프

​
DABs vs 수동 배포(UI)

DABs수동 배포
초기 설정YAML 학습 필요, 초기 비용 있음즉시 시작 가능
반복 배포명령어 한 줄매번 UI 클릭 반복
환경 일관성완벽히 보장사람에 의존, 오류 발생 가능
감사/추적Git 이력으로 완전 추적불가
팀 협업PR 리뷰 기반 변경 관리변경 충돌 발생 가능
적합한 규모중규모 이상 팀개인/소규모 PoC

​
DABs vs Terraform

DABsTerraform
Databricks 신기능즉시 지원Provider 릴리즈 대기
클라우드 인프라불가 (Databricks 전용)AWS/Azure/GCP 모두 관리
상태 파일불필요 (플랫폼 관리).tfstate 직접 관리, 협업 시 원격 상태 설정 필요
드리프트 감지제한적강력한 terraform plan
생태계Databricks 내부광범위한 커뮤니티 모듈

​
학습 곡선

초급: databricks.yml 기본 구조 이해 (1-2일)
  → Job/Pipeline 단순 배포

중급: 멀티 환경(targets), 변수 관리, 권한 설정 (1주)
  → dev/staging/prod 분리 운영

고급: CI/CD 연동, 모노레포, 커스텀 템플릿 (2-4주)
  → 팀 전체 배포 플랫폼 구축

​
9. 베스트 프랙티스와 흔한 실수

​
베스트 프랙티스

1. 항상 validate 먼저 실행 
# 배포 전 반드시 검증
databricks bundle validate -t prod
databricks bundle deploy -t prod
2. Service Principal로 CI/CD 인증 Personal Access Token은 사용자와 연결되어 있어 퇴직 시 파이프라인이 중단됩니다. CI/CD에서는 반드시 Service Principal을 사용합니다. 3. run_as를 prod에 명시 
targets:
  prod:
    mode: production
    run_as:
      service_principal_name: "sp-prod-pipeline"  # 사용자 개인 계정이 아닌 SP 사용
4. 변수 기본값은 dev 기준으로 설정 개발자가 -t 옵션 없이 명령을 실행하면 기본 타겟(dev)이 사용됩니다. 실수로 prod에 영향을 주는 것을 방지합니다. 5. 리소스 이름에 ${bundle.target} 포함 
name: "daily-etl-${bundle.target}"   # daily-etl-dev, daily-etl-prod 구분
같은 Workspace를 여러 환경이 공유할 때 이름 충돌을 방지합니다.

​
흔한 실수

실수원인해결 방법
배포 후 리소스가 사라짐mode: development에서 다른 사용자가 deploy 실행 — 이름에 사용자명이 붙어 별도 리소스로 생성됨dev는 개인별 독립 공간임을 이해, 공유 dev는 mode 생략
prod에 dev 카탈로그 데이터가 들어감변수 기본값이 dev 카탈로그인 상태로 prod 배포-t prod 지정 시 변수 재확인, validate에서 변수 출력 확인
CI/CD 인증 실패Token 만료 또는 Service Principal 권한 부족SP에 Workspace 접근 + 번들 리소스 CAN_MANAGE 권한 부여
YAML 들여쓰기 오류탭/스페이스 혼용에디터에서 YAML 린터 활성화, bundle validate로 사전 확인
리소스 삭제 안 됨bundle destroy를 실행했지만 외부에서 수동으로 생성된 리소스는 삭제 불가DABs 외부에서 생성한 리소스는 DABs가 관리하지 않음을 이해

​
정리

핵심 개념설명
databricks.yml번들의 모든 것을 정의하는 메인 설정 파일입니다
resourcesJobs, Pipelines, Dashboards 등 Databricks 리소스를 YAML로 선언합니다
targetsdev, staging, prod 등 환경별 설정을 분리합니다
variables환경별로 다른 값(카탈로그, 엔드포인트 등)을 ${var.이름} 으로 참조합니다
bundle validate실제 배포 없이 설정 오류를 사전에 확인합니다
bundle deploy정의된 리소스를 대상 환경에 생성/업데이트합니다
CI/CDGitHub Actions 등과 연동하여 PR 기반 자동 배포 파이프라인을 구축합니다

​
참고 링크