Storm vs. Spark Streaming: 내부 메커니즘의 차이점

-
트렌드 면에서는 기계학습에 밀린 것 같지만, 실시간 처리 또는 스트리밍 처리는 대단히 중요한 기술이다. 오픈소스로 존재하는 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이 조금 우수하다 판단한다. 물론 최적의 솔루션은 당신 상황에 맞아야 하겠다.

Comments

Post a Comment

Popular posts from this blog

일본만화 추천 100선

-
1.군계 (액션,격투)

격투만화 중에서는 아주 유명하고 열광적으로 좋아하는 사람이 많은 만화입니다. 전체적으로 만화의 분위기는 어둡고요... 줄거리를 소개하죠. 주인공인 료는 모범생이었습니다. 그러나 부모님의 강압적인 통제... 그에 대한 무의식적 반발로 부모님을 살해하게 되고 맙니다. 그리고 교도소에서 많은 변화를 겪게되죠..그리고 악의 화신같은 존재가 되고 말죠..... 또 그에 대항하는 인물이 나타나고.... 만화에 대한 소개가 만화의 질을 못 따라가네요. 이 만화는 선과 악에 대해 생각해볼 수있는 만화입니다. 그리고 싸움이란 인간에게 어떤 의미가 있는것일까? 하는 생각도요. 아..군계는 싸움닭이란 뜻입니다. 네이밍센스가 좋죠.


2. 생추어리(해적판제목:빛과 그림자) (액션,정치)

일본 최고의 극화체 만화가인 이케가미 료이치님의 작품입니다. 캄보디아에서 일본 외교관의 아들로 태어난 두 남자 이야기를 그리고 있습니다. 캄보디아의 킬링필드(대학살..실존사건입니다.)와중에서 살아남아 돌아온 두 주인공..한명은 암흑계 보스로 다른 한 명은 정치계 거물로 성장해갑니다. 두 남자의 목숨과도 같은 우정....그들의 관계는 어떻게 될까? 뛰어난 스토리작가와 항상 작업하여 재미는 보장이 되는 작품입니다. 단 남성우월주의가 작품전반에 깔려있어서 여성이 보기엔 거부감을 느낄수도 있는 작품..남자분인거 같아 추천합니다.


3.수라의 각 (역사,무협)

해황기의 작가가 쓴 매우 흥미진진한 역사 무협물입니다. 일본 역사속의 많은 실존인물들의 얘기를 기둥줄거리로 하여 거기에 허구를 작가의 능수능란한 솜씨로 섞어냅니다. 이 작품은 코믹 만화인 수험의 제왕에도 등장하는 데요....그 만화에 이런 말이 있지요. "역사 공부를 하려거든 수라의 각을 읽어라" 이 만화작가의 다른 작품인 해황기도 매우 흥미진진하답니다.


4.베르세르크 (판타지)

말이 필요없는 판타지의 최고 걸작.... 뛰어난 작화에 철학적인 사유까지 배어든 최고의 작품. 안 읽으셨다면 부디 읽어보시길..


5.…
Read more

음성 인공지능 스타트업의 기회 분석

-
음성 인공지능 분야에서 스타트업이 생각해볼 수 있는 전략은 아마 다음과 같이 3가지 정도가 있을 것이다:

독자적 Vertical 음성 인공지능 Application 구축기 음성 플랫폼을 활용한 B2B2C 형태의 비지니스 구축기 음성 플랫폼 생태계 내에 3rd party 서비스 구축
(1) 의 접근은 도메인 특화된 Standalone 음성 인공지능 Application을 만드는 방법이다. (2) 의 접근은 기 음성 플랫폼 비지니스 사업자에 특수 분야 기술을 제공해서 최종적으로 소비자에게 전달되는 B2B2C 형태의 사업 추진이다. 마지막으로 (3) 은 기 음성 플랫폼 내 3rd party 서비스를 개발하여 소비자에게 제공하는 방법이다. 지금부터 하나씩 사례와 함께 자세히 살펴보자.

1) 독자적 Vertical 음성 인공지능 Application 구축

너무 당연한 얘기지만 스타트업이 구글이나 아마존의 범용 음성인식과 차별없는 음성 인식을 통해 경쟁하려 든다면 그것은 별로 좋은 아이디어는 아니다. 구글이나 바이두와 같은 막강한 기업 만큼의 예산과 기술을 갖추고 있지 않기 때문에 무조건 백전 백패다.

그러나, 특정 산업에 특화된 문제를 발굴하고 AI를 결합해 그 문제를 해결하는 접근으로 속도를 내고 있는 Vertical AI 스타트업이 있다. 대표적으로 Chorus.ai와 한국의 리뷰와이저(?), 액션파워 정도가 될 것 같다.

코러스의 창업자는 도메인 특화된 버티컬 엔진이 (경험적으로 퉁쳐서) 일반 범용 엔진보다 최소 15% 향상된 성능을 낼 수 있다고 한다. 국내 Vertical voice AI 회사도 만나본 적은 있지만 개인적으로 나눈 대화다 보니 특별히 언급은 생략한다.

뭐 여하튼 (정량적 평가 수치는 확인할 수 없었으나) 기술적으로 따져보았을 때 명백히 narrow domain으로 접근하면 자연어 처리에 있어 그 복잡도를 낮추고 결론적으로 높은 성능을 낼 수는 있을 것이다.

이 때문에 도메인 특화된 음성 인식 엔진은 당장 빠르게 우위를 점할 수 있다는 점은 분명하…
Read more

How socket.io-redis adapter works? 레디스 어댑터 동작원리

-
Image
보통 실시간 메시징 처리에 socket.io와 redis를 많이 사용하는데, 그 동작 메커니즘이 자세히 소개된 글을 찾기 어려웠다. 이유는 간단한데, 소스코드가 그냥 간단해서 글로 쓰고 자시고 건더기도 없어 그런듯. 
기본적으로 socket.io는 Server, Namespace, Room, 그리고 Socket으로 구성되어있고 멀티 노드를 위해 pluggable 디자인 방식으로 Adapter라는 것이 존재한다. 
Default In-Memory 방식은 배열에 socket과 room 정보를 저장하기 때문에 웹 서버에 붙어있는 clients 외 에는 알 길이 없다. 이때 redis adapter를 사용하면 다음과 같이 동작하는데, sender가 원격에서 넘어왔다면 그냥 내 로컬 clients에게 deliver하는 것으로 종료하고 그렇지 않으면, 다른 노드에게 publish하여 메시지를 전달한다. 

분산 인프라 치고는 놀랍게도 Javascript 몇 줄 안되는 소스코드로 node, socket.io, 그리고 redis가 동작한다. 좀 이해하기 쉽게 도식화하면 다음과 같다:

Read more