빅데이터 배치처리외에 실시간 대량데이터에 대한 처리요건도 늘어감에 따라 스터디를 진행하고 있다.

대표적으로 Storm이 있는데 Spout와 Bolt의 연결을 이용한 Stream 처리 엔진으로 보면 될 것 같다.


모든 책에서 대표적으로 소개되고 있는 로그파일처리부분을 살펴보면 

- 로그파일은 flume을 통해서 읽고

- kafka를 통해서 message 병렬분산 처리를 한다.

- storm과의 연결은 kafka spout를 통한다. (인터넷에 다양한 spout가 이미 존재한다.)


각 구성요소의 개념을 간단히 살펴보면


1. Spout
데이터를 입력받는 곳이다. 공식사이트에서 수도꼭지로 표현되며 단어의 의미는 주둥이,분출

데이터를 끌어오는 개념이며 현재 다양한 source로 부터 받을 수 있도록 spout이 존재한다.

spout과 spout간의 연결도 가능하다.

- open메소드 : 최초 한 번 수행되며 일반적으로 환경구성이 필요한 내용들이 들어간다.

nextTuple 메소드 : 데이터가 넘어올 때 마다 수행되며, 실제 데이터를 분출시키는 부분이다.

SpoutOutputCollector를 통해서 데이터를 전달한다. (collector.emit메소드를 호출)

declareOutputFields  : 보내는 데이터에 대해서는 key값을 정의해주어야 OutputFieldsFieldsDeclarer.declare메소드를 호출한다. 해당 Spout에 연결된 Spout/Bolt에서는 이 Key값을 통해서 Value를 가져올 수 있다.


전달 키값을 동일하게 쓰면 받는 쪽에서는 구분없이 하나의 데이터 처리가 가능하며 
전달 키값을 분리하면 분리 처리도 가능함

키값에 대해서는 Topology정의시 상수화 하는 것도 하나의 방법이 될 수 있다.


ack / fail은 필요에 따라 구현한다.



2. Bolt
실제 각 활용영역별로 커스터마이징이 이루어져야 하는 부분이다.

- prepare : 최초 한 번 수행되며 준비에 필요한 내용들이 들어간다. (ex, 환경, IP 등)

- execute : 실제 넘어온 Tuple을 가지고 로직을 수행한다. tuple.getValueByField 메소드를 호출하여 사전에 정의된 Key값을 통해서 value를 가지고 올 수 있다.

declareOutputFields  : Spout와 동일함


3. Topology

만들어진 Spout와 Bolt를 서로 연결하여 망을 형성한다.

TopologyBuilder를 통해서 구성하고 subtmit한다.

이후 해당 Topology는  사전에 기동된 Storm 프로세스 ( Nimbus )에 전달되고 Nimbus는 각 Supervisor로 할당하여 작업을 수행한다.

작업이 수행되면 별도로 Worker 프로세스가 기동되며 Worker 프로세스내에 Topolog상의 component가 분배되어 Thread로 수행된다. 커스터마이징을 통해서 수동으로 component위치를 지정하여 자원사용량을 분산시키는 것도 가능한다. 

topology 별로 최소 worker 1개 이상이 필요하고 그 이상 지정도 가능하다.

4. Architecture

Nimbus : HDFS의 Namenode와 유사하여 마스터 노드의 역할을 한다. Topology를 받아서 각 Supervisor에게 배포하고 작업을 수행하며 추적한다.

Supervisor : Nimbus로부터 명령을 받아서 Worker 프로세스르 구동한다.

Worker : 실제 컴포넌트 (Bolt, Spout)가 할당되어 task를 수행한다.


5. 정리
분산 병렬처리를 위해서는 기본적으로 Key/Value형태의 데이터로 구성되어야 핞다. (ex, Map/Reduce, Spark 등)

Storm도 마찬가지로 데이터 전달시 Key/Value형태로 전달하도록 되어있다.

빅데이터를 이야기 할 때 항상 나오는 Iteration 과 Interactive를 좀더 공부할 필요가 있다.

 

6. Storm과 Spark 간단비교

 a. Storm
Apache에서 Storm을 보면 Distributed, real-time computation system으로 소개된다.

실제 Spout나 Bolt의 구현부를 보면 건단위의 흐르는 데이터 (Streaming...) 처리에 적합한 구조로 되어있다.

로그파일은 어쨌든 파일인데 왜 Storm으로 처리하는 예제가 나올까라는 의문을 가졌었는데 로그파일의 경우 실시간 row단위로 쌓이는 데이터이기 때문에 흘러가는 데이터로 보는게 맞다는 생각이 들었다.

어쨌든 Storm은 데이터를 저장하는 것이 아니라 계속 흘려보내는 의도로 출발된 구조로 보면 되겠다.

번외로 Spout와 Bolt간의 특정데이터를 공유해야 할 필요가 있을때는 IMDG를 사용할 수 있을 듯 하다.


 b. Spark

Apache에서 Spark는 Fast and general engine for large-scale data processing 으로 소개된다.
내용과 실제 구현방법을 보면  배치성처리 컨셉이 강하며, 기본적으로는 Map/Reduce처리방식과 유사하다.

RDD개념을 도입하여 Disk I/O를 최소화 했기 때문에 iteration에 강하고, 결과를 다시 인풋으로 받는 (ex, kmeans) 알고리즘 구현시 강점이 있다. Stream처리를 위한 개념으로 Spark Streaming도 있지만 결국 간격이 짧은 배치를 수행하는 컨셉이다.
기본적으로 RDD생성은 파일 또는 다른 RDD에서만 가능하기 때문에 실시간 Stream에는 적합하지 않는 것으로 보인다.


'BigData' 카테고리의 다른 글

Hadoop Securiy for Multi tenant #1  (0) 2017.01.17
Flume-Kafka-Elasticsearch 테스트  (0) 2016.03.14
CAP 정리  (0) 2014.11.28
NoSQL  (0) 2014.11.28
Hadoop 이란  (0) 2014.11.28

+ Recent posts