Skip to main content

개념

💡 Spark Declarative Pipelines (SDP) 는 데이터 변환 파이프라인을 ”** 무엇을(What)” 만들지 선언하면, Databricks가 ” 어떻게(How)**” 실행할지를 자동으로 관리해 주는 프레임워크입니다. 이전에는 Delta Live Tables (DLT) 라는 이름으로 불렸습니다.
Apache Spark Structured Streaming 위에 구축된 추상화 레이어로, 배치와 스트리밍 데이터 파이프라인을 SQL 또는 Python으로 생성할 수 있습니다. 클라우드 스토리지 파일 수집, 메시지 버스 소비, 증분 배치/스트리밍 변환을 모두 지원합니다.

명령형 vs 선언형 비교

방식명령형 (Imperative)선언형 (Declarative)
비유”달걀을 깨고, 팬을 달구고, 기름을 두르고…""스크램블 에그를 만들어 주세요”
코드읽기→변환→쓰기→에러처리→재시도 직접 구현결과 테이블의 정의만 작성
의존성개발자가 실행 순서를 직접 관리시스템이 자동으로 파악하고 실행
에러 처리개발자가 체크포인트, 재시도 직접 구현시스템이 자동 관리 및 복구
인프라클러스터 생성, 라이브러리 설치 직접 수행서버리스로 자동 프로비저닝
# ❌ 명령형: 모든 것을 직접 관리해야 합니다
df = spark.readStream.format("delta").load("/bronze/orders")
cleaned = df.filter(col("order_id").isNotNull()).dropDuplicates(["order_id"])
query = (cleaned.writeStream
    .format("delta")
    .option("checkpointLocation", "/checkpoints/silver_orders")
    .option("mergeSchema", "true")
    .outputMode("append")
    .trigger(availableNow=True)
    .toTable("silver_orders"))
query.awaitTermination()
-- ✅ 선언형 (SDP): 결과만 정의합니다. 나머지는 시스템이 알아서 합니다.
CREATE OR REFRESH STREAMING TABLE silver_orders (
    CONSTRAINT valid_id EXPECT (order_id IS NOT NULL) ON VIOLATION DROP ROW
)
AS SELECT * FROM STREAM(bronze_orders);

SDP의 핵심 구성 요소

데이터 객체

구성 요소설명SQL 키워드
Streaming Table새 데이터만 증분 처리하는 추가 전용 테이블입니다. 각 레코드가 정확히 한 번(Exactly-Once) 처리됩니다CREATE STREAMING TABLE
Materialized View전체 데이터를 대상으로 결과를 계산하고 캐싱하는 뷰입니다. 스케줄에 따라 자동 갱신됩니다CREATE MATERIALIZED VIEW
Temporary View파이프라인 내에서만 사용할 수 있는 중간 결과입니다. 외부에서 조회할 수 없습니다CREATE TEMPORARY VIEW (SQL) / @dp.temporary_view (Python)

처리 단위

구성 요소설명
Flow소스에서 타겟으로 데이터를 이동시키는 처리 단위입니다. Append, Append-Once, CDC 세 가지 유형이 있습니다
Sink외부 시스템으로 데이터를 내보내는 메커니즘입니다
Pipeline여러 테이블, 뷰, Flow를 묶어서 실행하는 배포 단위입니다

실행 모드

모드설명적합한 사용
Triggered수동으로 실행하거나 스케줄에 따라 실행합니다. 처리 완료 후 리소스를 해제합니다배치 ETL, 정기 갱신
Continuous지속적으로 실행되며, 새 데이터가 도착하면 즉시 처리합니다실시간 스트리밍
Development Mode빠른 반복 개발을 위한 모드입니다. 실패 시 클러스터를 유지하여 디버깅이 용이합니다개발/테스트

SDP의 장점

장점설명
자동 의존성 관리테이블 간 참조를 분석하여 실행 순서를 자동으로 결정합니다. DAG(Directed Acyclic Graph)를 시각적으로 표시합니다
자동 증분 처리Streaming Table은 변경된 데이터만 처리하여 비용과 시간을 절약합니다
데이터 품질 모니터링Expectations로 데이터 품질을 자동으로 검증하고, 위반 건수를 리포팅합니다
자동 에러 복구체크포인트에서 자동으로 재시작합니다. 일시적 오류에 대한 재시도도 자동입니다
서버리스 지원클러스터 관리 없이 서버리스로 실행할 수 있습니다. 자동 스케일링을 제공합니다
스키마 자동 관리Auto Loader와 결합 시 스키마 추론, 진화, 체크포인트가 모두 자동입니다
Unity Catalog 통합생성된 테이블이 자동으로 Unity Catalog에 등록되어 거버넌스가 적용됩니다

SQL과 Python 지원

SDP는 SQL과 Python 두 가지 언어를 지원하며, 하나의 파이프라인에서 두 언어를 혼합 하여 사용할 수 있습니다 (단, 파일 단위로는 단일 언어).

SQL 방식

-- Streaming Table
CREATE OR REFRESH STREAMING TABLE bronze_orders
AS SELECT * FROM STREAM read_files('s3://bucket/orders/', format => 'json');

-- Materialized View
CREATE OR REFRESH MATERIALIZED VIEW gold_daily_revenue
AS SELECT DATE(order_date) AS day, SUM(amount) AS revenue
FROM silver_orders GROUP BY 1;

Python 방식

from pyspark import pipelines as dp

@dp.table(comment="Bronze 주문 데이터")
def bronze_orders():
    return (spark.readStream
        .format("cloudFiles")
        .option("cloudFiles.format", "json")
        .load("s3://bucket/orders/"))

@dp.materialized_view(comment="일별 매출 집계")
def gold_daily_revenue():
    return spark.sql("""
        SELECT DATE(order_date) AS day, SUM(amount) AS revenue
        FROM silver_orders GROUP BY 1
    """)

파이프라인 생성 및 실행

UI에서 생성

  1. PipelinesCreate Pipeline
  2. Pipeline 이름 입력
  3. Source Code: 노트북 또는 파일 경로 지정 (최대 100개 소스 파일)
  4. Destination: Unity Catalog의 카탈로그.스키마 지정
  5. Compute: Serverless(권장) 또는 Classic
  6. Pipeline Mode: Triggered 또는 Continuous
  7. Start 클릭

Asset Bundles (IaC)

resources:
  pipelines:
    sales_pipeline:
      name: "sales-medallion-pipeline"
      catalog: "production"
      schema: "ecommerce"
      serverless: true
      continuous: false
      libraries:
        - notebook:
            path: "/Workspace/pipelines/bronze.sql"
        - notebook:
            path: "/Workspace/pipelines/silver.sql"
        - notebook:
            path: "/Workspace/pipelines/gold.sql"
      configuration:
        "pipelines.trigger.interval": "1 hour"

시스템 제약 사항

공식 문서에 명시된 파이프라인 제약 사항을 정리합니다.
제약
워크스페이스당 최대 동시 파이프라인 업데이트1,000
파이프라인당 최대 소스 파일 수100(50개 파일/폴더 조합, 간접적으로 최대 1,000개 파일)
Materialized View의 외부 스트리밍 소스 사용❌ 불가 (같은 파이프라인 내의 Streaming Table만 소스로 사용 가능)
Hive Metastore에서 Unity Catalog로 업그레이드❌ 불가 (새 파이프라인 생성 필요)
JAR 라이브러리 사용❌ 불가 (Python 라이브러리만 지원)
pivot() 함수 사용❌ 불가 (Eager Loading 이슈)
Delta Lake 타임 트래블Streaming Table만 가능. Materialized View에서는 불가
Iceberg 읽기Streaming Table, Materialized View에서 미지원

이벤트 로그 모니터링

파이프라인의 실행 이벤트, 데이터 품질 결과, 성능 메트릭을 이벤트 로그를 통해 SQL로 조회할 수 있습니다.
-- 파이프라인 이벤트 로그 조회
SELECT
    timestamp,
    event_type,
    message,
    details
FROM event_log(TABLE(catalog.schema.my_streaming_table))
WHERE event_type IN ('flow_progress', 'dataset_quality')
ORDER BY timestamp DESC;

최신 기능

🆕 TRIGGER ON UPDATE: 소스 테이블이 변경되면 파이프라인을 자동으로 갱신하는 기능입니다.
🆕 Dry Run: 실제 데이터를 업데이트하지 않고 파이프라인의 정확성을 검증하는 기능입니다. 개발 중 빠른 피드백에 유용합니다.
🆕 Serverless Performance Mode: 서버리스 SDP의 성능을 최적화하는 모드가 베타로 출시되었습니다.
🆕 Failure Notifications: 파이프라인 실패 시 자동 알림을 보내는 기능이 추가되었습니다.

DLT에서 SDP로 — 리브랜딩 배경

Delta Live Tables(DLT)는 2021년에 출시된 Databricks의 선언적 파이프라인 프레임워크였습니다. 2024년부터 Spark Declarative Pipelines(SDP) 로 이름이 변경되었는데, 이 변화에는 전략적 의미가 있습니다.
시점명칭변화 배경
2021Delta Live Tables (DLT)Delta Lake 위의 ETL 프레임워크로 출시
2024Lakeflow Declarative PipelinesLakeflow 브랜드 통합 (Connect + Jobs + DLT)
2025Spark Declarative Pipelines (SDP)Apache Spark 프로젝트에 기여, 오픈소스화 방향
리브랜딩의 핵심 이유:
  1. 오픈소스 전략: Databricks는 SDP의 핵심 기술을 Apache Spark 프로젝트에 기여하여, 벤더 종속(lock-in) 우려를 해소하려 합니다. “Delta Live Tables”라는 이름은 Databricks 독점 느낌이 강했지만, “Spark Declarative Pipelines”는 Spark 생태계의 일부라는 인식을 줍니다.
  2. Lakeflow 브랜드 통합: 수집(Connect), 변환(SDP), 오케스트레이션(Jobs)을 하나의 Lakeflow 제품군으로 묶어 데이터 엔지니어링 전체 라이프사이클을 어필합니다.
  3. Delta Lake 의존성 완화: 향후 Iceberg 등 다른 테이블 포맷도 지원할 수 있는 확장성을 확보합니다.
⚠️ 실무 참고: 기존 DLT 파이프라인 코드는 SDP에서 100% 호환 됩니다. dlt 패키지가 pyspark.pipelines로 변경되었으나, 기존 import dlt도 계속 동작합니다. API 변경 사항은 마이그레이션 가이드를 참고하세요.

SDP vs Apache Airflow 비교

데이터 파이프라인을 구축할 때 Apache Airflow와 SDP 중 어떤 것을 선택할지 고민하는 경우가 많습니다. 두 도구는 해결하는 문제 자체가 다릅니다.
비교 항목SDPApache Airflow
역할데이터 변환(Transformation) 프레임워크워크플로 오케스트레이션(Orchestration) 도구
추상화 수준”무엇을(What)” 만들지 선언”어떻게(How)” 실행할지 명령
데이터 품질Expectations 내장별도 프레임워크 필요 (Great Expectations 등)
증분 처리자동 (체크포인트, 스키마 진화)수동 구현 (변경 감지 로직 직접 작성)
의존성 관리SQL/Python 참조에서 자동 추론DAG에서 명시적으로 정의
스케일링자동 (Enhanced Autoscaling)Executor 설정 수동 관리
비용 모델Serverless DBU (사용한 만큼)Airflow 인프라 상시 운영 비용
모니터링이벤트 로그, 시스템 테이블 내장Airflow UI + 외부 모니터링 도구
외부 시스템 연동제한적 (Databricks 생태계 중심)풍부한 Operator/Hook 생태계
실무에서의 올바른 조합:
SDP (변환) + Lakeflow Jobs (오케스트레이션) = Databricks 네이티브 스택
SDP (변환) + Airflow (오케스트레이션) = 하이브리드 스택 (기존 Airflow 투자 보존)
💡 SA 관점: 고객이 이미 Airflow를 사용 중이라면, Airflow에서 SDP 파이프라인을 트리거하는 하이브리드 패턴을 권장합니다. DatabricksSubmitRunOperator로 SDP 파이프라인 업데이트를 시작할 수 있습니다. 장기적으로는 Lakeflow Jobs로 마이그레이션하면 관리 포인트가 줄어듭니다.

Enhanced Autoscaling 동작 원리

SDP는 일반 Spark 클러스터의 오토스케일링과 다른 Enhanced Autoscaling 알고리즘을 사용합니다. 이 차이를 이해하면 비용 최적화에 큰 도움이 됩니다.

일반 Spark 오토스케일링 vs Enhanced Autoscaling

비교 항목일반 Spark AutoscalingSDP Enhanced Autoscaling
스케일 업 기준대기 중인 태스크 수파이프라인 DAG 분석 + 데이터 볼륨 예측
스케일 다운유휴 Worker 감지 (보수적)Flow 완료 시 즉시 축소 (공격적)
파이프라인 인식없음 (태스크 단위)있음 (Flow/테이블 단위)
비용 효율보통높음 (유휴 시간 최소화)

Enhanced Autoscaling의 핵심 동작

Phase처리 내용Worker 할당
Phase 1Bronze 테이블 처리데이터 양 분석 → 10대 할당
Phase 2Silver 테이블 처리의존성 충족 대기 → 5대로 축소
Phase 3Gold 테이블 처리집계 중심 → 3대로 축소
완료-모든 Worker 해제
Enhanced Autoscaling은 각 Flow의 데이터 볼륨과 처리 복잡도를 사전 분석 하여 필요한 만큼만 Worker를 할당합니다. 일반 오토스케일링처럼 “느린 반응 → 과다 할당 → 느린 축소” 패턴이 발생하지 않습니다.
💡 비용 영향: Enhanced Autoscaling은 동일 워크로드 대비 일반 Spark 클러스터보다 20~40% 낮은 DBU 소비 를 보이는 것이 일반적입니다. 특히 다수의 Flow가 순차적으로 실행되는 파이프라인에서 차이가 두드러집니다.

Triggered vs Continuous 모드 — 성능/비용 심층 분석

Triggered 모드 상세

속성설명
동작업데이트 요청 시 모든 Flow를 한 번 실행하고 종료합니다
리소스실행 중에만 컴퓨트 할당, 완료 후 해제됩니다
지연 시간스케줄 간격 + 컴퓨트 시작 시간 (서버리스: 10초, Classic: 510분)
비용 패턴실행 시에만 과금. 간헐적 워크로드에 경제적입니다
적합한 경우시간/일 단위 배치 ETL, 비용 민감한 환경, 데이터 신선도 요구가 낮은 경우

Continuous 모드 상세

속성설명
동작클러스터가 상시 실행되며, 새 데이터가 도착하면 즉시 처리합니다
리소스최소 Worker가 항상 할당되어 있습니다
지연 시간초~분 단위 (데이터 도착 후 거의 즉시 처리)
비용 패턴24/7 과금. 유휴 시간에도 최소 비용이 발생합니다
적합한 경우실시간 대시보드, IoT 이벤트 처리, 저지연 요구사항

비용 시뮬레이션 예시

시나리오: 일 4회 실행, 회당 15분 소요, 10 DBU/시간

Triggered 모드:
  4회 × 15분 × 10 DBU/시간 = 10 DBU/일 = 300 DBU/월

Continuous 모드:
  24시간 × 10 DBU/시간 = 240 DBU/일 = 7,200 DBU/월
  (→ Triggered 대비 24배 비용!)

손익 분기점: 하루 약 16회 이상 실행 시 Continuous가 유리
  (단, 실시간 처리의 비즈니스 가치를 별도 평가해야 합니다)

pipelines.trigger.interval 설정

Triggered 모드에서 이 설정은 파이프라인 내부 마이크로배치 간격 을 제어합니다. Continuous 모드에서는 새 데이터 폴링 간격을 의미합니다.
configuration:
  "pipelines.trigger.interval": "5 minutes"   # 5분마다 새 데이터 확인
⚠️ Gotcha: pipelines.trigger.interval은 Lakeflow Jobs의 스케줄과 다릅니다. Jobs 스케줄은 “파이프라인 업데이트를 언제 시작할지”를 제어하고, trigger.interval은 “실행 중인 파이프라인 내에서 얼마나 자주 새 데이터를 확인할지”를 제어합니다.

서버리스 SDP — 장점과 한계

서버리스 SDP의 장점

장점설명
즉시 시작클러스터 프로비저닝 대기 없이 ~10초 이내 시작합니다
자동 스케일링Enhanced Autoscaling이 기본 적용됩니다
제로 관리DBR 버전, 라이브러리, 패치 관리가 불필요합니다
비용 효율실행 시간에 대해서만 정확히 과금됩니다

서버리스 SDP의 한계와 주의사항

한계상세 설명대안
커스텀 라이브러리 제한PyPI 패키지만 설치 가능, C 확장이 있는 라이브러리는 제한적Classic 클러스터 + init script
Init Script 미지원클러스터 초기화 스크립트를 사용할 수 없습니다Classic 클러스터 사용
네트워크 제한외부 네트워크 접근이 제한될 수 있습니다 (VPC/VNet Peering 불가)Classic + VPC Peering
GPU 미지원GPU 인스턴스를 지정할 수 없습니다Classic 클러스터 + GPU
리전 제한일부 리전에서는 서버리스가 미지원입니다Classic 클러스터 사용
DBU 단가서버리스 DBU 단가가 Classic보다 높습니다 (1.52배)장시간 실행 시 Classic이 저렴할 수 있음
실행 시간 제한단일 업데이트의 최대 실행 시간이 48시간입니다워크로드 분할

Classic vs Serverless SDP 선택 가이드

서버리스 SDP를 선택하세요:
  ✅ 파이프라인 실행 시간이 짧은 경우 (< 2시간)
  ✅ 간헐적으로 실행되는 배치 ETL
  ✅ 특별한 라이브러리/네트워크 요구사항이 없는 경우
  ✅ 빠른 개발 반복이 필요한 경우

Classic SDP를 선택하세요:
  ✅ 외부 네트워크 접근이 필요한 경우 (DB 직접 연결 등)
  ✅ GPU가 필요한 ML 파이프라인
  ✅ 커스텀 C 라이브러리가 필요한 경우
  ✅ 매우 긴 실행 시간 (> 8시간, Spot 인스턴스 활용 시 비용 유리)

엔터프라이즈 패턴과 실무 가이드

파이프라인 분리 전략

대규모 환경에서는 파이프라인을 어떻게 분리할지가 중요한 아키텍처 결정입니다.
패턴설명장점단점
단일 파이프라인모든 테이블을 하나의 파이프라인에서 관리의존성 관리 용이장애 시 전체 영향, 대규모에서 느림
레이어별 분리Bronze/Silver/Gold를 별도 파이프라인으로 분리독립적 스케줄, 장애 격리파이프라인 간 의존성 관리 필요
도메인별 분리비즈니스 도메인(주문, 고객, 재고)별 파이프라인팀별 독립 운영, 확장 용이도메인 간 조인이 필요한 Gold 처리 복잡
하이브리드수집(Bronze)은 통합, 변환(Silver/Gold)은 도메인별균형 잡힌 접근설계 복잡도 증가
💡 SA 권장 패턴: 대부분의 엔터프라이즈 고객에게는 하이브리드 패턴 을 권장합니다. Bronze 레이어는 중앙 데이터 엔지니어링 팀이 관리하고, Silver/Gold는 각 도메인 팀이 독립적으로 운영하는 구조가 가장 효과적입니다.

Expectations 고급 활용

-- 단일 규칙: NULL 체크
CONSTRAINT valid_id EXPECT (order_id IS NOT NULL) ON VIOLATION DROP ROW

-- 비율 기반 규칙: 95% 이상 통과해야 함
CONSTRAINT valid_amount EXPECT (amount > 0) ON VIOLATION DROP ROW

-- 치명적 규칙: 위반 시 파이프라인 실패
CONSTRAINT critical_date EXPECT (order_date IS NOT NULL) ON VIOLATION FAIL UPDATE

-- 복합 규칙
CONSTRAINT valid_status EXPECT (status IN ('pending', 'completed', 'cancelled'))
    ON VIOLATION DROP ROW
Expectations 전략:
전략적용 위치ON VIOLATION
데이터 존재성Bronze → SilverDROP ROW (불량 데이터 제거)
비즈니스 규칙Silver → GoldDROP ROW (비즈니스 로직 위반 제거)
치명적 이상전체 레이어FAIL UPDATE (파이프라인 중단)
통계적 이상Gold별도 모니터링 (Lakehouse Monitor)

성능 최적화 팁

  1. 소스 파일 수 최적화: 파이프라인당 소스 파일을 50개 이하로 유지합니다. 파일이 많으면 DAG 분석 시간이 증가합니다.
  2. Streaming Table 우선 사용: 가능하면 Materialized View 대신 Streaming Table을 사용합니다. 증분 처리가 훨씬 효율적입니다.
  3. Photon 활성화: SDP는 Photon 엔진과 결합 시 SQL 변환 성능이 2~5배 향상됩니다.
  4. APPLY CHANGES 최적화: CDC 처리 시 KEYS를 적절히 지정하고, SEQUENCE BY를 사용하여 순서를 보장합니다.
  5. Partition Pruning: 날짜 기반 파티셔닝을 적용하면 증분 처리 효율이 높아집니다.

정리

핵심 개념설명
SDP선언적 데이터 파이프라인 프레임워크입니다 (구 Delta Live Tables)
Streaming Table새 데이터만 증분 처리합니다. Exactly-Once 보장됩니다
Materialized View전체 데이터를 재계산하여 캐싱합니다
Flow소스→타겟 데이터 이동 단위입니다 (Append, CDC)
Expectations데이터 품질 규칙을 선언적으로 정의합니다
Triggered/Continuous배치 또는 실시간 실행 모드를 선택합니다
Enhanced AutoscalingDAG 인식 기반 자동 스케일링으로 비용을 최적화합니다
서버리스 SDP즉시 시작, 제로 관리이지만 네트워크/라이브러리 제약이 있습니다

참고 링크