[Flume, Kafka] 개념 및 아키텍처

1. Flume

개념

원천에 있는 데이터들(파일형태, DB형태, 소켓에서 넘어오는 데이터, API를 통해 만들어지는 데이터 등)를 수집할 때 프로토콜, 메시지포맷, 발생주기, 데이터 크기 등을 고려해서 수집하고 적재해야 하는데 이러한 과정들을 자동적으로 편리하게 수집, 적재해주는 기능을 하는 것이 플럼이다.

주요 구성요소는 다음과 같다.

-Source(수집담당): 다양한 원천 데이터를 수집하기 위해 Avro, Thrift, JMS, Spool Dir, Kafka 등 여러 주요 컴포넌트를 제공하며 수집한 데이터를 Channel로 전달한다.

 

-Channel(소스와 싱크의 중간다리): Source와 Sink를 연결하며, 데이터를 버퍼링하는 컴포넌트로 메모리, 파일, 데이터베이스를 채널의 저장소로 활용한다.

 

-Sink(적재담당): 수집한 데이터를 Channel로부터 전달받아 최종 목적지에 저장시켜준다. 

HDFS, Hive, Logger, Avro, ElasticSearch, Thrift 등을 제공

 

-Interceptor(수집데이터 전처리): Source와 Channel사이에서 데이터 필터링 및 가공하는 컴포넌트로서 필요시 사용자가 직접 정의한 interceptor를 사용할 수 있다.

 

-Agent(플럼구성요소의 집합): Source -> (Interceptor) -> Channel -> Sink로 구성된 일련의 과정들을 한 묶음으로 플럼의 에이전트라고 한다.

 

 

아키텍처

1

플럼에이전트

소스 -> 채널 -> 싱크

 

2

플럼에이전트

소스 -> 인터셉터 -> 채널 -> 싱크1 -> 하둡

                                      싱크2 -> DB

 

3

플럼에이전트1 -> 플럼에이전트2

                    -> 플럼에이전트3

 

4

---

2. Kafka

개념

원천에서 대규모로 발생하는 작은 데이터들은 초당 수백에서 수천건에 달할 수 있다.
이러한 데이터를 동기화 처리하기에는 무리가 있다.
따라서 이들을 비동기 처리하는데 중간에 Queue나 Topic을 배치해서 버퍼의 역할을 해줘야 한다.
이러한 버퍼의 역할을 하는 것이 Kafka이다.

즉, Kafka는 수집단계에서 버퍼역할 및 트랜잭션 처리를 해주는 기능을 가지고 있다.

 

Kafka 아키텍처는 모두 Zookeeper를 이용해야 한다.

 

Kafka의 구성요소는 다음과 같다.

 

-Broker: Kafka의 서비스 인스턴스이다. 즉, Topic을 담고 있는 집합이라고 생각하면 된다. 하나의 버퍼가 되는 것이다.

 

-Topic: Broker에서 데이터의 발생/소비(송신)을 처리하는 중간 저장소이다. 데이터들이 해당 Topic에서 잠시 저장되었다가 필요한 시점에 내보낼 수 있는 공간이다.

 

-Partition : 메세지는 Topic으로 분류되고 Topic은 여러 개의 Partition으로 나눠질 수 있다. Partition내의 한 칸은 로그라고 불린다. 데이터는 한 칸의 로그에 순차적으로 append된다. 메세지의 상대적인 위치를 나타내는게 Offset이다. 배열에서의 Index와 같다.

 

-Provider: Broker의 Topic에 데이터를 전송해주는 역할을 한다.

 

-Consumer: Broker의 특정 Topic이 보내는 데이터를 수신받는 역할을 한다. 또한 consumer그룹은 consumer들의 집합이다. 
또한 Consumer 그룹은 하나의 topic에 대한 책임을 갖는다. 

 

 

*참고사항

하나에 topic에 여러개의 partition을 나눠서 쓰는 이유

대용량의 메시지를 처리하는데 Topic내에 하나의 Partition 로그에 데이터가 append되면 시간이 굉장히 많이 걸린다.

따라서 Partition을 여러 개 두어서 메세지를 처리한다.

주의할 점으로 Partition을 늘리면 다시 줄일 수 없고 여러 개의 partition이 있으면 consumer가 메세지를 소비할 때 순차적으로 소비하는 것이 아니라 순서에 상관없이 소비한다.

따라서 메시지 소비 순서가 중요한 모델(증권 등)이라면 partition을 늘리는 것을 주의해야 한다.

 

아키텍처

1. 기본

 

2. 멀티브로커/싱글노드

 

3. 멀티브로커/멀티노드