이 문서는 데이터 엔지니어링 섹션의 일부입니다.
개념
💡 Spark Declarative Pipelines (SDP) 는 데이터 변환 파이프라인을 “무엇을(What)“만들지 선언하면, Databricks가”어떻게(How)” 실행할지를 자동으로 관리해 주는 프레임워크입니다. 이전에는 Delta Live Tables (DLT) 라는 이름으로 불렸습니다.Apache Spark Structured Streaming 위에 구축된 추상화 레이어로, 배치와 스트리밍 데이터 파이프라인을 SQL 또는 Python으로 생성할 수 있습니다. 클라우드 스토리지 파일 수집, 메시지 버스 소비, 증분 배치/스트리밍 변환을 모두 지원합니다.
명령형 vs 선언형 비교
| 방식 | 명령형 (Imperative) | 선언형 (Declarative) |
|---|---|---|
| 비유 | ”달걀을 깨고, 팬을 달구고, 기름을 두르고…" | "스크램블 에그를 만들어 주세요” |
| 코드 | 읽기→변환→쓰기→에러처리→재시도 직접 구현 | 결과 테이블의 정의만 작성 |
| 의존성 | 개발자가 실행 순서를 직접 관리 | 시스템이 자동으로 파악하고 실행 |
| 에러 처리 | 개발자가 체크포인트, 재시도 직접 구현 | 시스템이 자동 관리 및 복구 |
| 인프라 | 클러스터 생성, 라이브러리 설치 직접 수행 | 서버리스로 자동 프로비저닝 |
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 방식
Python 방식
파이프라인 생성 및 실행
UI에서 생성
- Pipelines→ Create Pipeline
- Pipeline 이름 입력
- Source Code: 노트북 또는 파일 경로 지정 (최대 100개 소스 파일)
- Destination: Unity Catalog의 카탈로그.스키마 지정
- Compute: Serverless(권장) 또는 Classic
- Pipeline Mode: Triggered 또는 Continuous
- Start 클릭
Asset Bundles (IaC)
시스템 제약 사항
공식 문서에 명시된 파이프라인 제약 사항을 정리합니다.| 제약 | 값 |
|---|---|
| 워크스페이스당 최대 동시 파이프라인 업데이트 | 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로 조회할 수 있습니다.최신 기능
🆕 TRIGGER ON UPDATE: 소스 테이블이 변경되면 파이프라인을 자동으로 갱신하는 기능입니다.
🆕 Dry Run: 실제 데이터를 업데이트하지 않고 파이프라인의 정확성을 검증하는 기능입니다. 개발 중 빠른 피드백에 유용합니다.
🆕 Serverless Performance Mode: 서버리스 SDP의 성능을 최적화하는 모드가 베타로 출시되었습니다.
🆕 Failure Notifications: 파이프라인 실패 시 자동 알림을 보내는 기능이 추가되었습니다.
DLT에서 SDP로 — 리브랜딩 배경
Delta Live Tables(DLT)는 2021년에 출시된 Databricks의 선언적 파이프라인 프레임워크였습니다. 2024년부터 Spark Declarative Pipelines(SDP) 로 이름이 변경되었는데, 이 변화에는 전략적 의미가 있습니다.| 시점 | 명칭 | 변화 배경 |
|---|---|---|
| 2021 | Delta Live Tables (DLT) | Delta Lake 위의 ETL 프레임워크로 출시 |
| 2024 | Lakeflow Declarative Pipelines | Lakeflow 브랜드 통합 (Connect + Jobs + DLT) |
| 2025 | Spark Declarative Pipelines (SDP) | Apache Spark 프로젝트에 기여, 오픈소스화 방향 |
- 오픈소스 전략: Databricks는 SDP의 핵심 기술을 Apache Spark 프로젝트에 기여하여, 플랫폼 의존(lock-in) 우려를 해소하려 합니다. “Delta Live Tables”라는 이름은 Databricks 독점 느낌이 강했지만, “Spark Declarative Pipelines”는 Spark 생태계의 일부라는 인식을 줍니다.
- Lakeflow 브랜드 통합: 수집(Connect), 변환(SDP), 오케스트레이션(Jobs)을 하나의 Lakeflow 제품군으로 묶어 데이터 엔지니어링 전체 라이프사이클을 어필합니다.
- Delta Lake 의존성 완화: 향후 Iceberg 등 다른 테이블 포맷도 지원할 수 있는 확장성을 확보합니다.
⚠️ 실무 참고: 기존 DLT 파이프라인 코드는 SDP에서 100% 호환 됩니다.dlt패키지가pyspark.pipelines로 변경되었으나, 기존import dlt도 계속 동작합니다. API 변경 사항은 마이그레이션 가이드를 참고하세요.
SDP vs Apache Airflow 비교
데이터 파이프라인을 구축할 때 Apache Airflow와 SDP 중 어떤 것을 선택할지 고민하는 경우가 많습니다. 두 도구는 해결하는 문제 자체가 다릅니다.| 비교 항목 | SDP | Apache Airflow |
|---|---|---|
| 역할 | 데이터 변환(Transformation) 프레임워크 | 워크플로 오케스트레이션(Orchestration) 도구 |
| 추상화 수준 | ”무엇을(What)” 만들지 선언 | ”어떻게(How)” 실행할지 명령 |
| 데이터 품질 | Expectations 내장 | 별도 프레임워크 필요 (Great Expectations 등) |
| 증분 처리 | 자동 (체크포인트, 스키마 진화) | 수동 구현 (변경 감지 로직 직접 작성) |
| 의존성 관리 | SQL/Python 참조에서 자동 추론 | DAG에서 명시적으로 정의 |
| 스케일링 | 자동 (Enhanced Autoscaling) | Executor 설정 수동 관리 |
| 비용 모델 | Serverless DBU (사용한 만큼) | Airflow 인프라 상시 운영 비용 |
| 모니터링 | 이벤트 로그, 시스템 테이블 내장 | Airflow UI + 외부 모니터링 도구 |
| 외부 시스템 연동 | 제한적 (Databricks 생태계 중심) | 풍부한 Operator/Hook 생태계 |
💡 SA 관점: 고객이 이미 Airflow를 사용 중이라면, Airflow에서 SDP 파이프라인을 트리거하는 하이브리드 패턴을 권장합니다. DatabricksSubmitRunOperator로 SDP 파이프라인 업데이트를 시작할 수 있습니다. 장기적으로는 Lakeflow Jobs로 마이그레이션하면 관리 포인트가 줄어듭니다.
Enhanced Autoscaling 동작 원리
SDP는 일반 Spark 클러스터의 오토스케일링과 다른 Enhanced Autoscaling 알고리즘을 사용합니다. 이 차이를 이해하면 비용 최적화에 큰 도움이 됩니다.일반 Spark 오토스케일링 vs Enhanced Autoscaling
| 비교 항목 | 일반 Spark Autoscaling | SDP Enhanced Autoscaling |
|---|---|---|
| 스케일 업 기준 | 대기 중인 태스크 수 | 파이프라인 DAG 분석 + 데이터 볼륨 예측 |
| 스케일 다운 | 유휴 Worker 감지 (보수적) | Flow 완료 시 즉시 축소 (공격적) |
| 파이프라인 인식 | 없음 (태스크 단위) | 있음 (Flow/테이블 단위) |
| 비용 효율 | 보통 | 높음 (유휴 시간 최소화) |
Enhanced Autoscaling의 핵심 동작
| Phase | 처리 내용 | Worker 할당 |
|---|---|---|
| Phase 1 | Bronze 테이블 처리 | 데이터 양 분석 → 10대 할당 |
| Phase 2 | Silver 테이블 처리 | 의존성 충족 대기 → 5대로 축소 |
| Phase 3 | Gold 테이블 처리 | 집계 중심 → 3대로 축소 |
| 완료 | - | 모든 Worker 해제 |
💡 비용 영향: Enhanced Autoscaling은 동일 워크로드 대비 일반 Spark 클러스터보다 20~40% 낮은 DBU 소비 를 보이는 것이 일반적입니다. 특히 다수의 Flow가 순차적으로 실행되는 파이프라인에서 차이가 두드러집니다.
Triggered vs Continuous 모드 — 성능/비용 심층 분석
Triggered 모드 상세
| 속성 | 설명 |
|---|---|
| 동작 | 업데이트 요청 시 모든 Flow를 한 번 실행하고 종료합니다 |
| 리소스 | 실행 중에만 컴퓨트 할당, 완료 후 해제됩니다 |
| 지연 시간 | 스케줄 간격 + 컴퓨트 시작 시간 (서버리스: |
| 비용 패턴 | 실행 시에만 과금. 간헐적 워크로드에 경제적입니다 |
| 적합한 경우 | 시간/일 단위 배치 ETL, 비용 민감한 환경, 데이터 신선도 요구가 낮은 경우 |
Continuous 모드 상세
| 속성 | 설명 |
|---|---|
| 동작 | 클러스터가 상시 실행되며, 새 데이터가 도착하면 즉시 처리합니다 |
| 리소스 | 최소 Worker가 항상 할당되어 있습니다 |
| 지연 시간 | 초~분 단위 (데이터 도착 후 거의 즉시 처리) |
| 비용 패턴 | 24/7 과금. 유휴 시간에도 최소 비용이 발생합니다 |
| 적합한 경우 | 실시간 대시보드, IoT 이벤트 처리, 저지연 요구사항 |
비용 시뮬레이션 예시
pipelines.trigger.interval 설정
Triggered 모드에서 이 설정은 파이프라인 내부 마이크로배치 간격 을 제어합니다. Continuous 모드에서는 새 데이터 폴링 간격을 의미합니다.
⚠️ 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보다 높습니다 ( | 장시간 실행 시 Classic이 저렴할 수 있음 |
| 실행 시간 제한 | 단일 업데이트의 최대 실행 시간이 48시간입니다 | 워크로드 분할 |
Classic vs Serverless SDP 선택 가이드
엔터프라이즈 패턴과 실무 가이드
파이프라인 분리 전략
대규모 환경에서는 파이프라인을 어떻게 분리할지가 중요한 아키텍처 결정입니다.| 패턴 | 설명 | 장점 | 단점 |
|---|---|---|---|
| 단일 파이프라인 | 모든 테이블을 하나의 파이프라인에서 관리 | 의존성 관리 용이 | 장애 시 전체 영향, 대규모에서 느림 |
| 레이어별 분리 | Bronze/Silver/Gold를 별도 파이프라인으로 분리 | 독립적 스케줄, 장애 격리 | 파이프라인 간 의존성 관리 필요 |
| 도메인별 분리 | 비즈니스 도메인(주문, 고객, 재고)별 파이프라인 | 팀별 독립 운영, 확장 용이 | 도메인 간 조인이 필요한 Gold 처리 복잡 |
| 하이브리드 | 수집(Bronze)은 통합, 변환(Silver/Gold)은 도메인별 | 균형 잡힌 접근 | 설계 복잡도 증가 |
💡 SA 권장 패턴: 대부분의 엔터프라이즈 고객에게는 하이브리드 패턴 을 권장합니다. Bronze 레이어는 중앙 데이터 엔지니어링 팀이 관리하고, Silver/Gold는 각 도메인 팀이 독립적으로 운영하는 구조가 가장 효과적입니다.
Expectations 고급 활용
| 전략 | 적용 위치 | ON VIOLATION |
|---|---|---|
| 데이터 존재성 | Bronze → Silver | DROP ROW (불량 데이터 제거) |
| 비즈니스 규칙 | Silver → Gold | DROP ROW (비즈니스 로직 위반 제거) |
| 치명적 이상 | 전체 레이어 | FAIL UPDATE (파이프라인 중단) |
| 통계적 이상 | Gold | 별도 모니터링 (Lakehouse Monitor) |
성능 최적화 팁
- 소스 파일 수 최적화: 파이프라인당 소스 파일을 50개 이하로 유지합니다. 파일이 많으면 DAG 분석 시간이 증가합니다.
- Streaming Table 우선 사용: 가능하면 Materialized View 대신 Streaming Table을 사용합니다. 증분 처리가 훨씬 효율적입니다.
- Photon 활성화: SDP는 Photon 엔진과 결합 시 SQL 변환 성능이 2~5배 향상됩니다.
- APPLY CHANGES 최적화: CDC 처리 시
KEYS를 적절히 지정하고,SEQUENCE BY를 사용하여 순서를 보장합니다. - Partition Pruning: 날짜 기반 파티셔닝을 적용하면 증분 처리 효율이 높아집니다.
정리
| 핵심 개념 | 설명 |
|---|---|
| SDP | 선언적 데이터 파이프라인 프레임워크입니다 (구 Delta Live Tables) |
| Streaming Table | 새 데이터만 증분 처리합니다. Exactly-Once 보장됩니다 |
| Materialized View | 전체 데이터를 재계산하여 캐싱합니다 |
| Flow | 소스→타겟 데이터 이동 단위입니다 (Append, CDC) |
| Expectations | 데이터 품질 규칙을 선언적으로 정의합니다 |
| Triggered/Continuous | 배치 또는 실시간 실행 모드를 선택합니다 |
| Enhanced Autoscaling | DAG 인식 기반 자동 스케일링으로 비용을 최적화합니다 |
| 서버리스 SDP | 즉시 시작, 제로 관리이지만 네트워크/라이브러리 제약이 있습니다 |