Skip to main content

왜 파이프라인 설정이 중요한가?

SDP(Spark Declarative Pipelines, 구 Delta Live Tables)는 파이프라인의 실행 모드, 클러스터 구성, 타겟 카탈로그, 채널 등을 설정을 통해 제어합니다. 올바른 설정은 개발 생산성, 프로덕션 안정성, 비용 효율성에 직접적인 영향을 미칩니다.

Development vs Production 모드

SDP는 두 가지 실행 모드를 제공하며, 각 모드는 파이프라인의 동작 방식이 크게 다릅니다.
비교 항목Development 모드Production 모드
데이터 재처리전체 데이터가 아닌 2개 파일만 샘플 처리합니다전체 데이터 를 처리합니다
클러스터 재사용실행 사이에 클러스터를 유지합니다 (빠른 반복)매 실행마다 클러스터를 새로 생성합니다
오류 처리오류 발생 시 파이프라인을 즉시 중단합니다재시도 정책에 따라 자동 복구를 시도합니다
비용클러스터 유지 비용 발생실행 시에만 비용 발생
적합한 용도개발, 디버깅, 테스트프로덕션 운영
모드특징설명
Development 모드샘플 데이터, 클러스터 유지, 빠른 피드백개발 및 테스트에 적합합니다
Production 모드전체 데이터, 클러스터 자동 관리, 재시도 정책프로덕션 운영에 적합합니다
Development 모드에서 검증을 완료한 후 Production 모드로 전환합니다.
🔥 현업 사례: Development 모드와 Production 모드를 혼동해서 데이터를 날린 경험 한 고객사의 데이터 엔지니어가 프로덕션 파이프라인을 수정한 후, Development 모드인 줄 모르고 “Start” 버튼 을 눌렀습니다. Development 모드에서는 기존 테이블을 삭제하고 샘플 데이터만으로 재생성하기 때문에, 프로덕션 Gold 테이블 3개의 데이터가 샘플 2개 파일 분량으로 대체 되었습니다. 마침 BI 대시보드가 이 테이블을 참조하고 있었고, 경영진이 “매출이 갑자기 99% 줄었다”고 보고받는 사태가 벌어졌습니다. 복구 과정: Delta의 Time Travel 기능(RESTORE TABLE ... TO VERSION AS OF)으로 데이터를 복구했지만, 원인 파악과 복구에 약 2시간이 소요되었습니다. 재발 방지책:
  1. 프로덕션 파이프라인은 반드시 "development": false로 고정(UI에서 변경 불가하도록)
  2. 개발용과 프로덕션용 파이프라인을 물리적으로 분리(같은 파이프라인에서 모드 전환 금지)
  3. 프로덕션 파이프라인은 Asset Bundles로만 배포(UI 직접 수정 금지)

안전한 개발-프로덕션 분리 패턴

현업에서 권장하는 패턴은 같은 코드, 다른 파이프라인 입니다.
# Asset Bundles로 환경별 파이프라인 자동 분리
# bundle.yml
targets:
  dev:
    default: true
    resources:
      pipelines:
        etl:
          name: "etl-pipeline-DEV"
          catalog: "dev_catalog"
          target: "ecommerce"
          development: true     # ← 개발 모드

  prod:
    resources:
      pipelines:
        etl:
          name: "etl-pipeline-PROD"
          catalog: "production"
          target: "ecommerce"
          development: false    # ← 프로덕션 모드
이렇게 하면 databricks bundle deploy -t devdatabricks bundle deploy -t prod로 완전히 분리된 파이프라인이 생성되어, 모드 혼동 사고를 원천 차단할 수 있습니다.

클러스터 설정

서버리스 컴퓨트

서버리스를 선택하면 클러스터 구성을 직접 관리할 필요가 없습니다. Databricks가 자동으로 인프라를 프로비저닝합니다.
{
    "name": "my-serverless-pipeline",
    "serverless": true,
    "catalog": "catalog",
    "target": "schema"
}
장점고려사항
클러스터 시작 대기 시간 최소화커스텀 라이브러리 설치 제한
인프라 관리 불필요특정 인스턴스 타입 지정 불가
자동 스케일링일부 워크로드에서 비용이 다를 수 있음

Job Cluster (클래식)

세밀한 클러스터 제어가 필요한 경우 직접 클러스터를 구성합니다.
{
    "name": "my-classic-pipeline",
    "clusters": [
        {
            "label": "default",
            "num_workers": 4,
            "node_type_id": "i3.xlarge",
            "spark_conf": {
                "spark.databricks.delta.optimizeWrite.enabled": "true"
            },
            "aws_attributes": {
                "availability": "SPOT_WITH_FALLBACK",
                "first_on_demand": 1
            }
        },
        {
            "label": "maintenance",
            "num_workers": 2,
            "node_type_id": "m5.xlarge"
        }
    ]
}
클러스터 레이블용도
default파이프라인의 기본 처리에 사용됩니다
maintenanceOPTIMIZE, VACUUM 같은 유지보수 작업에 사용됩니다

Auto Scaling 설정

{
    "clusters": [
        {
            "label": "default",
            "autoscale": {
                "min_workers": 2,
                "max_workers": 10,
                "mode": "ENHANCED"
            }
        }
    ]
}

Enhanced Autoscaling의 실전 효과

SDP의 Enhanced Autoscaling 은 일반 클러스터의 Autoscaling과 다릅니다. 파이프라인의 데이터 흐름 단계를 이해하고, 각 단계에서 필요한 만큼만 노드를 할당 합니다.
비교 항목일반 AutoscalingEnhanced Autoscaling (SDP)
스케일 기준CPU/메모리 사용률데이터 흐름 단계별 워크로드
스케일 속도느림 (메트릭 수집 후 판단)빠름 (파이프라인 그래프 분석)
과잉 프로비저닝빈번함최소화
실전 비용 절감10~20%30~50%
💡 현업 팁: Enhanced Autoscaling의 효과가 가장 극적인 경우는 ”** Bronze에서 대량 수집 → Silver에서 소량 변환 → Gold에서 집계**” 패턴입니다. Bronze 단계에서 10개 노드가 필요해도, Gold 단계에서는 2개면 충분합니다. Enhanced Autoscaling은 이 차이를 자동으로 감지하여 노드를 줄입니다.
[Bronze 수집]     ████████████████████  10 nodes
[Silver 변환]     ████████████          6 nodes
[Gold 집계]       ████                  2 nodes

→ 일반 Autoscaling: 전 구간 10 nodes 유지 → 비용 낭비
→ Enhanced: 단계별 최적화 → 약 40% 절감

Channel (채널) 설정

채널은 SDP 런타임의 버전 을 결정합니다. 신기능 테스트와 프로덕션 안정성 사이의 균형을 맞출 수 있습니다.
채널설명권장 용도
Current최신 안정 버전의 SDP 런타임입니다프로덕션 환경
Preview차기 버전의 기능을 미리 사용할 수 있습니다개발, 신기능 테스트
{
    "name": "my-pipeline",
    "channel": "CURRENT"
}

타겟 카탈로그/스키마 설정

Unity Catalog 통합

SDP 파이프라인의 결과 테이블을 Unity Catalog에 저장합니다.
{
    "name": "sales-pipeline",
    "catalog": "production",
    "target": "sales_data"
}
설정설명
catalog결과 테이블이 저장될 Unity Catalog 카탈로그입니다
target결과 테이블이 저장될 스키마(데이터베이스)입니다
위 설정으로 파이프라인 내에서 CREATE STREAMING TABLE orders를 실행하면 production.sales_data.orders로 생성됩니다.
💡 카탈로그/스키마를 파이프라인 레벨에서 설정하면, 개별 테이블 정의에서 3단계 네임스페이스를 매번 작성할 필요가 없습니다.

파이프라인 설정 전체 예제

JSON 설정

{
    "name": "ecommerce-etl-pipeline",
    "catalog": "production",
    "target": "ecommerce",
    "serverless": true,
    "channel": "CURRENT",
    "development": false,
    "continuous": false,
    "photon": true,
    "edition": "ADVANCED",
    "configuration": {
        "source_path": "s3://raw-data/ecommerce/",
        "quality_threshold": "0.95",
        "environment": "production"
    },
    "libraries": [
        {
            "notebook": {
                "path": "/Workspace/pipelines/ecommerce/bronze"
            }
        },
        {
            "notebook": {
                "path": "/Workspace/pipelines/ecommerce/silver"
            }
        },
        {
            "notebook": {
                "path": "/Workspace/pipelines/ecommerce/gold"
            }
        }
    ],
    "notifications": [
        {
            "email_recipients": ["data-team@company.com"],
            "alerts": {
                "on_update_failure": true,
                "on_update_success": false,
                "on_flow_failure": true
            }
        }
    ]
}

YAML 설정 (Asset Bundles)

resources:
  pipelines:
    ecommerce_etl:
      name: "ecommerce-etl-pipeline"
      catalog: "${var.catalog}"
      target: "${var.schema}"
      serverless: true
      channel: "CURRENT"
      development: ${var.is_dev}
      photon: true
      edition: "ADVANCED"

      configuration:
        source_path: "${var.source_path}"
        quality_threshold: "0.95"
        environment: "${bundle.target}"

      libraries:
        - notebook:
            path: "./pipelines/bronze.sql"
        - notebook:
            path: "./pipelines/silver.py"
        - notebook:
            path: "./pipelines/gold.sql"

      notifications:
        - email_recipients:
            - "data-team@company.com"
          alerts:
            on_update_failure: true
            on_flow_failure: true

주요 설정 옵션 총정리

설정설명기본값
name파이프라인 이름입니다(필수)
catalogUnity Catalog 카탈로그입니다
target타겟 스키마(데이터베이스)입니다
serverless서버리스 컴퓨트 사용 여부입니다false
channel런타임 채널입니다 (CURRENT/PREVIEW)CURRENT
development개발 모드 활성화 여부입니다true
continuous연속 실행 모드 여부입니다false
photonPhoton 엔진 활성화 여부입니다false
edition에디션입니다 (CORE/PRO/ADVANCED)ADVANCED
configuration파이프라인에서 사용할 키-값 매개변수입니다{}
libraries파이프라인에 포함할 노트북/파일 목록입니다(필수)

configuration 매개변수 활용

configuration에 정의한 값은 파이프라인 코드에서 spark.conf.get()으로 접근할 수 있습니다.
# Python에서 파이프라인 설정값 읽기
source_path = spark.conf.get("source_path")
quality_threshold = float(spark.conf.get("quality_threshold"))
-- SQL에서 파이프라인 설정값 읽기
SELECT * FROM STREAM read_files(
    '${source_path}',
    format => 'json'
);

Continuous 모드 vs Triggered 모드

모드동작적합한 시나리오
Triggered(기본값)한 번 실행하고 종료합니다. 새 데이터가 있으면 처리하고 멈춥니다배치 ETL, 스케줄 실행
Continuous항상 실행 상태를 유지하며, 새 데이터가 도착하면 즉시 처리합니다실시간 스트리밍, 저지연 요구
⚠️ Continuous 모드는 항상 클러스터가 실행 중이므로 비용이 지속적으로 발생합니다. 실시간 요구사항이 없다면 Triggered 모드 + 스케줄링을 권장합니다.

실전 비용 비교: Continuous vs Triggered

현업에서 가장 많이 묻는 질문이 “Continuous 모드 비용이 얼마나 되나요?”입니다.
모드24시간 기준 비용 (4 Worker, i3.xlarge)월 비용 예상데이터 지연
Continuous24시간 × XDBU= X DBU = ~50/일~$1,500/월수초~수분
Triggered (1시간 간격)24회 × 10분 = 4시간 × XDBU= X DBU = ~8/일~$250/월최대 1시간
Triggered (15분 간격)96회 × 10분 = 16시간 × XDBU= X DBU = ~33/일~$1,000/월최대 15분
💡 현업 팁: 대부분의 내부 분석/BI 용도에서는 15분~1시간 지연이 허용 됩니다. “실시간이 필요하다”고 요청하는 경우에도, 실제로 확인해 보면 “1시간 이내면 충분”인 경우가 80% 이상입니다. Continuous 모드는 정말 분 단위 지연이 비즈니스에 직접적인 영향을 미치는 경우(사기 탐지, 실시간 추천 등)에만 사용하세요.

서버리스 SDP의 비용 예측 방법

서버리스 SDP는 인프라를 자동 관리하지만, 비용 예측이 어렵다는 현업의 피드백이 있습니다.

비용 구성 요소

구성 요소과금 기준비중(일반적)
처리 DBU데이터 처리량(바이트)에 비례70~80%
대기 DBUContinuous 모드 시 유휴 대기10~20%
유지보수 DBUOPTIMIZE, VACUUM 자동 실행5~10%

비용 예측을 위한 실전 공식

월간 서버리스 SDP 비용 ≈
    (일 데이터 처리량 GB × 처리 단가 × 30일)
  + (유지보수 비중 10~15%)
  + (Continuous 시 대기 비용)

예시: 일 100GB 처리, Triggered 모드
  ≈ (100GB × $0.07/GB × 30일) + 15%
  ≈ $210 + $31.5
  ≈ 약 $242/월
🔥 현업에서는: 서버리스 SDP 비용을 정확히 예측하기 어려우므로, 첫 달은 클래식(Job Cluster)과 서버리스를 병렬로 돌려서 비용을 비교 하는 것을 권장합니다. 한 고객사에서는 서버리스 전환 후 비용이 20% 절감된 반면, 다른 고객사에서는 10% 증가한 사례도 있었습니다. 워크로드 특성에 따라 다르므로 반드시 직접 비교 테스트를 하세요.

서버리스 비용 모니터링

-- 서버리스 SDP의 일별 DBU 사용량 추적
SELECT
    DATE(usage_date) AS date,
    sku_name,
    SUM(usage_quantity) AS total_dbus,
    SUM(usage_quantity * list_price) AS estimated_cost_usd
FROM system.billing.usage
WHERE sku_name LIKE '%SERVERLESS%DLT%'
    AND usage_date > CURRENT_DATE() - INTERVAL 30 DAYS
GROUP BY 1, 2
ORDER BY date DESC;

정리

핵심 설정권장값
개발 단계Development 모드, Preview 채널
프로덕션Production 모드, Current 채널
비용 최적화서버리스 또는 Spot 인스턴스
성능 최적화Photon 활성화, Auto Scaling
환경 분리Asset Bundles 변수로 카탈로그/스키마 분리

참고 링크