어느정도 규모가 있는 데이터(꼭 빅데이터까지 안가더라도)를 다루는 솔루션들의 플로우는 보통 "수집->저장->분석->시각화" 정도다.

여기서 실시간성이 더 중요한 팩터라면 저장보다 분석이 앞단으로 오게되는 경우도 있다.

사실 위와 같은 플로우는 오래전부터 여기저기서 구현되어 왔는데 요즘에는 저 플로우를 채울 수 있는 오픈소스들이 많이 나와있다.


제일 먼저 생각나는 놈이 로그 수집을 담당하는 logstash와 로그 저장 및 검색을 담당하는 elasticsearch, 그리고 시각화를 담당하는 kibana를 에코시스템으로 묶어서 많이들 쓰는 것 같더라. 근데 데이터 양이 커지면 커질 수록 직접적으로 부하를 받는 데이터 수집부, 즉 logstash가 ruby로 구현되어 있어 퍼포먼스가 얼마나 나오는지는 잘 모르겠다. 일정 이상의 데이터셋에서는 다른 스택으로 넘어가거나 스케일 업을 통해서 해결하는 모양이다.


hadoop과 hbase 조합도 한동안 많이 쓰였고 지금도 많이 쓰이고 있는 걸로 알고 있다. 실시간 성이 중요하지 않은, 배치처리가 가능한 데이터에 대해서 주로 이렇게 처리하는 걸로 알고 있다. 근데 솔직히 빅데이터=하둡으로 여기는 사람들이 많은 것 같은데 우리나라에서 정말 빅데이터 급의 데이터셋을 다루는 회사가 몇이나 되는지 궁금하다.


실시간 성 데이터들에 대해서는 기존에는 storm에 message queue를 붙여서 구현하는 방식이 많이 쓰인 걸로 알고 있다. 근데 기존 배치성 데이터를 위한 프레임워크였던 spark에서 spark streaming이라는 새로운 네이밍을 붙여 storm을 위협하고 있는 형세다. 사실 핫하기로는 spark streaming이 더 핫한 것 같다. 개인적으로도 제일 손대보고 싶은 프레임워크 이기도 하다.


message queue는 엔터프라이즈 급에서는 kafka가 제일 많이 쓰이는 것 같다. message queue 종류는 zeroMQ, active mq, rabbit mq 등등 충분히 성숙된 오픈소스들이 많고 퍼포먼스 면에서는 kafka가 zero mq 등보다 크게 앞서지 않는 걸로 알고 있는데 강점이 무언지 정확히 모르겠다. 

한번 kafka document들을 찬찬히 살펴본 적이 있는데 다른 message queue들이 전부다 메모리에 데이터를 담아놓는 방식을 취하는데 비해 kafka는 디스크에 sequential하게 기록하는 방식을 취하는 것이 굉장히 인상적이었다. 컴퓨터를 조금이라도 공부해본 사람들이라면 메모리보다 디스크가 속도가 느리다는 건 상식이었는데 kafka는 이 상식을 깼다. 그럼에도 불구하고 퍼포먼스가 떨어지지는 않는다.

document는 그 이유를, 메모리에 적재하는 방식은 random access를 통해 데이터를 찾아가야 하지만 message queue는 그 특성상 random access보다 sequential access가 더 많이 일어나고, 그렇다고 하면 sequential하게 데이터를 기록하는 방식으로도 퍼포먼스가 크게 뒤처지지 않으면서 데이터의 persistence를 확보할 수 있다는 거였다.  이런 식의 발상을 해낼 수 있는 사람들보면 부럽다.