Skip to main content
이 문서는 데이터 엔지니어링 섹션의 일부입니다.

개념

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

명령형 vs 선언형 비교


SDP의 핵심 구성 요소

데이터 객체

처리 단위

실행 모드


SDP의 장점


SQL과 Python 지원

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

SQL 방식

Python 방식


파이프라인 생성 및 실행

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)


시스템 제약 사항

공식 문서에 명시된 파이프라인 제약 사항을 정리합니다.

이벤트 로그 모니터링

파이프라인의 실행 이벤트, 데이터 품질 결과, 성능 메트릭을 이벤트 로그를 통해 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) 로 이름이 변경되었는데, 이 변화에는 전략적 의미가 있습니다. 리브랜딩의 핵심 이유:
  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 중 어떤 것을 선택할지 고민하는 경우가 많습니다. 두 도구는 해결하는 문제 자체가 다릅니다. 실무에서의 올바른 조합:
💡 SA 관점: 고객이 이미 Airflow를 사용 중이라면, Airflow에서 SDP 파이프라인을 트리거하는 하이브리드 패턴을 권장합니다. DatabricksSubmitRunOperator로 SDP 파이프라인 업데이트를 시작할 수 있습니다. 장기적으로는 Lakeflow Jobs로 마이그레이션하면 관리 포인트가 줄어듭니다.

Enhanced Autoscaling 동작 원리

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

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

Enhanced Autoscaling의 핵심 동작

Enhanced Autoscaling은 각 Flow의 데이터 볼륨과 처리 복잡도를 사전 분석 하여 필요한 만큼만 Worker를 할당합니다. 일반 오토스케일링처럼 “느린 반응 → 과다 할당 → 느린 축소” 패턴이 발생하지 않습니다.
💡 비용 영향: Enhanced Autoscaling은 동일 워크로드 대비 일반 Spark 클러스터보다 20~40% 낮은 DBU 소비 를 보이는 것이 일반적입니다. 특히 다수의 Flow가 순차적으로 실행되는 파이프라인에서 차이가 두드러집니다.

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

Triggered 모드 상세

Continuous 모드 상세

비용 시뮬레이션 예시

pipelines.trigger.interval 설정

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

서버리스 SDP — 장점과 한계

서버리스 SDP의 장점

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

Classic vs Serverless SDP 선택 가이드


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

파이프라인 분리 전략

대규모 환경에서는 파이프라인을 어떻게 분리할지가 중요한 아키텍처 결정입니다.
💡 SA 권장 패턴: 대부분의 엔터프라이즈 고객에게는 하이브리드 패턴 을 권장합니다. Bronze 레이어는 중앙 데이터 엔지니어링 팀이 관리하고, Silver/Gold는 각 도메인 팀이 독립적으로 운영하는 구조가 가장 효과적입니다.

Expectations 고급 활용

Expectations 전략:

성능 최적화 팁

  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: 날짜 기반 파티셔닝을 적용하면 증분 처리 효율이 높아집니다.

정리


참고 링크