[Hadoop_기초]Udemy course - 섹션 9. Kafka & Flume

80강. Kafka 설명

스트리밍이란?

스트리밍은 웹로그나 센서 데이터 등의 소스에서 데이터를 가져오는 것으로, 데이터를 거의 실시간으로 수집하는 것을 말한다. 

즉 기존의 hive, pig , spark 등은 이미 데이터 스토리지에 데이터가 들어와있는 상태이며 이를 다른 곳으로 이관하는 상황에서 사용되었다.

 

그러나 클러스터에 담겨있는 것이 아닌 실시간으로 데이터가 들어오고 즉시 처리되어야 하는 경우가 있는데, 이럴 때 스트리밍 기술을 사용하는 것이다. 

 

스트리밍 활용 시 고민해야 할 부분

1.  어떻게 많은 데이터 소스에서 클러스터로 데이터를  전달할 수 있을까? 
   따라서 이를 위해 안정적이며 규모있는 클러스터와 그 메커니즘이 필요하다. 
2.  이렇게 수집한 로그 데이터를 어떻게 활용할 것이냐?

즉 첫 번째는 기술적인 고민이며, 두 번째는 좀 더 데이터 활용적인 고민이다. 

 

Kafka란?

-> publish/subscribe messaging system(메시지 발행/인용 시스템)

가장 대표적인 기술인 Kafka는 데이터가 생성되는 즉시 데이터 스토리지에 가져올 수 있다. 

즉 실시간 데이터 수집 기술이라고 볼 수 있다. 

HDFS 즉 하둡 파일 시스템 외에도,  HBase나 다른 데이터베이스에도 실시간으로 데이터를 저장할 수 있다. 

즉 하둡 만의 스트리밍 기술이 아니다.

 

스트리밍 기술은 빅데이터를 한 곳에 쌓아두었다가 일괄/주기적으로 배치 처리하는 대신 실시간으로 흘러들어오는 데이터를 즉시 처리하며 저장해나가는 것이 핵심이다. 

 

 

kafka의 서버는 발행자 즉 데이터 소스(웹 서버, 센서 등)로부터 오는 모든 데이터를 일정 기간동안 저장하고,

데이터가 저장됨과 동시에 "토픽"이라고 불리는 데이터 스트림에게 저장한 데이터를 발행 즉 보낸다. 

 

위의 아키텍쳐에서 알 수 있듯이 kafka 클러스터는 다양한 서버에서 실행되는 다수의 프로세스를 처리하고 분산한다. 

 

producer

producer는 데이터를 만들어 내는 주체로서 로그를 만드는 앱 서비스일 수도 있고 새로운 센서 데이터를 수신하고 있을수도 있다.

이렇게 수신하면서 데이터를 클러스터에 집어넣는 역할을 한다. 

consumer

kafka의 consumer는 하나 이상의 토픽을 인용하는데, 이 때 인용한 지점을 기억한다.

따라서  consumer의 작업에서 장애가 발생해도 기억한 지점으로 찾아돌아올 수 있는 것이다. 

만약 작업 도중에 접속을 끊거나 과거의 어떤 지점으로 재개하고 싶어도 가능하다. 

 

consumer는 producer가 메지시를 토픽에 발행하면 그 토픽을 인용하여 들어오는 데이터를 받아들인다.

그리고 Kafka 라이브러리에 연결되어 데이터를 어떤 방식으로 읽거나 쓰고 처리한다. 

이 consumer는 여러 서비스가 될 수 있는데 대표적으로 spark streaming앱은 kafka클러스터의 특정한 토픽과 소통하도록 구성되어있다. 

connector

 connector의 경우, 다양한 데이터 베이스와 연결하기 위한 플러그인 모듈이다. 

이럴 활용함으로써 토픽에 메시지를 발행할 때 데이터베이스에 새 열을 만들거나 그 메시지를 수신할 수 있다. 

어떤 데이터 베이스가 kafka에 어떠한 변화를 발행하거나 반대로 kafka의 변화를 수신해서 데이터베이스 내의 새 행으로 가져오도록 설정할 수 있다. 

 

또는 producer의 데이터를 kafka에 끊임없이 발행하고 싶을 때 사용할 수도 있다.

stream processor

producer가 웹서버에서 구조화되지 않은 원시 웹 로그 라인을 만든다고 할 때 stream processor가 그 로그 데이터에서 새 로그 라인을 수신하고 필요한 정보를 간결하고 구조화된 양식으로 추출해서 kafka의 새 토픽에 다시 발행한다. 

 

예를 들어, kafka가 있고 여기의 producer들이 웹 서버로부터 새 로그를 수신하고 있다.

stream processor가 그 로그 항목을 실시간으로 처리해서 필요한 정보를 추출한다. 

이를 새 토픽에 발행하고

connector를 통해 데이터베이스에 안정적으로 보관한다. 

 

Kafka의 확장

클러스터에 걸쳐 분산될 수 있다. 즉 단일 실패지점이 없다.

다수의 프로세스를 실행하는 다수의 서버가 존재한다. 

이러한 분산 시스템들은 kafka에 연결된 모든 발행자와 인용자의 데이터를 토픽에 나눠서 저장하거나 처리한다. 

 

위의 그림처럼 consumer를 분산할 수도있다.

kafka가 어떤 토픽을 인용하는 소비자 그룹에게 데이터를 발행하면 전체 그룹은 그 처리를 분산해서 진행한다. 

또한 분산된 각 consumer 서버는 각 메시지의 복사본을 가지게 된다. 

 

 

81~82강. [실습]  

81강.  kafka 설정 및 데이터 게시하기

82강. kafka로 웹 로그 게시하기

 

83강. Flume 설명

데이터를 클러스터로 스트리밍해서 처리하는 또 다른 방법이다.

 

그러나 kafka와의 가장 큰 차이점은 flume은 hadoop에서만 사용된다. 

flume에는  hdfs, hbase 등 하둡 생태계의 시스템에 데이터를 기록하기 위해 연결할 내장 싱크(sink)가 있다. 

 

원래는 로그 집계 문제를 다루기 위해 개발되었다. 

가령 대규모 웹사이트의 웹서버 집단이 있는데 그 웹 서버 로그의 모든 데이터를 한 곳으로, 즉 hdfs 하둡 클러스터로 모아야 했다. 

그렇다고 로그를 바로 하둡 클러스터에 저장할 수는 없다.

 

여러 웹 서버와 HDFS 하둡 클러스터 사이에서는 완충제가 필요한데, 그 이유는 하둡 클러스터가 한 번에 여러 곳에 연결되는 것을 싫어하기 때문이다. 

특히나 로그 트래픽은 일정치 않기 때문에 더욱 직접 연결하여 데이터를 전달할 수 없다. 

 

flume과 같은 시스템은 중간에서 일종의 완충제 역할을 하여, 데이터가 생산되고 적재되는 곳 사이에서 

클러스터를 다운시키지 않고 안정적으로 데이터를 전달한다. 

 

Flume Agent

flume 에이전트에서 source, channel, sink 세 개의 요소가 핵심이다.

다양한 종류의 소스와 싱크를 구성해서 다양한 데이터 소스와 데이터 목적지에 연결할 수 있다.

 

flume에서 소스가 웹 서버의 로그 디렉터리에 수신되는 웹 서버 로그를 수신한다. 

이렇게 수신한 로그 데이터를 메모리나 파일 채널을 통과하여 싱크에 전달하고, 싱크는 그 데이터를 hdfs 나 다른 하둡 클러스터의 데이터 스토리지에 작성한다.

source

 데이터가 오는 곳이다. 

즉 위의 그림처럼 웹서버와 연결되어서 데이터를 가장 먼저 수집하는 곳이다. 

 

몇가지 옵션이 있는데,

1. 채널 선택기에 고정해서 로직을 소스에 첨부할 수 있다. 그러면 관찰되는 데이터를 어디로 보내질지 결정할 수 있다.

2. 아니면 소스의 일부로 인터셉터를 가질 수 있다. 인터셉터는 들어오는 데이터를 다시 보내기 전에 추가하거나 변형한다. 

channel

소스와 싱크 사이에서 데이터가 어떻게 전달되는지 결정한다.

1. 하나는 메모리를 통해서, 가장 빠른 방법이다.

2. 또 다른 방법은 파일을 통해서 -> 데이터의 지속적인 전달을 위해서 이 방법이 좋다. flume서버가 다운되어도 회복가능

 

그러나 대부분의 경우 메모리로도 충분하다. 

 

sink

데이터가 어디로 가거나 저장되는지를 결정하며, 에이전트의 일부로 다수의 싱크를 가질수 도 있다.

그러나 싱크는 하나의 채널에만 연결할 수 있다. 

즉 kafka와 이 점이 다르다.

 

또한 kafka는 데이터를 무기한으로 저장하고 사람들이 원하는 때에 데이터를 꺼내올 수 있다. 

즉 데이터 스토리지 역할 또한 가능하다. 특정 기간 후에 임의로 데이터를 파기하거나 계속 둘 수 있다.

그러나 flume은 싱크가 데이터를 채널에서 가지고 오면 바로 삭제한다. 

 

이에 따라 데이터가 다수의 위치와 다양한 전송률로 전송된다면  kafka가 구성하기에 좀 더 쉽다.

-> avro는 하둡의 특정한 소통양식이다

->  kafka를 소스 혹은 싱크로 연결할 수 있다. 

 

Multi-tiered-fan-in

위의 구조로 디자인할 수 있다는 점이 flume의 장점이다.

 

대량의 로그 트래픽을 생산하는 다수의 애플리케이션 서버가 있다.

이들은 먼저 서버와 물리적으로 가까운 1 tier flume agent에게 간다. 

네트워크 토플로지의 입장에서는 이 앱 서버들이 데이터를  flume 에이전트로 내보냄에 따라 수 많은 네트워크 트래픽을 만들어낸다. 

그리고 또 다른 레이어가 있다.

그 다음에는 더 적은 수의 2 tier flume agent가 있으며, 이를 통해 최종적으로 하둡 클러스터에 데이터를 적재한다. 

 

이런 류의 아키텍쳐는 확장성이 있으며 유연하다

 

보통 이런 아키텍쳐에서는 1차 레이어에서 avro 싱크를 구성하고 다음 에이전트에게 효율적으로 전달할 수 있다. 

 

데이터 전달 과정에서 데이터 트래픽이 너무 많아서 1차적으로 hdfs 데이터 스토리지에 지연이 생긴다고 하면,

그 다음에는 중간의 flume에도 지연이 생기기 시작한다.

이렇게 이벤트를 처리할 공간이 모자라기 시작하면, 결국 에이전트와 연결을 거부하는 문제가 생기므로

flume를 디자인할 때 일정정지기간동안 각 레이어의 한계를 초과하지 않도록 설계해야 한다. 

 

 

84~85강. [실습]

84강. flume을 설정하고 로그 게시하기

85강. flume으로 디렉터리를 감시하며 그 데이터를  HDFS에 저장하기