1. HDFS(Hadoop Distributed FileSystem)
HDFS는 Hadoop Distributed FileSystem이 의미하는 것처럼 하둡 네트워크에 연결된 기기에 데이터를 저장하는 분산형 파일시스템으로 실시간 처리보다는 배치처리를 목적으로 설계되어 작업량이 적거나 빠른 데이터 응답이 필요한 작업에서는 적합하지 않음
2. HDFS의 구조
1) Block based file system
(1) Block based file system?
HDFS는 블록 구조의 파일 시스템이다. HDFS에 저장되는 모든 파일은 일정 크기의 블록으로 나눠져 여러 서버에 분산 저장된다.
블록 크기는 기본 128MB로 되어있고, 설정으로 변경이 가능하다. 블록 단위로 분산해서 저장하기 때문에 로컬디스크보다 큰 규모로 데이터를 저장할 수 있고, 저장할 수 있는 요량을 페타바이트 단위까지 확장할 수 있다.
(2) 파일과 블록
- 하나의 파일은 하나 또는 복수의 블록에 저장된다. 이 때 어떤 파일이 어느 블록에 저장되어있었는지는 메타데이터로 네임노드가 메모리에서 관리한다.
- 복수의 파일이 하나의 블록에 저장될 수는 없다.
- 하나의 파일의 사이즈가 블록 사이즈를 넘어가면 여러개의 블록에 나누어 저장된다.
- 하나의 파일 사이즈 혹은 하나의 블록 사이즈를 초과하는 크기의 파일이 블록사이즈로 딱 나누어 떨어지지 않아서 남은 사이즈가 하나의 블록 사이즈보다 작다면 해당 블록은 그 크기만큼만 점유한 블록으로 관리된다. 즉 블록사이즈가 128MB일 때 129MB의 파일을 저장하고자 한다면 128MB 블록 하나와 1MB블록 하나에 저장되며 1MB블록의 남은 127MB에 다른 파일의 데이터가 저장되는 일은 없다.
- 실제 디스크를 점유하는 공간은 블록 내에 파일이 차지하는 크기이다. 즉 블록사이즈가 128MB라도 할당된 파일의 사이즈가 1MB라면 실제 디스크 사용량은 1MB이다.
2) Name Node and Data Node
기본적으로 마스터 슬레이브 구조를 가진다.
마스터 슬레이브
장치나 프로세스가 하나 이상의 다른 장치나 프로세스를 통제하고 통신 허브 역할을 하는 비대칭 통신 및 제어 모델
이전 포스트에서 예시를 들었던 것처럼 하둡을 거대한 도서관이고 HDFS를 책을 보관하는 시스템이라고 한다면 NameNode는 그 도서관의 사서이며 DataNode는 책이 꽂혀있는 책장이라고 볼 수 있다.
즉 하나의 네임 노드(사서)가 여러 개의 데이터 노드(책장)에 대한 메타 데이터를 가지고 있으며 데이터는 블록(책) 단위로 나눠져 데이터 노드에 저장된다.
HDFS는 이처럼 하나의 네임 노드와 여러 개의 데이터 노드로 구성된 하나의 파일 시스템이다.
(1) 네임 노드(namenode)
네임노드는 블록의 위치, 권한 등의 정보를 유지한다.
기본적으로는 모든 현재 정보는 메모리에 유지하고, 두 종류의 파일로도 기록한다.
Fsimage(File System Image) : name node 가 생성된 이후로부터의 HDFS의 namespace 정보를 모두 가지고 있다.
Edit log : Fsimage 로부터 현재까지의 변경사항 로그이다.
네임노드는 다음과 같은 기능과 역할을 한다.
1. Metadata Management
파일 시스템을 유지하기 위한 메타데이터를 관리한다.
메타데이터는 파일 시스템 이미지(file name, directory, size, access/auth control)와 파일에 대한 블록 매핑 정보로 구성된다.
클라이언트에게 빠르게 응답해야하므로 메모리에서 데이터를 관리한다.
File system namespace의 모든 변경사항을 관리한다.
2. Data Node Management
데이터 노트의 리스트를 관리, 유지, 변경한다. 명시적인 admin 명령 또는 Monitoring 결과에 따라 대상을 변경한다.
3. Data Node Monitoring
데이터 노드는 네임 노드에게 3초마다 heart beat를 전송한다. 하트 비트는 데이터 노드 상태정보와 데이터 노드에 저장되어있는 블록의 목록(block report)로 구성된다. 네임 노드는 하트 비트 데이터를 기반으로 데이터 노드의 실행 상태, 용량 등을 관리한다. 그리고 일정 기간동안 하트 비트를 전송하지 않는 데이터 노드는 장애가 발생한 서버로 판단한다.
4. Block Management
네임 노드는 블록에 대한 정보를 관리한다. 장애가 발생한 데이터 노드를 발견하면, 해당 데이터 노드에 위치한 블록을 새로운 데이터 노드로 복제한다. 또한 용량이 부족한 데이터 노드가 있다면, 용량의 여유가 있는 데이터 노드로 블록을 이동시킨다. 복제본의 수를 관리해서, 복제본의 수와 일치하지 않는 블록이 있다면 블록을 추가로 복제하거나 삭제한다.
5. Client request
클라이언트가 HDFS에 접근할 때 언제나 네임노드에 먼저 접속한다. 파일을 저장하는 경우, 기존 파일의 저장 여부, 권한 체크 등을 한다. 파일을 조회하는 경우 실제 블록의 위치정보를 반환한다.
(2) 데이터 노드(datanode)
데이터노드는 클라이언트가 HDFS에 저장하는 파일을 디스크에 유지한다. 저장하는 파일은 크게 두 종류이다.
- 실제 데이터인 로우(raw) 데이터
- chekcsum, created time 등 메타데이터가 설정된 파일
DataNode의 기능
- 클라이언트로부터 실제데이터의 read/write request 를 받아 처리한다.
- 네임 노드로부터 명령을 받아서 자신의 디스크에 있는 블록을 생성, 복제, 삭제를 수행한다.
- HDFS의 상태를 네임 노드에게 하트 비트로 보낸다.
- 자신이 가진 블록들의 리스트와 상태를 네임 노드에게 보낸다
데이터 노드의 상태
데이터 노드의 상태는 활성 상태와 운영 상태로 나누어 진다.
활성 상태
- Live : 하트비트를 통해 활성 상태가 확인 된 경우
- Stale : 문제가 발생하여 지정 시간 동안 하트비트를 받지 못한 경우
- Dead : 지정 시간 동안 응답이 없을 경우
운영 상태
데이터 노드의 업그레이드나 작업을 하기 위해 서비스를 잠시 멈춰야 할 경우 블록을 안전하게 보관하기 위해 설정
- NORMAL : 서비스 상태
- DECOMMISSIONED: 서비스 중단 상태
- DECOMMISION_INPROGRESS : 서비스 중단 상태 진행 중
- IN_MAINTATENANCE : 정비 상태
- ENTERING_MAINTENANCE : 정비 상태 진행 중
3) Replication
(1) Block Size와 replication factor
HDFS는 여러대의 서버로 이루어진 클러스터에 큰 크기의 파일들을 신뢰성있게 저장하도록 디자인 되어 있다. 각 파일의 내용은 여러개의 블록의 리스트로 저장한다. 각 블록은 fault tolerance(고장 감내성)을 위해서 복제된다. 각 파일마다 block size와 replication factor가 지정된다.
하나의 파일의 모든 블록은 마지막 블록을 제외하고는 모두 같은 사이즈이다.(기본 128MB) 단, 가변 길이 블록에 대한 지원이 append와 hsync에 대해서는 가능해서 마지막 블록을 채우지 않고도 새 블록을 시작할 수 있다.
애플리케이션은 파일의 replica 수를 지정할 수 있다. 이것을 replication factor라고 하는데 이는 파일 생성 시점에 정해지고 생성 이후에 변경할 수도 있다. HDFS의 파일은 (append, truncate를 제외하면) 한순간에 하나의 writer만 존재할 수 있다.
블록의 replication에 대한 결정은 네임노드가 한다. 네임노드는 주기적으로 데이터노드로부터 하트 비트와 블록 리포트를 받는다. 이를 기반으로 replication에서 데이터를 복제해 와야할지 혹은 새로운 replication을 생성해야 할지 등을 결정한다.
(2) Purpose of Replica Placement
replica의 위치는 HDFS의 신뢰성과 성능에 큰 영향을 미친다. replica의 위치에 대한 최적화 규칙이 HDFS의 다른 분산 파일 시스템과의 가장 큰 차이점이기도 하며 이 기능에 엔지니어의 경험과 튜닝에 대한 이해가 가장 많이 녹아있다고 볼 수 있다.
replica placemnet와 관련된 모든 정책은 데이터의 성능과 신뢰성을 개선하기 위해 수많은 시행착오와 최적화 작업의 결과물이며 그 중 가장 첫번째 대표적인 것이 rack-aware replica placement다.
(3) Rack-Awareness
대용량 HDFS 클러스터에 존재하는 computing instance들은 통상적으로 많은 서버 랙(rack)에 위치한다. 서로 다른 두 개의 랙에 위치한 두 개의 서버는 랙 마다 존재하는 스위치를 거쳐서 통신하게 된다. 이 때 network bandwidth는 같은 랙에 있는 다른 서버와 통신할 때보다 더 증가하게 된다.
Hadoop Rack Awareness를 통해 네임 노드는 각 데이터 노드의 rack id를 알고 있다.
replica를 위치시키는 가장 간단한 정책은 하나의 replica는 unique rack에 존재하도록 하는 것이다. 이것은 하나의 랙이 통째로 장애가 났을 때를 대비해서 데이터의 유실을 방지해준다. 또한 이 정책은 replica들을 전체 랙에 골고루 분산하도록 유도하기 때문에 클러스터 전체의 부하를 분산하는 효과도 얻을 수 있다.
하지만 이 정책은 write시 여러개의 랙을 걸쳐서 블록 데이터를 전파해야 하므로 write operation의 비용을 증가시킨다.
(4) Block Placement Policy Default
대부분의 경우 replica factor = 3이다. 이때의 HDFS의 기본 placement policy는 다음과 같다.
1. 하나의 replication은 가능한 한 writer와 같은 랙에 있는 데이터 노드에 저장하도록 한다.
1-1. 만약 writer가 하나의 데이터 노드에서 동작한다면, 기본적으로 하나의 replica는 해당 데이터 노드의 local에 저장한다.
1-2. 만약 writer가 데이터노드에 있는 것이 아니라면, writer가 동작하는 노드와 같은 랙에 있는 데이터 노드를 랜덤하게 선택해서 저장한다
2. 나머지 두 개의 replica는 writer와 다른 랙의 서로 다른 두 데이터 노드에 저장되도록 한다.
따라서 총 unique rack 의 수는 2이다.
위의 그림을 예로 들면 A데이터에 대해서 writer가 rack2 내에 있는 Datanode10 혹은 다른 노드(name node, edge node 등) 위에서 동작하고 있으며 writer가 동작하고 있는 rack2에 있는 Datanode10에 primary 버전을 저장했으면 나머지 두 개의 replica 버전은 writer와 다른 랙(rack1)의 서로 다른 데이터 노드(Datanode1, Datanode2)에 각각 저장되며 이 replica는 rack1과 rack2 두 개의 unique rack를 가지게 되는 것이다.
(5) Replica Selection - Read
Global bandwidth의 소비를 줄이고, read latency를 줄이기 위해서 HDFS는 read 요청에 대해서 reader와 가까운 곳에 있는 replica로부터 데이터를 읽도록 시도한다. reader node와 같은 랙에 replica가 존재한다면 해당 read 요청은 그 replica에서 데이터를 읽는다. 만약 HDFS 클러스터가 여러 데이터센터에 걸쳐져 있다면, 같은 데이터센터에 있는 replica를 읽는 것을 선호한다.
HDFS의 사용 목적
1. Hardware Failure
HDFS를 구성하는 분산 서버에는 다양한 장애가 발생할 수 있다. 예를 들어 하드디스크에 오류가 생겨서 데이터 저장에 실패하는 경우, 디스크 복구가 불가능해 데이터가 유실되는 경우, 네트워크 장애가 생겨 특정 분산 서버에 네트워크 접근이 안되는 경우 등이 있다.
HDFS는 이러한 장애를 빠른 시간에 감지하고 대처할 수 있게 되어 있다. HDFS에 데이터를 저장하면, 복제본도 함께 저장되어 데이터 유실을 방지하고 헬스 체크를 통해 장애를 감지하고 대처한다.
2. Streaming Data Access
HDFS는 클라이언트의 요청을 빠르게 처리하는 것보다 동일한 시간 내에 더 많은 데이터를 처리하는 것을 목표로 한다.
HDFS는 이것을 위해 Random Access를 고려하지 않는다. user와 상호작용하는 것보다는 batch 처리에 더 맞게 디자인 되어있다.
따라서 은행 서비스, 쇼핑몰과 같은 transactional 서비스에서 기존 파일 시스템 대신 HDFS를 쓰는 것은 적합하지 않다.
HDFS는 Random Access 대신 Streaming 방식으로 데이터에 접근하도록 설계되어 있다. 클라이언트는 HDFS 명령어/API를 통해서 연속된 흐름으로 데이터에 접근할 수 있다.
3. Large Data Sets
HDFS는 하나의 파일이 GB ~ TB 스준의 데이터 크기로 저장될 수 있게 설계되어 있다. 이것으로 높은 데이터 전송 대역폭을 지원하고 하나의 클러스터에서 수백대의 노드를 구성할 수 있다. 하나의 인스턴스에서는 수백만개 이상의 파일을 지원한다.
4. Simple Coherency Model
데이터베이스에서 데이터의 무결성은 데이터의 신뢰도와 직결되며 아주 중요한 문제이며 데이터의 입력이나 변경을 제한해서 데이터의 안정성을 깨는 동작을 막는 것을 의미한다.
HDFS는 write-once-read-many access model이 필요하다. HDFS에서 한 번 저장된 데이터는 수정할 수 없고, 읽기만 가능하게 하는 것으로 데이터의 무결성을 지킨다. 데이터 수정은 불가능 하지만, 파일의 이동, 삭제, 복사는 지원한다.
(최초에는 아예 수정이 되지 않았지만 현재는 end of file 위치에 append가 가능하다.)
이런 Simple Data Coherency Model은 데이터 접근에 대한 높은 throughput(처리량)을 갖게 한다. 이 방식이 MapReduce에서 큰 장점이 된다.
5. Moving Computation is Cheaper than Moving Data
데이터를 이용해서 computing processing을 한다면, 데이터가 Processor와 가까울 수록 효율이 좋은데 이는 데이터의 양이 클 수록 영향이 더욱 커진다. Network의 혼잡을 줄이고 시스템 전체의 throughtput을 높일 수 있다.
HDFS는 이것을 위해 computing 자원을 data가 있는 위치로 이동시키는 것을 선택한다. Data를 이동시키는 것보다 비용이 싸고 빠르기 때운이다. HDFS는 이러한 방식을 위한 인터페이스를 제공한다.
6. Portabillity Across Heterogeneous Hardware and Software Platforms
HDFS는 쉽게 HW/SW 플랫폼을 옮길 수 있도록 디자인 되었다. 인텔 칩, AMD 칩이 설치된 하드웨어에서 동일한 기능으로 동작한다. CentOS나 Redhat Linux 상관없이 동일하게 동작한다. 이는 HDFS의 서버 코드가 Java로 구현되어있기 때문에 가능하다.
-> 대용량 데이터 셋의 플랫폼으로 채택되는 주요한 원인 중 하나
'Develop > Data Engineering' 카테고리의 다른 글
| 웹 크롤링에 대해 알아보자 (0) | 2025.04.16 |
|---|---|
| Hadoop 개요 (0) | 2025.03.23 |