|
◆ 이 글은 popit에 게시된 아래 블로그를 정리한 글이다. ◆ |
실시간 처리 프레임워크는 streaming model에 따라 크게 두가지 방식으로 구분된다.
Streaming Model
1) Native stream processing systems
- 유입되는 모든 records, event를 스트리밍에 도착하는 시점에 하나씩 처리하는 native stream 방식
2) Micro-batching
- 유입되는 records를 짧은 주기의 batch로 처리 가능산 단위로 묶어 스트리밍으로 보내는 방식
| 구분 | 장점 | 단점 |
| native stream processing system | 모든 로직 가능 데이터가 유입되는 즉시 처리하여 mricro-batching보다 latency(지연)가 적음 상태 관리에 대한 구현이 쉬움 throughput 낮음 |
장애처리시 어려움 특정 키를 갖고 파티셔닝 처리를 할 경우 특정 키에 데이터가 집중되면 job의 병목요소가 됨 |
| micro-batching | 로직에 제약 상태관리, join, split 등 특정 오퍼레이션 구현이 어려움 batch의 주기는 인프라의 상태, 비즈니스 로직과 관계 |
장애복구 빠름 로드밸런싱 용이 |
실시간 처리 프레임워크를 위 방식에 따라 구분해보면 아래와 같다.
(출처: http://www.cakesolutions.net/teamblogs/)
| 구분 | Apache storm | Trident | Spark | Samza | Flink |
| Streaming model | native | micro-batching | micro-batching | native | micro-batching |
| API | Compositional | Compositional | Declarative | Compositional | Declarative |
| Guarantee | At-least-once | Exactly-once | Exactly-once | At-least-once | Exactly-once |
| Fault Tolerance | Record ACKs | Record ACKs | RDD based Checkpointing | Log-based (kafka 활용) |
Checkpointing |
| Satate Management (상태관리) |
Not build-in | Dedicated Operators | Dedicated Dstream | Stateful Operators | Stateful Operators |
| Latency | Very low | Medium | Medium | Low | Low |
| Throughput | Low | Medium | High | Medium | Low |
| Maturity | High | High | High | Medium | Low |
Fault Tolerance & State Management
Native 방식의 경우 fault tolerance 측면에서 mricro-batching 방식보다 까다롭다.
Fault tolerance 측면에서 각 스트리밍 프레임워크를 비교해보자면
Record ACKS with Apache storm and Trident
하나의 oprerator는 모든 record에 대해 처리가 된 시점에 해당 record를 보내온 이전 operator에 ACK 신호를 전송한다.
ACK 신호를 받으면 해당 record의 백업본을 폐기할 수 있다.
만약 ACK를 받지 못할 경우 재처리가 가능하다.
데이터 유실이 적으나 중복이 발생할 수 있는 방식이다.
이런 방식을 "At-least-once"라고 부르며 중복제거에 대한 로직이 별도로 필요하다.
다만 데이터의 흐름에 ACK 체크가 들어가다 보니 thoroghput이 낮은 것이 단점이다.
RDD based-checkpointing with Spark
micro-batching 방식으로 데이터 처리를 하므로 각 batch job에 대해 성공/실패에 대한 상태 관리를 한다.
실패한 micro-batch job은 새로운 worker node가 재실행하며 데이터 중복이 발생하지 않는 방식이다.
앞서 설명한 Record ACKS 방식에 비해 장애 처리가 수월하며 이로 인해 throughput이 높다.
상태관리 또한 micro-batching으로 관리하여 각 Job별로 수행 결과와 상태를 관리한다.
Log-based with Samza
Samza는 offset 기반의 메시징 시스템을 활용하며 보통 kafka를 사용한다.
Kafka는 iunput stream의 partition별로 offset을 저장하는데, Samza는 이 offset을 모니터링하다가 실패하면 이 offset을 참조하여 데이터 재처리를 진행한다.
하지만 offset을 기준으로 처리하여도 데이터 중복이 발생할 수 있으며 데이터 누락의 위험은 낮다.
CheckPointing with Flink
Flink는 checkpoint barrier를 전송하고 각 operator들은 해당 checkpoint에 해당하는 stream 데이터를 처리한다.
Storm과 Spark의 방식의 중간점에 있는 방식이며 모든 데이터를 ACK처리하지 않으면서도 native streaming 모델을 고수한다.
Flink의 전달 방식은 Exactly once이다.
상태관리는 각 단계별 operator를 제공하는데 두 가지 유형이 존재한다.
1) 로컬 시스템의 하나의 operator에서 실행되는 여러 개의 Task들 중 하나의 Task에 대한 상태를 말하며 서로 다른 Task간 통신하지 않는다.
2) 코드단에서 정해진 key에 따라 파티셔닝되고 key를 바탕으로 전체 파티션의 상태를 관리한다.
'Spark' 카테고리의 다른 글
| Spark 3.0 무엇이 바뀌었을까? (0) | 2021.07.18 |
|---|