Spark Streaming (r1)

DStream은 Spark Streaming의 핵심 추상화 개념으로, 연속적인 실시간 데이터 스트림을 일정한 시간 간격으로 나눈 일련의 RDD로 표현한다. 이는 연속적인 데이터 흐름을 일련의 작은 배치 데이터로 '이산화'한다는 의미에서 'Discretized Stream'이라는 이름이 붙었다. DStream은 내부적으로 일련의 RDD로 구성되며, 각 RDD는 특정 배치 간격 동안 수집된 데이터를 담고 있어, 사용자는 마치 정적 데이터를 다루듯이 스트림 데이터에 대해 변환과 액션을 적용할 수 있다.

DStream은 Spark Core의 RDD API와 매우 유사한 고수준 API를 제공한다. 사용자는 map, reduce, join, filter와 같은 익숙한 변환 연산을 DStream에 적용할 수 있으며, 이러한 연산은 내부의 각 RDD에 자동으로 적용된다. 이는 기존 배치 처리 애플리케이션을 가진 개발자가 비교적 쉽게 스트림 처리 애플리케이션으로 전환할 수 있게 해주는 주요 장점이다. 또한 DStream은 윈도우 연산을 지원하여, 과거 일정 시간 동안의 데이터를 집계하는 슬라이딩 윈도우 기반 처리를 구현할 수 있다.

DStream의 생성은 StreamingContext를 통해 이루어진다. 주요 데이터 소스로는 Kafka, Flume, HDFS, TCP 소켓 등이 있으며, 이러한 소스로부터 데이터를 수신하여 DStream 객체를 생성한다. 생성된 DStream은 변환 체인을 통해 처리되고, 최종적으로 출력 액션을 통해 결과를 외부 시스템에 저장하거나 표시한다. DStream의 처리 모델은 마이크로 배치 처리에 기반하여, 설정된 배치 간격마다 새로운 RDD를 생성하고 Spark 엔진에 의해 작업으로 스케줄링되어 실행된다.

이러한 DStream 기반의 마이크로 배치 아키텍처는 강력한 장애 복구 메커니즘과 확장성을 제공한다. 각 RDD의 계보 정보를 통해 체크포인트와 함께 데이터 손실 없이 장애를 복구할 수 있으며, Spark 클러스터의 리소스를 동적으로 활용하여 처리량을 조절할 수 있다. 그러나 이 모델은 연속 처리 모델에 비해 기본적인 처리 지연이 존재한다는 한계를 가지며, 이는 후속 모델인 Structured Streaming에서 개선되었다.

Spark Streaming의 핵심 처리 모델은 마이크로 배치 처리이다. 이는 연속적인 스트림 처리 데이터를 매우 짧은 간격으로 나눈 작은 배치 처리 단위로 처리하는 방식을 의미한다. 사용자가 설정한 배치 간격(예: 1초, 2초)마다 Spark 엔진은 해당 시간 동안 도착한 데이터를 하나의 RDD로 묶어 새로운 배치 작업을 생성하고, 이를 Spark Core의 분산 처리 인프라를 통해 실행한다.

이러한 접근 방식은 순수한 이벤트 기반 처리에 비해 지연 시간이 다소 길 수 있지만, Spark의 기존 배치 처리 엔진과 동일한 API와 장애 복구 메커니즘을 그대로 활용할 수 있는 장점이 있다. 결과적으로 개발자는 일관된 프로그래밍 모델로 배치 애플리케이션과 스트리밍 애플리케이션을 통합하여 작성할 수 있으며, 시스템의 복잡성을 크게 줄일 수 있다.

마이크로 배치 처리의 성능과 지연 시간은 배치 간격 설정에 직접적으로 영향을 받는다. 더 짧은 간격은 더 낮은 지연을 제공하지만, 작업 스케줄링 오버헤드가 증가할 수 있다. 반면, 더 긴 간격은 처리량을 높일 수 있지만 실시간성은 감소한다. 따라서 애플리케이션의 요구사항에 따라 처리 지연과 처리량 사이의 최적의 균형점을 찾는 것이 중요하다.

Spark Streaming에서 외부 데이터 소스로부터 데이터를 수집하는 방식은 크게 리시버 기반 접근 방식과 다이렉트 접근 방식으로 구분된다. 이 두 방식은 데이터 수신의 신뢰성, 성능, 장애 복구 메커니즘에서 차이를 보인다.

리시버 기반 접근 방식은 전통적인 방법으로, 수신기라고 불리는 장기 실행 태스크를 워커 노드에 배포하여 데이터를 수신한다. 리시버는 카프카나 플럼과 같은 소스로부터 데이터를 지속적으로 읽어들여, 블록 단위로 나누어 메모리에 저장한다. 이 블록들은 주기적으로 스파크 컨텍스트에 의해 처리되는 RDD로 변환된다. 이 방식은 WAL을 통해 데이터 수신 자체의 장애 복구를 보장할 수 있지만, 데이터가 메모리에 저장되므로 가비지 컬렉션의 영향을 받을 수 있고, 리시버 자체가 단일 장애 지점이 될 위험이 존재한다.

반면, 다이렉트 접근 방식은 스파크 1.3 버전 이후 도입된 더 효율적인 방법이다. 이 방식은 리시버를 사용하지 않고, 각 배치 간격마다 카프카와 같은 소스에 직접 접근하여 데이터의 오프셋 범위를 질의한다. 그 후, 해당 범위의 데이터를 RDD로 직접 읽어들여 처리한다. 이는 데이터 수신과 처리의 지연 시간을 줄이고, 정확히 한 번 의미론을 더욱 강력하게 보장한다. 또한, 리시버의 메모리 오버헤드가 없어지고, 입출력 성능이 향상되며, 장애 복구 시 카프카의 내구성 있는 로그를 신뢰할 수 있어 시스템 설계가 단순해진다.

Spark Streaming 애플리케이션의 실행은 두 개의 핵심 컨텍스트 객체를 기반으로 이루어진다. 첫 번째는 모든 Apache Spark 애플리케이션의 진입점이 되는 SparkContext이다. 이 객체는 클러스터에 대한 연결을 설정하고, RDD와 같은 기본적인 자원과 메모리를 관리하며, 애플리케이션의 실행 환경을 구성하는 역할을 한다.

Spark Streaming 애플리케이션에서는 SparkContext를 확장한 StreamingContext가 추가로 필요하다. StreamingContext는 스트리밍 처리의 핵심 제어자로, 데이터를 수집할 배치 간격을 설정하고, DStream을 생성하며, 전체 스트리밍 작업의 시작과 종료를 관리한다. 모든 스트리밍 연산은 이 StreamingContext 내에서 정의되고, start() 메서드 호출을 통해 실행이 시작된다.

두 컨텍스트는 계층 구조를 이룬다. 즉, 하나의 StreamingContext는 반드시 하나의 SparkContext를 필요로 하며, 이를 생성자의 인자로 받아 초기화한다. 이 구조는 Spark Streaming이 Spark Core 엔진과 Spark SQL이나 MLlib 같은 다른 라이브러리를 완벽하게 공유하고 통합할 수 있는 기반이 된다. 애플리케이션 종료 시에는 stop() 메서드를 호출하여 StreamingContext와 그 하위의 SparkContext를 모두 안전하게 종료해야 한다.

Spark Streaming의 트랜스포메이션과 액션은 DStream에 적용되는 핵심 연산으로, 데이터를 변환하고 결과를 도출하는 방식을 정의한다. 이 개념들은 Apache Spark의 핵심 RDD 연산 모델을 스트리밍 컨텍스트에 그대로 확장한 것이다. 트랜스포메이션은 기존 DStream으로부터 새로운 DStream을 생성하는 지연 실행 연산이며, 액션은 실제로 결과를 외부 저장소에 쓰거나 출력하는 즉시 실행 연산이다.

주요 트랜스포메이션에는 map, flatMap, filter와 같은 무상태 연산과, reduceByKey, countByValue와 같은 상태 유지 연산이 포함된다. 특히 reduceByWindow나 countByWindow와 같은 윈도우 연산은 특정 시간 간격 내의 데이터를 집계하는 중요한 트랜스포메이션이다. 또한 join이나 union을 사용하여 여러 데이터 스트림을 결합할 수도 있다. 이러한 모든 트랜스포메이션은 DAG 형태로 계획되며, 액션이 호출되기 전까지는 실제 실행이 시작되지 않는다.

반면, 액션은 처리 파이프라인의 실행을 트리거한다. 대표적인 액션으로는 결과를 콘솔에 출력하는 print(), RDD 형태로 각 배치의 결과를 반환하는 foreachRDD(), 그리고 스트림 처리의 상태를 디스크에 저장하는 saveAsTextFiles() 등이 있다. foreachRDD는 특히 처리된 데이터를 데이터베이스나 분산 파일 시스템과 같은 외부 시스템에 저장할 때 널리 사용된다.

트랜스포메이션과 액션의 구분은 Spark Streaming의 효율적인 실행 계획 수립과 장애 복구에 기여한다. 지연 실행 모델은 불필요한 중간 계산을 피하고 최적화된 실행 경로를 구성할 수 있게 하며, 체크포인팅을 통해 상태 정보를 저장함으로써 시스템 장애 시에도 정확한 처리를 보장한다.

윈도우 연산은 스트림 처리에서 특정 시간 단위로 데이터를 그룹화하여 집계하거나 분석할 수 있게 해주는 Spark Streaming의 핵심 기능이다. 이 연산을 통해 고정된 길이의 시간 창을 정의하고, 그 창 안에 들어오는 데이터에 대해 집계 함수나 조인 연산을 수행할 수 있다. 이는 연속적인 데이터 흐름에서도 일정 기간 동안의 추세나 패턴을 관찰하는 데 필수적이다.

윈도우 연산은 주로 윈도우 길이와 슬라이딩 간격이라는 두 가지 매개변수로 정의된다. 윈도우 길이는 집계를 수행할 시간 창의 크기를 의미하며, 슬라이딩 간격은 해당 윈도우가 얼마나 자주 이동하는지를 결정한다. 예를 들어, 30초 길이의 윈도우를 10초 간격으로 슬라이딩시키면, 10초마다 지난 30초 동안의 데이터에 대한 새로운 집계 결과가 생성된다. 이를 통해 실시간 분석에서 롤링 평균 계산이나 특정 시간대의 이벤트 수 카운트 같은 작업을 효율적으로 처리할 수 있다.

DStream은 window(), reduceByWindow(), countByWindow() 등 다양한 윈도우 기반 트랜스포메이션 메서드를 제공한다. 이러한 연산들은 내부적으로 마이크로 배치 처리 모델 위에서 동작하며, 각 배치 간격에 도착한 데이터를 미리 정의된 시간 창에 맞춰 자동으로 할당하고 처리한다. 또한 상태 관리를 위한 updateStateByKey()나 mapWithState()와 같은 연산과 결합하여, 시간이 지남에 따라 변화하는 상태를 윈도우 내에서 추적하고 업데이트하는 복잡한 비즈니스 로직을 구현할 수 있다.

윈도우 연산의 사용은 데이터 대시보드 구축, 실시간 모니터링 시스템, 사기 탐지와 같은 이벤트 기반 처리 시나리오에서 특히 유용하다. 그러나 윈도우 길이를 길게 설정하거나 상태 정보를 과도하게 유지할 경우 메모리 사용량이 증가하고 지연 시간이 늘어날 수 있어, 애플리케이션의 요구사항과 클러스터 자원을 고려하여 매개변수를 신중하게 튜닝해야 한다.

배치 간격 설정은 Spark Streaming 애플리케이션의 성능과 지연 시간을 결정하는 핵심 매개변수이다. 이 간격은 스트림 처리 엔진이 들어오는 데이터를 모아 하나의 마이크로 배치 작업으로 처리하기 위해 대기하는 시간을 정의한다. 개발자는 StreamingContext를 초기화할 때 이 값을 초 단위로 설정하며, 일반적으로 500밀리초에서 수 초 사이의 값을 사용한다.

간격이 너무 짧으면 스케줄링 오버헤드가 증가하여 시스템 자원을 비효율적으로 사용하게 되고, 너무 길면 데이터 처리의 지연 시간이 증가하여 실시간성에 부정적인 영향을 미친다. 따라서 애플리케이션의 요구사항, 데이터 유입 속도, 그리고 클러스터의 자원을 고려하여 최적의 값을 실험을 통해 찾아야 한다. 이 설정은 애플리케이션 시작 후에는 동적으로 변경할 수 없다.

배치 간격은 DStream의 생성과 실행 주기를 직접적으로 통제한다. 각 간격 동안 수집된 데이터는 RDD의 형태로 변환되어 Spark Core 엔진에 의해 병렬 분산 처리된다. 결과적으로 이 설정은 처리 처리량과 지연 시간 사이의 트레이드오프를 관리하는 중요한 수단이 된다.

Spark Streaming의 장애 복구 메커니즘은 체크포인팅을 핵심으로 한다. 체크포인팅은 애플리케이션의 상태 정보를 내구성이 있는 저장소(예: HDFS 또는 Amazon S3)에 주기적으로 저장하는 과정이다. 이렇게 저장되는 정보에는 DStream의 메타데이터와 각 마이크로 배치 처리의 진행 상황이 포함된다. 만약 드라이버 프로그램에 장애가 발생하여 중단되더라도, 새로운 드라이버 인스턴스를 시작하고 저장된 체크포인트 정보를 로드함으로써 중단 지점부터 처리를 재개할 수 있다. 이를 통해 시스템은 장애 발생 시에도 데이터 처리를 정확하게 복구할 수 있는 기반을 마련한다.

체크포인팅은 특히 상태를 유지해야 하는 연산을 수행할 때 필수적이다. 예를 들어, 윈도우 연산이나 updateStateByKey와 같은 상태 기반 트랜스포메이션을 사용하는 경우, 각 배치 간격마다 계산된 중간 상태를 체크포인트에 저장한다. 이는 장애 복구 시 단순히 데이터 소스에서 데이터를 다시 읽는 것을 넘어서, 복잡한 계산 상태까지도 정확하게 복원할 수 있도록 보장한다. 따라서 체크포인팅을 활성화하지 않으면, 드라이버 장애 시 모든 상태 정보가 손실되어 처리 로직에 오류가 발생할 수 있다.

장애 복구의 신뢰성은 데이터 소스의 특성과도 깊이 연관되어 있다. 리시버 기반 접근 방식을 사용할 경우, 수신된 데이터는 먼저 Write-Ahead Log에 기록되어 데이터 손실을 방지한다. 반면, 카프카와 같은 외부 소스에 대한 다이렉트 접근 방식을 사용하면, Spark Streaming이 각 배치의 오프셋 정보를 직접 관리하고 체크포인트에 저장한다. 이로 인해 장애 복구 시 정확한 오프셋부터 데이터를 다시 읽어 처리할 수 있어, 정확히 한 번 의미론을 달성하는 데 기여한다.

Spark Streaming은 Apache Spark의 분산 처리 엔진을 기반으로 구축되어, 데이터 처리의 확장성을 핵심 강점으로 삼는다. 이는 클러스터 컴퓨팅 환경에서 수백 대의 노드로 구성된 클러스터에 작업을 분산시켜 실행할 수 있음을 의미한다. 사용량이 증가하여 데이터 처리량이 늘어나면, 클러스터에 컴퓨팅 노드를 추가하는 방식으로 시스템의 규모를 쉽게 확장할 수 있다. 이러한 수평적 확장 덕분에 대규모 실시간 데이터 스트림을 처리하는 데 적합하다.

고속 처리는 인메모리 컴퓨팅과 마이크로 배치 처리라는 두 가지 설계로 실현된다. Spark Core 엔진의 인메모리 컴퓨팅 능력을 활용하여 디스크 I/O로 인한 지연을 최소화하고 중간 결과를 메모리에 저장함으로써 처리 속도를 극대화한다. 또한 연속적인 스트림 처리를 매우 짧은 간격(예: 1초 미만)의 마이크로 배치로 나누어 처리하는 방식은, 순수 이벤트 기반 처리에 비해 구현 복잡도를 낮추면서도 배치 처리의 높은 처리량을 유지할 수 있게 한다.

이러한 확장성과 고속 처리 능력의 조합은 실시간 분석, 로그 모니터링, 주식 시장 데이터 처리와 같이 낮은 지연 시간과 높은 처리량을 동시에 요구하는 다양한 비즈니스 인텔리전스 및 운영 모니터링 시나리오에서 Spark Streaming을 효과적인 솔루션으로 만든다.

Spark Streaming은 데이터 처리의 신뢰성을 보장하기 위해 정확히 한 번 의미론을 핵심 목표로 삼는다. 이는 각 입력 레코드가 정확히 한 번만 처리되어 결과에 반영됨을 보장하는 것을 의미한다. 이는 네트워크 지연이나 시스템 장애로 인해 데이터가 중복 전송되거나 유실될 수 있는 분산 스트리밍 환경에서 매우 중요한 특성이다.

이러한 의미론을 달성하기 위해 Spark Streaming은 체크포인팅과 Write Ahead Log 메커니즘을 결합한 장애 복구 전략을 사용한다. 스트리밍 컨텍스트는 주기적으로 애플리케이션의 상태(예: 메타데이터, 생성된 RDD)를 내구성 있는 저장소에 체크포인트로 저장한다. 동시에 수신된 데이터는 처리되기 전에 WAL에 기록되어 장애 발생 시에도 데이터를 복구할 수 있도록 한다. 이를 통해 드라이버나 익스큐터에 장애가 발생하더라도, 마지막 체크포인트부터 WAL에 저장된 데이터를 바탕으로 처리를 재개하여 중복이나 유실 없이 정확히 한 번 처리를 보장한다.

또한, 트랜스포메이션과 액션을 수행하는 출력 연산에서도 신뢰성을 유지해야 한다. 출력 대상인 외부 시스템(예: 데이터베이스, 분산 파일 시스템)이 멱등성 업데이트를 지원하거나, 트랜잭션 메커니즘을 통해 출력 결과의 정확성을 함께 보장해야 완전한 정확히 한 번 의미론이 실현된다. 따라서 애플리케이션 설계 시 출력 싱크의 특성을 고려하는 것이 필요하다.

이러한 강력한 신뢰성 보장은 금융 거래 모니터링, 실시간 과금 시스템, 정확한 실시간 대시보드 구축과 같이 데이터 정확성이 필수적인 사용 사례에서 Spark Streaming의 주요 장점으로 작용한다.

Spark Streaming은 Apache Spark의 핵심 컴포넌트로 설계되어, 단일 통합 스택 내에서 배치 처리, 대화형 쿼리, 스트리밍 처리를 가능하게 한다. 이는 개발자가 동일한 애플리케이션 내에서 실시간 데이터 스트림과 역사적 데이터를 함께 처리하는 복합 파이프라인을 구축할 수 있음을 의미한다. 사용자는 Spark의 핵심 RDD API와 동일한 프로그래밍 모델과 API를 스트리밍 작업에 적용할 수 있어, 배치 처리 애플리케이션에서의 지식을 그대로 활용할 수 있다.

이 통합의 핵심 이점은 코드와 자원의 재사용성이다. Spark Streaming은 Spark Core 엔진 위에서 실행되므로, 메모리 관리, 장애 복구, 클러스터 스케줄링과 같은 모든 기본 인프라를 공유한다. 또한 Spark SQL, MLlib, GraphX와 같은 상위 수준 라이브러리와도 원활하게 연동된다. 예를 들어, 스트리밍 데이터를 DataFrame으로 변환하여 Spark SQL로 실시간 쿼리를 수행하거나, MLlib를 사용하여 스트리밍 머신러닝 모델을 훈련시키는 것이 가능하다.

이러한 긴밀한 통합은 엔드투엔드 데이터 처리 워크플로우를 단순화한다. 하나의 클러스터에서 ETL 파이프라인, 실시간 대시보드, 예측 분석을 동시에 운영할 수 있어, 별도의 스트리밍 시스템과 배치 처리 시스템을 유지 관리하는 복잡성과 비용을 크게 줄여준다. 결과적으로 Spark Streaming은 Spark 생태계의 강력한 확장성과 성능을 실시간 처리 영역으로 자연스럽게 확장하는 역할을 한다.

Spark Streaming은 실시간으로 생성되는 대규모 데이터 스트림을 처리하고 분석하는 데 널리 사용된다. 주요 활용 분야는 실시간 대시보드 구축, 시스템 모니터링, 그리고 즉각적인 의사결정 지원이다. 예를 들어, 웹사이트의 사용자 클릭 스트림을 분석해 실시간 트래픽 보고서를 생성하거나, 소셜 미디어 피드에서 특정 키워드를 모니터링하는 데 활용할 수 있다. 또한 사물인터넷 센서나 서버 로그에서 발생하는 연속적인 데이터를 처리하여 이상 징후를 탐지하고 경고를 발생시키는 실시간 모니터링 시스템의 핵심 엔진으로 작동한다.

이 기술은 특히 금융 거래 모니터링, 사기 탐지, 네트워크 보안 분석과 같은 분야에서 강점을 발휘한다. 신용카드 거래나 주식 시장 데이터와 같은 고속 스트림을 처리해 비정상적인 패턴이나 사기 가능성이 높은 거래를 실시간으로 식별할 수 있다. 데이터 센터나 클라우드 인프라의 상태를 지속적으로 추적하는 성능 모니터링에도 적용되어, 시스템 장애를 사전에 예측하거나 리소스 사용률을 최적화하는 데 기여한다.

실시간 분석 파이프라인을 구성할 때, Spark Streaming은 Kafka, Flume, HDFS 등 다양한 데이터 소스와 손쉽게 연동된다. 처리된 결과는 다시 데이터베이스, 분산 파일 시스템, 또는 대시보드 도구로 전달되어 시각화된다. 이를 통해 기업은 운영 현황에 대한 즉각적인 인사이트를 얻고, 비즈니스 프로세스를 개선하며, 사용자 경험을 실시간으로 최적화하는 데 도움을 받는다.

Spark Streaming은 이벤트 기반 처리를 위한 강력한 플랫폼으로 활용된다. 이는 웹 로그, 센서 데이터, 금융 거래 기록, 소셜 미디어 피드 등과 같이 연속적으로 발생하는 이벤트 스트림을 실시간으로 처리하고 분석하는 데 적합하다. 이러한 처리 방식은 데이터가 생성되는 즉시 반응하여 실시간 분석이나 모니터링을 가능하게 하며, 배치 처리 방식에 비해 훨씬 낮은 지연 시간으로 인사이트를 도출할 수 있다.

주요 응용 사례로는 사기 탐지, 실시간 추천 시스템, 운영 대시보드 구축, 사용자 행동 분석 등이 있다. 예를 들어, 온라인 거래 플랫폼에서는 Spark Streaming을 사용해 비정상적인 거래 패턴을 즉시 감지하거나, 콘텐츠 제공 서비스에서는 사용자의 클릭 스트림을 분석해 실시간으로 맞춤형 콘텐츠를 추천할 수 있다. 또한 IoT 장치에서 수집된 센서 데이터 스트림을 처리하여 예측 정비나 실시간 제어에 활용하는 것도 대표적인 사례이다.

이벤트 기반 처리를 구현할 때 Spark Streaming은 DStream을 통해 데이터 흐름을 일정한 배치 간격으로 나누어 처리하는 마이크로 배치 모델을 사용한다. 이를 통해 복합 이벤트 처리가 가능해지며, 윈도우 연산을 적용해 특정 시간 범위 내의 이벤트를 집계하거나 조인하는 등의 복잡한 로직을 실행할 수 있다. Kafka, Flume 등의 메시지 큐 시스템과의 통합을 통해 다양한 소스로부터의 이벤트 스트림을 안정적으로 수집하고 처리 파이프라인을 구성할 수 있다.

Spark Streaming 애플리케이션을 초기화하려면 먼저 SparkContext와 StreamingContext를 생성해야 한다. SparkContext는 Spark 애플리케이션의 진입점으로, 클러스터에 대한 연결과 자원 할당을 담당한다. StreamingContext는 SparkContext를 기반으로 생성되며, 스트리밍 처리를 제어하는 핵심 객체이다. 여기서는 배치 간격을 초 단위로 설정하여 마이크로 배치의 주기를 정의한다.

가장 기본적인 예제는 로컬 소켓에서 텍스트 데이터를 수신하여 단어 수를 실시간으로 세는 것이다. 이를 위해 StreamingContext의 socketTextStream 메서드를 사용하여 특정 호스트와 포트로부터 데이터 스트림을 생성한다. 생성된 DStream에 flatMap과 reduceByKey 같은 트랜스포메이션을 적용하여 단어별 개수를 계산한 후, print 액션을 호출하여 결과를 콘솔에 출력한다.

애플리케이션을 시작하려면 StreamingContext의 start() 메서드를 호출하고, 처리가 종료되거나 중단될 때까지 대기하기 위해 awaitTermination() 메서드를 호출한다. 이는 애플리케이션이 무한히 실행되도록 하여 실시간으로 들어오는 데이터를 계속 처리하게 한다. 장애 복구를 위해 checkpoint 디렉토리를 설정할 수 있으며, 이는 윈도우 연산이나 상태 기반 연산을 사용할 때 특히 중요하다.

아래는 Python (PySpark)을 사용한 기본적인 단어 카운트 예제의 코드 구조이다.

```python

from pyspark import SparkContext

from pyspark.streaming import StreamingContext

# SparkContext 생성

sc = SparkContext("local[2]", "NetworkWordCount")

# 1초 배치 간격으로 StreamingContext 생성

ssc = StreamingContext(sc, 1)

# 로컬호스트의 9999 포트로부터 텍스트 스트림 생성

lines = ssc.socketTextStream("localhost", 9999)

# 공백으로 분리하여 단어로 나눈 후, (단어, 1) 쌍 생성 및 카운트

words = lines.flatMap(lambda line: line.split(" "))

pairs = words.map(lambda word: (word, 1))

wordCounts = pairs.reduceByKey(lambda x, y: x + y)

# 결과 출력

wordCounts.pprint()

# 스트리밍 컨텍스트 시작

ssc.start()

# 종료 신호를 기다림

ssc.awaitTermination()

```

이 예제를 실행하기 전에 netcat 같은 도구로 로컬 9999 포트에 데이터를 전송해야 한다. 이 기본 구조를 바탕으로 Kafka나 HDFS 같은 다양한 데이터 소스에 연결하거나, 더 복잡한 트랜스포메이션과 액션을 적용하여 실시간 분석 애플리케이션을 개발할 수 있다.

Spark Streaming은 다양한 외부 데이터 소스로부터 실시간 데이터 스트림을 수신할 수 있도록 설계되었다. 주요 연결 방식으로는 리시버 기반 접근법과 다이렉트 접근법이 있으며, 특히 Apache Kafka와의 통합이 널리 사용된다. 카프카와의 연결은 초기에는 리시버를 통해 이루어졌으나, 데이터 손실 없이 정확히 한 번의 의미론을 보장하는 다이렉트 API 방식이 선호된다. 이 방식은 주키퍼에 의존하지 않고 카프카의 오프셋을 직접 관리하여 효율성과 신뢰성을 높인다.

HDFS나 Amazon S3와 같은 파일 시스템도 중요한 데이터 소스이다. 이들은 주로 정적 데이터를 읽거나, 스트리밍 처리 결과를 저장하는 싱크로 활용된다. Spark Streaming은 지정된 디렉토리를 모니터링하여 새로 추가되는 파일을 실시간으로 읽어들여 DStream을 생성할 수 있다. 이는 로그 파일 수집이나 배치 처리 결과와의 연동에 유용하다.

이 외에도 TCP 소켓, Apache Flume, Amazon Kinesis 등 다양한 소스를 지원한다. 각 데이터 소스에 맞는 전용 커넥터 라이브러리를 사용하여 SparkContext와 StreamingContext를 초기화한 후 연결을 설정한다. 데이터 소스의 특성에 따라 내결함성을 위한 체크포인트 설정이나 파티션 수 조정 등의 최적화가 필요하다.

Spark Streaming은 마이크로 배치 처리 모델을 기반으로 하기 때문에, 처리 지연 시간은 필연적으로 존재한다. 이 지연 시간은 주로 설정된 배치 간격에 의해 결정되며, 일반적으로 수백 밀리초에서 수 초 사이의 범위를 가진다. 이는 각 배치가 수집되고 처리되는 데 필요한 시간으로, 순수한 이벤트 단위의 스트림 처리 엔진에 비해 더 높은 지연을 유발할 수 있다.

지연 시간은 데이터 소스로부터의 수집, 클러스터 내 네트워크 통신, 스파크 엔진에서의 연산 처리, 그리고 결과 출력까지의 전체 파이프라인에서 발생한다. 특히 복잡한 윈도우 연산이나 상태 기반 트랜스포메이션을 사용할 경우, 상태를 관리하고 업데이트하는 추가 오버헤드로 인해 지연이 더욱 증가할 수 있다.

이러한 지연 시간을 최소화하기 위해 배치 간격을 줄이는 방법이 있지만, 이는 너무 잦은 작업 스케줄링으로 인해 시스템 오버헤드를 증가시켜 오히려 처리량을 저하시킬 수 있다. 따라서 처리 지연 시간과 시스템 처리량 사이의 최적의 트레이드오프를 찾는 것이 중요하다. 매우 낮은 지연(예: 밀리초 단위)이 요구되는 사용 사례의 경우, Spark Streaming보다는 Apache Flink나 Apache Storm과 같은 진정한 스트림 처리 엔진을 고려하는 것이 적합할 수 있다.

상태 관리란 스트리밍 애플리케이션이 시간이 지남에 따라 지속적으로 업데이트되어야 하는 정보를 유지하는 것을 말한다. 예를 들어, 지난 1시간 동안의 웹사이트 방문자 수를 실시간으로 집계하거나, 사용자 세션 동안의 활동을 추적하는 경우가 이에 해당한다. Spark Streaming은 updateStateByKey나 mapWithState와 같은 연산자를 통해 키-값 쌍 기반의 상태 관리를 지원한다. 그러나 이러한 상태는 장애 발생 시에도 유지되어야 하므로, 신뢰할 수 있는 상태 관리를 위해서는 체크포인트 디렉터리를 설정하고 상태 정보를 HDFS나 아마존 S3와 같은 내구성 있는 스토리지에 주기적으로 저장해야 한다. 이는 추가적인 설정과 저장소 비용을 발생시킨다.

상태 관리의 복잡성은 주로 애플리케이션의 규모와 상태의 크기가 커짐에 따라 증가한다. 상태 데이터가 너무 커지면 메모리 부족으로 인해 성능이 저하되거나 애플리케이션이 실패할 수 있다. 또한, 상태 업데이트 로직을 직접 작성해야 하며, 상태의 일관성과 장애 복구를 보장하는 것은 개발자의 책임이다. 특히 윈도우 연산과 상태 연산이 결합된 복잡한 로직에서는 디버깅과 유지보수가 어려워질 수 있다.

이러한 복잡성을 완화하기 위해 Spark는 이후에 도입된 Structured Streaming에서 상태 관리를 더욱 단순화하고 최적화했다. Structured Streaming은 내부적으로 상태 관리를 처리하며, 워터마크 메커니즘을 통해 지연 데이터와 상태 정리를 보다 효율적으로 관리한다. 따라서 새로운 애플리케이션을 개발할 때는 상태 관리의 필요성과 복잡성을 고려하여 Spark Streaming의 DStream API 대신 Structured Streaming API를 사용하는 것이 권장되는 경우가 많다.