[빅데이터] 빅데이터 분석 단계

출처 : https://book.naver.com/bookdb/book_detail.nhn?bid=14412152 

빅데이터 분석과 활용

*해당 글은 학습을 목적으로 위의 도서 내용 중 일부 내용만을 요약하여 작성한 포스팅입니다.

 상세한 내용 및 전체 내용 확인을 원하신다면 도서 구매를 추천드립니다.

 

 

빅데이터 분석의 전체 과정

빅데이터 분석 단계

빅데이터 분석 과정은 데이터를 모으는 수집, 이를 저장하는 저장, 통계, 텍스트 마이닝, 머신러닝 등을 활용한 분석, 그리고 이를 전달하는 리포팅&시각화 단계가 있다.

 

이에 대해 단계별 솔루션의 특징과 사용 방법을 정확하게 인지하고 있다면 빅데이터 솔루션을 조합하고 구성할 수 있다.

 

 

 

 

1) 수집 단계

1-1) 플럼 (Flume)

플럼은 클라우데라에서 제작되어 아파치 재단에서 관리중인 로그 수집기이다.

대량의 이벤트 데이터를 전송하기 위해 사용되며, 간결한 아키텍처를 가지고 있어 유지보수 및 확장성이 뛰어나다.

 

소스, 채널, 싱크 구조로 이루어져 있으며, 소스는 데이터 변환, 채널 지정 역할을 수행하고 채널은 데이터를 임시 보관하는 큐 역할을 수행한다. 그리고 싱크는 채널로부터 이벤트를 받아 전달하는 역할을 수행한다.

 

 

 

1-2) 척와 (Chukwa)

척와의 데이터 수집 구조

척와는 분산 시스템을 모니터링하기 위한 데이터 수집기이고, 하둡 분산 파일 시스템과 맵 리듀스 프레임워크 기반에서 동작한다.

 

수집과 프로세싱 단계의 파이프라인으로 구성되어 있는데, 스테이지 간에 인터페이스를 둠으로써 기존 코드를 손상시키지 않고 코드를 작성할 수 있다.

 

척와는 어댑터, 에이전트, ETL 프로세스, 데이터 분석 스크립트, HICC로 구성되어 있다.

어댑터는 데이터를 수집하고, 에이전트는 데이터를 내보낸다. 그리고 ETL 프로세스로 데이터를 파싱하고 아카이브 한다. 그리고 데이터 분석 스크립트는 하둡 클러스터 상태를 수집하고, HICC는 데이터를 나타내기 위해 웹 포털 형태의 인터페이스를 제공한다.

 

 

 

1-3) 스쿱 (Sqoop)

 

Sql on Hadoop의 약자로, 아파치 하둡과 RDBMS 간 대량의 데이터 전송을 위해 개발된 도구이다. Import할 DB의 종류에 따라 추출 방식이 약간씩 달라질 수 있지만, 데이터 전달을 대체적으로 쉽게 자동화할 수 있다.

 

스쿱은 맵리듀스를 사용하여 데이터를 가져오고 내보낸다. 하둡에서 RDBMS로 나갈 때는 EXPORT, 반대는 IMPORT라 한다.

 

클라이언트는 메타 데이터를 읽고 하둡의 매퍼만이 수행하는 잡으로 데이터를 하둡에 임포트하거나 익스포트 한다.

 

 

1-4) 스트림 셋 (StreamSet)

https://streamsets.com/blog/streamsets-data-collector-the-first-four-years/

실시간으로 데이터를 흘리는 경량의 수집 엔진.

 

연속적인 데이터 흐름 속에서 데이터 프로세싱이나 라우팅을 위해 데이터 콜렉터를 사용하는데, 이 콜렉터에 데이터의 흐름을 정의하기 위해서는 파이프라인을 정의해야 한다.

 

스트림셋은 이러한 파이프라인을 웹 기반의 UI를 통해 설정하고, 모니터링하고, 리뷰할 수 있다.

 

 

 

1-5) 나이파이 (NIFI)

https://nifi.apache.org/assets/images/flow.png

나이파이는 NSA에서 만들어진 분산 환경에 최적화된 데이터 수집, 처리기이다. 나이파이의 기본적인 디자인 컨셉은 플로 그빈의 프로그래밍 기법과 같다.

 

플로파일이라는 데이터 단위를 플로파일 프로세서가 수집, 변형, 저장하는 방식으로 작동하고 커넥션은 프로세서와 프로세서를 연결해 플로파일을 전달하게 된다. 플로파일이 생성되는 플로파일 리포지토리에 속성값과 내용이 어디에 있는지 저장되고, 콘텐츠 리포지토리에 내용이 저장된다. 그리고 프로세서가 처리될 때마다 원천 리포지토리에 프로파일 이력이 남게된다.

나이파이 구조

나이파이는 JVM 위에서 실행되는데, 웹 서버, 플로 컨트롤러, 리포지토리로 구성된다.

웹 서버는 HTTP 기반 명령어를 실행하고 API를 제어한다. 플로 컨트롤러는 스레드를 관리하고, 프로세서, 컨트롤러 서비스등이 자원을 언제 사용해야 하는지 스케줄링한다.

 

 

 

1-6) 플루언트디 (Fluentd)

플루언트디 동작 구조

플루언트디는 데이터 수집과 전달을 통합하여 데이터의 이용 및 사용을 쉽게하는 데이터 수집기이다.

플루언트디를 수집 대상 서버에 설치하면 해당 어플리케이션이 로그 저장소에 데이터를 전송하는 방식으로 동작한다.

 

플루언트디 내부 구조

플루언트디는 7개의 컴포넌트로 구성된다.

인풋은 다양한 포맷의 데이터를 수집한다. (플러그인 기반) 파서는 플루언트디에서 지원하지 않는 데이터 형식을 지원하기 위해 필요하며 다양한 포맷의 데이터를 파싱할 수 있다.

필터는 아웃으로 보내기 전에 데이터를 필터링, 필드 추가, 삭제, 마스킹한다. 버퍼는 들어온 데이터를 바로 아웃풋으로 보내지 않고 조절 기능을 하는데, 파일 방식과 메모리 방식으로 수행할 수 있다. 여기서 포메터는 로그 저장소가 원하는 형태로 데이터를 변환한다.

마지막으로 아웃풋은 필터링된 데이터를 로그 저장소에 저장한다.

 

 

 

 

2) 저장

2-1) 하둡 (Hadoop)

http://hadoop.apache.org/

하둡은 분산 환경에서 대량의 자료를 저장, 처리하는 자바 기반의 오픈소스 프레임워크이다. 분산 데이터를 처리하기 위해 맵리듀스 알고리즘을 사용하고, HDFS를 활용해 데이터를 저장한다.

 

 

2-2) HBase, 피닉스 (Phoenix)

 

HBase는 하둡 파일 시스템 기반에서 작동하는 칼럼 단위의 데이터 저장, 압축, 메모리 작업이 가능한 NoSQL 데이터베이스이다. 그리고 피닉스는 HBase 위에 RDB에서 사용하는 SQL 레이어를 사용할 수 있게 하는 오픈소스 개발 도구이다.

 

간단하게 말하면 피닉스는 NoSQL인 HBase를 RDB처럼 사용할 수 있게 해준다. 또한 HBase에 특화된 푸시 다운 기능을 사용하여 사용자가 작성한 쿼리가 HBase 명령어로 컴파일되어 쿼리가 수행되게 해주어, 빠른 접근이 가능하다.

하지만 여러 분석 함수들은 피닉스에서는 제한이 되기 때문에 데이터 분석 기능의 구현에는 어려움이 있을 수 있다.

HMaster와 리전 서버 구조

HBase의 저장 구조를 이해하기 위해 HMaster와 리전 서버 (Region Server)를 이해해야 한다.

HMaster는 리전 서버들의 시작, 재할당, 복구 등의 일을 하고, 클러스터의 리전 서버들을 모니터링한다. 추가로 테이블에 대한 DDL을 수행한다.

리전 서버의 저장 구조

리전 서버는 HDFS 데이터 노드에서 실행되는데, 클라이언트와 통신하며 IO 작업을 한다.

만약 클라이언트가 데이터 저장을 요청하면 WAL (Write Ahead Log) 파일에 기록된다. 이는 데이터 저장 실패를 복구하기 위해서이다.

블록 캐시는 읽기 캐시인데, 자주 사용하는 데이터를 메모리에 저장하여 읽기 성능을 높이기 위해 사용된다.

멤스토어 (Memstore)는 쓰기 캐시이다. HDD에 기록되기 전의 데이터가 저장되는데, Key-Value 데이터를 정렬하여 저장하는데, 이 파일은 HFile에 저장된다.

WAL에 쌓인 데이터가 멤스토어에 복사되면 클라이언트는 응답을 받게 된다.

 

 

2-3) 카산드라 (Cassandra)

 

카산드라는 칼럽 기반의 데이터 모델과 분산 보델을 기반으로 한 분산 데이터베이스이다. 해시를 이용한 링 구조를 사용하여 노드의 추가, 삭제가 쉬우나 조인이나 트랜잭션을 지원하지 않고 인덱스 기능이 미비하다. 또한 과도한 키 스페이스와 테이블 생성은 메모리 오버플로우를 발생시킬 수 있다.

카산드라 데이터의 저장 구조

여기서 키 스페이스는 카산드라의 데이터 구조이다.

키 스페이스가 논리적 저장소로써 최상위에 존재하고, 그 아래에 테이블이 존재한다.

테이블은 여러 개의 로우로 구성되어 있고, 로우의 칼럽은 키/값 쌍으로 이루어져 있다.

카산드라는 링 구조를 통해 데이터를 분산하여 저장하고, 파티션 키라는 데이터를 해시하여 링 구조로 각 노드에 분산 저장한다.

여기서 파티션 키는 테이블의 로우에서 로우 키라고 생각하면 되고, 링 구조의 각 노드는 장비 하나하나라고 보면 된다.

 

 

 

4) 빅데이터 분석

4-1) 머하웃 (Mahout)

 

머하웃의 사전적 의미는 코끼리(하둡)을 모는 사람이다. 협업 필터링, 클러스터링, 분류에 초점을 맞춘 머신러닝용 라이브러리를 제공하는 프레임워크이다.

머하웃은 크게 협업 필터링, 클러스터링, 분류 기능을 제공한다.

기능	머하웃 제공 알고리즘	설명
협업 필터링	사용자 기반	사용 패턴이 유사한 사용자를 찾아 추천
	항목 기반	항목 간 유사성을 토대로 추천
클러스터링	캐노피 (Canopy)	속도가 빠른 근사적 군집 기술로, 다른 클러스터링 알고리즘의 초기 시드 작성에 사용
	K-Means	거리를 기반으로 군집화
	Mean-shift	클러스터 수를 지정하지 않고 임의의 형태로 생성
	Dirichlet	디리클레 분포에 기반을 두고 계산하는 혼합 모델링
분류	나이브 베이즈 분류	각 사건이 서로 영향을 주지 않는 독립적인 관계라고 가정하여 베이즈 정리를 기반으로 분류
	컴플리먼트 나이브 베이즈	단순성과 속도는 유지하되 나이브 베이즈에서 일부 문제 해결

 

 

4-2) 스파크 (Spark)

 

스파크는 범용 분산 환경의 고성능 클러스터링 플랫폼이다.

디스크 기반으로 수행되던 기존의 작업과 달리 인메모리 기반, 즉 메모리에서 수행하기에 빠른 데이터 처리가 가능하며, 하나의 플랫폼 내에서 배치, 스트리밍 처리, 머신러닝 등 다양한 처리 기법이 존재한다.

또한 파이썬, 자바, 스칼라 등 다양한 언어를 지원하는 SDK를 가지고 있다.

하지만 실시간 처리에 최적화 되어 있으므로 안정성을 원하는 시스템에서는 적합하지 않을 수 있다.

스파크는 여러 개의 컴포넌트로 구성된다.

스파크 코어는 병렬 분산 처리 엔진이고, 스파크 SQL은 sql을 담당한다. 이 스파크 sql을 이용하면 구조적 데이터와 반구조적 데이터를 포함한 다양한 데이터 유형을 처리할 수 있다.

스파크 스트리밍은 실시간으로 데이터를 받아 특정 작업을 고성능으로 처리한다. MLib은 머신러닝을 위해 만들어진 라이브러리이다.

그래프X는 그래프 처리를 담당한다.

 

 

 

4-3) 스톰 (Storm)

 

스톰은 트위터에서 사용하는 실시간 분석 분산 시스템으로 유명하다. 한 마디로 거대한 스케일의 스트리밍 프로세싱 플랫폼이다.

하둡에서는 데이터 처리를 위해 맵리듀스 작업을 실행하는데, 스톰에서는 이를 토폴로지 작업을 수행한다고 한다. 맵 리듀스 작업에서는 정해진 데이터 세트를 처리한 후 완료되지만 토폴로지는 스트림 처리를 위해 계속해서 메시지를 처리한다.

여기서 토폴로지는 실시간 계산 그래프인데, 토폴로지에서 각 노드는 로직 처리를 포함하고, 노드들의 링크는 어떻게 데이터가 노드를 통과해야 하는지를 나타낸다.

스톰의 스트림 처리 아키텍처

위의 그림에서 스파우트 (Spout)는 스트림 처리를 위한 작업 단위인 토폴로지와 데이터 소스로부터 데이터를 가져오고 전달한다. 그리고 볼트 (Bolt)는 데이터 처리와 저장을 담당한다.

 

또한 하둡의 잡트래커와 태스크 트래커의 역할은 님버스 데몬과 슈퍼바이저 데몬이 대신한다. 님버스는 수행 코드를 배포하고, 슈퍼바이저 노드에 작업을 할당하고, 장애 발생 시 failover 역할을 담당한다. 그리고 슈퍼바이저 노드는 할당된 토폴로지 작업의 일부를 처리할 워커 프로세스의 구동을 담당한다.

스톰의 작업 처리 메커니즘

님버스와 슈퍼바이저는 주키퍼를 이용해 장애에 대응한다. 실시간으로 생성되어 전달된 데이터 구조체를 스톰에서틑 튜블이라 정의하고, 튜플의 흐름을 스트림으로 정의한다. 스파우트는 튜블을 묶어 스트림으로 만들어 볼트에게 전달한다. 볼트는 스트림을 처리하는 로봇으로 볼 수 있는데, 볼트는 튜플을 받아 필터링, 조인 등을 통해 통계, 차트, 이벤트 등의 자료를 만든다.