하둡은 왜 필요할까?
우리가 RDB에 데이터를 저장할 때는 데이터를 행을 기준으로 저장하는데 이를 우리는 행 지향 데이터베이스라고 한다. RDB는 기본적으로 동시 접속에 좋은 성능을 보이고 낮은 지연시간을 가진다. 하지만 메모리의 부족에는 급격한 성능하락을 보이는 특징을 가진다. 이 때문에 DBMS의 성능을 측정할 때 메모리를 바꿔가면서 성능을 측정하게 되는 것이다.
여기서 우리가 데이터 처리의 관점에서 생각을 해보면 데이터 처리의 경우 열지향이라는 것을 생각할 수 있다. 우리가 판다스를 사용하기 편한이유는 column base로 데이터 추출이 용이하기 때문인것처럼 말이다. 이러한 열지향 데이터 베이스의 경우 다음 2가지 관점에서 수억건 이상 데이터를 저장하는 데이터 레이크에서 선호된다.
1) 특정 컬럼만 가져오기 때문에 컬럼에 대한 쿼리가 많이 들어오는 데이터 처리 관련 쿼리에 대해 오버헤드가 줄어든다.
2) 컬럼에는 유사한 데이터 들이 들어있기 때문에 이에 대한 압축 효율이 좋다.
그렇기 때문에 데이터 레코드가 수억건 이상이 되는 데이터 레이크에서는 열지향 데이터베이스(Teradata, Amazon Redshint)등을 사용하여 메모리 부족으로 인한 급격한 성능저하를 방지한다.
그럼 열지향 데이터 베이스가 무조건 좋은가? 이는 또 다른 이야기다. 열지향 데이터 베이스는 위와 같은 장점을 가지지만 각각의 쿼리들이 overhead가 크다는 단점을 가진다. 행은 record별로 데이터를 처리하기 때문에 각각의 쿼리들에 대해서 overhead가 가볍다. 따라서 이러한 열지향 데이터 베이스 처리의 overhead를 줄이기 위해 MPP(Massively parallel programming) 아키텍쳐를 많이 사용한다. MPP 아키텍쳐는 하나의 쿼리를 여러개의 sub-task로 분리하고 가능한 한 최대로 병렬로 처리하는 아키텍쳐를 의미한다.
그러면 이러한 열지향 데이터 베이스를 기반으로 해서 대규모 데이터 베이스에 대한 구축을 위해서는 무엇을 해야할까? 그때 필요한게 Hadoop이다. Hadoop은 비구조화된 데이터를 읽어들여 열지향 스토리지로 변환하는 과정에서 데이터 가공 및 압축을 위해 사용되는 분산처리 프레임 워크이다.
그렇기 때문에 다음 그림에서 알 수 있듯이 Hadoop은 분산 시스템을 구성하는 다수 소프트웨어의 집합체이다.
이번 글에서는 Hadoop 1.0에 대해 알아보고 다음 글에서 Hadoop 2.0에 대한 글을 이어나가겠다.
Hadoop 1.0
Hadoop 1.0은 분산 파일 시스템인 HDFS(Hadoop Distributed File System)와 MapReduce로 이루어져 있다.
HDFS(Hadoop Distributed File System)
대량의 파일을 효과저장해주는 파일 시스템으로 마스터&슬레이브 아키텍쳐를 가진다. 마스터는 NameNode라고 불리며 슬레이브는 DataNode라고 불린다.
Name Node
Client의 파일 접근에 대한 요청을 처리하기 위해 NameNode에서는 파일에 대한 메타 데이터를 관리한다. 이러한 메타데이터 관리를 위해 EditLog와 FSImage 파일을 사용한다.
EditLog : 메타 데이터의 변화를 기록하는 로그 파일
FSImage : 파일 시스템의 네임스페이스와 Block들에 대한 매핑 정보를 저장한다.이는 추후 DataNode에 의해 바뀌기 때문에 지속적인 저장을 하지는 않는다.
이러한 NameNode의 실패는 파일에 대한 접근을 못하게 만들기 때문에 HDFS에서는 이러한 실패에 대한 방지책으로 원격의 NFS마운트와 Secondary NameNode를 운영한다. Secondary NameNode란 체크포인팅 서버로 NameNode의 snapshot을 저장하는 역할을 하며 이를 위해 주기적으로 업데이트를 진행한다. 따라서 이를 이용하여 NameNode실패로 인해 MasterNode가 재시작이 될때 복구를 진행한다.
Data Node
실제 데이터가 쪼개져서 Block에 저장되고 이 Block들은 DataNode에 저장된다. 그리고 이러한 Block들은 속도와 안정성을 위해 Replica를 만들게 되고 보통의 경우 Replica를 다른 Rack에 저장해서 운영하게 된다. 이러한 DataNode는 주기적으로 NameNode에게 자신의 Block에 대한 레포트와 Heatbeat를 NameNode에게 전달하는데 Block 레포트는 자신의 Block들의 변경사항등에 대한 내용을 전달하고 Heartbeat는 디스크 가용공간의 정보, 데이터 이동, 적재량 정보등을 보내는데 사용된다.
MapReduce
MapReduce는 여러 노드에 Task를 분배하는 방법이다. MapReduce의 Task는 Map과 Reduce의 Phase로 나뉘게 된다. 먼저 큰 파일을 Block단위로 나누고 모든 블럭에 대해 같은 Map 작업을 수행하고 이후 Reduce작업을 수행하여 작업을 처리하게 된다. 이러한 과정을 처리하기 위해 Hadoop에서는 JobTracker와 TaskTracker라는 구성요소로 MapReduce작업을 처리하게 된다.
MapReduce작업을 설명하기에 앞써 MapReduce를 수행하기 위한 구성요소를 먼저 설명하겠다.
TaskTracker
DataNode마다 1개의 TaskTracker가 존재하고 이러한 TaskTracker는 여러 Task를 관리하게 된다.
JobTracker
TaskTracker의 리소스가 얼마나 사용가능한지, 얼마나 사용하고 있는지 등의 리소스 관리를 하며 스케줄링, 모니터링을 수행하는 Map과Reduce Job을 전송하여 분석을 진행한다. 만약 특정 Task에서 Fail이 발생하면 이를 다른 노드에 할당한다.
MapReduce 과정 설명
MapReduce의 작업은 Input - Split - Mapping - Shuffling - Reducer - Final Output 순으로 이어진다.
다음 예시는 긴 문장에서 단어들이 몇번 나왔는지 Count하는 작업에 대해서 Map Reduce를 적용했을 때의 예시이다.
MapReduce의 작업의 순서는 다음과 같다.
(1) Fork
인풋 파일이 미리 쪼개져서 시스템에 저장되었다고 가정하면 사용자가 map과 reduce함수를 정의한 프로그램을 프로세스를 실행하면 이를 map과 reduce작업을 할 워커노드들에게 전달한다.
(2) Assign Map and Reduce
마스터 노드(JobTracker)는 Mapper워커들에게는 mapping역할을, Reducer워커들에게는 reduce 역할을 수행하라고 지정해준다.
(3) Read, Map, Local write
Mapper노드들은 분할된 데이터(input Splits)을 읽어오고 이에 대해서 Map함수를 실행시킨다. Mapping이라는 영역에서 볼 수 있듯이 Map함수에 대한 결과값은 key-value형태로 로컬 디스크에 저장되고 JobTracker에 완료가 되었다고 TaskTracker가 알리게 된다.
(4) Reduce, Write
그러면 마스터 노드들은 Mapper노드들이 만들어낸 Key-Value 형태의 결과를 Shuffling하여 Reduce 노드들에게 전달하게 된다. 그러면 왜 Shuffling이라는 과정을 거치게 될까? 여러 Mapper노드들이 만들어낸 결과를 보면 서로 겹치는 값들이 존재할 것이다. 혹은 Reduce 대상 들 중 같이 Reduce작업을 수행하면 처리 속도가 빨라지는 것들이 존재할 것이다. JobTracker들은 이러한 값들에 대한 처리를 효율적으로 하기위해 Shuffling이라는 작업을 거쳐 Reduce노드들에게 Job을 분배하게 된다. 그렇게 나온 결과물을 File 형태로 마지막으로 만들어 내게 되고 MapReduce작업은 종료 되게 된다.
Hadoop 1.0의 문제는?
우리는 이제까지 HDFS와 MapReduce로 이루어져있는 Hadoop 1.0에 대해서 알아보았다. HDFS 시스템을 통해 데이터에 대해 분산저장을 하여 Client의 요청에 대해서 적절히 대응하며 MapReduce작업을 통해 비구조화된 데이터를 읽어들여 열지향 데이터베이스로 바꾸기 위한 분산처리 과정을 배웠다. 하지만 구조상 볼 수 있듯이 MasterNode에 너무 많은 Load가 집중되는 것을 알 수 있다. 이를 해결하기 위해 Hadoop 2.0이 어떻게 설계 되어있는지 다음 글에서 계속해서 이어나가겠다.
'개발 > 데이터 엔지니어링' 카테고리의 다른 글
데이터 파이프라인 용어 정리 (0) | 2023.06.30 |
---|