분산 파일 시스템
네트워크로 연결된 여러 머신의 스토리지를 관리하는 팡리 시스템
일반적인 컴퓨터도 분산 파일 시스템을 가지고 있습니다.
Google File system(GFS)
구글 파일 시스템(Google File System, GFS 또는 GoogleFS)은 구글에 의해 자기 회사 사용 목적으로 개발된 분산 파일 시스템이다.[일반 상용 하드웨어를 이용하여 대량의 서버를 연결하여 데이터에 대한 접근이 효율적이고 안정적이다. 새로운 버전의 구글 파일 시스템 코드이름은 콜로서스(Colossus)이다
하둡에서는 HDFS 라는 분산 파일 시스템을 제공합니다.
대표적인 시스템은 의 특징 :
- 범용 하드웨어를 사용하여 분산 파일 시스템 구성
- 블록 단위 저장
- 마스터/워커 구조
- 내고장성(Fault-tolerance)제공
- 확장성 제공
HDFS Block
하나의 파일을 여러 블록으로 저장
하둡 2에서는 기본 블록 사이즈가 128MB(하둡 1은 64MB)
실제 파일 크기가 블록 사이즈가 적은 경우 파일 크기만큼만 디스크 사용
해당 사이즈 만큼 블록사이즈로 쪼개진다.
왜 HDFS Block 은 클까?
- 일반적인 디스크 블록에 비해 큼(128MB)
- 탐색 비용 최소화
- 블록의 시작점을 탐색하는데 적게 걸림
- 메타 데이터 크기 감소
Blcok 단위 처리 이점
- 파일 하나의 크기가 실제 하나의 물리 디스크 사이즈보다 커질수 있음 - (1테라 바이트 인 경우 1테라보다큰 파일은 저장할수 없지만 분산 시스템에서 block 단위로 저장하게 되면 여러클러스트로 쪼개져서 저장하기 때문에 1테라보다 더 큰 데이터를 저장할수 있다. )
- 스토리지 관리 단순화
- 내고장성과 가용성을 지원하는 복제 기능지원적합 (즉 블록단위로 복사본을 두어서 장애처리할떄 사용가능_)
데이터 노드들이 워커 역할을 담당한다. Namenode는 메타 데이터 즉 어떤 정보가 저장되어있는지 나와있다.
NameNode
메타데이터 관리
- FsImage(파일 시스템 이미지): 네임스페이스를 포함한 데이터의 모든 정보
- EditLog:데이터 노드에서 발생한 데이터 변환 내역
- 데이터 노드 관리
Secondary NameNode
- Namenode의 Standby 역하링 아님
- 체크포인트
- FsImage와 Editlog를 주기적으로 병합
- 주기적으로 Namenode 와 FsImage를 백업
체크포인트 과정을 살펴보자
에딘 로그에 롤링을 요청합니다.
롤링이랑 현재 로그를 새로운 이름으로 변경하고 기존의 이름으로 새로운 로그에 파일을 생성하는것
롤링을 요청한 후 에딘로그랑 fs이미지를 다운 받습니다. 그후 merge 하고 fsImage를 Namenode로 업로드 해줍니다.
그후 fs이미지들을 NameNode에서 교체하는 작업을 하게 되고 이를 통해 에딘로그가 커지는것을 방지하고 네임노드가 재구동하는것을 빠르게 실행시킬수 있다. 또한 에딘로그가 커지면서 발생하는 디스크의 문제도 해결할수 있다.
주기적으로 Namenode의 fsImage를 백업하고 난 이후 업데이터된 내용들은 반영이 되지 않아서 데이터가 유실이 될수 있다.
DataNode
- 실제 파일을 로컬 파일시스템에 HDFS 데이터를 저장
- 하트비트를 통한 데이터 노드 동작 여부 전달
- 저장하고 있는 블록의 목록을 주기적으로 네임노드에 보고
실제 HDFS 에서 파일 저장하는 과정을 보자.
크기가 374MB이면 3개로 구성이 됩니다. 복제 개수가 2로 설정이 되어있다고 가정을 하고
블록은 하나의 데이터노드에 저장되는것이 아닌 갯수에 맞게 각각 존재하게 된다.
HDFS에서 기본 설정은 3입니다.
이전에도 살펴 보았지만 하나의 DataNode가 장애가 발생하더라도 백업파일로 돌아가게 되어 문제가 없습니다.
HDFS 읽기 연산
실행되는 과정을 알아보자
클라이언트에서 파일이 보관된 위치를 클라이언트에 반환을 하고 클라이언트는 DataNode들에게 데이터를 요구하고 읽게 됩니다.
HDFS 쓰기 연산
파일을 쓰는 경우는 먼저 네임노드들에게 파일 정보 쓰기 요청을 하고 네임노드들에게 쓸 리스트들을 클라이언트에 주게된다. 클라이언트가 파일노드들에게 파일쓰기를 요청합니다.
그리고 DataNode 간에 복제가 진행이 됩니다. 복제가 완료되면 에크 정보를 받게 되고 클라이언트가 모든 에크가 복제 되었다고 정보를 받으면 NameNode에게 완료 되었다고 알려줌.
HDFS 추가 특징
블록캐싱 기능 제공 :
데이터노드에 저장된 데이터중에서 자주 있는 블록을 블록캐시로 데이터노드 메모리에 명시적으로 캐싱을 할수 있다.
파일 단위로도 캐싱이 가능하다 조인화 같은곳에서 읽기 성능을 향상 시킬수 있다.
HDFS Federation 지원
파일이 많아지기 시작하면 메모리 사용량이 증가한다 이러한 문제를 지원하기 위해서 버전2부터는 Federation 즉 네임노드를 등록하여 사용하게 되는것이고 각각의 디렉토리마다 네임노드를 실행해서 관리하게 합니다.
그러면 메모리 문제를 해결할수 있습니다.
고가용성(HA)지원
네임노드의 문제가 발생하면 모든 작업이 중단되고 파일을 읽거나 쓰는것을 할수 없어서 버전2에서는 고가용성(active랑 스탠바이)을 지원하고
메타 데이터 정보를 유지하고 있다가 Active가 오류가 있으면 스탠바이네임이 작동한다.
'ML > Hadoop & Spark' 카테고리의 다른 글
Hadoop window 설치 (0) | 2022.07.28 |
---|---|
Hadoop 클러스터 구축 고려사항/하둡 버전에 다른점 (0) | 2022.07.21 |
데이터파이프라인 오케스트레이션 (0) | 2022.07.21 |
데이터 파이프라인 패턴 (0) | 2022.07.20 |
데이터 파이프라인이란? (0) | 2022.07.20 |