이벤트에서 인사이트까지: transformWithState의 스키마 변화를 통한 복잡한 상태 처리

산업 전반에서 데이터 엔지니어링의 가장 지속적인 과제 중 하나는 스키마 변화입니다. 비즈니스 요구 사항이 바뀌고, 데이터 소스가 변경되며, 새로운 이벤트 필드가 하룻밤 사이에 나타나기 때문에 데이터 엔지니어링 팀은 시스템을 계속 실행하기 위해 파이프라인과 상태 저장소를 지속적으로 조정해야 합니다.

기존 스트리밍 방식은 스키마가 변경되면 고장이 납니다. 상태 저장소가 호환되지 않고 파이프라인이 실패합니다. 팀은 스키마 마이그레이션을 위해 과거 데이터를 잃거나 값비싼 다운타임을 경험해야 하는 선택의 기로에 서게 됩니다. 이는 단순한 기술적 문제가 아니라 비즈니스 민첩성을 저해하는 장애물입니다. 

Apache Spark™ 4.0은 상태 저장 스트리밍에서 스키마 변화를 가능하게 할 뿐만 아니라 원활하게 해주는 획기적인 API인 transformWithStateInPandas를 도입했습니다. 지능형 상태 관리와 자동 스키마 호환성을 통해 스트리밍 애플리케이션은 중요한 상태 정보를 보존하면서 비즈니스 요구 사항에 따라 발전할 수 있습니다.

이 게시물은 transformWithState 시리즈의 네 번째이자 최신 글입니다: 

• 새로운 API의 설계 원칙과 아키텍처에 대해 자세히 알아보는 Apache Spark용 transformWithState™ 구조화된 스트리밍을 소개합니다.
• Spark에서 임의 상태 저장 Stream 처리의 진화에서는 transformWithStateInPandas의 고유한 이점을 살펴봅니다.
• 새로운 transformWithState API를 사용한 지속적인 환경 모니터링, 환경 IoT 사용 사례에 transformWithState를 적용한 실제 사례입니다.

이 블로그에서는 transformWithState API가 어떻게 실시간 워크로드를 위한 고급 상태 저장 처리를 가능하게 하여 IoT 모니터링에서 실시간 세션 분석에 이르는 사용 사례를 지원하는지 소개합니다. 

Spark Streaming의 스키마 변화 과제 

스테이트풀 Spark Streaming에서 스키마를 진화시키면 상당한 운영상의 마찰이 발생합니다.applyInPandasWithState와 세션_윈도우 같은 기존 접근 방식에서는 스키마 메타데이터가 구워진 상태로 상태가 직렬화되어 데이터 구조와 지속 상태 간에 엄격한 결합이 이루어집니다.

필드 추가, 유형 변경, 열 재정렬 등 스키마를 수정하면 기존 상태가 새로 들어오는 데이터와 호환되지 않게 됩니다. 스키마 불일치로 인해 역직렬화 실패가 발생하여 수동 해결 방법을 사용해야 합니다:

• 상태 비호환성:이전 상태는 새 스키마 구조와 조정할 수 없습니다.
• 수동 마이그레이션: 개발자는 스키마를 연결하기 위해 사용자 지정 변환 로직을 작성해야 합니다.
• 필수 다운타임: 스키마 변경으로 인해 Stream을 중단하고, 상태를 오프라인으로 마이그레이션한 후 다시 시작해야 합니다.
• 데이터 손실 위험: 마이그레이션 중 기록 상태가 손상되거나 손실될 수 있습니다.
• 버전 관리 오버헤드: 여러 스키마 버전을 지원하려면 광범위한 상용구 코드가 필요합니다.

스키마 변화를 위해 트랜스폼위드스테이트인판다스 (TWS)가 필요한이유

Spark는 기본 세션화를 위한 세션_윈도우와 사용자 정의 상태 저장 처리를 위한 applyInPandasWithState와 같은 검증된 솔루션을 제공하지만, 진화하는 비즈니스 요구 사항에 따라 원활한 스키마 변화를 위한 추가적인 유연성이 필요한 경우가 많습니다. transformWithStateInPandas는 이러한 기반을 바탕으로 데이터와 비즈니스 로직을 지속적으로 발전시켜야 하는 시나리오를 구체적으로 해결합니다.

다음은 transformWithStateInPandas가 스키마 변화에 이상적인이유입니다 :

• 자동 스키마 호환성: 필드 추가, 유형 확대, 열 재정렬 등 기존 상태는 새 스키마 버전과 원활하게 통합됩니다.
• 진화 중 상태 보존: 스키마가 변경되어도 데이터 손실이 없으며, 과거 상태는 계속 액세스 가능하고 가치 있게 유지됩니다.
• 다운타임을 최소화하는 진화: 스키마 변경은 서비스 중단을 최소화하면서 배포됩니다.

시나리오 심층 분석

실시간으로 고객 여정 재구성하기

여러분이 빠르게 성장하는 온라인 소매 플랫폼인 "StreamShop(" )의 데이터 엔지니어링 팀의 일원이라고 가정해 보겠습니다. 월요일 아침, CEO가 전환율에서 경쟁사보다 앞선다는 경쟁사 분석 결과를 출력한 출력물을 들고 엔지니어링 회의실로 들어왔습니다. 마케팅 팀에서 답을 요구하고 있습니다:

"수백만 달러를 광고에 지출하고 있지만 사용자들은 어디로 이탈하고 있을까요?" "실제로 구매로 이어지는 고객 경로는 무엇인가요?" "사용자가 지금 무엇을 하고 있는지에 따라 경험을 개인화할 수 있나요?"

이는 개별적인 이벤트에 대한 질문이 아니라 사용자가 클릭하고, 탐색하고, 장바구니에 상품을 추가하고, 구매하거나 포기할 때 전개되는 사용자 여정, 연결된 순서 및 행동 스토리에 대한 질문입니다. 이러한 여정은 세션으로 진행됩니다.

웹 및 모바일 앱의 클릭스트림 데이터가 Apache™ Kafka를 통해 유입됩니다. 모든 페이지 조회, 클릭, '장바구니 담기'를 스트리밍 파이프라인이 추적하고, 정의된 스키마를 사용하여 세션화하며, flatMapGroupsWithState를 사용하여 레코드를 저장합니다.  하지만 이제 새로운 과제가 생겼습니다. 바로 지난주에 모바일팀이 데이터팀에 알리지 않고 device_type 및 page_category 와 같은 추가 필드를 보내는 새 버전을 배포했습니다.

현재 사용 중인 창형 집계 솔루션은 이 시나리오를 기본적으로 지원하지 않으므로 파이프라인을 중지하고 스키마를 수정한 다음 체크포인트를 reset해야 합니다. 스키마가 변경될 때마다 이 운영을 수행해야 하므로 비실용적입니다. 보다 강력하고 유연하며 스키마 변화를 투명하게 처리할 수 있는 솔루션이 필요합니다.

기초: 스키마 변화를 통한 지능형 세션 구축

세션 진화 이해

클릭스트림 이벤트는 세션 ID, 사용자 ID, timestamp, 이벤트 유형 등 기본 V1 스키마로 간단하게 시작할 수 있습니다. 하지만 StreamShop이 발전함에 따라 이벤트도 진화하고 있습니다. 이제 디바이스 유형, 페이지 카테고리, 매출 금액과 같은 커머스 관련 데이터 등 풍부한 컨텍스트 정보가 포함된 V2 이벤트를 수신할 수 있습니다.

문제는 단순히 두 개의 스키마를 처리하는 것이 아니라 기존 상태를 잃거나 다시 시작하지 않고 발전시키는 것입니다. 세션화 로직은 세션 연속성을 유지하면서 이러한 변화를 정상적으로 처리해야 합니다.

transformWithStateInPandas 스키마 변화 :

스테이트 스토어에서 스키마 변화란 무엇인가요?

스키마 변화란 스트리밍 query가 상태 정보를 잃거나 기록 데이터를 완전히 재처리할 필요 없이 데이터의 상태 저장소 스키마 변경을 처리할 수 있는 기능을 말합니다. transformWithStateInPandas의 경우, 이는 기존 세션 상태를 유지하면서 쿼리 버전 간에 상태 변수 스키마를 수정할 수 있음을 의미합니다. 아래에서 구현을 살펴보겠습니다.

세션라이저 구현

이 예제에서는 고급 세션 처리를 위해 두 개의 사용자 정의 클래스인 SessionizerV1과 SessionizerV2를 만들었습니다. 이 두 클래스는transformWithStateInPandas가 기본 지표 추적뿐만 아니라 각 사용자 여정의 컨텍스트와 진화를 이해하는 데어떻게 도움이 되는지보여줍니다.

V1 프로세서: 재단

세션을 위한 기본 스키마를 설정하여 이벤트_수,총_수익과같은 사용자 지정 값을 추적하도록 세션라이저 V1에서 설정했습니다. 

V2 프로세서: 진화한 스키마 정의하기

V2는 자동 스키마 변화의 진정한 강점을 보여줍니다. 프로세서 V2에서는 두 개의 새로운 열을 추가하고 기존 열(event_count)의 유형을 확장했으며, 이는 기본 상태 저장소에서 원활하게 업데이트됩니다. 

기존의 창 기반 세션화와 달리 transformWithStateInPandas 세션화 도구는 참여 패턴, 상거래 행동, 심지어 사용한 스키마 버전까지 포함하여 각 사용자의 여정에 대한 풍부한 컨텍스트를 유지하는 데 도움이 될 수 있습니다.

상태 스키마 진화:

• 유형 확대: event_count의 경우 정수형 → 긴 유형 (자동 변환)
• 새 필드: 장치 유형 및 페이지 카테고리 (진화한 V1 상태의 경우 없음으로 표시됨)
• 동일한 상태 변수: "세션_상태" 이름 사용 시 자동 진화 가능
• 필드 순서: 호환성을 위해 마지막에 새 필드 추가

스키마 변화를 통한 이벤트 처리

handleInputRows 메서드는 V2가 새로운 V2 이벤트와 진화한 V1 상태를 모두 지능적으로 처리하는 방법을 보여줍니다:

스키마 변화 마스터하기: 기술 심층 분석

스키마 변화 과제에 대한 이해

최신 세션화의 진정한 복잡성은 단순히 이벤트를 그룹화하는 것이 아니라 시간에 따른 이벤트의 진화를 처리하는 것입니다. 스트림샵에서는 웹 플랫폼이 여전히 원래 스키마를 사용하는 동안 모바일 앱 업데이트가 향상된 데이터를 전송하기 시작하면서 이 문제가 중요해졌습니다.

스키마 변화는 실제로 어떤 모습일까요?

V1 이벤트(원본 스키마):

V2 이벤트(향상된 스키마):

전체 파이프라인 구성

V2는 동일한 체크포인트 위치를 사용하여 마지막으로 커밋된 오프셋부터 V1의 상태 저장소 스키마를 원활하게 계속 처리하므로 데이터를 재처리하지 않고도 스키마를 진화시킬 수 있습니다.

데이터브릭스가 스키마 진화를 자동으로 처리하는 방법

V2 프로세서가 V1 상태를 읽으면 자동으로 마법이 일어납니다. 데이터브릭스는 이러한 변환을 백그라운드에서 수행합니다:

1. 활자 넓히기(자동)

2. 필드 추가(자동)

3. 진화 감지(당사 로직)

비즈니스 영향: 결과 스토리

스키마 변화의 실제 모습 보기

세션화 파이프라인을 배포한 결과 스키마가 성공적으로 진화한 것으로 나타났습니다. 이렇게 진행됩니다:

V1 결과 - 기본 스키마가 있는 초기 세션입니다:

• 터미널 이벤트(구매/로그아웃)로 세션_2 및 세션_4 완료
• 세션_1, 세션_3, 세션_5, 세션_6은 비종료 이벤트(페이지_보기)로 활성 상태로 유지됩니다.
• 상태는 세션 1, 3, 5, 6에 대해 지속됩니다.

Delta 출력:

V1 세션화 출력:

스테이트스토어를 검사합니다:

V2 세션화 출력:

레코드 상태 스키마 버전 V2 읽기 - 진화한 스키마로 세션이 개선되었습니다:

• 진화한 V1 상태 + 새로운 V2 필드를 사용하여 세션_1 완료
• evolved_from_v1: true는 성공적인 스키마 변화를 확인합니다.
• 향상된 컨텍스트: 기기 유형(모바일, 데스크톱, 태블릿), 페이지 카테고리(결제, 프로필, 제품)
• 이벤트 누적: 총 3개의 이벤트, $50 수익.
• 상태 연속성을 유지하면서 V1에서 V2 프로세서로의 깔끔한 마이그레이션을 시연합니다.

스키마 변화 분석:

실제 스키마 변화 성공

핵심 인사이트: V2의 세션 1은 evolved_from_v1: true를 보여주기 때문입니다:

1. V1(페이지_보기)에서 비종료 이벤트가 발생 → 상태가 지속되었습니다.
2. V2 프로세서가 V1 상태를 읽을 때 새 필드에서 없음 값을 자동으로 감지했습니다.
3. 데이터브릭은 V1 상태(5개 필드)를 V2 상태(7개 필드)로 원활하게 변환했습니다.
4. 유형 확장(정수형 → 긴 유형)이 자동으로 발생했습니다.
5. V2 이벤트에서 채워진 새 필드(device_type, page_category)
6. 누적 이벤트 3개로 세션 완료, 성공적인 상태 연속성 입증

필수 구성

스키마 변화는 Spark 구성의 조합에서만 지원됩니다 . 

1. Avro 인코딩(필수)

2. RocksDB 상태 저장소(필수)

스키마 변화의 비즈니스 가치

스키마 변화를 통해 조직은 일상 운영에 지장을 주지 않으면서 새로운 기능과 인사이트를 추가할 수 있습니다. 이러한 유연성을 통해 기업은 지속적으로 개선하고 더 빠르게 혁신하며 경쟁력을 유지할 수 있습니다.

• 배포 간 다운타임 최소화: 다운타임을 최소화하면서 새로운 데이터 필드 또는 추적 기능을 도입할 수 있습니다. 고객과 내부 팀은 중단 없는 서비스를 경험하고, 비즈니스는 더 풍부한 인사이트를 얻을 수 있습니다.
• 점진적 롤아웃: 스키마 변경을 점진적으로 도입하여 위험을 줄이고 팀과 시스템 전반에서 보다 원활하게 적용할 수 있습니다. 비즈니스 리더는 한꺼번에 대규모로 commit할 필요 없이 새로운 기능을 테스트하고 검증할 수 있습니다.
• 기록 연속성: 조직은 기존 세션 상태와 기록 컨텍스트를 유지하여 비용이 많이 드는 데이터 재처리를 피할 수 있습니다. 이를 통해 과거와 현재를 원활하게 파악할 수 있어 의사 결정권자가 장기적인 트렌드와 인사이트를 활용할 수 있습니다.
• 분석 연속성: 플랫폼이 진화하더라도 일관된 메트릭이 유지됩니다. 이러한 안정성을 통해 경영진과 애널리스트는 데이터나 보고 불일치에 대해 걱정할 필요 없이 의사 결정에 집중할 수 있습니다.

궁극적으로 상태를 보존하면서 스키마를 발전시킬 수 있는 능력은 기업이 실시간 분석에 접근하는 방식을 변화시킵니다. 혁신과 운영의 우수성을 함께 보장하여 서비스 타격을 최소화하거나 전혀 없이 지속적인 성장을 지원합니다.

결론

Apache Spark™ 4.0의 transformWithState API는 단순한 기술 업그레이드가 아니라 실시간 고객 분석 구축 방식의 전환을 의미합니다.

StreamShop에서는 팀 전체에 대한 실시간 가시성을 강화했습니다:

• 실시간으로 고객 여정을 추적하는 마케팅
• 몇 시간 내에 제품 기능 영향 측정
• 엔지니어링은 상태 투명성을 통해 심층적인 시스템 인사이트를 얻습니다.

기본 내장된 스키마 변화 기능을 통해 세션화 파이프라인은 비즈니스의 발전에 따라 자동으로 조정되어 새로운 이벤트, 플랫폼, 터치포인트가 원활하게 처리됩니다.

여정, 참여, 전환 퍼널을 추적하든, 트랜스폼위드스테이트인판다스는 원시 이벤트를 실행 가능한 인사이트로 전환하여 성장을 촉진하는 지속적인 고객 이해를 구축합니다.

이 포스팅에서는 이 API가 어떻게 IoT 및 세션 기반 분석 사용 사례 전반에서 확장 가능한 상태 저장 처리를 가능하게 하는지를 강조하면서 transformWithState 시리즈를 마무리합니다.

관련 리소스

• Spark Structured Streaming 프로그래밍 가이드
• 상태 저장 애플리케이션 스키마 변화
• 스테이트풀 파이프라인의 성능 개선
• 깃허브 리포지토리

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