Spark의 Streaming 처리 방식 - 마이크로 배치(micro-batch)

Spark의 Streaming 처리 방식 - 마이크로 배치(micro-batch)

#출처 : Spark Streaming으로 유실 없는 스트림 처리 인프라 구축하기

http://readme.skplanet.com/?p=12465

실시간 처리(Real-time processing)와 스트림 처리(Stream processing)

실시간 처리는 데이터 처리의 목표 또는 제약 사항이라고 볼 수 있고, 

스트림 처리는 데이터 처리 방식이라고 볼 수 있습니다.

실시간이라는 용어에는 마감시각(deadline)이 있고, 마감시각 내에 주어진 연산을 완료하지 못하면 실패로 처리합니다. 조금 더 세분화하면 마감시각을 놓쳤을 때의 처리 결과에 따라 Hard/Firm/Soft real-time으로 구분합니다.      

스트림 처리는 범위가 한정되지 않고(unbounded) 끊임 없이 흘러가는(stream) 데이터에 대한 처리 방식입니다.

반대로 한정된(bounded) 데이터의 처리를 배치 처리(batch processing)라고 합니다. 

작은 배치 처리를 무한히 하는 방식도 스트림 처리에 포함되고, 이를 마이크로 배치(micro-batch)라고 합니다. 

잘 설계된 스트림 처리는 배치 처리를 포함한다고 까지 말할 수 있습니다.

결국, 스트림 처리가 끊임없이 흘러가는 데이터를 처리하다 보니 당연하게도 배치 처리에 비해 데이터 처리 결과를 빠르게 받아볼 수 있어서 실시간 처리라고 불릴 수도 있습니다. 

[중략...]

Spark Streaming의 선택

 스트림 처리를 신뢰도(reliability)에 따라 다음과 같이 세 가지 보장 방식으로 구분할 수 있습니다.

• At-most-once(최대 한 번): 데이터 유실이 있을 수 있어, 추천하지 않는 방식
• At-least-once(적어도 한 번): 데이터 유실은 없으나 재전송으로 인해 중복이 생길 수 있음. 대부분의 경우 충분한 방식
• Exactly-once(딱 한 번): 데이터가 오직 한 번만 처리되어 유실도 중복도 없음. 모든 상황에 대해 완벽히 보장하기 어렵지만 가장 바라는 방식

Core Storm과 Spark Streaming을 비교하면 Spark Streaming이 exactly-once를 보장하기 때문에 조금 더 믿을만하지만, 마이크로 배치처럼 동작하도록 추상화 계층을 추가한 Storm Trident에 비해서 Spark Streaming은 아직 부족한 점이 많았습니다. 

[중략...]

스트림 처리 프레임웍으로 선택한 Spark Streaming을 간단히 정리하면, 다음 그림과 같습니다.

그림 4. Spark Streaming 흐름
출처: http://spark.apache.org/docs/latest/streaming-programming-guide.html

끊임없이 들어오는 스트림 데이터를 Spark Streaming이 배치 간격(batch interval)마다 데이터를 나누고, 나눠진 배치 데이터를 Spark Core 엔진이 처리해서 배치 간격마다 결과를 내놓습니다. 즉, 스트림 처리를 작은 시간 간격을 갖는 배치 처리의 연속으로 전환하여 처리합니다. 이러한 방식을 마이크로 배치(micro-batch) 방식이라고 합니다. 또한 각각의 배치 처리는 Spark으로 분산 처리하기 때문에, 좋은 성능을 가지면서도 장애 복구가 가능한 Spark의 장점들을 모두 이어 받았습니다.

Spark Streaming이 마이크로 배치 방식을 택한 이유는 배치 처리용 Spark이 먼저 개발된 후에 Spark의 다양한 기능을 그대로 이용하면서 스트림 처리가 가능하도록 추가한 기능이 Spark Streaming이기 때문입니다. 초기 Spark Streaming의 설계는 Discretized Streams: Fault-Tolerant Streaming Computation at Scale 논문에서 확인할 수 있습니다.

마이크로 배치 방식은 continuous 처리 방식의 스트림 처리 시스템보다 latency가 큰 단점이 있지만, 배치 처리와 스트림 처리를 하나의 시스템에서 처리할 수 있는 장점이 되었습니다. 기존의 continuous 처리 방식과의 차이점은 https://databricks.com/blog/2015/07/30/diving-into-spark-streamings-execution-model.html 에서 조금 더 살펴볼 수 있습니다.

배치 처리와 스트림 처리를 하나의 시스템에서 코드를 재활용해서 사용할 수 있기 때문에, 최근 대용량 데이터 처리에서 많이 언급되는 람다 아키텍처(Lambda Architecture)에 적합한 방식이라고 할 수 있습니다. 람다 아키텍처에서는 배치 계층(batch layer)과 속도 계층(speed layer)이 따로 존재하는데, Spark Streaming은 람다 아키텍처를 하나의 시스템에서 구현할 수 있어, 한 걸음 더 나아간 방식이라고 할 수 있습니다.