LTAP 글과 Lakehouse//RT 글은 둘 다 "CDC 파이프라인이 필요 없다"를 장점으로 내세웠습니다. 없애겠다는 그 CDC가 정확히 무엇인지, 대표 오픈소스인 Debezium 문서로 정리해 둡니다.
한 줄 정의
CDC(Change Data Capture)는 데이터베이스에서 일어난 변경을 잡아 다른 시스템으로 보내는 방법입니다. 운영 DB의 주문 테이블이 바뀌면, 그 변경을 분석 시스템으로 옮기는 식입니다.
Debezium은 Kafka Connect용 소스 커넥터 모음입니다. 커넥터마다 하나의 데이터베이스를 맡아, 그 데이터베이스의 CDC 기능으로 변경을 읽어 옵니다.
변경을 잡는 세 가지 방법
폴링. 주기적으로 "최근에 바뀐 행"을 조회합니다. updated_at 같은 열이 필요하고, 자주 조회할수록 DB에 부담이 갑니다.
이중 쓰기. 앱이 DB에 쓰면서 동시에 다른 시스템에도 씁니다. 둘 중 하나만 성공하면 어긋납니다.
로그 기반. DB가 원래 남기는 트랜잭션 로그를 읽습니다. Debezium이 쓰는 방식입니다.
로그 기반이 나은 이유
Debezium 문서가 꼽는 장점은 이렇습니다.
- 모든 변경을 잡는다. 폴링 사이에 생겼다 사라진 변경도 놓치지 않습니다.
- 삭제도 잡는다. 폴링으로는 지워진 행을 알기 어렵습니다.
- 지연이 낮다. 문서는 MySQL과 PostgreSQL에서 밀리초 단위라고 설명합니다. 잦은 폴링으로 CPU를 쓰지 않아도 됩니다.
- 데이터 모델을 바꾸지 않는다. "Last Updated" 같은 열을 추가할 필요가 없습니다.
그런데 왜 없애고 싶어 하나
로그 기반 CDC는 잘 동작합니다. 그래도 파이프라인은 파이프라인입니다.
커넥터를 운영해야 하고, 스키마가 바뀌면 다운스트림이 깨질 수 있고, 운영 DB와 분석 시스템 사이에 시차가 생깁니다. 변경이 Kafka를 거쳐 레이크로, 다시 웨어하우스로 가는 동안 구성 요소가 계속 늘어납니다.
LTAP의 발상은 이 경로를 아예 없애는 것입니다. 운영 DB가 처음부터 레이크의 개방 형식으로 저장하면 옮길 필요가 없다는 주장입니다. 이 주장이 얼마나 현실적인지는 아직 지켜봐야 합니다. 다만 CDC가 무엇을 해 주고 있었는지 알아야, 그걸 없앴을 때 무엇을 대신 챙겨야 하는지 보입니다. 삭제 추적, 변경 이력, 시점 복원 같은 것들입니다.
