HDFS란 Hadoop File System의 약자로 하둡 파일 시스템을 의미합니다.
HDFS
HDFS란 말그대로 하둡이 실행되는 파일을 관리해주는 시스템입니다.
이는 크게 NameNode, DataNode로 구성되어져 있습니다.
HDFS 와 기존의 대용량 파일시스템의 큰 차이점은 HDFS는 저사양 서버를 이용해 스토리지를 구성할 수 있다는 점 입니다. 기존의 대용량 파일시스템 또는 데이터베이스를 구성하려면 고성능의 서버나 대용량의 외장 스토리지가 필요 하였으며 이러한 시스템은 웹 서버 와 같은 서버에 비해 상당히 많은 비용이 발생되게 됩니다.
하지만 HDFS를 이용하면 수십 혹은 수백 대의 웹 서버급 서버나 저사양 서버를 묶어서 하나의 스토리지 처럼 사용 할 수 있게 됩니다.
이때 HDFS에 저장되는 데이터는 물리적으로 분신된 서버의 로컬 디스크에 저장되게 되고, 파일의 읽기 와 저장 같은 제어는 HDFS에서 제공되는 API 를 통해 처리되게 됩니다. 모든 업무의 유형이 HDFS로 대체할 수 있는 것은 아니며 대규모 데이터 저장 이나 배치로 대규모 데이터의 처리를 하는 경우 HDFS 를 이용하면 유용하게 사용할 수 있습니다.
HDFS 특징
1. 대용량 데이터를 범용 서버만으로 처리 가능
데이터 파일 크기나 개별 장비의 파일 시스템 크기에 제한이 없음
2. 용량 확장성
데이터가 증가하면 노드를 추가로 처리가능
3. 높은 처리량 실현
데이터의 부분 수정 불가, 랜덤 접근 불가, 큰 블록 처리 -> 고속 처리로 이어짐.
4. 슬레이브 노드의 일부가 고장 나도 데이터 손실을 방지 가능
복수개의 노드에 데이터 복제 유지.
HDFS 설계 목표
장애 복구
HDFS는 장애에 있어 상당히 유연한 대처가 이루어 져야 하는데 그래서 장애 복구를 할 수 있도록 설계가 되어져야 한다.
1) 디스크 오류로 인한 데이터 저장 실패 및 유실에 같은 장애를 빠른 시간에 감지 및 대처
2) 데이터를 저장하면 복제 데이터도 함께 저장해서 데이터 유실 방지.
3) 분산 간 서버 간 주기적인 상태 체크(Heart Beat)
스트리밍 방식의 데이터 접근
HDFS에 파일 저자 및 조회를 위해서는 스트리밍 방식으로 데이터에 접근하는 방식을 취해야 하기 때문에 HDFS은 스트리밍 방식의 데이터 접근을 목표로 설계 되어져 있고 뿐만 아니라 배치 작업과 높은 데이터 처리량을 위해서도 스트리밍 방식을 사용한다.
HDFS 는 클라이언트의 요청을 빠른시간 안에서 처리하는 것 보다 동일한 시간내에 더 많은 데이터를 처리하는 것을 목표로 하고 있습니다.
HDFS는 이를 위해서 랜덤 방식의 데이터 접근을 고려하고 있지 않습니다. 그래서 인터넷 뱅킹, 인터넷 쇼핑몰 과 같은 서비스에서 기존 파일 시스템 대신 HDFS 를 사용하는 것은 적합하지 않습니다.
HDFS는 랜덤 접근 방식 대신 스트리밍 방식으로 데이터에 접근 되도록 설계/구현 되어 있습니다. 그래서 클라이언트는 끊김없이 연속된 흐름 데이터에 접근할 수 있습니다.
대용량 데이터 저장
하둡의 본질적인 목적인 대용량 데이터를 처리하기 위해 우선 대용량을 데이터를 저장하는 기능이 있어야 하는데 때문에 높은 데이터 전송 대역폭, 하나의 클러스터에서 수백 대의 노드를 지원한다. 그리고 하나의 인스턴스 에서 수백만 개 이상의 파일을 지원한다.
HDFS 는 하나의 파일이 기가바이트에서 테라바이트 또는 그 이상의 크기로 저장 할 수 있도록 설계되어 있습니다. 하나의 클러스터에서 수백 대의 노드를 지원할 수 있으며 하나의 인스턴스에서는 수백만개 이상의 파일 처리를 지원하고 있습니다.
데이터 무결성
데이터베이스에서 데이터 무결성이란 저장되는 데이터의 일관성을 의미합니다. 즉 데이터의 입력 이나 변경등을 제한해 데이터의 안전성을 저해는 요소를 막는 것을 의미 합니다. HDFS 에서는 한 번 저장한 데이터는 더는 수정 할 수 없고, 읽기만 가능해서 데이터 무결성을 유지 하게 됩니다.
데이터의 수정은 불가능 하지만 파일 이동, 삭제, 복사 할 수 있는 인터페이스를 제공 하고 있으며 한번 기록된 데이터의 수정이 불가능한 부분은 하둡 2.0 알파 버전부터 저장된 파일에 append 는 가능하게 추가/개선 되었습니다.
NameNode의 역할
HDFS의 중추라고 불리우는 NameNode는 HDFS에서 핵심적이고 중요한 역할을 합니다.
메타데이터 관리
NameNode는 하둡에서 처리되는 파일 속성 정보나 파일 시스템 정보를 디스크가 아닌 메모리에서 직접 관리하는 역할을 합니다. 이를 메타 데이터라고 말하며 앞서 말했듯이 디스크가 아닌 메모리를 통해 직접 관리하기 때문에 빠른 응답이 가능하다.
HDFS 사용 상황 관리
NameNode는 DataNode와 주기적으로 상황을 주고 받으면서 DataNode의 용량이 다 차면 다른 DataNode로 블록을 이동 가능하도록 만들어 준다.
그리고 블록 복제본 수도 관리한다.(삭제 및 생성도 포함)
클라이언트의 HDFS 처리 요청 접수
NameNode는 클라이언트가 하둡이 어떻게 실행될지 처리에 대한 요청을 직접 접수하게 된다.
클라이언트가 HDFS에 대해 파일 접근을 요청을 하고
-> NameNode가 메타데이터를 바탕으로 대상 블록을 보유한 DataNode 리스트를 클라이언트에게 전달한다
-> 이 리스트를 가지고 클라이언트는 해당 DataNode에 직접 통신을 하게 된다.
DataNode 다운 여부 감시
NameNode는 DataNode와 수시로 통신을 주고 받는다고 앞서 이야기 했는데 이러한 주기적인 송신을 통해 (HeartBeat) DataNode의 다운 여부를 감시하고 데이터를 어떻게 처리 할지, 분배 할지 결정한다.
MetaData
NameNode가 metadata를 관리한다고 말했는데 metadata는 다음과 같이 6가지 정보를 담고 있습니다.
- 파일명
- 디렉터리
- 데이터 블록 크기
- 소유자 : 소속 그룹
- 파일 속성
- DataNode와 블록 대응 정보.
- 블록 ID와 해당 블록을 보유한 DataNode 정보
- DataNode가 하트비트를 3초 간격으로 전송 할때, 자신이 관리하는 블록 정보를 통지(block report)
- 이를 바탕으,로 전체 블록 정보를 구축 및 복제수가 충분한지 판단.
fsimage
메타 데이터에도 크게 fsimage와 edits로 구분할 수 있는데 그중에 fsimage는 앞서 메타 데이터가 가지고 있는 정보중 1~5번을 포함한 정보로써 메모리 상에 관리되어 있는 메타데이터 내의 파일 시스템 이미지이다.
edits
반면 edits는 파일 처리 시 로컬 파일 시스템에 생성되는 편집로그로써 메모리 상에서 관리되고 있는 파일 시스템 이미지(fsimage)에 적용된다.
SecondaryNode
하둡의 NameNode가 고장이 났을시에 HDFS에 가지고 있던 모든 정보들이 날아갈 수 잇는 위험을 방지하기 위해 NameNode의 이중화(HA)을 통해 이 문제를 방지한다고 했는데 그 방법이 바로 SecondaryNode을 구성하는 것이다.
SecondaryNode 구성
1) HA 클러스터 구성을 사용하지 않는 클러스터에서 사용.
2) 주기적으로 NameNode에서 fsimage와 edits를 받아서 이들을 합치고, HDFS에 대한 갱신 내용을 반영한 새로은 fsimage를 생성.
3) 생성한 fsimage를 NameNode로 전송
4) 체크 포인트를 실시하여 fsimage에 적용 완료한 edits를 삭제함으로써 디스크 공간 절약
5) NameNode 재시작시 fsimage에 대한 edits 적용 크기를 줄일 수 있어서 재시작 시 시간 단축
6) NameNode 장애가 발생한 경우, 메타 데이터를 보존 함으로써 완전 데이터 손실을 방지.
DataNode
데이터노드는 클라이언트가 HDFS에 저장하는 파일을 로컬디스크에 유지하며 로컬 디스크에 저장되는 파일은 두 종류로 구성이 되게 됩니다
첫번째 파일은 실제 데이터가 저장되어 있는 로우 데이터이며, 두 번째 파일은 체크섬이나 파일 생성 일자 와 같은 메타 데이터가 설정되어 있는 파일 입니다.
블록 구조 파일 시스템
HDFS는 블록 구조의 파일시스템 입니다.
HDFS 에 저장하는 파일은 특정 크기의 블록으로 나눠져 분산된 서버에 저장 됩니다. 블록 크기는 기본적으로 64MB로 설정돼 있으며, 하둡 환경설정 파일이나 다른 방법으로 변경이 가능 합니다. 여러 개의 블록은 동일한 서버에 저장하기 때문에 로컬 서버의 하드디스크보다 큰 규모의 데이터를 저장 할 수 있으며 저장할 수 있는 용량을 수십 GB,TB,PB 까지 확대가 가능 하게 됩니다.
블록의 사이즈 64MB
HDFS의 기본 블록의 사이즈가 64MB 로 디스크의 블록 사이즈나 파일시스템 또는 데이터베이스 블록 사이즈 보다 큰 이유는 여러가지가 있습니다.( 64MB 는 하둡 1 버전 기준 입니다 )
- Disk Seek Time 감소
디스크의 탐색 시간은 데이터의 위치를 찾는 데 걸리는 시간인 시크 타임 과 원하는 데이터의 섹터에 도달하는 데 걸리는 시간인 서치 타임(Search time)의 합 입니다.
하둡의 개발 시절 일반적인 디스크의 시크 타임은 10ms, 디스크 전송 대역폭은 100MB/s 였습니다. HDFS 는 시크 타임이 디스크 전송 대역폭의 1%만 사용하는 데 목표를 두었고 그래서 100MB 에 근접한 64MB를 사용하게(기본값으로) 된 것이며 하둡 2.0 버전 부터는 기본 블록 크기는 128MB 로 증가되었습니다.
이와 같이 일반적인 파일시스템이나 Database의 블록 사이즈에 비해 큰 용량을 사용하는 이유는 블록이 커짐에 따라 탐색 비용을 최소화 할 수 있으며 디스크에서 블록 시작점을 탐색하는데 걸리는 시간을 줄일 수 있게 되며 데이터를 전송하는데 더 많은 시간을 할애 할 수 있게 됩니다.
- 네임노드의 메타데이터 크기 감소
네임노드는 블록 위치, 파일명, 디렉토리 구조, 권한 정보와 같은 메타데이터 정보를 메모리에 저장하고 관리하게 됩니다.
예를 들어 100MB 크기의 파일을 저장할 경우 HDFS는 두 블록에 해당 하는 메타데이터만 저장하면 되게 됩니다. 하지만 일반적인 OS의 파일 시스템 블록 사이즈인 4k~8k 단위를 사용하게 된다면 동일한 크기의 파일을 저장할 경우 훨씬 더 많은 메타데이터가 생성이 되게 됩니다.
블록 개수는 네임노드에 할당된 힙 메모리의 크기에 영향을 받게 되며 약 100만개의 블록을 저장할 경우 힙 메모리는 약 1GB 정도 필요 할 수 있게 됩니다.
- 클라이언트와 네임노드 통신 감소
클라이언트가 HDFS에 저장된 파일을 접근 할 때 네임노드에서 해당 파일을 구성하는 블록의 위치를 조회하게 되며 블록이 커서 블록수가 작아진다면 접근 횟수가 감소하게 됩니다.
블록 단위 파일 저장
HDFS는 블록 단위로 파일을 나누어서 저장을 하게 되고 파일 하나의 크기가 단일 디스크의 크기보다 크더라도 저장할 수 있게 됩니다.
