주요 컨텐츠로 이동
공학

Apache Spark® 4.3 소개 - Databricks Runtime 19에서 이제 사용하실 수 있습니다

상태 기반 실시간 처리, 이력 보존 파이프라인, 그리고 더 빠른 소규모 데이터 개발

작성자: 정택 임, Wenchen Fan, Andreas Neumann, Serge Rielau, Hyukjin Kwon, Jerry Peng, DB Tsai, Daniel Tenedorio, Xiao Li , Reynold Xin

  • 실시간 모드에 상태 도입: 실시간 모드는 스트리밍 집계, 중복 제거, 사용자 지정 상태 비저장 처리를 추가하여 익숙한 Structured Streaming API를 사용하는 세 가지 대표적인 벤치마크에서 150ms 미만의 P99 엔드투엔드 지연 시간을 달성합니다.
  • SCD Type 2 Auto CDC로 이력 보존: Python, SQL, Spark Connect를 통해 레코드의 시간에 따른 변화를 추적하여 보고, 감사, 이력 분석을 위한 이력 보존 파이프라인을 간소화합니다.
  • 더 빠른 반복 작업 및 풍부한 API로 구축: Project Feather는 대상이 되는 소규모 데이터 쿼리의 실행 오버헤드를 줄여주며, Spark Connect, Python, SQL의 개선 사항을 통해 데이터 및 AI 애플리케이션의 개발, 디버깅, 운영이 더욱 쉬워집니다.

소개

Apache Spark 4.3은 실시간 모드에 상태 저장(stateful) 처리를 도입하여, 대표적인 세 가지 상태 저장 벤치마크에서 150밀리초 미만의 P99 엔드투엔드 지연 시간을 달성했습니다. 이제 스트리밍 집계, 중복 제거, 그리고 사용자 지정 상태 저장 처리를 Structured Streaming의 저지연 실행 모드에서 실행할 수 있으며, 이를 통해 이벤트 간의 컨텍스트를 기억해야 하는 애플리케이션까지 지원 범위를 확장할 수 있습니다.

그 파급 효과는 더 빠른 파이프라인 그 이상입니다. 지원되는 워크로드의 경우, 밀리초 수준의 지연 시간을 달성하기 위해 별도의 스트리밍 엔진을 따로 구축할 필요가 없습니다. 사기(fraud) 탐지부터 실시간으로 업데이트되는 사용자 활동 및 기기 모니터링에 이르기까지, 개발자는 일괄(batch) 처리, 분석, AI에 사용하는 것과 동일한 오픈 엔진에서 익숙한 Structured Streaming API를 사용하여 상태 저장 애플리케이션을 구축할 수 있습니다.

상태 저장 실시간 스트리밍은 Spark 4.3의 핵심 기능이지만, 엔진 전반에 걸쳐 다양한 개선 사항이 적용되었습니다. 이번 릴리스의 다섯 가지 주요 이점은 다음과 같습니다.

  • 상태 저장 실시간 애플리케이션 구축: 실시간 모드에서 스트리밍 집계, 중복 제거, transformWithState을 사용하여 이벤트가 들어올 때 컨텍스트를 유지할 수 있습니다.
  • SCD Type 2 Auto CDC로 이력 보존: Python, SQL, Spark Connect를 사용하여 레코드가 시간에 따라 어떻게 변경되는지 추적하고, 사용자 지정 변경 처리 로직을 줄일 수 있습니다.
  • 소규모 데이터에 대한 빠른 반복 작업: Project Feather는 불필요한 실행 오버헤드를 줄이며, Arrow 네이티브 캐싱은 더 효율적인 데이터 재사용을 지원합니다.
  • 더 많은 애플리케이션을 Spark에 연결: Spark Connect 관측 가능성(observability), JDBC 통합, Python 개선을 통해 원격 실행의 개발과 운영이 더욱 쉬워집니다.
  • SQL로 더 풍부한 분석 표현: VARIANT 변환, JSON_TABLE, 임시(temporal) 조인, 나노초 타임스탬프 미리보기를 통해 중첩 데이터 및 시간 기반 데이터의 네이티브 처리가 확장됩니다.

이러한 변경 사항을 통해 개발자는 하나의 오픈 엔진을 사용하여 데이터를 탐색하고, 변경되는 컨텍스트를 유지하며, 분석 및 AI 애플리케이션을 구동할 수 있습니다.

또한 Spark 4.3은 분기별 기능 릴리스 주기의 시작을 알리며, 기존 6개월 주기를 3개월 주기로 단축했습니다. 이처럼 짧아진 주기를 통해 사용자는 완료된 개선 사항을 더 빨리 접할 수 있으며, 커뮤니티는 피드백을 제공하고 향후 방향을 형성할 수 있는 기회를 더 자주 가질 수 있습니다.

실시간 스트리밍: 밀리초 규모의 지연 시간을 갖춘 상태 저장 애플리케이션

이벤트 처리에서 컨텍스트 유지로

사기 징후는 최신 트랜잭션뿐만 아니라 그 이전에 발생한 활동에도 좌우됩니다. 개인화 기능은 사용자의 최근 행동을 반영해야 합니다. 기기 모니터링은 새로운 측정값이 도착함에 따라 카운터와 집계 값을 업데이트해야 합니다. 이러한 애플리케이션에는 낮은 지연 시간과 상태(state)가 모두 필요합니다.

Spark 4.3은 이러한 상태 저장 처리 패턴으로 실시간 모드를 확장하여 완전한 스트리밍 엔진으로 거듭났습니다. 스트리밍 집계, dropDuplicates, 그리고 Scala/Java transformWithState 지원이 추가되었습니다(SPARK-58635, SPARK-57228). 개발자는 더 낮은 지연 시간만을 위해 다른 엔진을 도입할 필요 없이, Structured Streaming의 기존 프로그래밍 모델을 사용하여 키가 지정된 상태(keyed state)를 유지하고 결과를 업데이트할 수 있습니다.

세 가지 상태 저장 벤치마크에서의 150 ms 미만 P99 지연 시간

SPARK-58884에 보고된 벤치마크에 따르면, 세 가지 대표적인 상태 저장 워크로드 모두에서 P99 엔드투엔드 지연 시간이 150밀리초 미만을 기록했습니다.

상태 저장 워크로드P99 엔드투엔드 지연 시간
dropDuplicates136 ms
Window aggregation139 ms
transformWithState141 ms

이 결과는 중복 제거, 윈도우 집계, 사용자 지정 상태 저장 처리 전반에 걸쳐 저지연 실행이 이루어짐을 보여줍니다. 이는 테스트된 세 가지 워크로드의 측정값이며, 모든 파이프라인에 대한 지연 시간을 보장하는 것은 아닙니다.

익숙한 API, 저지연 실행

실시간 모드는 별도의 프로그래밍 모델을 도입하는 대신 Structured Streaming을 기반으로 구축되었습니다. 상태 저장 연산자는 내구성과 복구를 위해 Spark의 기존 상태 저장소(state store) 및 체크포인팅 메커니즘을 계속 사용합니다.

예: 각 기기에 대한 누적 카운트를 유지합니다. device_id 열이 있는 Kafka 기반 스트리밍 DataFrame events이 주어졌을 때:

기기 A, A, B에 대한 이벤트가 도착하면 Spark는 상태를 유지하고 카운트를 A=2 및 B=1(으)로 업데이트합니다. A에 대한 다른 이벤트가 도착하면 해당 상태는 A=3(으)로 업데이트됩니다.

연속적인 데이터 흐름을 위해 구축된 실행 엔진

상태 저장 실시간 모드를 지원하려면 Spark가 단계를 예약하고 연결하는 방식을 근본적으로 변경해야 했습니다. 기존의 블로킹 셔플 방식에서는 다운스트림 단계가 시작되기 전에 프로듀서 단계가 완료되어야 합니다. 해당 모델은 장기 실행 스트리밍 작업 간의 연속적인 데이터 흐름을 지원할 수 없습니다.

Spark 4.3은 네이티브 동시 단계 스케줄링 및 파이프라인 셔플을 도입하여 프로듀서와 컨슈머 단계가 동시에 실행될 수 있도록 합니다(SPARK-54699, SPARK-58076, SPARK-56664). 스트리밍 셔플은 실시간 모드를 위해 이 기능을 구현하여, 전체 프로듀서 단계가 완료될 때까지 기다리는 대신 각 키를 담당하는 다운스트림 작업에 레코드를 점진적으로 전송합니다.

개념적으로 실행 방식은 다음과 같이 변경됩니다.

프로듀서 단계 → 셔플 구체화(materialize) → 컨슈머 단계

변경 후:

프로듀서 단계 ⇄ 스트리밍 셔플 ⇄ 컨슈머 단계

Spark 4.3은 프로듀서가 계속 실행되는 동안 컨슈머가 읽기를 시작할 수 있도록 하는 새로운 종류의 셔플 의존성인 PipelinedShuffleDependency을 추가합니다(SPARK-58185). 스케줄러는 이러한 의존성으로 연결된 단계를 파이프라인 그룹, 즉 조정된 스케줄링 단위로 취급합니다. 해당 단계들은 함께 스케줄링되며, 한 단계에서 오류가 발생하면 전체 그룹이 실패합니다(SPARK-58263, SPARK-58398). 즉, 함께 실행되고 함께 실패합니다.

파이프라인 그룹의 모든 단계가 동시에 실행되므로, Spark는 모든 작업에 충분한 작업 슬롯(task slot)을 사용할 수 있는 경우에만 그룹을 승인합니다. 그렇지 않으면 작업이 멈추는(hanging) 대신 빠르게 실패(fail fast) 처리합니다.

Spark는 의존성 유형에 따라 각 셔플을 셔플 매니저로 라우팅합니다.

  • 일반 ShuffleDependency은 블로킹 셔플 매니저를 사용하며, 다운스트림 단계가 읽기 전에 모든 셔플 출력을 구체화합니다. SortShuffleManager은 기본 제공 구현입니다.
  • PipelinedShuffleDependency은 파이프라인된 셔플 매니저를 사용하여, 출력이 생성되는 즉시 사용할 수 있도록 합니다. StreamingShuffleManager은 기본 제공 구현입니다(SPARK-57141).

종속성 유형은 실행 계약을 정의하고, 셔플 매니저는 데이터 전송 메커니즘을 제공합니다. 스케줄러는 어떤 워크로드에서 생성되었는지 알 필요 없이 파이프라인된 단계를 조정합니다.

이 기반은 실시간 모드(Real-Time Mode)를 넘어 확장됩니다. 동시 단계 스케줄링, 파이프라인된 데이터 교환, 그리고 조정된 실행은 일회성 스트리밍 인프라가 아니라 일반적인 Apache Spark 엔진 기능입니다. Spark 4.3에서는 이를 통해 저지연 상태 저장 처리가 가능해집니다. 장기적으로 볼 때, 이는 기존의 단계별(stage-at-a-time) 실행 모델을 넘어설 필요가 있는 다른 워크로드를 위한 기반을 제공합니다.

실시간 모드의 디자인 및 애플리케이션 시나리오에 대한 배경 지식은 실시간 모드 소개를 참조하세요. 해당 게시글은 Databricks 구현을 설명하며, 여기서 논의되는 Spark 4.3 기능 범위와 벤치마크 결과는 위에 나열된 내용입니다.

Project Feather: 소규모 데이터에서의 더 빠른 반복 작업

LLM 지원 개발은 대개 짧은 피드백 루프를 따릅니다. 변환을 생성하고, 샘플에서 실행하고, 결과를 검사하고, 코드를 개선하는 방식입니다. 각 반복은 단 몇 개의 행이나 작은 파일만을 처리할 수 있지만, 작업 스케줄링과 셔플링은 연산 자체보다 더 많은 비용이 들 수 있습니다.

Project Feather는 이러한 고정 실행 오버헤드를 목표로 하여, 소규모 데이터 세트에서 SQL 및 DataFrame 코드를 탐색하고 검증할 때 Spark의 응답 속도를 높여줍니다. 개발자는 코드를 직접 작성하든 AI 어시스턴트와 협업하든, 샘플에서 더 큰 워크로드로 이동할 때 동일한 API를 사용할 수 있습니다.

Spark 4.3은 자격을 갖춘 소규모의 단일 파티션 쿼리 조각을 위해 옵트인 방식의 셔플 없는 단일 작업 실행을 도입합니다(SPARK-57851). 자격을 갖춘 스캔이 출력이 이미 하나의 파티션에 있다고 보고하면, 지원되는 다운스트림 작업은 불필요한 셔플을 피할 수 있습니다.

예시: 작은 집계 작업을 실행하고 검사합니다. 카테고리 열이 포함된 단일 파일로 저장된 작은 Parquet 데이터 세트를 사용합니다:

6가지 사례:

category, Exchange, SPARK_LOCAL_CONNECT_REUSE=1, zip, counter_diff and jaro_winkler_similarity.

결과는 카테고리별 카운트입니다. 적격한 쿼리의 경우, 물리적 계획은 그렇지 않으면 셔플을 유발했을 `Exchange`를 생략할 수 있습니다. 이는 변환이 개발자에 의해 작성되었든 코딩 어시스턴트에 의해 제안되었든 관계없이 동일한 '실행 및 검사' 워크로드를 지원합니다.

기본 적격성 제한에 따라, 적격 파일 스캔은 단일 파티션에 맞는 비어 있지 않은 작은 파일 하나를 읽고, 적격한 로컬 인메모리 관계는 최대 1,000개의 행을 포함합니다. 지원되는 쿼리 형태에는 선택된 스캔, 집계, distinct 연산, 윈도우, 정렬, 그리고 limit이 포함됩니다.

Feather는 또한 선택 사항인 Arrow 네이티브 데이터 세트 캐싱(SPARK-57268)을 추가하여, 압축 및 열 통계가 포함된 Arrow 형식으로 캐시된 배치(batch)를 저장합니다. Arrow 기반 입력은 불필요한 변환을 방지하여 동일한 데이터를 반복해서 탐색하는 워크로드를 지원합니다. 단일 작업 최적화와 Arrow 캐시는 모두 옵트인 방식입니다. 이를 켜려면 새 Apache Spark 애플리케이션을 시작할 때 정적 설정 spark.sql.cache.serializer=org.apache.spark.sql.execution.columnar.ArrowCachedBatchSerializer을 설정하세요. 더 광범위한 프로세스 내 로컬 파티션 재조정은 다음 릴리스를 목표로 하는 후속 작업입니다(SPARK-57399).

이러한 개선 사항은 시작에 불과합니다. Apache Spark 커뮤니티는 향후 릴리스에서도 소규모 데이터 성능에 지속적으로 투자하여 실행 오버헤드를 줄이고 대화형 탐색 및 LLM 지원 개발을 위한 피드백 루프를 단축할 것입니다.

오픈소스 Auto CDC의 SCD Type 2: 데이터 변경에 따른 히스토리 보존

현재 상태 테이블은 고객이 현재 어디에 살고 있는지 알려줄 수는 있지만, 주문이 접수되었을 때 고객이 어느 지역에 속해 있었는지는 알려주지 못합니다. 보고, 감사, 그리고 이력 분석에는 종종 둘 다 필요합니다. Spark 4.3은 Auto CDC에 엔드투엔드 SCD(Slowly Changing Dimension) Type 2 지원을 추가하여(SPARK-56249), 파이프라인이 변경될 때마다 최신 값으로 덮어쓰는 대신 모든 레코드의 히스토리를 추적할 수 있도록 합니다. 이 기능은 Python, SQL, 그리고 Spark Connect를 통해 사용할 수 있으며(SPARK-58321, SPARK-58247, SPARK-58261), 사용자가 수동 병합 작업 대신 변경 사항을 자동으로 적용할 수 있게 해줍니다.

예시: 시간에 따른 고객 상태와 지역 추적. 고객 ID, 이벤트 시간, 상태, 그리고 지역이 포함된 customer_changes 파이프라인 소스가 주어졌을 때:

또는 이를 SQL로 표현할 수 있습니다:

SCD-2 출력 테이블에서 모든 고유 키는 일련의 레코드로 표현되며, 각 레코드는 두 개의 추가 메타데이터 열인 __START_AT과 __END_AT을 사용하여 유효 기간의 시작과 끝을 표시합니다. 예를 들어, 변경 레코드가 id가 17인 고객이 지역 West에서 East(으)로 이동했음을 나타내는 경우, 파이프라인은 이전 지역 West이 포함된 레코드를 유지하고 그 종료 시점을 변경 레코드의 이벤트 시간으로 표시합니다. 그리고 지역 East 및 해당 레코드의 이벤트 시간을 시작으로 하는 새 레코드를 삽입합니다. 그런 다음 분석에서는 이벤트 시간 시퀀스의 관련 시점에 적용되었던 지역을 사용할 수 있습니다.

내부적으로 Auto CDC는 선언적 플로우 정의를 대상 스키마 유도 및 전용 SCD Type 2 스트림 처리와 연결합니다(SPARK-58319, SPARK-57395, SPARK-58321). 키는 엔터티를 식별하고, 시퀀싱은 변경 순서를 결정하며, 히스토리 추적 열은 어떤 속성 변경이 히스토리 버전을 생성하는지 지정합니다. 또한 엔진은 예약된 열, 시퀀싱 유형, 그리고 히스토리 추적 구성을 검증하고(SPARK-57251, SPARK-58313, SPARK-58391), 더 좁은 마이크로배치를 진화된 대상 스키마와 조정합니다(SPARK-58418).

Auto CDC는 MERGE를 사용하여 각 마이크로배치를 대상에 적용하므로, 대상 테이블은 커넥터가 데이터 소스 V2(Data Source V2) 행 수준 작업을 구현하는 카탈로그에 있어야 합니다. Parquet을 포함하여 Apache Spark에 내장된 파일 형식은 이에 해당하지 않습니다. 따라서 흔히 선택되는 대안은 Iceberg입니다.

Spark Connect: 더 쉬운 개발, 모니터링, 그리고 운영

애플리케이션과 AI 에이전트는 자체 프로세스에서 Apache Spark를 호출하고, 세션을 관리하며, 실패한 요청을 서버에서 실행 중인 작업과 연결해야 합니다. Spark 4.3은 세션 및 작업 가시성, 요청 어트리뷰션, 그리고 더 광범위한 클라이언트 지원을 통해 이러한 워크로드를 위한 Spark Connect를 강화합니다.

Spark Connect는 DataFrame 연산을 gRPC를 통해 논리적 계획(logical plan)으로 전송하고, 서버의 Spark 엔진을 통해 실행하며, Arrow 배치로 결과를 다시 스트리밍합니다. Spark 4.3에는 Connect 세션과 연산을 나열하고 검사하기 위한 REST 엔드포인트가 추가되었으며, 클라이언트와 서버 간의 실행을 추적하기 위한 연산 ID도 함께 추가되었습니다(SPARK-57941, SPARK-58547). POSIX 시스템에서의 로컬 PySpark 개발을 위해, 실험적 기능인 `SPARK_LOCAL_CONNECT_REUSE=1` 옵션은 실행 간에 지속적인 Connect 서버를 재사용하여 반복적인 시작 오버헤드를 방지합니다(SPARK-57787). PySpark의 SQLContext 호환성 래퍼(wrapper)도 Spark Connect와 함께 작동합니다(SPARK-57021).

Spark Connect JDBC 드라이버는 ARRAY, MAP 및 STRUCT 결과 지원과 더 풍부한 결과 세트 처리를 추가하고(SPARK-57380, SPARK-57274), SQL 타입 메타데이터 및 더 호환성이 뛰어난 스키마 검사 기능을 제공하며(SPARK-57627), 예외 처리를 개선했습니다(SPARK-57933, SPARK-58619). API 범위가 DataFrame.zip, SCD Type 2 Auto CDC, 나노초 타임스탬프 타입 및 리터럴로 확장되었습니다(SPARK-57247, SPARK-58247, SPARK-57160, SPARK-57161).

별도로, 커뮤니티 작업에는 세션 인식 라우팅 및 멀티테넌트 연산을 위한 Spark Connect Gateway(SPARK-58455), 또 다른 클라이언트 구현 경로인 Rust 및 Rust 기반 Python 클라이언트(SPARK-58960), 그리고 쿼리를 제출하기 전에 지원되는 서버 연산을 식별하기 위한 기능 검색 제안(SPARK-56398)이 포함됩니다. 이러한 노력들은 별도의 개발 일정으로 진행되며 4.3 기능에 기본 포함되지 않습니다.

PySpark: 향상된 API와 개선된 Python 실행

Python 워크플로는 종종 별도의 단계에서 파생 열(derived column)을 구축하고, 결과를 결합하며, pandas, Arrow 및 Spark 간에 데이터를 이동합니다. Spark 4.3은 하위 실행 경로를 개선하는 동시에 DataFrame API를 통해 이러한 작업을 더 많이 수행할 수 있도록 합니다. DataFrame.zip는 Spark Connect를 사용할 때를 포함하여 RDD API로 전환하지 않고도 호환되는 열 프로젝션을 결합하는 방법을 제공합니다(SPARK-55886, SPARK-57247).

예제: 식별자를 파생 값과 결합합니다. 동일한 입력에서 두 개의 프로젝션을 생성하고 해당 열들을 결합합니다:

결과는 id=1와(과) doubled=20, 그리고 id=2와(과) doubled=40을(를) 쌍으로 연결합니다. `zip`은 동일한 기본 계획의 프로젝션 전용 변환을 결합합니다. 행 정렬을 유지하려면 해당 프로젝션 아래의 필터링, 정렬, 조인 또는 집계는 양쪽 모두에서 동일해야 합니다.

광범위한 실행 작업은 데이터 전송, 일괄 처리(batching) 및 네이티브 연산을 대상으로 합니다. Pickle 기반 UDF 입력 배치는 행 수뿐만 아니라 바이트 단위로 제한될 수 있으므로, 행 크기가 다양할 때 더 나은 제어가 가능합니다(SPARK-57593). 일괄 처리된 pandas-on-Spark 프로젝션 및 추가적인 네이티브 NumPy 구현은 불필요한 작업을 줄이고(SPARK-58230, SPARK-58234), pandas-to-Spark 변환은 PyArrow ChunkedArray 열에 대한 지원을 추가합니다(SPARK-46776).

또한 이번 릴리스에는 기존 벡터 함수에 대한 Python 및 Scala 바인딩(SPARK-57284), 그룹화된 공분산 및 기술 통계(SPARK-40336, SPARK-40337), 롤링 및 확장 중앙값 및 표준 오차 연산(SPARK-40341, SPARK-40340), 그리고 show_versions 진단 기능이 추가되었습니다(SPARK-40373). 트레이스백(traceback) 로컬 변수는 민감한 데이터를 포함할 수 있으므로 옵트인(opt-in) 방식으로 제공됩니다(SPARK-57271).

Spark SQL: 분석 및 AI를 위한 더 나은 컨텍스트 준비

이벤트 페이로드는 중첩된 문서로 도착하며, 간격이 매우 짧은 이벤트는 마이크로초보다 더 높은 정밀도를 요구할 수 있습니다. 이러한 입력을 준비하는 데 모든 변환마다 별도의 사용자 정의 처리 계층이 필요해서는 안 됩니다. Spark 4.3은 문서 조작, 시간적 매칭, 옵트인 나노초 타임스탬프 미리보기 등 반정형 데이터 및 시계열 분석을 위한 네이티브 SQL을 확장합니다(SPARK-56822).

예제: 동일한 마이크로초 내의 두 이벤트를 구분합니다. 미리보기를 활성화하고(아직 안정적인 기능이 아니며 호환성이 깨지는 변경이 발생할 수 있음) 1나노초 차이의 타임스탬프를 비교합니다(SPARK-56969, SPARK-56965, SPARK-57211):

비교 결과는 true(으)로 평가됩니다. 마지막 자릿수가 버려지지 않고 유지됩니다. 미리보기 기능은 7부터 9까지의 정밀도에서 TIMESTAMP_NTZ(p) 및 TIMESTAMP_LTZ(p)을(를) 지원합니다.

이는 단순히 새로운 SQL 타입 이름을 수락하는 것 이상의 작업을 필요로 했습니다. 나노초 지원은 구문 분석, 내부 값 표현, 캐스트(cast), 표현식, Spark Connect, 캐싱, 데이터 소스 통합 전반으로 확장됩니다(SPARK-56822). 새로운 timestamp_nanos 및 unix_nanos 함수는 숫자 변환을 처리합니다(SPARK-57526, SPARK-57527). 스토리지 및 커넥터 지원은 각 데이터 경로에 따라 다르므로, 미리보기는 엔드투엔드로 평가되어야 합니다.

변경되는 JSON 페이로드를 유용한 데이터로 변환하기

애플리케이션 이벤트, 문서 내보내기, 모델 응답은 종종 중첩된 JSON 형태로 들어옵니다. Spark 4.3의 JSON_TABLE (SPARK-58366)은 배열 확장과 형식화된 필드 추출을 결합하는 반면, VARIANT 변환을 사용하면 파이프라인이 사용자 지정 문서 처리 UDF 없이도 필드를 업데이트하거나 제거할 수 있습니다(SPARK-57804, SPARK-57417). 두 기능을 함께 사용하면 분석, 보강, 검색 파이프라인을 위한 콘텐츠 준비 과정이 훨씬 간단해집니다.

예시: 관련 문서 섹션을 추출합니다.

이렇게 하면 파이프라인이 다른 다운스트림 작업을 수행하기 전에 소스 메타데이터로 보강할 수 있는 형식화된 행이 생성됩니다. JSON_TABLE은 각 행 항목의 공유 순회를 통해 열 경로를 해결하므로 모든 열에 대해 별도의 구문 분석을 수행할지 않아도 됩니다. 또한 Spark는 집계, 정렬, 조인을 수행하는 지원되는 쿼리로 VARIANT 필드 추출 푸시다운을 확장합니다(SPARK-58089).

후속 SQL/JSON 작업(SPARK-58686)은 스칼라 추출, 존재 여부 확인, 조각 검색을 위한 JSON_VALUE, JSON_EXISTS, JSON_QUERY를 도입하여 이러한 방향성을 확장합니다(SPARK-58685, SPARK-58687, SPARK-58723). 명시적인 누락 값 및 오류 처리를 통해 애플리케이션은 변경되는 스키마를 더 예측 가능하게 처리할 수 있습니다. 이는 추가적인 4.3 기능이 아니라 후속 개발 사항입니다.

이벤트 발생 당시의 정보와 이벤트 매칭

과거 분석과 모델 평가는 나중에 추가된 정보가 아니라 이벤트가 발생했을 때의 컨텍스트가 필요합니다. Spark 4.3의 SQL ASOF JOIN은 (미리 보기 기능으로, 호환성이 깨지는 변경이 발생할 수 있음) 수동으로 작성한 범위 조인 뒤에 순위를 매기는 방식을 대신하여 이러한 시간적 일치를 직접 표현합니다(SPARK-58092).

예시: 예측에 사용할 수 있는 피처를 재구성합니다. 여기서 available_at는 피처 버전이 사용 가능해진 시점을 기록합니다(SPARK-58122, SPARK-58123):

10시 3분에 수행된 예측은 10시 5분이 아니라 10시에 사용 가능했던 피처 버전과 일치합니다. 전용 정렬-병합 실행 경로를 사용하면 이러한 매칭이 애플리케이션별 쿼리 로직이 아니라 엔진 작업으로 처리됩니다. 가용성 타임스탬프가 당시의 상황을 정확히 반영한다는 가정 하에, 학습 데이터, 평가, 인시던트 분석을 위한 시점 기반 데이터 보강이 훨씬 간단해집니다.

주요 개선 사항 및 감사의 말씀

Spark 4.3에서는 일상적인 데이터 처리를 위한 새로운 API와 성능 개선 사항도 도입되었습니다. SQL에는 배열을 행으로 확장하는 ANSI UNNEST, 누적 카운터를 델타로 변환하는 `counter_diff` 윈도우 함수, 문자열 유사도를 비교하는 `jaro_winkler_similarity`가 추가되었습니다. 지원되는 파일 소스에 tar, zip, 7z 아카이브 읽기에 대한 옵트인 지원이 추가되어 별도의 추출 단계가 필요 없어졌습니다. 엔진은 집계 실행을 개선하고 적격한 UNION 작업에 대해 전체 단계 코드 생성을 기본적으로 활성화합니다. 옵트인 최적화를 통해 적격한 외부 조인 및 안티 조인의 셔플 파티션에 null 조인 키가 분산됩니다. 중첩 데이터 처리 시 구조체 배열 내의 사용되지 않는 필드에 대한 프루닝이 향상되었고, 더 많은 배열 고차 함수에 대한 코드 생성이 추가되었습니다. 벡터화된 Parquet 읽기를 통해 타입 변환과 사전 디코딩이 개선되었습니다.

Spark 4.3은 Apache Spark 커뮤니티의 저력을 보여주며, 200명이 넘는 기여자분이 1,100개가 넘는 Jira 티켓을 해결하는 데 도움을 주셨습니다. 이번 릴리스를 가능하게 해주신 코드 기여, 리뷰, 테스트, 문서화, 피드백을 제공해 주신 모든 분께 감사드립니다.

image1.png

Spark 4.3 시작하기

릴리스 다운로드 및 문서를 보려면 Apache Spark 다운로드 페이지를 방문하시고, 업그레이드하기 전에 마이그레이션 가이드를 확인하세요. Databricks 가용성에 대해서는 Databricks Runtime 릴리스 노트를 참고하세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)

관련 태그:

오픈 소스

최신 게시물을 이메일로 받아보세요

블로그를 구독하고 최신 게시물을 이메일로 받아보세요.