LLM WikiAccess-protected knowledge portal

WIKI

Apache Spark 4.2: CDC 통합·메트릭 뷰·실시간 스트리밍·Arrow 기본값으로 달라진 운영 지형

요약 2026년 7월 14일 출시된 Apache Spark 4.2.0 은 단일 마이너 릴리스 치고 운영 지형을 크게 바꿀 네 가지 변화를 담고 있다. 1. CDC 통합 Delta Lake, Iceberg, Hudi 각자의 증분 쿼리 방언을 하나의 CHANGES 인터페이스로 통합 2. Metric View 비즈니스 지표 정의를 엔진 내부에서 관리하는 시맨틱 레이어 3. 실시간 모드 RTM 수 밀리초 지연을 목표로 하는 Struc

경로human/study/content/database-frontier/119-apache-spark-4-2-cdc-metric-views-rtm-arrow-udf.md
카테고리Study
태그#arrow #metric #mysql #rtm #study #udf #views

요약

2026년 7월 14일 출시된 Apache Spark 4.2.0은 단일 마이너 릴리스 치고 운영 지형을 크게 바꿀 네 가지 변화를 담고 있다.

  1. CDC 통합: Delta Lake, Iceberg, Hudi 각자의 증분 쿼리 방언을 하나의 CHANGES 인터페이스로 통합
  2. Metric View: 비즈니스 지표 정의를 엔진 내부에서 관리하는 시맨틱 레이어
  3. 실시간 모드(RTM): 수 밀리초 지연을 목표로 하는 Structured Streaming Real-Time Mode 정식 지원
  4. Arrow UDF 기본화: Python UDF에 Arrow 경로를 기본값으로 전환해 직렬화 비용 제거

각각은 독립적인 운영 결정을 요구한다. 이 글은 네 변화의 내부 작동 방식과 배포 시 고려해야 할 트레이드오프를 다룬다.

배경: 왜 지금 이 네 가지인가

CDC 단편화의 누적된 고통

2024년 이후 Lakehouse 스택을 운영하는 팀은 공통된 문제에 직면했다. Delta Lake, Apache Iceberg, Apache Hudi 세 포맷이 각자 증분 데이터를 노출하는 방식이 달랐다.

같은 파이프라인이 소스 포맷에 따라 완전히 다른 코드를 요구했다. 커넥터를 교체하거나 포맷을 마이그레이션할 때 파이프라인 전체를 재작성해야 했다.

Spark 4.2는 DataSource v2(DSv2) API에 Changelog 믹스인 인터페이스를 추가해 이 단편화를 해소한다.

변화 1: CHANGES 절과 DSv2 Changelog API

아키텍처

새로운 Changelog 인터페이스는 커넥터 수준의 계약이다. Delta Lake, Iceberg, Hudi 등 DSv2 커넥터가 이 인터페이스를 구현하면 Spark 플래너가 표준 CDC 쿼리를 처리한다. 커넥터는 포맷 특화 변경 이벤트를 Spark에 넘기고, 엔진이 나머지를 담당한다.

엔진이 처리하는 공통 후처리:

커넥터는 이 로직을 직접 구현할 필요가 없다.

Delta Lake
↓
Changelog impl
Apache Iceberg
↓
Changelog impl
Apache Hudi
↓
Changelog impl
→
Spark 4.2 엔진
중복 제거·UPDATE 변환·순 변경 계산
→
CHANGES 절 SQL
DataFrame .changes() API
Streaming CDC 파이프라인
Spark 4.2 CHANGES 절 아키텍처: DSv2 Changelog 인터페이스

사용 방법

배치 모드에서 특정 버전 범위의 변경을 조회한다.

-- 버전 10에서 20 사이의 변경 이력 조회 (Open question: 정확한 문법은 공식 릴리스 노트 확인 필요)
SELECT * FROM my_table CHANGES FROM VERSION 10 TO VERSION 20;

DataFrame API에서도 동일하게 사용할 수 있다.

df = spark.read \
    .option("startingVersion", "10") \
    .option("endingVersion", "20") \
    .changes("my_table")

Structured Streaming과 결합하면 실시간 CDC 파이프라인을 구성할 수 있다.

-- 스트리밍 CDC 파이프라인 (Open question: STREAM + CHANGES 결합 문법 확인 필요)
CREATE STREAMING TABLE cdc_sink AS
  SELECT * FROM STREAM my_table CHANGES FROM VERSION 0;

Open question: 위 SQL 문법은 연구 과정에서 합성된 것이다. 공식 Spark 4.2.0 릴리스 노트(https://spark.apache.org/releases/spark-release-4-2-0.html)에서 정확한 구문을 확인하고 사용하라.

변화 2: Auto CDC와 Spark Declarative Pipelines

Spark Declarative Pipelines(SDP)는 파이프라인 정의에서 CDC 처리를 선언적으로 지정하는 상위 레이어다. 사용자는 키 컬럼, 시퀀스 컬럼, 연산 컬럼을 선언하면 된다.

선언 항목역할
키 컬럼UPSERT/DELETE 대상 행 식별
시퀀스 컬럼이벤트 순서 결정 (타임스탬프 또는 단조 증가 ID)
연산 컬럼INSERT/UPDATE/DELETE 구분

Spark는 선언에 따라 SCD Type 1 업서트를 자동 실행한다. 일치하는 키는 UPDATE, 새 키는 INSERT, 삭제 이벤트는 DELETE로 처리한다. 이전의 APPLY CHANGES INTO 문법은 이 새 API를 선호해 deprecated됐다.

변화 3: Metric View — 시맨틱 레이어를 엔진 안으로

문제: 지표 정의가 클라이언트에 분산된다

기존에는 "월별 수익" 같은 KPI를 각 대시보드 도구, BI 클라이언트, 분석 쿼리가 제각각 정의했다. 집계 함수 선택, 필터 기준, 날짜 컬럼 해석이 클라이언트마다 달라져 지표 불일치가 발생했다.

Metric View 구조

Spark 4.2는 WITH METRICS 절이 있는 특수 뷰 타입을 도입한다. 뷰 내부에 측정값(measure)과 차원(dimension)을 정의하면, 뷰를 쿼리하는 클라이언트는 집계 함수를 다시 명시하지 않고도 정의된 지표를 사용할 수 있다.

-- Metric View 생성 (Open question: WITH METRICS 문법 세부사항은 릴리스 노트 확인 필요)
CREATE VIEW revenue_metrics WITH METRICS AS
SELECT
  customer_id,
  order_date,
  SUM(order_amount) AS total_revenue  -- measure
FROM orders;

주요 설계 결정:

변화 4: Structured Streaming Real-Time Mode 정식 지원

마이크로배치의 지연 한계

표준 Structured Streaming은 마이크로배치 방식이다. 각 배치를 처리하고, 체크포인트를 기록하고, 다음 배치를 시작한다. 체크포인트 오버헤드로 인해 최소 지연이 수백 밀리초 수준이다.

Spark 2.3부터 실험적으로 제공된 Continuous Processing(CP) 모드는 지연을 수 밀리초 수준으로 낮추는 것을 목표로 했지만, 4.2 이전까지 실험적 상태였다.

RTM 아키텍처

Spark 4.2에서 정식 지원으로 승격된 Real-Time Mode(RTM)는 Continuous Processing을 기반으로 한다. 마이크로배치 스케줄러 대신 파티션당 하나의 장기 실행 태스크를 유지한다. 체크포인트는 에포크 단위로 기록되고, 마이크로배치 방식처럼 배치마다 커밋하지 않는다.

마이크로배치 모드
Batch 1 처리 → 체크포인트
Batch 2 처리 → 체크포인트
Batch 3 처리 → 체크포인트
지연: 수백ms ~ 수초
정확히 한 번(Exactly-Once)
vs
Real-Time Mode (RTM)
파티션당 장기 실행 태스크
에포크 단위 체크포인트
연속 처리 — 배치 경계 없음
지연: 단일 자릿수 ms (무상태 파이프라인)
최소 한 번(At-Least-Once)
마이크로배치 vs RTM 처리 모델 비교

RTM 적합 사례:

RTM 제한사항:

변화 5: Arrow UDF 기본화

기존 Python UDF의 직렬화 비용

기존 Python UDF는 JVM과 Python 프로세스 사이에서 행을 직렬화해야 했다. 각 행이 Python Row 객체로 변환됐다가 다시 JVM으로 돌아오는 과정에서 Pickle/CloudPickle 직렬화가 발생했다. CPU와 메모리 모두 비쌌다.

Pandas UDF는 이미 Apache Arrow IPC 포맷을 사용해 배치 단위로 데이터를 전달했다. RecordBatch 형태로 전달하면 행 단위 직렬화 없이 처리할 수 있었지만, 사용자가 함수 시그니처를 Pandas 스타일로 바꿔야 했다.

Spark 4.2의 기본값 변경

Spark 4.2는 두 설정을 기본값 true로 전환한다.

설정4.2 이전 기본값4.2 기본값
spark.sql.execution.pythonUDF.arrow.enabledfalsetrue
spark.sql.execution.arrow.pyspark.enabledfalsetrue

일반 Python UDF(@udf)도 이제 Arrow 경로를 기본으로 사용한다. 함수 시그니처를 바꾸지 않고도 Arrow 최적화 경로를 자동으로 탄다.

from pyspark.sql.functions import udf
from pyspark.sql.types import StringType

# Spark 4.2 이후: 변경 없이 Arrow 경로 자동 사용
@udf(StringType())
def process_name(name):
    return name.upper()

# Arrow 비활성화가 필요한 경우 (Arrow 호환 불가 타입)
spark.conf.set("spark.sql.execution.pythonUDF.arrow.enabled", "false")

주의사항: Arrow 타입 변환이 지원되지 않는 Python 타입(예: 복잡한 커스텀 객체)을 UDF에서 사용하면 오류가 발생할 수 있다. 기존 UDF가 많은 환경에서는 업그레이드 전 Arrow 호환성 확인이 필요하다.

운영자 체크리스트

CDC 마이그레이션
□ 기존 Delta/Iceberg/Hudi 증분 쿼리 코드 목록 작성
□ 커넥터 버전이 Changelog 인터페이스 지원 여부 확인
□ APPLY CHANGES INTO → Auto CDC 마이그레이션 계획 수립
Arrow UDF 호환성
□ 기존 Python UDF에서 Arrow 직렬화 불가 타입 사용 여부 확인
□ 스테이징 환경에서 전체 UDF 오류 유무 검증
□ 문제 UDF에만 arrow.enabled=false 설정 후 점진적 전환
RTM 도입 판단
□ 파이프라인이 무상태 변환 위주인가 (RTM 적합)
□ 싱크가 멱등성을 지원하는가 (At-Least-Once 허용 여부)
□ 현재 마이크로배치 지연이 SLO를 실제로 위반하는가 먼저 측정
Metric View 도입 판단
□ 팀 내 비즈니스 지표 정의 불일치 문제가 실제로 있는가
□ dbt 시맨틱 레이어, Cube.js 등 기존 솔루션과 역할 중복 검토
□ 현재 Spark 버전이 4.2로 업그레이드 준비됐는가
Spark 4.2 업그레이드 전 확인 항목

종합 판단

네 가지 변화는 독립적이지만 함께 보면 Spark 4.2의 방향성이 명확해진다. 엔진이 데이터 계층에서 더 넓은 의미를 담으려 한다. CDC는 포맷 계층의 단편화를 엔진이 흡수하고, Metric View는 BI 계층의 지표 정의를 엔진이 흡수한다. RTM은 스트리밍 레이턴시 요구사항을 더 낮은 계층에서 충족하고, Arrow UDF 기본화는 Python 생태계와의 경계 비용을 줄인다.

이 방향은 LLM 기반 데이터 에이전트가 Spark를 직접 쿼리하는 시나리오에서도 의미가 있다. Metric View로 지표 정의를 발견하고, CHANGES 절로 증분 데이터를 추출하고, RTM으로 실시간 이벤트를 처리하는 에이전트 파이프라인이 단일 Spark 세션 안에서 구성 가능해진다.

실무 우선순위는 다음 순서를 권장한다: Arrow UDF 호환성 검증(리스크 최소 대비 성능 이득 큰 변화) → CDC API 통합(포맷 이식성 개선) → RTM 검토(실제 지연 요구사항이 있는 파이프라인만) → Metric View(팀 지표 정의 관리 성숙도 도달 후).

References