본문 바로가기

data engineering

Hadoop의 개요 #2 - HDFS 특징

하둡의 아키텍쳐는 가장 크게 두가지로 나뉜다. 

하둡 파일시템인 HDFS(Hadoop Distributed File System)와 하둡에 저장된 데이터를 처리하는 MapReduce(Yarn).

이번 포스팅은 HDFS에 다뤄보겠다. 

HDFS(Hadoop Distributed File System)

HDFS는 말 그대로 하둡 분산 파일 시스템이다. 

대용량의 파일을 분산된 서버에 저장하고 그 데이터를 빠르게 처리할 수 있게 설계되었다.


아룬 머시(아파치 하둡 부사장)은 인터뷰에서 HDFS를 소개할 때 이렇게 말했다.

HDFS란 하둡 네트워크에 연결된 아무 기기에나 데이터를 밀어 넣는 분산형 파일시스템이다. 물론 여기에도 체계가 있어서 그냥 닥치는 대로 배치하는 것은 아니지만, RDBMS의 고도로 엄격한 저장 인프라에 견줘보면 돼지우리나 다름없다 "

 

돼지우리...인 HDFS의 

특징을 4가지로 살펴볼 수 있다.

 

1. 대용량 데이터 저장

HDFS는 하나의 파일이 기가바이트에서 테라바이트 이상의 크기로 저장 될 수 있다. 

 

2. 데이터 무결성데이터베이스에서 데이터 무결성이란, 데이터베이스에 저장되는 데이터가 일관성을 가지는 것을 의미한다. 데이터의 입력이나 변경을 막아서 데이터의 안정성을 유지한다.그래서 HDFS에서는 한번 저장된 데이터를 수정할 수 없고 읽기만 가능하게 해서 데이터 무결성을 유지한다. 데이터의 수정은 불가능하지만 파일 이동, 삭제, 복사는 가능하다.
3. 장애 복구HDFS는 장애를 빠른 시간에 감지하고 대처가 가능하다. 데이터를 저장하면 복제 데이터도 함께 저장되어 데이터 유실을 방지하고 분산 서버간에 주기적으로 상태를 체크해 빠른 시간에 장애를 인지한다.(기본 블록당 3개를 복제하여 다른 데이터노드에 저장)
4. 스트리밍 방식의 데이터 접근HDFS는 클라이언트의 요청을 빠른 시간 내에 처리하는 것보다 동일한 시간 내에 더 많은 데이터를 처리하도록 설계되었다.(이게 빠른 게 아닌가? 싶을 수 있다. 하지만 하둡은 <빠른 시간내의 데이터 처리>보다는 <데이터 양>에 중요성을 두고 있다는 것이다.)그래서 클라이언트는 끊김 없이 연속된 흐름으로 데이터에 접근해야한다. 

 

전의 포스팅에서 하둡은 Data Lake라고 표현했었다. 즉, 정말 다양한 형태의 데이터를 아주 많이 저장할 수 있고 최초로 저장할 때의 데이터 형식을 변환하지 않으며 만약 데이터에 문제가 생기면 HDFS에서 알아차려서 복구도 해주며 또, 데이터에 접근할 때(예를 들어 읽을때) 끊임없이 데이터에 접근해서 많은 데이터를 비교적 빠른 시간내에 처리할 수 있다. 

*참고로 Data Lake는 막대한 양의 원본 데이터나 세분화된 데이터를 액세스 지점까지 native 형식으로 보관하는 스토리지 이다.


HDFS를 돼지우리 말고 다른 말로 정의를 한다면 '블록 구조 파일 시스템' 이다.그런데 그 블록이 좀 크다 Hadoop 2.X 기준으로는 블록이 128MB이다.(Hadoop 1.x는 64MB)일반 파일 시스템의 블록 크기가 4~8KB인것을 생각해보면 굉장히 큰 것을 알 수 있다. 왜 파일이 저장되는 단위인, 블록을 이렇게 크게 설정했을까?(임의로 크기 설정 가능)두가지 이유가 있는데, 
첫번째는 디스크 시크타임(Seek time)이 감소가 된다. 일반적인 디스크 시크타임은 10ms, 디스크 전송대역폭은 100MB/s 인데 HDFS는 시크타임이 디스크 전송 대역폭의 1%만을 사용하고자 해서, 100MB에 근접한 64MB를 사용한 것이라고 한다. 
두번째로는 네임노드가 유지하는 메타데이터의 크기를 감소하기 위해서이다. 메타데이터란 데이터의 관한 데이터...로 블록의 위치, 파일명, 디렉터리 구조, 권한 정보 등등이 있는 데이터이다. 여기서 네임노드는 하둡의 마스터 서버로 슬레이브 서버들을 관리하는 서버이다. 만약 200MB의 파일을 저장한다면, 파일은 2개의 블록으로 쪼개질 것이다. 그러면 네임노드는 그 두개의 블록에 대한 메타데이터만 저장하고 관리하면 된다. 하지만 일반적인 파일 시스템의 크기는 기껏해야 4~8K 여서 만약 200MB의 파일을 저장한다면 메타데이터가 최소 25개 이상 생길것이다. 

이렇게 메타데이터 수를 적게하면 뭐가 좋을까? 

클라이언트와 네임노드의 통신이 감소하는 것이다. 

클라이언트는 하둡에 데이터를 쓰고 싶을 수도 있고, 저장된 데이터를 읽고 싶을 수도 있다. 

만약 저런 Active를 취한다면 클라이언트는 무조건 네임노드에 접근해 원하는 데이터의 위치를 알아야한다. 만약 메타데이터 수가 적으면 클라이언트는 네임노드에 접근하는 횟수가 줄어든다. 

64MB 이상으로 블록 크기를 정하면 좋겠지만 그 이하로도 설정할 수 있긴하다. 하지만 최소 1MB 이상으로 설정을 해야한다.

 


HDFS는 블록을 저장할 때 기본적으로 3개씩 블록의 복제본을 저장한다.(복제본 수는 변경 가능) 왜냐하면 데이터 유실을 방지하기 위해서 인데, 특정 서버의 하드디스크에 오류가 생겨도 복제된 블록을 이용해 데이터를 조회할 수 있다.
데이터가 블록 단위로 쪼개지고 HDFS 클러스터에 저장되는 과정을 간단하게 그림으로 나타냈다. 

500MB 파일                   블록 단위로 쪼개짐        HDFS 클러스터

 

다음에는 HDFS의 아키텍처에 대해 포스팅하겠다.