빅데이터 수집 기술 소프트웨어에는 플럼과 카프카가 있습니다.
플럼과 카프카에 대해 알아보겠습니다.
플럼은 오픈소스 프로젝트로 개발된 로그 데이터를 수집하는 기술이다. 여러 서버에서 생산된 대용량 로그 데이터를 효과적으로 수집을 하여 HDFS에 데이터를 전송 및 적재를 한다. 구조가 단순하고 유연하여 다양한 유형의 스트리밍 데이터 플로우(Streaming Data Flow) 아키텍처를 구성할 수 있다. 많은 기업들에서 실제 서비스 로그 데이터 관리를 위해 사용하고 있다.
플럼의 구성요소는 아래와 같습니다.
Source | 다양한 원천 시스템의 데이터를 수집하기 위해 Avro, Thritf, JMS, Spool Dir, Kafka 등 여러 주요 컴포넌트를 제공하며, 수집한 데이터를 Channel로 전달 |
Sink | 수집한 데이터를 Channel로 전달받아 최종 목적지에 저장하기 위한 기능으로 HDFS, Hive, Logger, Avro, ElasticSearch, Thritf 등을 제공 |
Channel | Source와 Sink를 연결하며, 데이터를 버퍼링하는 컴포넌트로 메모리, 파일, 데이터베이스를 채널의 저장소로 활용 |
Interceptor | Source 와 Channel 사이에서 데이터 필터링 및 가공하는 기능 제공, Timestamp, Host, Regex Filtering 등을 기본 제공 |
Agent | Source -> (Interceptor) -> Channel -> Sink 컴포넌트 순으로 구성된 작업 단위로 독립된 인스턴스로 생성 |
플럼과 유사한 기술에는 Fluented, Scribe, logstash, Chukwa, NiFi, Embuk 등이 있다.
플럼의 아키텍처는 다음과 같이 크게 4가지 구성으로 되어있다.
첫 번째 아키텍처는 원천에 있는 파일, DB를 Source가 수집을 하여 Channel로 전송을 하고 Channel이 Sink로 전송을 하고 Sink가 하둡(HDFS)에 적재를 하는 기본적인 데이터 파이프라인이다.
두 번째 Source가 데이터를 수집해오면 Interceptor가 가공을 하고 Channel로 전송 후 각각의 Sink로 전송을 한다. 각각의 Sink는 하둡에도 저장할 수도 있고, DB에도 저장할 수 있다.
세 번째 아키텍처는 병렬로 구성을 할 수 있다. 데이터를 나눠서 처리속도를 높힐 수 있다.
네 번째 아키텍처는 수집해야할 원천 데이터가 대규모일 때 사용할 수 있는 아키텍처이다.
실시간으로 기록 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산 데이터 스트리밍 플랫폼입니다. 이는 여러 소스에서 데이터 스트림을 처리하고 여러 사용자에게 전달하도록 설계되었다. 간단히 말해, A지점에서 B지점까지 이동하는 것뿐만 아니라 A지점에서 Z지점을 비롯해 필요한 모든 곳에서 대규모 데이터를 동시에 이동할 수 있다.
원천 시스템으로부터 대규모 트랜잭션 데이터가 발생했을 때 중간에 데이터를 버퍼링 하면서 타깃 시스템에 안정적으로 전송해주는 강력한 기능과 아키텍처를 제공하는 중간 시스템이다.
Broker | 카프카의 서비스 인스턴스로서, 다수의 Broker를 클러스터로 구성하고 Topic이 생성되는 물리적 서버 |
Topic | Broker에서 데이터의 발생/소비 처리를 위한 저장소 |
Provider | Broker의 특정 Topic에 데이터를 전송(발행)하는 역할로서 애플리케이션 카프카 라이브러리를 이용해 구현 |
Consumer | Broker의 특정 Topic에서 데이터를 수신(소비)하는 역할로서 애플리케이션에서 카프카 라이브러리를 이용해 구현 |
Publisher는 메세지를 topic을 통해서 카테고리화 한다. 분류된 메시지에 받기를 원하는 구독(Subscriber)은 해당 topic을 구독(Subscriber)함으로써 메시지를 읽을 수 있다. Publisher와 Subscriber는 서로 모르는 상태지만 topic을 통해서 메시지를 주고받을 수 있다.
첫 번째 아키텍처는 1대의 카프카 서버만 설치하고, 1개의 broker만 구성을 했다. 대량의 발생/소비 요건이 없고 업무 도메인이 단순할 때 이용한다.
두 번째 아키텍처는 1대의 카프카 서버에 2개의 broker를 구성한 아키텍처입니다. 물리적인 카프카 서버가 1대이므로 역시 대량의 발행/소비 요건에는 사용하기 어렵지만 업무 도메인이 복잡해서 메시지 처리를 분리 관리해야할 때 이용한다.
세 번째 아키텍처는 주로 많이 사용하는 아키텍처이다. 물리적인 노드가 2개이고 여러개의 broker를 구성을 한다. 대량의 발행/소비 데이터 처리에 적합하며, 물리적으로 나눠진 broker간의 데이터 복제가 가능해진 안정 성성이 높다.
카프카와 플럼의 활용방안이다.
플럼이 대규모 데이터를 수집을 해오고 플럼이 카프카에 데이터를 전송을 하고 카프카가 하둡에 안정적으로 저장을 하고 관리를 해준다. 플럼은 수집하는 역할이고 카프카는 중간 버퍼 역할이다.
출처 : 실무로 배우는 빅데이터 기술 : 데이터 수집, 적재, 처리, 분석, 머신러닝까지[2판]
7. 빅데이터 실시간 적재 - HBase & Redis (0) | 2021.10.18 |
---|---|
6. 빅데이터 적재 개요 (0) | 2021.09.16 |
4. 빅데이터 수집 개요 (0) | 2021.09.13 |
3.하둡 간단한 명령어 실습 (0) | 2021.09.10 |
2. Cloudera Manager (CM) 설치 (1) | 2021.09.01 |
댓글 영역