Hadoop Ecosystem 쓱 보기 -1 (HDFS, MapReduce1)

데이터 웨어하우스를 공부하다보니, 분산시스템의 근간인 하둡 에코시스템을 대체해 사용자가 관리하는 부분을 데이터 웨어하우스가 대신해주고 테이블을 생성하고 쿼리를 튜닝하는 부분만 신경쓰게 해준다는 것을 알게 됐다. 데이터 웨어하우스를 구축할땐 비록 하둡의 개념이 쓸모없어 보이지만, '분산 시스템을 이해하고 데이터 웨어하우스를 구축하는 것과 이해하지 않고 그저 구축하는 것은 눈에 보이지 않는 차이를 낳지 않을까?'싶다

 

하둡을 직접 운용하는 것은 어렵지만, 각각의 컴포넌트들이 왜 필요하게 됐는지를 살펴보고자 한다. 오늘 멘토님이 하둡과 Hive, HiveQL, Impala, trino 등이 왜 필요하게 됐는지 전체적인 그림으로 설명해 주셨는데 그 그림을 토대로 이야기를 풀어가보고자 한다

 

 

HDFS

하나의 파일이 서버 한대에 담긴다면, 하둡이 존재할 이유는 없었을 것이다. 하지만 한대의 서버에 담기지 않는 크기의 파일이 등장했다. 이를 저장하기 위해선 크게 두 가지의 선택지가 있다

 

1. 하나의 서버를 더 키우면 되잖아?(Scale-up)

2. 여러 개의 서버에 파일을 나눠 저장하면 되잖아?(Scale-out)

 

1번을 선택했을땐, 한계가 분명하다. 하나의 서버를 확장할 수 있는 한계(발열, 전력)가 분명하고 한대의 고성능 서버를 구비하는 것보다 여러대의 저성능 서버를 구비하는 것이 비용적으로 저렴하다. 또한 1대의 고성능 서버로 구성했을때 서버가 다운되면 전체 시스템이 중단된다. 따라서 1번을 선택하기엔 리스크가 너무 크다

 

그럼 2번을 선택했을땐 어떨까? 여러대의 저성능 서버를 구축하고 파일을 나눠 저장하면 된다. 하지만 2번을 선택했을땐 다음과 같은 또다른 문제들이 등장한다

 

1. 파일을 여러개로 어떻게 나눌건가?

2. 여러개의 서버중 하나가 고장나면 어떻게하나?

 

 

하둡의 HDFS는 바로 이 부분을 구현한 분산 파일 프레임워크다. HDFS는 클라이언트가 하나의 거대한 파일을 저장하려고 하면 그걸 블록 단위(최대 256MB)로 쪼개 각 서버에 나눠 저장한다. 이때 블록 단위로 쪼개 저장하는 것을 sharding(partition)이라고 한다. 또한 서버중 하나가 고장나면 파일이 손상되기 때문에 이를 방지하기 위해 replica라는 복제본을 다른 서버에 저장해둔다

 

[출처] https://journalofbigdata.springeropen.com/articles/10.1186/s40537-021-00505-y

 

 

HDFS는 크게 네임 노드와 데이터 노드로 구성되어 있다. 네임 노드는 파일/디렉터리 구조와 메타데이터, 블록에 대한 메타데이터 또한 저장된다. 데이터 노드는 파일 시스템의 실질적 일꾼으로 클라이언트나 네임 노드의 요청이 있을때 블록을 저장하고 탐색하며 저장하고 있는 블록 목록을 네임 노드에게 주기적으로 보고하는 등의 일을 한다

 

 

 

MapReduce 1

하나의 서버에서 처리할 수 없는 데이터는 어떻게 처리할 수 있을까? 여기서 마찬가지로 두가지 선택지가 있다

 

1. 하나의 서버를 더 키우면 되잖아?(Scale-up)

2. 여러 개의 서버에서 나눠 처리하면 되잖아?(Scale-out)

 

1번을 선택하면 HDFS에서 말했던 것과 마찬가지로 분명한 한계가 존재하며, 고성능 서버를 구축하려고 할수록 아아아아아주 비싸 구축할 수 없게될 것이다

 

2번을 선택하면 어떨까? 여러 대의 서버를 구비하고 데이터를 여러 대로 나눠 처리하면 될 것이다. 하지만 말이 쉽지 여러 대의 서버를 관리한다는게 말처럼 쉬운 일은 아닐 것이다. 2번을 선택했을땐 다음과 같은 문제가 발생한다

 

1. 여러대의 서버에 데이터를 나눌때 하나의 서버에 데이터가 몰리는 현상을 어떻게 해결할 것인가?

2. 여러대의 서버의 결과를 어떻게 병합할 것인가?

 

 

하둡의 MapReduce는 바로 이 부분을 구현한 분산 데이터 처리 프레임워크다. MapReduce는 클라이언트가 데이터 처리를 요청하면 해당하는 데이터가 저장된 노드 혹은 인접한 노드(데이터 지역성 최적화)의 리소스를 활용해 데이터를 처리한다

 

[출처] https://www.researchgate.net/figure/Interaction-between-Jobtracker-and-TaskTrackers_fig3_282556675

 

 

MapReduce1은 크게 Job Tracker와 Task Tracker로 구성되어 있다. 클라이언트가 요청한 것을 하나의 Job이라 표현하는데, Job Tracker는 Job을 여러개의 태스크로 나누고 스케줄링하며, 시스템에서 실행되는 모든 Job을 관리한다. Task Tracker는 이름에서 알 수 있듯이 태스크를 수행한다

 

MapReduce의 태스크는 Map과 Reduce로 이루어져 있는데, 사용자가 Map과 Reduce 부분의 코드를 작성해 제출하면 다음과 같이 처리해준다

 

[출처] https://www.geeksforgeeks.org/mapreduce-understanding-with-real-life-example/

 

 

각 데이터 블록에서 데이터를 가져와 Map 태스크에 전달한다. Map 태스크는 각 행에서 key, value를 추출하고 컴바이너를 통해 일차적으로 병합한다. 병합된 데이터는 셔플(정렬과 집계)링을 통해 키 기반으로 정렬되고 같은 키를 가진 데이터는 동일한 리듀스의 입력으로 전달된다. Reduce 태스크는 최종적으로 데이터를 집계하고 그 결과를 HDFS에 저장한다

 

 

 

정리

정리하자면, 하둡이 등장하게 된 계기는 결국 한대의 서버로 저장하고 처리할 수 없는 데이터가 등장하면서다. 사람들은 이를 처리해 분석하거나 사용하기 위해 고민했고, 그 결과로 하둡이 등장하게 됐다. 어떤 기술이 나왔다는 것은 결국 필요에 의해서고 각 필요를 따라 공부하다보면 큰그림이 그려지는 것 같다. 다음 장에서는 Mapreduce2와 YARN이 등장하게 된 이유를 살펴보고자 한다