20.1 스트림 처리란
연속형 애플리케이션(Continuous Processing)
- 기존의 Spark Streaming은 마이크로 배치 방식으로 동작, 그러나 저지연 처리가 필요한 애플리케이션에는 한계
- 나머지 컴포넌트와 쉽게 연동할 수 있어야 하여 '연속형 애플리케이션' 이란 개념을 추가
- 연속적인 데이터 처리를 가능하게 하기 위해 Spark 2.3에서 추가 됨
주요 특징
저지연 처리
- 밀리초 단위의 지연 시간을 제공
End-to-End Exactly-Once Semantics
- 데이터 소스에서 싱크까지 데이터를 중복 없이 정확히 한 번만 처리
통합된 API
- Structured Streaming API를 사용하여 "연속 처리 모드"와 기존 "마이크로 배치 모드"를 모두 지원
예제
trigger(processingTime="1 second")를 사용하여 연속 처리 모드 활성화
from pyspark.sql import SparkSession
from pyspark.sql.functions import expr
# SparkSession 생성
spark = SparkSession.builder.appName("ContinuousProcessingExample").getOrCreate()
# 스트리밍 데이터 소스 설정 (예: Kafka)
input_stream = spark.readStream.format("kafka") \
.option("kafka.bootstrap.servers", "localhost:9092") \
.option("subscribe", "input_topic") \
.load()
# 데이터 변환 예제
transformed_stream = input_stream.selectExpr("CAST(key AS STRING)", "CAST(value AS STRING)")
# 연속 처리 모드로 스트리밍 데이터 싱크 설정
query = transformed_stream.writeStream \
.format("console") \
.option("checkpointLocation", "/path/to/checkpoint/dir") \
.trigger(processingTime="1 second") \
.outputMode("append") \
.start()
query.awaitTermination()
스트림 활용 가능한 예시
- 통보와 알림
- 실시간 리포트
- 실시간 제공 데이터 갱신
- 실시간 의사 결정
- 증분형 ETL
스트림 처리의 장점
- 대기 시간이 짧음
- 자동으로 연산결과의 증분을 생성하므로 반복된 배치 작업보다 더 효율적
스트림 처리의 과제
- 순서가 보장된 값에 대해 이벤트를 지정할 때 쉽지 않음
- 예를 들어 2-10-5 의 순서로 들어온 경우에만 어떤 액션을 수행하고 싶을 때, 2,5에 대한 상태값을 유지해야 함
20.2 스트림 처리의 핵심 설계 개념
레코드 단위 처리 (Record-at-a-time Processing)
- 레코드 단위 처리는 각 레코드를 개별적으로 처리
- 레코드를 배치 단위로 묶어서 처리하는 기존의 마이크로 배치 방식과 구별 됨
선언형 API (Declarative API)
- 선언형 API는 개발자가 "무엇을" 하고 싶은지 기술하는 방식으로, "어떻게" 하는지를 신경 쓰지 않아도 되도록 설계된 API
- Spark SQL과 DataFrame API가 대표적인 예
이벤트 시간
- 원천 시스템에서 각 레코드에 기록한 타임스탬프 기반으로 데이터를 처리하는 방식
- 순서가 뒤섞이는 경우가 있으므로, 늦게 도착한 이벤트의 상태를 추적 함
처리 시간
스트리밍 애플리케이션에 레코드가 도착한 시간을 기반으로 처리하는 방식
증분 처리(Incremental Processing)
- 데이터가 도착할 때마다 이전에 처리된 상태를 기반으로 새로운 데이터를 증분 형태로 처리
- 예를 들어, 실시간 로그 분석에서 새로운 로그가 도착할 때마다 로그 집계 결과가 업데이트 됨
- 전체 데이터를 다시 계산하는 대신, 새로운 데이터만 처리하여 효율적으로 결과를 갱신
상태 저장(Stateful Processing)
- 구조적 스트리밍은 상태 저장(stateful) 연산을 지원
- 이전 연산 결과를 메모리에 저장하여 이후에 들어오는 데이터와 함께 사용
- 집계 연산, 윈도우 연산 등에서 상태 저장이 유용하게 사용
연속형 처리와 마이크로 배치 처리 차이
- 연속형 처리는 최대 처리량이 적음
- 연속형 처리는 고정형 연산 토폴로지를 사용해, 전체 시스템을 중지해야 변경 가능
- 마이크로 배치 처리는 노드당 더 높은 처리량을 얻음
- 마이크로 배치 처리는 부하 분산 기술을 동적으로 사용 가능
- 마이크로 배치 처리는 모으기 위한 시간이 필요하므로 기본적인 지연시간이 발생
20.3 스파크 스트리밍 API
DStream API
- 2016도에 가장 널리 쓰는 스트림 처리 엔진, 현재는?
- 제약사항 1 : 자바나 파이썬의 객체와 함수의 매우 의존적
- 제약사항 2 : 처리 시간을 기준으로 동작하여, 이벤트 처리 기준으로 처리하려면 자체적으로 구현
- 오래된 버전
구조적 스트리밍
- 고수준 연산 기반의 선언형 API를 기반으로 만들어짐 (DataFrame, Dataset)
- 이벤트 시간 데이터 처리를 지원
- 데이터가 도착 할 때마다 자동으로 증분 형태의 연산결과를 생성
'DataPipeline > Spark' 카테고리의 다른 글
Spark - Databricks를 통한 디버그 환경설정 (0) | 2024.10.26 |
---|---|
스파크완벽가이드 - 21장 구조적 스트리밍의 기초 (0) | 2024.08.18 |
스파크완벽가이드 - 18장 모니터링과 디버깅 (0) | 2024.08.18 |
스파크완벽가이드 - 17장 스파크 배포환경 (0) | 2024.08.18 |
스파크완벽가이드 - 16장 스파크 애플리케이션 개발하기 (0) | 2024.08.18 |