kkwang
로그인
kkwang
로그인
HDFS
kkwang
·
2022년 7월 14일
팔로우
0
HDFS
분산파일시스템
하둡
0
하둡 분산 파일시스템
Data가 단일 물리 머신의 저장용량 초과 -> 전체 DataSet을 분리된 여러 머신에 나눠 저장 필요
네트워크로 연결된 여러 머신의 스토리지를 관리하는 파일시스템
일반 파일시스템보다 복잡
특정 노드에 장애가 발생해도 Data 유실없는 강건한 파일시스템 목표
HDFS(Hadoop Distribution FileSystem)
특징
매우 큰 파일
스트리밍 방식의 데이터 접근
범용 하드웨어
빠른 데이터 응답시간
수많은 작은 파일
다중 라이터와 파일의 임의 수정
HDFS 개념
블록
HDFS 블록 : 128MB
HDFS 파일은 블록 크기 보다 작은 데이터 일 경우, 전체 블록 크기를 모두 점유하지 않음
1MB 크기의 파일이면 128MB가 아닌, 1MB만 사용
HDFS 블록이 큰 이유는?
탐색 비용(seek time)을 최소화하기 위해
블록이 크면 seek time을 줄일 수 있고 Data 전송의 시간에 시간을 더 할애할 수 있음
분산 파일시스템에 블록 추상화 개념을 도입하는 이유
파일 하나의 크기가 단일 디스크 용량보다 클 수 있음
-> 하나의 파일을 구성하는 여러 개의 블록이 다른 디스크에 저장 될 수 있으므로
스토리지의 서브시스템을 단순화
-> 저장에 필요한 디스크 양만 계산하면 되며, 메타데이터는 블록과 별도로 분리 할 수 있음
내고장성(fault tolerance), 가용성(availability)을 위한 복제(replication)을 구현하기 용이
-> 블록 손상 및 머신 장애에 대처하기 위해 각 블록은 물리적으로 분리된 다수 머신에 복제 되기 때문
HDFS 역시 fsck 명령어로 블록을 관리
네임노드(NameNode)와 데이터노드(DataNode)
네임노드
파일시스템의 네임스페이스 관리
파일시스템 트리 및 모든 파일 메타데이터 유지
Namespace image, Edit log라는 두 종류 파일로 저장
파일에 해당하는 블록이 어느 데이터노드에 있는 파악
HDFS 클라이언트
네임노드와 데이터노드 사이를 통신/파일시스템 접근
데이터노드
네임노드의 요청에 따라 블록 저장/탐색/목록보고
네임노드 장애 복구
다수의 파일시스템에 영구적인 상태를 저장(파일 백업)
보조 네임노드(Secondary NameNode) 운영
-> Edit log가 너무 커지지 않도록, 주기적으로 네임스페이스 이미지를 Edit log와 병합하여 새로운 네임스페이스 이미지를 생성 (병합작업에 CPU와 메모리가 필요하므로 별도 머신에서 실행하는 것이 좋음)
블록캐싱
읽기 성능 향상
빈번하게 접근하는 블록을 오프-힙 블록캐시(Off-heap block cache)라는 데이터노느 메모리에 명시적 캐싱 가능
맵리듀스/스파크와 같은 잡스케줄러는 캐싱된 데이터노드를 실행 가능
HDFS 페더레이션
네임노드는 파일시스템 모든 파일과 각 블록에 대한 참조 정보를 메모리에서 관리
파일이 매우 많은 대형 클러스터의 확장성에 걸림돌 -> 메모리
HDFS 페더레이션 : 각각의 네임노드가 네임스페이스를 나누어 관리
네임스페이스 볼륨, 블록 풀 을 관리
네임스페이스 볼륨은 서로 독립적 -> 네임노드 서로 통신 불필요, 장애 발생 시 다른 네임 노드에 영향 없음
HDFS 고가용성(HA)
데이터 손실 방지 위해 네임노드 메타데이터를 복제 해놓는 방식과 보조 네임노드 통해 체크포인트를 생성하는 방식 존재
하지만 이마저도 새로운 네임노드가 투입 될 때까지 먹통
하둡 2.x 부터 고가용성(High Availability) 지원
Active-Standby로 한 쌍의 네임노드 구성
Active NameNode 장애 발생 시, Stand-by NameNode가 곧바로 역할을 이어 받음
kkwang
Self Study
팔로우
이전 포스트
Github 기본 정리
0개의 댓글
댓글 작성