Databricks CDC와 CDF 완전 정리

데이터 환경이 복잡해지고 데이터가 폭발적으로 증가하면서, 전체 데이터를 매번 다시 처리하는 방식은 이제 효율성이 크게 떨어집니다. 이런 한계를 해결하기 위해 등장한 기술이 바로 CDC(Change Data Capture)와 CDF(Change Data Feed)입니다. Databricks는 Delta Lake 기반으로 이 두 기능을 매우 쉽게 활용할 수 있도록 지원하고 있어, 대규모 데이터 환경에서도 빠르고 효율적인 파이프라인을 구축할 수 있습니다.

 

이번 포스팅에서는 Databricks의 CDC와 CDF가 무엇인지, 그리고 실제 업무에서 어떻게 활용되는지 쉽게 풀어보겠습니다.

 

1. CDC(Change Data Capture)란?

CDC는 말 그대로 데이터의 변화(Change)를 포착(Capture)하는 기술입니다. 즉, 전체 테이블을 다시 처리하는 것이 아니라 변경된 부분만 골라내는 방식입니다. CDC가 잡아내는 데이터는 다음과 같습니다.

 

• 새로 들어온 데이터(Insert)
• 기존 값이 바뀐 데이터(Update)
• 삭제된 데이터(Delete)

 

CDC를 사용하면 다음과 같은 장점이 있습니다.

• 전체 데이터를 다시 읽을 필요가 없어 처리 속도 향상
• 변경된 영역만 처리하여 클러스터 비용 절감
• Kafka, MySQL, Postgres, SAP 등 다양한 외부 시스템의 변경 사항을 실시간으로 수집 가능

 

Databricks에서는 Auto Loader나 Structured Streaming과 함께 CDC를 연동하는 방식이 많이 사용됩니다. 예를 들어, 외부 DB의 변경 사항을 Kafka → Spark Streaming → Delta Lake로 실시간으로 흘려보낼 수 있습니다.

 

 

2. CDF(Change Data Feed)란?

CDC가 외부에서 발생한 데이터 변경을 감지하는 기술이라면, CDF는 Delta Lake 테이블 내부에서 변경된 데이터를 쉽게 조회할 수 있도록 제공하는 기능입니다. Delta Lake는 테이블이 업데이트될 때마다 내부적으로 변경 이력을 기록합니다. CDF를 사용하면 이 변경 이력을 아래와 같은 형태로 바로 조회할 수 있습니다.

 

• insert
• update_preimage
• update_postimage
• delete

 

이 덕분에 Delta Lake는 변경된 데이터만 효율적으로 읽을 수 있게 되며, Incremental ETL 작업이 매우 단순해집니다.

SELECT * 
FROM table_changes('sales', 5)

 

이 쿼리는 sales 테이블의 5번 버전 이후 변경된 모든 데이터를 쉽게 조회할 수 있습니다.

 

 

3. CDC vs CDF 차이점 정리

구분	CDC	CDF
개념	외부 데이터의 변경을 감지	Delta Lake 내부 변경 이력을 조회
목적	외부 변경 내용을 파이프라인으로 전달	변경된 데이터만 읽어 downstream 처리
활용	DB → Kafka → Delta 실시간 적재	Incremental ETL, SCD2, Dashboard 업데이트
위치	외부 시스템 중심	Delta Lake 내부 기능

CDC가 외부에서 변화를 가져오는 기술이라면, CDF는 Delta Lake가 스스로 기록한 변경 내용을 개발자가 꺼내 쓸 수 있게 만든 기능입니다.

 

 

4. Databricks에서 CDC·CDF가 강력한 이유

Delta Lake 기반의 일관된 구조

변경 감지부터 저장, 변경 이력 조회까지 모두 Delta Lake 안에서 일관되게 처리할 수 있어 구조가 단순합니다.

Incremental ETL이 매우 간단

CDF를 기반으로 변경된 데이터만 읽어들이기 때문에 전체 데이터를 반복적으로 스캔할 필요가 없습니다.

비용 절감

처리해야 할 데이터 양이 줄어들기 때문에 작업 비용이 크게 떨어집니다.

SCD Type 2 구현이 쉬움

update_preimage와 update_postimage 값 덕분에 과거 이력 테이블 관리가 수월합니다.

DLT(Delta Live Tables)와 자연스러운 통합

CDC ingestion → Delta → CDF 기반 변환까지 파이프라인을 안정적으로 자동화할 수 있습니다.

 

5. 실제 활용 시나리오

1) 고객 데이터 변경 시 실시간 반영

CRM DB의 고객 정보가 변경되면 CDC를 통해 Kafka로 전달하고, Delta Lake에 적재한 뒤, CDF로 변경된 데이터만 추출하여 Feature Store에 반영해 추천 시스템을 실시간으로 업데이트할 수 있습니다.

2) 결제·거래 데이터의 Incremental ETL

매일 방대한 결제 데이터 전체를 다시 읽을 필요 없이 변경된 거래만 추출하여 성능과 비용을 크게 줄일 수 있습니다.

3) 실시간 대시보드 업데이트

CDC 기반 스트리밍으로 데이터를 지속적으로 받고 CDF로 변경된 부분만 반영해 분석 테이블을 업데이트하는 구조가 매우 효율적입니다.

 

 

CDF(Change Data Feed) 사용 시 주의해야 할 점

1. VACUUM은 CDF 데이터 보존 기간을 넘어가면 변경 이력을 삭제한다

Delta Lake의 VACUUM은 오래된 파일을 물리적으로 삭제하는데, CDF의 변경 이력 역시 결국은 테이블의 데이터 파일로 구성됩니다.

즉:

• CDF는 Delta 테이블에 남아 있는 파일들을 기반으로 변경 이력을 제공합니다
• VACUUM이 오래된 파일을 삭제하면 해당 구간의 CDF 데이터는 더 이상 조회할 수 없음

핵심 포인트

CDF는 Delta의 retention 기간 안에서만 보장됩니다. 그리고 VACUUM이 retention보다 더 오래된 파일을 삭제하면 그 이전의 변화 이력은 복구 불가능합니다.

 

2. CDF 보존 기간 설정이 별도로 존재한다

CDF 보존 기간은 다음 속성으로 지정합니다.

delta.enableChangeDataFeed = true
delta.minReaderVersion = 2
delta.minWriterVersion = 5
delta.changeDataFeedRetentionDuration = 'interval 30 days'

 

기본값은 아래와 같습니다.

• change data feed retention duration = 30일

 

즉, 아무 설정하지 않으면 CDF가 보존되는 기간은 기본 30일이며 VACUUM이 이 기간 이후 파일을 삭제하면 CDF도 사라집니다.

 

3. VACUUM retention이 CDF retention보다 짧으면 CDF는 깨진다

가장 위험한 구성은 다음과 같습니다.

• CDF retention: 30일
• VACUUM retention: 7일

 

이렇게 되면 VACUUM이 7일 이전의 파일을 삭제하는 순간 CDF는 "30일 동안" 사용할 수 없게 되고, 사실상 7일까지만 조회할 수 있습니다.

정리

CDF를 정상적으로 활용하려면

• VACUUM retention ≥ CDF retention duration

을 반드시 유지해야 합니다.

 

즉:

vacuumRetention >= changeDataFeedRetention

이 조합이 깨지면 CDF는 정상적으로 작동하지 않습니다.

 

4. CDF는 전체 변경 이력을 영구 저장하는 기능이 아니다

많은 사람들이 실수하는 부분인데, CDF는 CDC(Change Data Capture) 로그처럼 “영구적인 변경 기록 저장소”가 아닙니다.

 

CDF = Delta가 일시적으로 변경 이력을 제공하는 기능 

 

기본적으로는 ETL, Downstream 업데이트에 활용하기 위한 기능이며 장기 보관용으로 설계된 기능이 아닙니다.

 

5. CDF를 장기 보관하고 싶으면 별도 테이블로 저장해야 한다

CDF에 있는 변경 이력을 장기적으로 관리하고 싶다면

1. CDF에서 변경 내용 추출
2. 별도의 bronze/changelog 테이블에 저장

이런 구조로 운영해야 합니다.

 

6. Optimize, Z-Order 등은 CDF와 충돌하지 않는다

Optimize나 Z-Order는 파일을 합치거나 정렬하는 작업이며, 변경 이력 자체를 삭제하지 않기 때문에 CDF에는 영향을 주지 않습니다. 하지만 다음은 영향을 줄 수 있습니다.

• Overwrite

• ReplaceWhere

• Repartition 후 overwrite

 

이런 작업들은 기존 파일을 삭제하거나 교체하므로 CDF 이력을 잃을 수 있습니다.

 

 

CDC는 CDF처럼 VACUUM·Retention 문제를 겪지 않는다

CDC는 Delta Lake 내부 기능이 아니라, 외부 소스(예: MySQL, Postgres, Oracle, Kafka, Debezium 등)에서 변경 사항을 추출하는 방식입니다. 즉,

• CDC는 데이터베이스의 transaction log
• 또는 CDC 플랫폼(Kafka Connect, Debezium, Amazon DMS 등)
• 또는 소스 시스템의 로그 기반 이벤트

 

에서 변화를 읽어오기 때문에, Delta Lake 내부 파일이 삭제되든, VACUUM이 돌든, retention 기간이 얼마든 CDC 자체에는 아무 영향이 없습니다. 정리하면:

CDF는 Delta 테이블 내부 이력 의존 → VACUUM 영향 O
CDC는 외부 소스 시스템의 로그 의존 → VACU움 영향 X

따라서 CDC는 변경 이력을 잃어버리는 구조적 문제가 없다고 보면 됩니다.

 

하지만 CDC에도 주의해야 할 점들이 존재한다

CDC는 CDF와 성격이 달라서 문제 포인트도 다릅니다. 아래는 CDC 사용 시 반드시 고려해야 하는 주의사항입니다.

 

1. CDC 소스의 retention(로그 보존 기간)을 반드시 확인해야 한다

CDC는 transaction log(redo log, WAL 등)에 의존합니다. 만약 소스 DB의 로그 보존 기간이 짧게 설정되어 있다면?

 

예시
• MySQL binlog 보존 기간: 7일
• Debezium CDC는 10일 후부터 가져가려고 시도

→ 로그가 이미 삭제되어 있어 CDC ingestion 실패
→ snapshot(전체 재적재) 필요

이 문제가 가장 흔한 CDC 장애 원인입니다.

 

2. CDC로 전달되는 이벤트 순서를 보장하지 않는 경우가 있다

시스템에 따라 CDC 이벤트가 out-of-order로 전달될 수 있습니다.

 

예시
• Kafka 파티션 구성에 따라 순서가 바뀜
• 병렬 ingest 시 update → delete → insert 순서가 꼬일 수 있음

→ Delta 테이블에서 최종 데이터 보정이 필요할 수 있음
→ Merge 조건을 잘 설계해야 함

 

3. CDC 이벤트 타입이 시스템마다 다름

CDC 이벤트는 표준화된 형식이 없습니다. 각 시스템마다 이벤트 구조가 다르기 때문에 ingestion 설계 시 주의가 필요합니다.

 

예시
• Debezium: before / after 구조
• SQL Server CDC: net changes vs all changes
• Oracle GoldenGate: insert / update / delete 이지만 컬럼 구조 다름
• SAP 시스템: ODP 기반 delta extraction

→ 매핑 로직 필요
→ 테이블 스키마 변경 시 파이프라인 업데이트 필요

 

4. CDC는 Schema Drift에 매우 민감하다

CDC는 스키마가 바뀌면 즉시 장애가 발생하기 쉽습니다. 예를 들어:

• 원본 DB에서 컬럼 추가/삭제
• CDC 이벤트 형식에 새로운 필드가 포함됨
• Delta Merge가 스키마 문제로 실패

 

이런 문제가 흔합니다. 따라서 자동 스키마 진화(auto schema evolution)를 적용하거나 스키마 변경 감지 로직을 넣어야 합니다.

 

5. Snapshot + CDC의 동기화가 틀어질 수 있다

많은 CDC 파이프라인은 아래 구조로 운영됩니다.

1. snapshot(전체 데이터 적재)
2. CDC로 변경 이력 반영

문제: snapshot 도중에 데이터가 변경되면?

• snapshot은 오래 걸리고
• CDC는 그 사이에 이벤트가 발생하면

→ duplicate
→ missing
→ delta mismatch

 

이 문제를 잡기 위해 snapshot 시 “CDC 로그 오프셋”을 잘 기록해야 합니다.

 

6. CDC 이벤트는 구조적으로 noisy하다

CDC는 Delta 테이블이 원하는 형태와 다른 "이벤트 로그" 형태입니다: 

 

• update 이벤트가 1건 발생해도 3개의 이벤트가 올 수 있음

• update_before
• update_after
• Tombstone 이벤트

→ 이를 Delta Lake 테이블로 merge하는 로직 필수

 

7. CDC ingestion은 시스템 부하를 유발할 수 있다

CDC는 대부분 transaction log를 읽기 때문에 소스 시스템(DB)에 부하가 발생할 수 있습니다.

 

예시
• 로그 사이즈 급증
• replication slot overflow(Postgres)
• binlog retention 증가로 스토리지 비용 증가

 

CDC를 안정적으로 운영하려면 소스 시스템의 리소스도 함께 관리해야 합니다.

 

 

 

Databricks의 CDC와 CDF는 현대적인 데이터 플랫폼에서 필수 기능입니다. 변경된 데이터만 효율적으로 처리할 수 있기 때문에 ETL 파이프라인의 성능과 비용을 동시에 개선할 수 있습니다. CDC로 외부 시스템의 변경 정보를 가져오고, CDF를 통해 Delta Lake 내부에서 변경 데이터만 추출하는 방식은 매우 실용적이며 특히 대규모 데이터를 다루는 환경에서 큰 효과를 발휘합니다.

앞으로 Databricks 기반 파이프라인을 설계하거나 개선할 때 CDC와 CDF는 반드시 고려해야 할 핵심 요소가 될 것입니다.