대용량 비정형 데이터 처리
더 많은 작업
- Large-scale Unstructured Data Processing; 대용량 비정형 데이터 처리
- 로그·텍스트처럼 형식이 정해지지 않은 대량의 데이터를 수집하고, 분산 저장·병렬 처리하고, SQL로 질의할 수 있게 만드는 기술들
관계형 DB와 ETL은 형식이 정해진 정형 데이터를 다루는 데 맞춰져 있다. 웹 서버 로그, 센서 데이터, 문서 같은 비정형 데이터는 양이 매우 많고 쉼 없이 생기며 스키마가 일정하지 않아 같은 방식으로 처리하기 어렵다. ADP 필기 2과목의 세부항목 '대용량 비정형 데이터 처리'는 이런 데이터를 다루는 흐름을 다음 네 가지로 나눠 본다.
| 단계 | 하는 일 | 대표 기술 |
|---|---|---|
| 대용량 로그 데이터 수집 | 여러 서버에서 생기는 로그를 모아 한곳(중앙 저장소)으로 옮김 | 플럼(Apache Flume) |
| 대규모 분산 병렬 처리 | 여러 대의 서버에 데이터를 나눠 저장하고 동시에 처리 | 하둡(HDFS, 맵리듀스) |
| 데이터 연동 | 관계형 DB의 정형 데이터와 하둡 사이에서 데이터를 주고받음 | 스쿱(Apache Sqoop) |
| 대용량 질의 | 하둡에 저장된 데이터를 SQL로 조회 | SQL-On-Hadoop: 하이브, 임팔라 등 |
로그 수집기는 수많은 서버에서 계속 생기는 로그를 빠짐없이 모아 HDFS 같은 저장소로 옮기는 일을 한다. 아파치 플럼 공식 문서는 플럼을 "여러 원천에서 나오는 대량의 로그 데이터를 효율적으로 수집·집계하여 중앙 저장소로 옮기는 분산형의 신뢰성 있고 가용성 높은 시스템"이라고 소개한다. 로그 수집기에 요구되는 특성은 다음과 같다.
| 특성 | 의미 |
|---|---|
| 초고속·대용량 | 많은 서버에서 동시에 쏟아지는 대량의 데이터를 지연 없이 받아 넘길 수 있어야 함 |
| 확장성 | 수집 대상 서버가 늘어나면 수집 에이전트도 쉽게 늘려 붙일 수 있어야 함 |
| 신뢰성 | 전송 중 장애가 생겨도 데이터가 사라지지 않아야 함 |
| 가용성 | 일부 구성 요소가 멈춰도 수집이 계속되어야 함(장애 조치 경로) |
플럼 에이전트는 소스(Source), 채널(Channel), 싱크(Sink) 세 부분으로 이루어진다. 소스가 이벤트를 받아 채널에 넣으면 채널은 싱크가 가져갈 때까지 이벤트를 보관하고, 싱크는 이를 HDFS나 다음 에이전트로 보낸다. 플럼은 소스·싱크가 채널에 넣고 꺼내는 일을 트랜잭션으로 묶어 이벤트 전달을 보장하며, 파일 채널을 쓰면 에이전트가 죽어도 이벤트를 되살릴 수 있다. 메모리 채널은 더 빠르지만 에이전트가 죽으면 남아 있던 이벤트를 잃는다. 여러 에이전트를 이어 붙이는 다중 홉(multi-hop) 구성, 하나로 모으는 팬인, 여러 곳으로 나누는 팬아웃, 장애 시 다른 경로로 보내는 페일오버 구성도 지원한다.
하둡은 값싼 범용 서버 여러 대를 묶어 큰 데이터를 저장하고 처리하는 오픈 소스 프레임워크다. 구글의 GFS와 MapReduce 논문의 아이디어를 바탕으로 한다.
- HDFS: 파일을 큰 블록(일반적으로 128MB)으로 나눠 여러 데이터노드에 저장하고, 블록마다 기본 3개의 복제본을 둔다. 네임노드가 파일 이름과 블록 위치 같은 메타데이터를 관리한다.
- 맵리듀스: 입력을 여러 조각으로 나눠 맵(Map) 작업이 병렬로 처리하고, 그 결과를 키별로 모아 리듀스(Reduce) 작업이 집계한다. 데이터가 있는 노드에서 계산을 실행해 네트워크 전송을 줄인다.
- 노드 하나가 고장 나도 다른 복제본과 작업 재실행으로 처리를 이어 간다. 서버를 더 붙이면 처리 용량이 늘어나는 수평 확장(scale-out) 구조다.
분석에는 비정형 데이터뿐 아니라 고객·주문처럼 관계형 DB에 있는 정형 데이터도 함께 필요하다. 스쿱은 관계형 DB와 하둡 사이에서 대량의 데이터를 옮기는 도구다. DB 테이블을 HDFS·하이브·HBase로 가져오는 import와, 하둡에서 처리한 결과를 다시 DB 테이블로 내보내는 export를 지원하며, 내부적으로 맵리듀스 작업을 여러 개 띄워 병렬로 전송한다. 스쿱 프로젝트는 2021년 아파치 소프트웨어 재단에서 은퇴하여 Apache Attic으로 옮겨졌다. 자세한 내용은 아파치 스쿱 문서를 참고한다.
맵리듀스 프로그램을 직접 짜는 일은 번거롭다. 그래서 하둡에 저장된 데이터를 SQL로 다루는 SQL-On-Hadoop 기술이 나왔다.
| 기술 | 특징 |
|---|---|
| 하이브(Apache Hive) | 분산 저장소의 데이터를 SQL(HiveQL)로 읽고 쓰고 관리하는 분산 데이터 웨어하우스 시스템. 테이블 정의 같은 메타데이터를 메타스토어에 두고, 질의를 분산 처리 작업으로 바꿔 실행한다. 대량 일괄 처리에 맞다. |
| 임팔라(Apache Impala) | 맵리듀스를 거치지 않고 전용 분산 질의 엔진이 HDFS나 HBase의 데이터에 직접 접근한다. 하이브와 같은 메타데이터와 SQL 문법을 쓰며, 대화형(실시간에 가까운) 질의를 목표로 한다. |
| 스파크 SQL | 스파크의 메모리 기반 분산 처리 위에서 SQL과 데이터프레임 연산을 수행한다. |
하이브는 일괄 처리형 분석에, 임팔라는 짧은 응답 시간이 필요한 대화형 분석에 주로 쓰인다는 대비가 시험에 자주 나온다. 임팔라 공식 소개는 맵리듀스를 우회하여 지연을 줄였기 때문에 질의 종류와 구성에 따라 하이브보다 훨씬 빠른 성능을 낸다고 설명한다.
웹 서비스의 접속 로그를 분석하는 경우를 예로 들면 흐름은 다음과 같다.
- 각 웹 서버에 둔 플럼 에이전트가 접속 로그를 수집해 HDFS에 저장한다.
- 회원 정보는 스쿱으로 관계형 DB에서 HDFS(또는 하이브 테이블)로 가져온다.
- 맵리듀스나 스파크로 로그를 정제하고 세션 단위로 집계한다.
- 하이브나 임팔라로 로그 집계 결과와 회원 정보를 조인해 SQL로 분석한다.
- 필요한 결과는 스쿱 export로 업무용 DB에 되돌려 보낸다.
- 로그 수집기의 요구 특성(초고속·대용량, 확장성, 신뢰성, 가용성)과 대표 도구인 플럼을 기억한다.
- 단계별 대표 기술 짝짓기: 수집은 플럼, 분산 저장·처리는 하둡(HDFS, 맵리듀스), RDBMS 연동은 스쿱, SQL 질의는 하이브·임팔라.
- 하이브는 SQL을 분산 처리 작업으로 바꿔 일괄 처리하고, 임팔라는 맵리듀스를 쓰지 않는 전용 엔진으로 대화형 질의를 한다는 차이를 구분한다.
- 하둡의 수평 확장(scale-out), 복제를 통한 장애 대응, 데이터가 있는 곳에서 계산한다는 원칙을 이해한다.