빅데이터 처리에 쓰이는 하둡이란 무엇인가?

빅데이터 시스템 기초개념 잡기

8 min readJun 29, 2021

목차
* 빅데이터를 다루는 작업
* 빅데이터
* 빅데이터 시스템의 구성
* 빅데이터 시스템의 근간: 하둡
- HDFS
- MapReduce

참고 서적

Do it! 직접 해보는 하둡 프로그래밍 - YES24

하둡, 이론에 그치지 않고 빅데이터로 실습하며 배우는 책! 저자는 2006년 부터 2011년까지 야후 본사에 근무하면서 하둡 관련 프로젝트를 진행했고 최근까지 국내외 기업의 하둡 관련 컨설팅을 진행하면서 하둡과…

m.yes24.com

빅데이터를 다루는 직업

데이터 엔지니어: 이 글에서 소개되는 빅데이터 시스템을 구축하는 엔지니어. 소프트웨어 엔지니어링적인 노력이 필요함.
데이터 과학자: 빅데이터 시스템 운영. 프로그래밍 기술 외에도 수학/통계 등의 지식, 해당 비즈니스 도메인에 대한 이해가 필요합니다. 데이터를 보고 그 데이터를 바탕으로 어떤 가설을 세운 다음, 가설을 바탕으로 모델을 만들고, 그걸 실제로 검증하고 꾸준히 개선하는 일을 하게 됩니다. 프로그래밍 스킬이 꼭 필요한 것은 아니지만, 남의 도움 없이 일을 빨리 진행하려면 적어도 프로토타이핑을 할 수 있는 프로그래밍 스킬이 큰 도움이 됩니다.

빅데이터

서버 한대로 처리할 수 없는 규모의 데이터 (아마존의 데이터 과학자인 존 라우저가 내린 빅데이터에 대한 간결한 정의-2012) → 분산 환경의 필요성
기존의 소프트웨어(오라클이나 MYSQL 같은 관계형 데이터 베이스)로는 처리할 수 없는 규모의 데이터
→ NoSQL 이나 하둡 등의 분산 환경 시스템의 스케일 아웃 방식으로 해결
3V(Volume, Velocity, Variety) + Variability
예시: 웹 검색엔진 데이터, 검색어 로그와 클릭 로그 데이터, 디바이스에서 생성되는 데이터, 소셜미디어의 데이터
대용량 데이터의 중앙 수집과 데이터 접근 민주화로 인해 빅데이터 시스템은 발전하고 있다.

빅데이터 시스템의 구성

1. 데이터 수집 모듈

데이터 수집 관련 오픈소스 Flume
에이전트라는 모듈을 데이터를 발생시키는 서버와 그 데이터를 수집하는 모듈들에 설치하고 그것들 사이를 연결하는 형태로 데이터를 이동시킴.
하나의 에이전트 내부에는 데이터를 받아들이는 하나의 소스와 받아들이는 데이터를 잠시 저장해주는 채널, 데이터를 최종적으로 다음 에이전트로 포워드해주는 싱크가 존재
분산 환경에서 메시징 기반으로 구성된 카프카(Kafka)

2. 데이터 저장 및 처리 모듈

하둡: 어떤 형태이든 모인 데이터를 저장하고 처리하는 역할을 담당하는 것.
→ 오픈소스, 스케일 아웃 방식
→ 처리하고자 하는 입력 데이터 파일의 데이터 블록을 갖고 있는 서버들을 골라서 그 서버에 코드를 보내고 코드를 실행하려 하는 것 (데이터가 있는 곳으로 코드를 이동)
→ 병렬 처리를 가능하게 해주는 단순한 데이터 모델(데이터는 레코드의 집합, 레코드는 키-레코드자체-와 밸류-작업할 데이터-를 가짐)
→ 오프라인 배치 프로세싱에 최적화(적은 수의 큰 데이터 파일들을 오프라인에서 배치로 처리하는 데 적합. 하지만 실시간 처리는 다른 모듈이 필요)

하둡은 다음 두 가지 모듈로 구성된다.
1) HDFS(Hadoop Distributed File System)이라고 부르는 분산파일 시스템
2) Map Reduce 라고 부르는 분산처리 시스템

3. 처리 데이터 액세스 모듈

실시간 데이터 액세스를 위한 외부 컴포넌트

기존 관계형 데이터베이스
NoSQL: 정의된 스키마와 같은 제약이 없어, 동적으로 새로운 필드를 추가하고 삭제하는 것이 가능하다. NoSQL은 분산 환경을 염두에 두기 때문에 처리할 수 있는 양이나 트래픽이 훨씬 더 거대합니다.
검색엔진

4. 작업 워크 플로우 관리 정의 모듈

하둡으로 원하는 작업을 수행하고자 하는 경우, 대부분 여러개의 Job들을 이어붙여서 실행해야만 합니다. 이런 Job들은 주기적으로 실행되든지 아니면 어떤 조건이 만족되면 실행되어야 하는 경우가 많습니다.

5. 데이터 시각화 모듈

모든 빅데이터 처리의 첫번째 작업은 데이터를 이해하는 것
→ 데이터의 특성 뿐 아니라 데이터가 올바르게 저장되고 있는지도 확인해야 한다.
→ 데이터 시각화르르 통해서 데이터의 패턴을 볼 수 있고, 그럼으로써 패턴을 위반하는 것들(흔히 Outlier라 불리는 것들)이 뭐가 있는지도 직관적으로 쉽게 알 수 있다.

빅데이터 시스템의 근간: 하둡

구글에서 발표한 두개의 논문들: Google File System, Map Reduce
이후 아파치 소프트웨어 파운데이션에서 아파치 하둡이라는 하둡 배포판을 공격적으로 발표하고 있다. 이 외에도 클라우데라, 홀튼웍스(야후), 맵알이라는 회사에서 하둡 배포판을 제공하고 있다.

활용

병렬도가 높은 단순 작업 ex) 이미지 포맷 변환
로그 분석
머신러닝

부적합한 경우

리얼타임 데이터 스트림 처리
반복실행이 많이 필요할 경우 오버헤드가 발생함
네트워크 대역폭보다 데이터 전송량이 너무 큰 경우 병목 지점 발생

HDFS: 분산파일 시스템

마스터(네임노드) / 슬레이브(데이터노드) 구조의 분산 파일 시스템
하나의 HDFS는 하나의 네임스페이스를 제공
→ 하나의 네임스페이스를 제공한다는 의미는 모든 사용자가 하나의 동일한 루트에서 시작하는 파일 시스템이라는 것

특징

파일을 여러개의 블록으로 나누어 저장한다.
한 블록의 크기는 64MB, 실제 프로덕션 환경에서는 128MB를 많이 사용
파일 하나는 적어도 하나의 블록을 가져야 하므로, 큰 파일을 다룰 때 사용
하부 운영체제의 파일 시스템을 그대로 사용한다.
서버 운영체제의 파일 시스템을 그대로 사용하여 구현된 분산환경의 파일 시스템
하드웨어가 고장나도 문제를 해결할 수 있다.
네임노드가 특정 데이터 노드에 문제가 발생한 것을 알면 바로 그 데이터 노드에 있던 데이터 블록들을 다른 데이터 노드들로 복제함. 언제나 정해진 복제본 개수를 준수하면서 로드를 적절히 서버들 간에 분배하려고 함
Write Once, Read Many
하둡 2.0부터 가능해진 데이터를 추가하는 작업
다른 시스템의 기본 구성 블록
HDFS는 스토리지 시스템으로 사용
ex) MapReduce와 NoSQL 중의 하나인 HBase
웹에서 접근 가능

네임노드

HDFS마다 단 하나(하둡 2.0 이전 버전)만 존재하는 마스터로 HDFS에 저장되는 각종 파일과 디렉토리들의 메타 정보를 관리하고 실제 데이터는 다수의 데이터 노드에 분산 저장하는 역할을 담당

2차 네임노드와 체크 포인트
네임노드에 문제가 발생하여 이를 복구해야 할 일이 발생하면 하둡 클러스터의 관리자는 2차 네임 노드에 마지막 체크포인트가 된 파일 위에 네임노드에 있는 에디트로그를 리플레이해서 HDFS 를 마지막 최종 상태로 복구하게 된다.
네임노드와 데이터노드간의 통신
하트비트(Heartbeat): 주기적으로 데이터 노드가 네임 노드에게 현재 상태를 보고하게 됨

HDFS I/O

읽기: HDFS 클라이언트는 네임노드와 통신하여 읽고자 하는 파일의 이름을 넘기고 네임노드로부터 해당 파일의 데이터 블록 위치 리스트를 얻어옴. 클라이언트는 이후 네임노드의 간섭없이 데이터 노드들과 직접 통신하여 데이터 블록을 차례대로 읽어들이게 됨.
쓰기: 네임노드는 실제 데이터 복제 과정에는 참여하지 않고 HDFS 클라이언트가 복제본 개수 만큼의 복제를 직접 시도 하지 않고 데이터 노드들을 통하여 차례로 수행하는 파이프라인의 형식의 방식을 채택함.
접근(액세스): HDFS 라이브러리를 이용하여 프로그램을 작성하거나 하둡 셸 커맨드를 이용

Map Reduce 프레임워크: 분산처리 시스템

마스터(잡 트래커) / 슬레이브(태스크 트래커) 구조의 분산 처리 시스템

특징

데이터가 있는 서버로 코드를 전송
데이터를 키/밸류 데이터셋의 변환으로 처리
→ 맵 태스크: 입력 데이터를 하나 이상의 조각으로 나눈 후 그것들을 데이터 조각의 수만큼 서버에서 각기 병렬 처리하는 것(key,value → key,value)
→ 리듀스 태스크: 맵 태스크로부터의 출력을 모아서 최종 처리하는 과정(key,value → key,value 프로그래머가 HDFS 상의 위치에 저장)
프레임워크가 같은 키를 갖는 페어들을 묶는 것을 알아서 해주기 때문에 프로그래머는 그에 대해서 신경쓸 필요가 없고 키/밸류 페어들의 집합을 어떻게 처리할 것인지만 고민하면 된다.

잡 트래커

Job: 하나의 Map Reduce 프로그램
→ 하나의 잡은 보통 하나의 맵 태스크와 하나 이상의 리듀스 태스크로 구성됩니다.
잡트래커: 하둡 MapReduce 프레임워크의 마스터 서비스로 사용자로부터 하둡 잡 실행 요청을 받아 이 잡의 태스크들을 해당 Map Reduce 클러스터 내의 태스크 트래커들로 나눠서 실행하고 그것들이 종료될 때까지 관리하는 역할을 합니다.
데이터와 출력 데이터 위치는 반드시 HDFS(혹은 호환 가능한 파일 시스템) 상에 존재해야 하고, 태스크 트래커들은 데이터 노드들과 같은 물리적인 서버에 존재해야 합니다.
태스크 트래커는 각 태스크마다 별개의 JVM을 할당하고 자식 프로세스로 실행합니다.

잡 트래커와 태스크 트래커 간의 통신

네임노드와 데이터 노드들처럼 잡 트래커는 주기적으로 태스크 트래커들에게 현재 상황에 대한 보고를 받습니다. (하트비트)

만일 태스크 트래커로부터 하트비트가 지정된 시간동안 안오면 잡트래커는 해당 태스크 트래커가 죽은 것으로 간주하고 그 태스크 트래커에서 돌던 태스크들은 다른 태스크 트래커에서 다시 수행하게 됩니다.

잡 스케줄러

클러스터에 여러 잡을 동시에 실행하게 됩니다. 하둡은 잡 스케줄러를 쉽게 교체 가능하도록 플러그인 구조를 갖고 있기 때문에 누구나 TaskScheduler를 구현할 수 있다면 자신의 스케줄러를 만들 수 있습니다.

FIFO 스케줄러
야후의 Capacity 스케줄러
페이스북의 Fair 스케줄러