Apache Spark 4.2: NEAREST BY·Metric Views·Auto CDC로 분석 엔진에 AI 워크로드를 직접 끌어들인 릴리스

왜 지금 봐야 하나

Apache Spark 4.2.0이 2026년 7월 14일 릴리스됐다. Spark 4.x 라인의 세 번째 릴리스로, 1,700개 이상의 Jira 이슈를 처리하고 250명 이상의 기여자가 참여했다.

이 릴리스에서 가장 눈에 띄는 변화는 AI 워크로드를 Spark SQL 안으로 당겨온 것이다. 벡터 유사도 검색, 상위-K 랭킹 조인, 지리공간 타입, 거버닝된 메트릭 뷰가 한 릴리스에 담겼다. 거기에 Change Data Capture의 SQL 네이티브 지원과 PySpark의 Arrow 기본화가 더해졌다.

이것이 단순한 기능 추가가 아닌 이유가 있다. Spark는 대규모 데이터 처리의 표준 엔진으로 이미 대부분의 데이터 인프라에 자리잡혀 있다. 여기서 벡터 검색과 지리공간 타입이 SQL 기본값이 되면, 별도의 특수 엔진을 도입하지 않아도 같은 파이프라인에서 이 작업들을 처리할 수 있다는 뜻이다.

이 글은 4.2의 핵심 변화를 운영자 관점에서 다룬다. 각 기능이 무엇을 해결하는지, 어떤 트레이드오프가 있는지, 기존 파이프라인에서 무엇을 바꿔야 하는지를 본다.

Spark 4.2 핵심 변화 지도

1. 벡터 SQL 프리미티브: NEAREST BY와 벡터 함수

왜 Spark에 벡터 검색이 필요한가

지금까지 대규모 벡터 검색은 별도 엔진을 요구했다. Pinecone, Qdrant, Milvus, pgvector 같은 전용 벡터 데이터베이스다. 이 엔진들은 HNSW나 IVF 같은 ANN(Approximate Nearest Neighbor) 인덱스를 최적화해서 작은 데이터셋에서 매우 빠른 검색을 제공한다.

그런데 실제 데이터 파이프라인에서는 다른 상황도 많다. 수백만 건의 제품 카탈로그에서 유사 상품을 찾거나, 매시 배치 파이프라인에서 문서 임베딩과 쿼리 임베딩을 조인하거나, Spark로 이미 처리한 데이터 위에서 ANN 검색을 추가로 돌리는 경우다. 이 경우 별도 벡터 DB를 올리고 데이터를 이중으로 유지하는 것은 운영 비용이 크다.

Spark 4.2의 벡터 SQL 프리미티브는 이런 배치·대규모 분석 워크로드를 타겟으로 한다.

NEAREST BY: 새로운 상위-K 랭킹 조인

핵심 신규 연산자는 NEAREST BY다. 특정 벡터에 가장 가까운 K개 행을 찾는 랭킹 조인이다.

-- 쿼리 임베딩과 가장 유사한 상위 5개 문서 검색
SELECT doc_id, content, cosine_similarity(embedding, :query_vec) AS score
FROM documents
NEAREST BY embedding TO :query_vec LIMIT 5;

내부적으로 이것은 전통적인 top-K 집계로 컴파일되지만, 분산 실행에서 각 파티션이 로컬 상위-K를 먼저 계산하고, 드라이버가 전역 상위-K를 결합한다. HNSW 같은 인덱스 기반 ANN보다 느릴 수 있지만, 수백만~수십억 규모의 배치 분석에서는 충분한 경우가 많다.

제공되는 벡터 함수들

Spark 4.2는 다음 벡터 함수를 SQL과 DataFrame API로 제공한다.

실제 사용 패턴에서는 임베딩을 ARRAY<FLOAT> 타입으로 저장하고, 위 함수를 SQL에서 직접 쓸 수 있다.

언제 Spark 벡터 검색을 쓰고, 언제 전용 벡터 DB를 쓰는가

이것이 운영자에게 가장 중요한 판단이다.

Spark 벡터 검색이 유리한 경우:

• 이미 Spark 파이프라인 안에서 처리하는 데이터에 벡터 검색을 추가할 때
• 배치 분석: 하루 1회 또는 시간 단위 오프라인 추천 생성
• 수백만 건 이하의 벡터 데이터셋 (예: 제품 카탈로그, 문서 컬렉션)
• 인프라 단순화가 목표일 때 (별도 벡터 DB 운영 제거)

전용 벡터 DB가 필요한 경우:

• 서브초 응답이 요구되는 실시간 사용자 검색
• 수억 이상의 대용량 벡터 데이터셋에서 높은 recall ANN
• 동적으로 벡터가 추가/삭제되는 온라인 워크로드
• HNSW/IVF 파라미터 세밀 튜닝이 필요한 경우

2. Metric Views: 분산 의미론을 엔진 안에 가두는 방법

메트릭 정의 분산 문제

"월별 활성 사용자"를 계산하는 SQL이 마케팅 팀 대시보드, 엔지니어링 팀 리포트, AI 추천 모델 피처 세 곳에서 다르게 정의돼 있는 상황은 어렵지 않게 찾을 수 있다. dbt 모델을 쓰거나 BI 도구에서 메트릭을 정의하더라도, 다른 팀이 같은 데이터에 다른 집계 로직을 쓰면 숫자가 일치하지 않는다.

Spark 4.2의 Metric Views는 이 문제를 엔진 레이어에서 해결한다. 비즈니스 메트릭을 한 번 정의하면, Spark가 집계 의미론을 집행한다.

Metric Views 구조

Metric View는 차원(Dimension)과 측정값(Measure)을 1등급 SQL 객체로 만든다.

CREATE METRIC VIEW monthly_active_users
  DIMENSIONS user_country, product_tier, signup_channel
  MEASURES
    mau AS COUNT(DISTINCT user_id) FILTER (WHERE is_active = TRUE),
    new_users AS COUNT(DISTINCT user_id) FILTER (WHERE is_new = TRUE)
  FROM user_events
  AGGREGATED BY year_month;

이렇게 정의하면, SQL, DataFrame API, BI 커넥터, AI 도구가 같은 정의를 소비한다. 쿼리를 다르게 쓰더라도 집계 의미론은 동일하게 유지된다.

운영자가 실제로 얻는 것

Metric Views는 데이터 신뢰성 문제를 방지하는 거버넌스 레이어다. 다음 상황에서 유용하다.

• AI/ML 피처 파이프라인과 BI 대시보드가 같은 메트릭을 소비해야 할 때
• 복잡한 집계 로직(FILTER, 시간 범위, 조건부 카운트)이 여러 팀에서 재사용될 때
• 메트릭 변경이 모든 다운스트림에 동시에 반영되어야 할 때

현재 dbt의 시맨틱 레이어, Looker의 LookML, 또는 자체 구현으로 이 문제를 해결하는 팀이라면, Spark SQL 안에 통합된 Metric Views가 하나의 레이어를 줄여줄 수 있다.

3. Change Data Capture: SQL CHANGES 절과 Auto CDC

SQL CHANGES 절

기존에 Spark에서 CDC를 처리하려면 Kafka 또는 외부 CDC 도구의 데이터를 스트리밍으로 받아 별도 처리 로직을 구현해야 했다. Spark 4.2는 이것을 SQL 네이티브 연산자로 가져왔다.

-- 테이블에서 행 수준 변경사항 읽기
SELECT operation, timestamp, before_values, after_values
FROM CHANGES OF orders
WHERE operation IN ('INSERT', 'UPDATE', 'DELETE')
  AND timestamp BETWEEN :start AND :end;

CHANGES OF 절은 배치와 스트리밍 양쪽에서 동작한다. DataFrame API와 PySpark, Spark Connect에서도 동일하게 쓸 수 있다.

Auto CDC in Declarative Pipelines

Spark 4.2는 Spark Declarative Pipelines(SDP) 안에서 Auto CDC를 지원한다. 이것은 소스 테이블의 변경사항을 대상 테이블에 선언형으로 적용하는 SCD Type 1 upsert 패턴이다.

@dlt.table
def orders_current():
    return (
        dlt.read_stream("orders_cdc")
        .apply_changes(
            target="orders_current",
            source="orders_cdc",
            keys=["order_id"],
            sequence_by="updated_at",
            apply_as_deletes=F.col("operation") == "DELETE"
        )
    )

Auto CDC는 순서 보장, 중복 제거, 삭제 처리를 선언형으로 다룬다. 기존에 이 로직을 직접 구현하던 팀은 상당한 코드를 줄일 수 있다.

운영자가 확인할 사항

CHANGES 절이 동작하려면 소스 테이블이 변경 이력을 지원해야 한다. Delta Lake, Apache Hudi, Apache Iceberg가 지원된다. 기존 Parquet 파일에는 적용되지 않는다. CDC를 사용하려면 소스 테이블 포맷을 먼저 확인해야 한다.

4. Arrow-first Python: 직렬화 오버헤드를 없앤 기본값 전환

무엇이 기본값이 됐나

Spark 4.2는 두 가지 Arrow 관련 설정을 기본값으로 전환했다.

spark.sql.execution.arrow.pyspark.enabled = true  (4.2 기본)
spark.sql.execution.pythonUDF.arrow.enabled = true  (4.2 기본)

첫 번째는 PySpark와 JVM 사이의 데이터 교환 방식을 Pickle 직렬화에서 Apache Arrow 컬럼형 형식으로 바꾼다. 두 번째는 Python UDF가 Arrow 배치로 데이터를 받아 처리하도록 한다.

실제로 얼마나 빨라지나

Arrow 기반 IPC는 Pickle 대비 데이터 교환 비용을 크게 줄인다. 특히 DataFrame을 Python으로 변환할 때(toPandas()), Python UDF를 대량 적용할 때, Pandas UDF(vectorized UDF)를 사용할 때 효과가 크다.

구체적인 수치는 워크로드에 따라 다르지만, Pandas UDF 기준으로 2~5배 처리량 향상이 보고된다.

주의사항: 호환성 검토 필요

Arrow 기본화는 기존 코드에 영향을 줄 수 있다. 주요 확인 사항은 다음과 같다.

4.1에서 4.2로 업그레이드할 때 테스트해야 하는 영역:

• Python UDF가 Arrow 직렬화와 호환되는 타입을 반환하는지 확인 (datetime, nullable int 등)
• toPandas() 결과가 기존과 동일한지 검증 (Arrow는 nullable 타입 처리가 다를 수 있음)
• 커스텀 직렬화 로직이 있는 UDF는 Arrow 경로에서 다르게 동작할 수 있음

공식 마이그레이션 가이드("Upgrading from PySpark 4.1 to 4.2")를 반드시 확인한다.

5. 지리공간 타입: ST_* 함수와 OGC 표준

Spark 4.2는 GEOMETRY와 GEOGRAPHY 타입을 내장하고, OGC Simple Feature Access 표준을 따르는 ST_* 함수 세트를 제공한다.

-- 반경 내 레스토랑 찾기
SELECT restaurant_id, name,
       ST_Distance(location, ST_Point(127.02, 37.52)) AS distance_m
FROM restaurants
WHERE ST_DWithin(location, ST_Point(127.02, 37.52), 1000)
ORDER BY distance_m;

GEOMETRY는 평면 좌표계(SRID 지정 가능), GEOGRAPHY는 구면 지구 기반 계산을 다룬다. WKB/WKT 형식 읽기·쓰기, Parquet 네이티브 지원이 포함된다.

이 기능이 중요한 이유는 PostGIS나 BigQuery GIS 없이 Spark SQL에서 공간 분석 파이프라인을 완결할 수 있게 됐다는 점이다. 물류, 리테일, 모빌리티처럼 위치 데이터를 다루는 팀에서 처리 엔진을 단순화할 수 있다.

4.1에서 4.2로 업그레이드할 때 확인 목록

Spark 4.2가 분산 데이터 플랫폼에서 갖는 의미

Spark 4.2는 기능 목록 이상의 의미가 있다. 이 릴리스는 "Spark를 AI 워크로드의 기반 처리 레이어로 쓴다"는 방향을 구체화한다.

벡터 검색은 RAG 파이프라인의 오프라인 인덱싱, 대규모 배치 추천 생성, 임베딩 기반 군집화 작업을 Spark 파이프라인 안에서 끝낼 수 있게 한다.

Metric Views는 AI 피처 스토어와 BI 대시보드가 같은 정의를 공유하는 거버넌스 레이어를 엔진 안에 만든다.

Auto CDC는 실시간 OLTP 데이터를 분석 레이크하우스로 가져오는 파이프라인의 구현 복잡도를 줄인다.

Arrow-first Python은 PySpark를 쓰는 ML 파이프라인의 처리 비용을 즉시 낮춘다.

동시에 한계도 명확하다. NEAREST BY는 HNSW 인덱스 기반 전용 벡터 DB보다 느리다. 실시간 사용자 검색에는 여전히 전용 벡터 DB가 맞다. Metric Views는 dbt 시맨틱 레이어나 Looker의 성숙한 생태계와 비교하면 아직 초기다.

이 릴리스를 "Spark 하나로 모든 것을 해결한다"는 신호로 읽기보다, "기존에 두 엔진이 필요했던 파이프라인 중 일부를 하나로 줄일 수 있는 경우가 생겼다"는 신호로 읽는 것이 맞다.

운영자 체크리스트

• 4.1 → 4.2 업그레이드 전에 Arrow 기본화 영향을 스테이징 환경에서 먼저 검증한다.
• Python UDF를 대량 사용하는 파이프라인은 toPandas() 결과와 UDF 반환 타입을 명시적으로 테스트한다.
• CHANGES OF 절을 쓰려면 소스 테이블이 Delta Lake, Iceberg, Hudi 중 하나여야 한다.
• NEAREST BY는 배치 ANN에 적합하다. 실시간 검색에는 전용 벡터 DB를 유지한다.
• 벡터 컬럼을 ARRAY<FLOAT> 타입으로 저장하면 4.2의 벡터 함수를 바로 쓸 수 있다.
• Metric Views는 기존 dbt 또는 BI 메트릭 레이어와 중복되지 않도록 도입 범위를 먼저 정한다.
• Real-Time Mode는 Stateless 스트리밍에만 적용된다. 상태 있는 스트리밍(집계, 조인)은 해당 없음.
• Spark 4.2부터 지리공간 타입이 기본 활성화된다. 기존 좌표 데이터를 마이그레이션하는 비용과 이점을 사전에 평가한다.

결론

Apache Spark 4.2는 분석 엔진에 AI 워크로드를 직접 통합하는 방향을 분명히 한 릴리스다. NEAREST BY와 벡터 함수, Metric Views, 네이티브 CDC, Arrow 기본화는 각각 독립적이지만, 합쳐서 보면 "Spark를 AI 시대의 데이터 처리 기반 레이어로 쓴다"는 전략이 보인다.

운영자 입장에서 가장 즉각적인 변화는 Arrow 기본화다. 업그레이드 즉시 PySpark 성능이 올라가지만, UDF와 타입 호환성을 먼저 검증해야 한다. 벡터 검색과 Metric Views는 기존 파이프라인을 단순화할 기회지만, 도입 범위와 전용 도구와의 역할 분담을 먼저 정해야 한다.

References

• Apache Spark, "Spark Release 4.2.0", 2026-07-14. https://spark.apache.org/releases/spark-release-4-2-0.html
• Databricks, "Introducing Apache Spark 4.2". https://www.databricks.com/blog/introducing-apache-spark-42
• Apache Spark Documentation, "Spark Declarative Pipelines Programming Guide". https://spark.apache.org/docs/latest/declarative-pipelines-programming-guide.html
• Apache Spark Documentation, "Spark Connect Overview". https://spark.apache.org/docs/latest/spark-connect-overview.html
• Apache Spark Documentation, "Geospatial (Geometry/Geography) Types". https://spark.apache.org/docs/4.2.0-preview4/sql-ref-geospatial-types.html
• Apache Spark, "Upgrading from PySpark 4.1 to 4.2". https://spark.apache.org/docs/latest/api/python/migration_guide/pyspark_upgrade.html
• The New Stack, "Spark 4.2 has a feature that could retire your vector database". https://thenewstack.io/spark-4-2-ai-workloads/
• Futurum Group, "Apache Spark 4.2: A Leap Forward for AI and Analytics Integration". https://futurumgroup.com/insights/apache-spark-42-a-leap-forward-for-ai-and-analytics-integration/
• Apache Spark, "Preview release of Spark 4.2.0". https://spark.apache.org/news/spark-4-2-0-preview4-released.html