Databricks Lakeflow Connect MySQL CDC: 게이트웨이 없는 통합 파이프라인으로 소스 데이터를 레이크하우스로 싣는 방법

왜 지금 봐야 하나

2026년 7월, Databricks가 Lakeflow Connect의 MySQL 통합 CDC 파이프라인을 Beta로 공개했다. 단순한 기능 추가가 아니다. MySQL에서 Databricks로 데이터를 지속적으로 옮기던 기존 아키텍처가 바뀐다.

기존 방식: 소스 DB → 별도 수집 게이트웨이(Ingestion Gateway) → 원시 이벤트 테이블 → 파이프라인 변환. 새로운 방식: 소스 DB → 통합 파이프라인(단일 업데이트에서 추출 + 적용).

게이트웨이를 없앤 것이 핵심이다. 관리해야 할 컴포넌트가 줄고, 레이턴시 경계가 단순해지며, 운영 복잡도가 낮아진다.

이 글은 Lakeflow Connect의 아키텍처, 표준 방식과 통합 파이프라인의 구체적 차이, AUTO CDC API, Unity Catalog와의 통합, 그리고 운영 판단 기준을 다룬다.

Lakeflow Connect 아키텍처 전체 그림

Lakeflow Connect는 외부 소스의 데이터를 Databricks 데이터 인텔리전스 플랫폼으로 수집하는 관리형 커넥터 모음이다. 두 가지 커넥터 유형이 있다.

관리형 커넥터는 소스 연결 인증 정보를 Unity Catalog 연결(Connection) 개체로 관리한다. 커넥터가 소스 데이터베이스에 접근할 때 Unity Catalog에서 자격 증명을 참조하므로, 민감 정보가 파이프라인 코드에 하드코딩되지 않는다.

기존 게이트웨이 방식과 통합 파이프라인의 차이

기존 방식: 두 단계 파이프라인

기존 MySQL CDC 연동은 다음 컴포넌트가 필요했다.

1. Ingestion Gateway: 고객 네트워크 또는 Databricks가 제공하는 게이트웨이 서버. 소스 MySQL의 바이너리 로그(binlog)를 지속적으로 읽어 원시 CDC 이벤트를 중간 스토리지에 기록한다.
2. 수집 파이프라인: 게이트웨이가 기록한 원시 이벤트를 읽어 Delta 테이블에 적재한다.
3. 변환 파이프라인: Delta 테이블의 CDC 이벤트를 처리해 INSERT/UPDATE/DELETE를 최종 테이블에 반영한다.

통합 파이프라인: 단일 업데이트

2026년 7월 Beta로 공개된 통합 파이프라인은 게이트웨이를 없앤다. 하나의 파이프라인 업데이트 안에서 추출(extraction)과 적용(application)이 함께 처리된다.

운영상 달라지는 것:

• 게이트웨이 서버 프로비저닝·모니터링·패치 불필요
• 중간 이벤트 테이블 없이 직접 Delta 테이블에 반영
• 파이프라인 하나로 데이터 이동 전체 경로 가시화
• 레이턴시 경계: 게이트웨이 버퍼링 제거로 소스 변경 → Delta 테이블 반영 간격 단축

AUTO CDC API: INSERT·UPDATE·DELETE 처리 방법

Databricks는 2026년에 APPLY CHANGES API를 AUTO CDC API로 대체했다. 두 API는 동일한 문법을 갖지만, 공식 권장 사항은 AUTO CDC를 사용하는 것이다.

AUTO CDC INTO 문법

SQL에서:

AUTO CDC INTO target_table
FROM source_stream
KEYS (order_id)
SEQUENCE BY updated_at
COLUMNS * EXCEPT (op, _metadata)
STORED AS SCD TYPE 1;

Python에서:

dlt.create_auto_cdc_flow(
    target="orders_silver",
    source="orders_cdc_raw",
    keys=["order_id"],
    sequence_by="updated_at",
    stored_as_scd_type=1,
    apply_as_deletes=dlt.col("op") == "D",
    apply_as_truncates=dlt.col("op") == "T"
)

SCD Type 1과 Type 2

이벤트 순서 보장: SEQUENCE BY 컬럼으로 지정된 값 기준으로 이벤트가 정렬된다. 소스에서 같은 레코드가 여러 번 변경되어 순서 없이 도착해도 자동으로 처리된다.

DELETE 처리: apply_as_deletes 조건으로 삭제 이벤트를 지정한다. SCD Type 1에서는 레코드가 물리적으로 제거된다. SCD Type 2에서는 __END_AT이 설정된다.

MySQL 통합 파이프라인 구성

MySQL 통합 CDC 파이프라인을 사용하려면:

1. Unity Catalog에 MySQL 연결(Connection) 생성:

CREATE CONNECTION mysql_prod
TYPE MYSQL
OPTIONS (
  host 'mysql.example.com',
  port '3306',
  user secret('databricks-mysql', 'username'),
  password secret('databricks-mysql', 'password')
);

1. Lakeflow Connect UI 또는 API에서 MySQL 커넥터 생성 시 "통합 파이프라인" 옵션 선택.

1. 복제할 테이블과 대상 카탈로그·스키마를 지정.

MySQL 소스 요구사항:

• binlog_format = ROW 설정 필수
• binlog_row_image = FULL 권장
• 연결 계정에 REPLICATION SLAVE, REPLICATION CLIENT, SELECT 권한 필요
• MySQL 5.7 이상

Row Filtering GA: 불필요한 행을 소스에서 제거

2026년 7월, Lakeflow Connect의 Row Filtering이 GA(일반 공개)됐다.

Row Filtering은 SQL WHERE 절과 유사한 조건으로 소스에서 특정 행만 수집한다.

예시: 특정 지역의 주문만 수집

region = 'APAC' AND status != 'CANCELLED'

활용 사례:

• 테스트·개발용 일부 데이터만 레이크하우스에 동기화
• GDPR 등 규정 준수로 특정 사용자 데이터를 수집 단계에서 제외
• 고용량 테이블에서 분석에 필요한 서브셋만 선택적으로 수집

Row Filtering은 수집 단계에서 적용되므로, 불필요한 데이터가 Delta 테이블에 기록되지 않는다. 사후 필터링과 달리 스토리지 비용과 처리 부하를 줄인다.

Unity Catalog 거버넌스 연동

Lakeflow Connect가 Unity Catalog와 통합된다는 것은 수집 파이프라인이 Unity Catalog의 거버넌스 레이어 안에서 동작한다는 의미다.

연결(Connection) 오브젝트: 소스 DB 자격 증명을 Unity Catalog에 저장. 파이프라인은 자격 증명 직접 참조 없이 연결 이름으로 소스에 접근한다.

대상 테이블 거버넌스: Lakeflow가 쓰는 Delta 테이블은 Unity Catalog에서 관리된다. 테이블 소유자, 접근 권한, 태그를 Unity Catalog에서 설정한다.

Lineage 자동 추적: Lakeflow 파이프라인이 데이터를 이동하면 Unity Catalog Lineage가 소스 → 브론즈 → 실버 경로를 자동으로 기록한다. 다운스트림 영향도 분석에 활용된다.

Audit Log: 파이프라인 실행, 데이터 접근, 설정 변경이 Unity Catalog Audit Log에 기록된다.

Medallion 아키텍처와 Lakeflow 파이프라인 연동

Lakeflow Connect는 Medallion(메달리온) 레이크하우스 아키텍처와 자연스럽게 통합된다.

Bronze 레이어: Lakeflow Connect가 원시 CDC 이벤트를 그대로 기록한다. 소스 레코드의 변경 이력과 메타데이터(타임스탬프, 연산 유형)가 보존된다.

Silver 레이어: AUTO CDC API가 Bronze의 CDC 이벤트를 처리해 현재 상태의 정제된 Delta 테이블을 유지한다. SCD Type 1이면 최신 값, SCD Type 2면 이력 포함 전체 레코드.

Gold 레이어: Silver 테이블을 기반으로 분석 목적의 집계·조인·마트 테이블을 생성한다.

Lakeflow Declarative Pipelines와 함께 쓸 때, Bronze → Silver → Gold 전체 파이프라인을 단일 파이프라인 그래프로 정의할 수 있다. 파이프라인 실행 엔진이 의존성 순서를 결정하고 재시도를 관리한다.

운영 판단 기준

통합 파이프라인을 선택하는 경우

• 소스가 MySQL이고 게이트웨이 서버 관리 오버헤드를 줄이고 싶을 때
• 단순한 데이터 이동이 목적이며 파이프라인 아키텍처를 단순하게 유지하려 할 때
• Databricks 완전 관리형 인프라만 사용하고 싶을 때

표준 게이트웨이 방식이 여전히 필요한 경우

• 통합 파이프라인이 지원하지 않는 소스 DB 또는 특수 구성
• 네트워크 경계상 게이트웨이가 소스에 더 가깝게 위치해야 할 때
• 고급 변환 또는 필터링 로직이 게이트웨이 단계에서 필요할 때

AUTO CDC vs APPLY CHANGES

신규 파이프라인은 AUTO CDC API를 사용한다. APPLY CHANGES는 기존 파이프라인 호환성을 위해 유지되지만, Databricks의 공식 권장 사항은 AUTO CDC로 전환이다.

주의해야 할 사항

• MySQL 통합 파이프라인은 2026년 7월 기준 Beta — 프로덕션 전환 전 충분한 검증 필요
• binlog_format = ROW 설정이 누락되면 연결은 되지만 변경 내용이 캡처되지 않는다
• Row Filtering은 수집 단계에서 적용되므로 필터 조건 변경 시 전체 재수집이 필요할 수 있다
• SCD Type 2 대상 테이블에서 DELETE는 __END_AT을 설정하지 물리적으로 제거하지 않는다 — 주기적 VACUUM 계획 필요

Open Questions

• MySQL 통합 파이프라인의 GA 전환 일정 미공개 (Beta 단계 유지 기간 불명)
• 대용량 초기 스냅샷(full load) 처리 방법과 병렬화 수준의 공개 문서화 미비
• Row Filtering과 AUTO CDC를 동시에 사용할 때의 SEQUENCE 보장 동작 상세 확인 필요
• Unity Catalog Lineage에서 소스 테이블 컬럼 수준 계보 지원 여부 미확인

References

• Databricks July 2026 Release Notes (AWS)
• Introducing Databricks Lakeflow — Databricks Blog
• Managed database connectors: CDC Overview — Databricks Docs
• AUTO CDC INTO (pipelines) — Databricks Docs
• The AUTO CDC APIs: Simplify change data capture — Azure Databricks
• Lakeflow Connect Gets Simpler for Database Ingestion — Medium
• Lakeflow Connect: Data Ingestion for the Lakehouse — Springer Nature