트렌드 면에서는 기계학습에 밀린 것 같지만, 실시간 처리 또는 스트리밍 처리는 대단히 중요한 기술이다. 오픈소스로 존재하는 Storm과 Spark을 한번 비교해보자. 물론 솔루션 선택은 자유이고, 상황에 맞는 것이 바로 최적의 솔루션이다.
1. Task Prallel vs. Data Parallel
계산 프로그래밍 모델에서부터 느낄 수 있는 가장 뚜렷한 차이는 먼저, Storm은 Task Parallelism이고 Spark Streaming은 Data Parallelism이다. 개인적으로는 보다 완성도 높은 시스템을 구현할 수 있는 Storm의 계산 그래프 구조를 선호하지만 코드의 복잡도 면에서는 Spark이 유리할 수 있다.
2. Streaming vs. Micro-batches
Spark streaming의 경우는 엄밀히 말하면 실시간 처리보다는 작은 단위의 배치 연속이라고 할 수 있다. Storm은 전형적인 event-driven record at a time processing model로써 살아있는 데이터를 처리한다고 하면, Spark은 휴면 상태로 넘어간 데이터를 처리한다. 때문에 Latency에서 차이가 발생하는데 Storm은 subsecond, Spark의 경우에는 사용자 임의지정 few seconds가 된다.
여기에서 중대한 차이점이 발생하는데, Storm의 경우에는 데이터 유실이 없어야 할 때 (no data loss), Spark은 중복 연산이 없어야할 때 (exactly once) 선택하는 것이 좋다.
한편, Storm Trident는 Micro-batches 스타일도 가능하다고 한다.
3. Stateless vs. Stateful
앞서 소개한대로 Storm은 매 레코드 별로 처리하기 때문에 State을 유지하지 않기 때문에 장애 복구 메커니즘이 Spark보다 복잡하고 re-launching 시간이 더 걸릴 것이다. Stateless vs. Stateful는 (뭔가 더 있을 것 같지만) 장애 복구 외의 차이점은 전혀 없다.
4. Integration with Batch processing
긴말 필요없이 당연히 Spark이 유리하겠다.
여기까지 알아봤고 과연 무엇이 최상의 솔루션인가? 내 생각엔 Storm이 조금 우수하다 판단한다. 물론 최적의 솔루션은 당신 상황에 맞아야 하겠다.
Subscribe to:
Post Comments (Atom)
-
음성 인공지능 분야에서 스타트업이 생각해볼 수 있는 전략은 아마 다음과 같이 3가지 정도가 있을 것이다: 독자적 Vertical 음성 인공지능 Application 구축 기 음성 플랫폼을 활용한 B2B2C 형태의 비지니스 구축 기 음성 플랫폼...
-
우리는 남들의 비판을 경험하면서 창조적 사고를 포기하게 된다. 비판으로부터 방어논리와 자기 검열에 취중한 나머지 더 이상 사고에 자유롭지 못하게 되니까 그렇다. 남들의 비판을 두려워하지 않는 자세.. 그것이 순수한 창조적 사고를 지속하는 방법이다...
-
“군자는 어울리되 패거리를 짓지 않고, 소인은 패거리를 짓되 어울리지 않는다." 군자는 의(義)를 높이기에 아부하지 않고, 부화뇌동(附和雷同)하지 않는다. 군자는 대의명분을 지키면서 화합하며 협력한다. 하지만 소인은 이익을 높이기에 이해관...
-
네이버, KT, 오라클, 그리고 잠깐의 사업을 거쳐 삼성전자에 입사한지도 2년이 지났습니다. 2016년 병신년을 뒤로하며 이번에는 꽤 색다른 도전에 나섭니다. 무슨 일이야!? 국내 O2O 숙박전문 회사 CTO로 조인합니다! 존! 나 고...
No comments:
Post a Comment