선언형 파이프라인(구 Delta Live Tables)과 증분 처리 패턴
60 Databricks Interview Questions Senior DEs Actually Ask (2026) — 미상 (DataVidhya 블로그, 2026) Data Engineering & ETL Pipelines, Q24-Q28, Q19-Q20 (pp.8-11)
이 모듈을 다 읽으면
- 선언형 파이프라인 프레임워크(구 DLT)가 일반 Spark 코드 작성과 무엇이 다른지 설명할 수 있다
- Expectations의 세 가지 위반 처리 방식(로그/드롭/파이프라인 중단)을 구분할 수 있다
- 체크포인트가 exactly-once 처리를 어떻게 보장하는지, MERGE INTO가 SCD Type 2와 CDF에서 각각 어떻게 쓰이는지 설명할 수 있다
원문은 이 선언형 ETL 프레임워크를 'Delta Live Tables(DLT)'라는 이름으로 소개하지만, 2026년 현재 Databricks는 이를 'Lakeflow' 제품군 아래 재편했다. 개념 자체 — 체크포인트와 저수준 상태 관리를 직접 다루는 대신 원하는 '목표 상태'를 선언하고 Expectations로 데이터 품질을 검증하는 방식 — 는 그대로 유효하며, 여기에 스트리밍 체크포인트, MERGE INTO 기반 SCD Type 2, Change Data Feed 같은 실전 증분 처리 패턴이 더해진다.
선언형 파이프라인 프레임워크 — 이름이 바뀐 DLT
원문이 소개하는 Delta Live Tables(DLT)는 ETL 파이프라인을 구축하는 복잡도를 낮춰주는 관리형 프레임워크다. 체크포인트와 상태를 관리하는 저수준 Spark 코드를 직접 작성하는 대신, 테이블의 '목표(target)' 상태를 정의하는 선언적 SQL이나 Python을 작성하면, 기반 인프라·오케스트레이션·오류 처리·데이터 품질 모니터링을 프레임워크가 자동으로 처리해준다. 엔지니어는 '배관(plumbing)'이 아니라 비즈니스 로직에 집중할 수 있다.
— 정정: Databricks는 2024~2025년에 걸쳐 데이터 엔지니어링 제품군을 'Lakeflow'라는 이름으로 재편했다. 이 재편에서 기존 Delta Live Tables는 'Lakeflow Declarative Pipelines(선언형 파이프라인)'으로, 수집 커넥터는 'Lakeflow Connect'로, 오케스트레이션(Jobs/Workflows)은 'Lakeflow Jobs'로 이름이 바뀌었다. 즉 2026년 기준으로 'DLT'는 여전히 통용되는 구용어이지만, 공식 제품명은 Lakeflow Declarative Pipelines다. 핵심 개념(선언적 정의, Expectations, 관리형 오케스트레이션)은 이름이 바뀌어도 동일하다.
Expectations는 이 프레임워크의 데이터 품질 기능이다. 파이프라인 코드 안에 직접 검증 규칙을 정의할 수 있으며, 규칙 위반 시 취할 동작을 선택할 수 있다: `EXPECT`(위반을 로그로만 남김), `EXPECT ... ON VIOLATION DROP ROW`(잘못된 데이터를 폐기), `EXPECT ... ON VIOLATION FAIL UPDATE`(파이프라인 전체를 중단). 이를 통해 고품질 데이터만 Silver·Gold 레이어에 도달하도록 보장한다.
핵심 포인트
- 선언형 파이프라인 프레임워크는 체크포인트·상태 관리 저수준 코드 대신 '목표 상태' 선언에 집중하게 해준다
- 원문의 'Delta Live Tables(DLT)'는 2024~2025년 Lakeflow 재편 이후 공식 명칭이 'Lakeflow Declarative Pipelines'로 바뀌었다 — 정정
- Expectations는 위반 시 로그만 남기거나(EXPECT), 행을 폐기하거나(DROP ROW), 파이프라인 전체를 중단(FAIL UPDATE)하는 세 가지 방식을 선택할 수 있다
체크포인트, MERGE INTO, SCD Type 2, Change Data Feed
체크포인트(Checkpoint)는 스트리밍 쿼리가 현재 상태와 진행 상황을 저장하는 영구 스토리지(S3나 DBFS 등)상의 디렉터리다. 쿼리가 실패하거나 클러스터가 재시작되면 Spark는 체크포인트를 참조해 이미 처리된 데이터가 무엇인지 확인하고 정확히 중단된 지점부터 재개한다. 이것이 Structured Streaming에서 'exactly-once' 처리 시맨틱을 보장하는 메커니즘이다.
`MERGE INTO` 명령은 소스 테이블(또는 DataFrame)을 타깃 Delta 테이블과 조인해, 매치 여부에 따라 다른 동작(UPDATE/INSERT/DELETE)을 수행하는 원자적 연산이다. 전통적으로 매치 대상 식별, 삭제 수행, 삽입 수행을 여러 단계로 나눠 처리하던 것을 하나의 원자적 연산으로 대체한다. SCD(Slowly Changing Dimension) Type 2는 모든 변경마다 새 행을 만들고 이전 행을 유효/만료 날짜나 `is_current` 플래그로 '닫는' 방식으로 이력을 추적하는 패턴인데, Databricks에서는 보통 `MERGE INTO`로 구현한다 — 들어오는 데이터를 타깃 테이블과 조인해 매치가 있고 속성이 바뀌었으면 기존 레코드를 '만료'로 표시하고 새 레코드를 '현재'로 삽입한다.
Change Data Feed(CDF)는 Delta 테이블이 모든 커밋에 대해 행 단위 변경 사항을 기록·출력할 수 있게 하는 기능이다. 최종 상태만 보여주는 게 아니라 어떤 행이 삽입·삭제·업데이트되었는지(업데이트의 경우 변경 전/후 값까지) 구체적으로 식별한다. 다운스트림 프로세스가 전체 데이터셋을 재처리하는 대신 변경분만 소비할 수 있게 해줘 증분 ETL 파이프라인 구축에 유용하다.
핵심 포인트
- 체크포인트는 스트리밍 쿼리의 진행 상황을 저장해 장애·재시작 후에도 정확히 이어서 처리(exactly-once)할 수 있게 한다
- MERGE INTO는 매치 식별·삭제·삽입을 하나의 원자적 연산으로 묶어 업서트를 수행하며, SCD Type 2 구현의 표준적인 방법이다
- Change Data Feed는 최종 상태가 아니라 행 단위 변경(삽입/삭제/업데이트 전후값)을 노출해 증분 ETL을 가능하게 한다