[하둡 완벽 가이드] - PART01 3장 정리

3장 하둡 분산파일 시스템인 HDFS에 대해 정리해 보려한다.

3장에서는 HDFS개요 및 설계 와 목표 , 블록개념 , 네임노드/데이터노드, 블록캐싱 공유스토리지,펜싱에 관한 내용들이 있다.

 

1. 데이터가 단일 머신 저장용량을 초과하면 왜 여러 머신에 나눠 저장해야 하는가?

단일 머신 저장용량을 초과하면 한대에 전부 담을수가 없기 때문에 물리적으로 선택지가 " 나눠담기" 밖에 없다. 그런데 분산저장은 단순히 공간을 늘리는 것 이상의 이점도 같이 가져온다.

 

1) 용량 확장(Scale-out)이 가능해짐

- 디스크/서버를 추가하면 그만큼 저장 공간이 선형적으로 증가.

- 한 대를 더 큰 장비를 바꾸는(Scale-up)방식은 비용이 급격히 커지고 한계가 빨리 옴.

2) 처리 성능(처리량)도 같이 올라감

- 데이터가 여러 노드에 분산되어 있으면, 각 노드가 자기 디스크에서 동시에 읽기/쓰기를 할수 있다.

- 즉, 병렬 I/O가 가능해져 대용량 데이터 처리(스트리밍 읽기)에 유리함.

3) 장애 허용(내고장성)을 설계할 수 있음

- 한 대에만 저장하면 그 머신/디스크가 죽는 순간 데이터가 통째로 위험해짐.

- 분산 파일시스템(HDFS 등)은 블록을 여러 노드에 복제해서, 일부 노드가 죽어도 데이터를 계속 읽을 수 있게 만든다.

4) 비용 효율(범용 하드웨어 활용)

- 아주 큰 단일 스토리지 장비(고가 SAN 등)보다, 여러 대의 범용 서버를 모아 쓰는게 보통 더 싸고 확장도 쉬움

2. 분산 파일 시스템(분산 시스템)이란 무엇인가?

-분산 파일시스템은 네트워크로 연결된 여러 컴퓨터의 저장공간을 하나의 파일시스템처럼 통합해 사용하는 시스템이다.

데이터는 여러 노드에 나뉘어 저장되지만 사용자는 로컬 파일시스템처럼 파일을 읽고 쓰며, 대용량 데이터 저장과 처리를 위해 사용됩니다.여러 대의 서버가 있는데 사용자는 하나의 저장소 처럼 사용 : 이게 분산 파일 시스템이다.

3. 분산 파일시스템이 일반 디스크 파일시스템보다 복잡한 이유는?

여러 머신과 네트워크를 기반으로 동작하며 장애 대응, 데이터 복제, 동기화 등을 함께 처리해야 하기 때문에 단일 디스크 파일시스템보다 훨씬 더 복잡하다.

일반 파일시스템

• 한 컴퓨터
• 한 디스크
• 로컬 I/O

분산 파일시스템

• 여러 서버
• 네트워크 연결
• 데이터 분산 저장

→ 고려할 요소 급증

4. 분산 파일 시스템에서 "강건함"(내고장성)이 특히 어려운 이유는?

여러 머신과 네트워크로 구성된 환경에서는 장애가 빈번하고 형태도 다양해 데이터 손실 없이 시스템을 계속 동작시키는 것이 매우 어렵기 때문이다.

장애가 기본적으로 많이 발생함

분산환경

• 서버수 많음
• 디스크 많음
• 네트워크 많음

고장 확률 상승

5. HDFS란 무엇이며 Hadoop에서 어떤 역할을 하는가?

HDFS는 Hadoop에서 사용하는 분산 파일시스템으로, 대용량 데이터를 여러 노드에 분산 저장하고 안정적으로 관리하는 저장 기반 역할을 한다.

 

Hadoop 구조속 위치

저장(HDFS) + 처리(MapReduce/Spark) + 자원관리(YARN)

여기서 HDFS는 데이터를 저장하는 핵심 계층이다.

 

정리: HDFS는 Hadoop Distributed File System의 약자로, 하둡에서 대용량 데이터를 여러 노드에 분산 저장하고 복제를 통해 안정적으로 관리하는 저장계층입니다. MapReduce나 Spark 같은 분산 처리 시스템이 데이터를 효율적으로 처리할 수 있도록 기반을 제공하는 핵심 역할을 합니다.

6. 하둡이 "범용 파일시스템"을 추구한다는 말은 무슨 의미인가?

하둡이 범용 파일시스템을 추구한다는 것은 특정 저장장치에 종속되지 않고 다양한 스토리지(HDFS, 로컬FS, S3 등)를 동일한 방식으로 사용할 수 있도록 추상화된 파일시스템 구조를 제공한다는 의미이다. 이를 통해서 알수있는건 저장소가 바뀌어도 동일한 방식으로 데이터를 읽고 쓸 수 있어 유연성과 확장성이 높아집니다.

7. 하둡이 로컬 FS, S3 같은 다른 스토리지와 통합하는 방식(추상화)은 왜 중요한가?

저장소 종류에 상관없이 동일한 방식으로 데이터를 처리할 수 있어 시스템 유연성,확장성,재사용성이 크게 향상되기 때문이다.

하둡은 : 저장소 위에 추상화 계층(FileSystem API)를 둔다. 이를 통해서 저장소가 바뀌어도 분석 코드를 그대로 사용할 수 있고, 온프레미스와 클라우드 환경을 유연하게 오가며 확장할 수 있기 때문에 매우 중요하다.

그래서 :

• HDFS
• 로컬 파일시스템
• S3
• 기타 스토리지

모두 같은 방식으로 사용 가능

저장소가 바뀌어도 분석 코드 그대로 사용

예:

• 개발 환경 → 로컬 FS
• 운영 환경 → HDFS
• 클라우드 → S3

코드 수정 거의 없음

8. HDFS가 "대용량 파일"에 최적화된 이유는?

HDFS는 큰 블록 단위 저장, 스트리밍 접근,병렬 처리 구조로 설계되어 대용량 파일을 빠르게 읽고 처리하는데 유리하기 때문이다.

왜 대용량 파일에 강하냐

블록 크기가 매우큼

일반파일시스템 - 블록 수 KB 단위 

HDFS - 기본 128MB 이상

 

블록이 크면 디스크 탐색 횟수 감소, 연속 전송 시간 증가.

 

HDFS는 전체파일을 순차적으로 읽고 " 한번 쓰고 여러번 읽기" 패턴에 최적화되어있다. 로그,기상데이터 같은 대용량 분석에 적합하다.

9. HDFS에서 말하는 "스트리밍 방식 접근"이란 무엇인가?

스트리밍 방식 접근은 파일을 처음부터 끝까지 순차적으로 읽거나 쓰는 방식으로, 전체 데이터 처리 효율을 높이기 위한 접근 방식이다.쉽게 말하면 "파일을 통째로 순서대로 읽는다"

10. HDFS가 "응답시간"보다 "처리량"을 더 중시하는 이유는?

HDFS는 대용량 데이터 분석을 위한 시스템으로, 개별 요청의 빠른 응답보다 전체 데이터를 얼마나 빠르게 처리하느냐가 더 중요하기 때문이다. 그래서 스트리밍 방식 접근과 병렬 처리를 통해 처리량을 극대화 하도록 설계되었습니다.

11. HDFS가 범용 하드웨어(commodity hardware)를 전제로 설계된 이유는?

대규모 데이터를 저장하려면 비용이 낮은 일반 장비를 많이 사용하는 것이 현실적이며, 대신 소프트웨어로 장애를 견디도록 설계했기 때문이다.

12. HDFS가 빠른 응답시간(수십 ms)을 요구하는 워크로드에 부적합한 이유는?

HDFS는 개별 요청을 빠르게 처리하는 시스템이 아니라, 대용량 데이터를 순차적으로 읽어 처리량을 높이도록 설계된 배치 중심 파일시스템 이기 때문이다. 실시간 조회나 트랜잭션 처리에는 HBase나 RDBMS 같은 시스템이 더 적합하다.

 

-Apache HBase는 대용량 데이터를 랜덤 읽기/쓰기로 낮은 지연단위(ms단위)에 처리하도록 설계된 분산 NoSQL 데이터베이스 이기 대문이다.

13 네임노드 메모리와 파일/ 디렉터리/ 블록 메타데이터 관계

네임노드는 HDFS의 모든 파일,디렉터리,블록 정보를 메모리에 메타데이터 형태로 저장해 관리하며, 이 메모리 크기가 곧 HDFS에서 관리 가능한 파일 수와 확장성을 결정한다. 파일하나, 디렉터리하나, 블록 하나마다 일정한 메모리를 사용하기 때문에 네임노드의 메모리 용량이 곧 관리 가능한 파일 수와 HDFS의 확장성을 결정하는 중요한 요소가 됩니다. 따라서 HDFS는 수많은 작은 파일보다는 적은 수의 대용량 파일을 다루는데 더 적합합니다.

 

14. "다중 라이터"와 "임의 수정"이 HDFS에서 제한되는 이유는?

HDFS는 대용량 파일을 순차적으로 처리하는 구조와 단순한 일관성 모델을 유지하기 위해 단일 라이터와 append 중심 설계를 채택했기 때문이다. 다중라이터나 임의수정은 블록 동기화, 정합성 유지, 락 관리 등의 복잡성을 크게 증가시키기 때문에 기본적으로 제한되어 있으며, 대신 '한번 쓰고 여러번 읽는'분석 워크로드에 최적화 되어있습니다.

 

다중라이터 : 여러 프로세스가 동시에 같은 파일에 쓰기 

임의 수정: 파일 중간 위치를 직접 수정

ex:) 파일 100MB 중 40MB 지점 수정

15. 디스크 블록과 파일시스템 블록은 무엇이며 차이는?

디스크 블록은 물리적 저장장치가 데이터를 읽고 쓰는 최소 단위이고, 파일시스템 블록은 운영체제가 파일을 관리하기 위해 사용하는 논리적 데이터 단위이다.

디스크 블록 (Physical block)

하드디스크/SSD가 실제로 데이터를 처리하는 단위.

• 하드웨어 개념
• 물리적 저장 단위
• 크기 : 보통 512B, 4KB

즉: 디스크가 한번에 읽고 쓸수 있는 최소 단위

파일 시스템 블록(Filesystem block)

운영체제가 파일을 저장할 때 사용하는 단위.

• 소프트웨어 개념
• 파일 관리 단위
• 크기: 보통 수 KB ~ 수십 KB

예: ext4 파일시스템 블록: 4KB

 

관계

파일 저장 과정: 파일 -> 파일시스템 블록으로 분할 -> 파일시스템 블록이 디스크 블록에 기록

16. HDFS 블록이란 무엇인가?

HDFS 블록은 HDFS에서 파일을 저장할 때 데이터를 나누는 기본 저장 단위로, 여러 데이터노드에 분산저장되는 대용량 데이터 조각이다. 이를 통해 대용량 파일을 안정적으로 저장하고 병렬 처리할 수 있는 기반이 됩니다.

17. HDFS 블록이 기본적으로 큰(ex:128MB) 이유는 무엇인가?

디스크 탐색 비용을 줄이고 순차 전송 비중을 높여 대용량 데이터의 처리 효율과 처리량을 극대화하기 위해서다. 이는 처리량을 극대화하고 네임노드의 메타데이터 부담을 줄이며,병렬 처리 효율을 높이는 데 중요한 설계 요소입니다.

핵심 원리

디스크 작업 시간: 탐색 시간(seek) + 데이터 전송 시간

18. "탐색 비용(seek cost)"과 "전송률(throughput)" 관점에서 블록 크기 논리를 설명해라.

블록이 작으면 디스크 탐색 시간이 반복되어 성능이 떨어지고, 블록이 크면 한 번 탐색 후 많은 데이터를 연속 전송할 수 있어 전송률이 높아지므로 HDFS는 큰 블록을 사용한다.

 

탐색 비용: Seek cost 디스크가 읽을 위치로 헤드를 이용하는 시간.

전송률 : 디스크가 실제 데이터를 읽어 전달하는 속도.

19. HDFS에서 작은 파일(예:1MB)은 128MB를 전부 점유하지 않는 이유는?

HDFS 블록 크기(128MB)는 저장 단위의 최대 크기일 뿐,파일이 작으면 실제 데이터 크기만큼만 디스크를 사용하기 때문이다.

그래서 HDFS는 공간 낭비는 적고 메타데이터 비용은 크다 그래서 작은 파일 수가 많으면 성능 문제가 발생한다.

다만 작은 파일이 많아지면 네임노드 메타데이터가 증가해 성능 문제가 발생할 수 있습니다.

20. 블록 추상화를 도입해서 얻는 이점 2가지는 무엇인가?

1.  파일 크기가 단일 디스크 용량을 초과해도 저장할수 있다.

2.  스토리지 관리와 장애 대응이 단순해진다.

정리 : HDFS에서 블록 추상화를 도입함으로써 파일을 여러 블록으로 나누어 여러 노드에 저장할 수 있어 단일 디스크 용량을 초과하는 대용량 파일도 저장할 수 있습니다. 또한 블록 단위로 복제와 관리를 수행할 수 있어 스토리지 관리가 단순해지고 장애 대응이 쉬워지는 장점이 있습니다.

21. 블록 단위가 스토리지 서브시스템 단순화에 도움이 되는 이유는?

고정 크기의 블록 단위로 데이터를 다루면 저장,위치 관리, 복제, 장애 복구 같은 작업 파일 단위보다 훨씬 단순하게 처리할 수 있기 때문이다. 파일 단위로 처리할 때 보다 관리 복잡도가 낮아지고 분산 시스템에서 확장성과 안정성을 확보하기 쉬워집니다.

 

22. 블록 복제가 내고장성/가용성을 제공하는 방식은?

HDFS는 각 블록을 여러 노드에 복제 저장해 하나의 노드나 디스크가 고장나도 다른 복제본을 사용해 데이터를 계속 읽고 복구할 수 있게 함으로써 내고장성과 가용성을 확보한다.

23. 복제 계수(replication factor)를 높이면 어떤 효과가 있는가?(읽기 부하 관점)

복제 계수가 높아지면 동일한 데이터를 제공하는 노드가 늘어나 읽기 요청을 여러 노드로 분산할 수 있어 읽기 부하가 감소하고 성능이 향상됩니다. 그 결과 특정 노드에 집중되는 읽기 부하가 줄어들고 병렬 처리 성능과 데이터 접근 속도가 향상됩니다. 다만 저장 공간과 쓰기 비용은 증가하는 trade-off가 있습니다.

24. HDFS가 마스터-워커 패턴으로 동작한다는 의미는?

하나의 중앙 관리 노드(마스터)가 전체 시스템을 통제하고, 여러 작업 노드(워커)가 실제 데이터 저장과 처리를 담당하는 구조로 동작한다는 의미다. 이 구조를 통해 중앙 관리와 분산 저장을 동시에 구현합니다.

25. 네임노드의 역할은 무엇인가?

네임노드는 HDFS의 중앙 관리자 역할을 하며 파일시스템의 메타데이터를 관리하고, 파일이 어떤 블록으로 구성되어 있으며 각 블록이 어떤 데이터노드에 있는지 추적한다. 또한 데이터노드 상태를 감시하고 블록 복제와 배치를 조정하는 핵심 역할을 수행합니다.

네임노드의 핵심 역할

• 파일 이름
• 디렉터리 구조
• 권한
• 소유자
• 생성/수정시간

파일 시스템의 "목차"다 

26. 네임스페이스 이미지(fsimage)와 에디트 로그(edits)는 무엇인가?

네임 스페이스 이미지(fsimage)는 HDFS 파일시스템의 현재 상태를 저장한 스냅샷이고, 에디트 로그(edits)는 그 상태가 변경된 모든 기록을 시간 순서대로 저장한 변경 로그다. 네임노드는 재시작 시 fsimage를 로드한 뒤 edits를 적용해 최신 상태를 복원합니다.

27. 블록 위치 정보는 왜 디스크에 영구 저장하지 않고 재구성 하는가?

블록 위치는 자주 변하는 동적인 정보이기 때문에 디스크에 저장하는 것보다 데이터노드로부터 다시 보고받아 재구성하는 것이 더 정확하고 효율적이기 때문이다.

28. 데이터노드의 역할은 무엇인가?

데이터노드는 HDFS에서 실제 데이터를 블록 단위로 저장하고 읽기/쓰기 요청을 처리하며, 저장된 블록 상태를 네임노드에 지속적으로 보고하는 역할을 한다. 네임노드의 지시에 따라 블록 복제나 삭제작업도 수행하는 실질적인 데이터 처리 노드입니다.

29. 데이터노드가 네임노드에 주기적으로 보고하는 것은 무엇인가?

데이터노드는 네임노드에 주기적으로 Heartbeat(상태 신호)와 Block Report(보유 블록 목록)를 보고한다. 네임노드는 이 정보를 기반으로 장애를 감지하고 블록 복제 상태를 관리한다.

30. 네임노드가 없으면 파일시스템이 동작하지 않는다는 이유는?

네임노드는 파일과 블록의 위치 정보를 관리하는 유일한 메타데이터 관리자이기 때문에, 네임노드가 없으면 데이터가 어디에 있는지 알수 없어 파일을 읽거나 쓸 수 없기 때문이다. 

 

HDFS 구성

 

• 네임노드 → 메타데이터 관리자
• 데이터노드 → 실제 데이터 저장

 

즉 데이터는 존재하지만 위치 정보는 네임노드만 알고 있다.

31. HDFS 클라이언트가 하는 역할은 무엇이며 POSIX 유사 인터페이스가 왜 중요한가?

HDFS 클라이언트는 사용자와 네임노드·데이터노드 사이의 통신을 담당해 파일 읽기/쓰기를 수행하며, POSIX 유사 인터페이스는 기존 파일시스템처럼 사용할 수 있게 해 개발과 사용을 쉽게 만든다.

32. 네임노드 장애 복구가 필수인 이유는 무엇인가?

네임노드는 HDFS의 파일과 블록의 위치를 포함한 메타데이터를 관리하는 단일 핵심 노드이기 때문에 장애가 발생하면 전체 파일시스템이 멈추므로 반드시 복구 메커니즘이 필요하다. 따라서 서비스 지속성과 데이터 가용성을 보장하기 위해 네임노드 장애 복구는 반드시 필요합니다.

33. 메타데이터를 다수 파일시스템에 백업하는 방식의 장점/한계는?

여러 파일시스템에 메타데이터를 백업하면 장애 시 복구 가능성과 안정성이 높아지지만, 네임노드 자체의 중단을 막지는 못해 고가용성을 완전히 보장하지는 못한다. 따라서 완전한 고가용성을 위해서는 Active-Standby 구조의 HA 구성이 필요하다.

34. (권장)로컬 디스크 + 원격 NFS 동시 백업이 왜 권장되는가?

로컬 디스크와 원격 NFS에 동시에 메타데이터를 저장하면 디스크 장애와 머신 장애 모두에 대비할 수 있어 데이터 안정성과 복구 가능성이 크게 높아지기 때문이다. 로컬은 빠른 접근과 복구에 유리하고, NFS는 물리적으로 분리된 위치에 백업을 보관할 수 있어 데이터 내구성과 복구 가능성을 높이기 때문에 권장된다.

 

35. 보조 네임노드의 "주역할"

보조 네임노드의 주 역할은 fsimage와 edits를 주기적으로 병합(체크포인트 생성)해 네임노드의 메타데이터 관리 부담을 줄이고 복구를 쉽게 만드는 것이고 재시작시 복구 시간을 단축하는데 기여한다.

36. 보조 네임노드가 체크포인트를 만든다는 의미는?

fsimage와 edits를 합쳐 최신 파일시스템 상태를 반영한 새로운 fsimage를 생성하는 작업을 수행한다는 의미다.

체크포인트의 개념

fsimage → 현재 상태 스냅샷

edits → 변경 이력

으로 나뉘어 저장되고 시간이 지나면 edits 로그 계속 증가된다.

 

정리하자면 보조 네임노드가 체크포인트를 만든다는 것은 fsimage와 edits를 병합해 최신 상태가 반영된 새로운 네임스페이스 이미지를 생성하는 것을 의미합니다. 이를 통해 메타데이터를 정리하고 네임노드 재시작 시 복구 시간을 줄일 수 있습니다.

37. 보조 네임노드가 별도 머신에서 돌아야 하는 이유는?

체크포인트 생성 작업이 많은 CPU 메모리를 사용하고, 네임노드 장애 시 복구를 위해 물리적으로 분리된 환경에 메타데이터 복사본을 유지해야 하기 때문이다.

 

이유 : 자원 사용량이 크다

보조 네임노드가 수행하는 작업

• fsimage 다운로드
• edits 다운로드
• 병합 처리
• 새로운 fsimage 생성

이과정은 cpu 많이사용, 메모리 많이사용, 디스크 I/O 많음

같은 머신에서 돌리면: 네임노드 성능 저하 발생.

 

38. Secondary NN이 있어도 데이터 손실이 "시간차로" 발생할 수 있는 이유는?

Secondary NameNode는 실시간 복제 장치가 아니라 "주기적 백업(체크포인트)" 장치이기 때문에, 동기화 사이 시간만큼 데이터 손실이 발생할 수 있다.

 

왜 "시간차"가 생기나?

Secondary NN은 실시간 동기화가 아님

작동방식 은 주기적으로 fsimage + edits 가져옴 →  병합 →  새 fsimage 생성 즉, 항상 최신 상태를 반영하지 않음.

39. 주 네임노드 장애 시 전통 복구 절차를 단계로 설명해보자

주 네임노드가 장애 났을때 HA없이(전통 방식: 백업 메타데이터 + Secondary NN 체크포인트) 복구하는 절차를 단계로 정리하면 아래 흐름이다.

1. 장애 확인 및 NN 프로세스 중단 확정

• 주 네임노드가 죽었는지(프로세스 다운/서버 다운)확인
• 혹시 살아있다면 완전히 중단(중복 NN 실행 방지)

2. "가장 최신" 메타데이터 확보

복구에 필요한것은 메타데이터 이다.

• NFS(원격) 등에 동기 백업된 fsimage/edits
• 또는 Secondary NameNode가 만든 체크포인트 fsimage

즉, "최신 스냅샷 + 가능한 최신 edits" 조합을 확보.

3. 새 네임노드 후보 머신 준비

• 새 서버(또는 복구 서버)에 Hadoop 설정 배치
• NameNode 저장 디렉터리(dfs.namenode.name.dir)준비(깨끗한 상태 권장)

4. 메타데이터 파일 복사

• 2단계에서 확보한 fsimage / edits를 세 네임노드의 NameNode 저장경로에 복사

5. fsimage와 edits 병합(체크포인트 생성)

• Secondary NN 체크포인트 fsimage가 최신이면 → 병합 과정이 거의 끝난 상태
• edits가 남아있고 최신 반영이 필요하면 → fsimage에 edits를 적용해 최신 상태로 만든다.

6. 새 네임노드 기동

• 새 머신에서 NameNode를 시작
• 시작하면서
  • fsimage를 메모리에 로드
  • edit를 리플레이(반영)

7. 데이터노드들의 Block Report 수신 → 블록 위치 재구성

• 네임노드는 블록위치 정보를 디스크에 영구 저장하지 않으므로 모든 데이터 노드가 보내는 블록리포트를 받는다.

8. Safe Mode 해제까지 대기 및 검증

• 초기에는 안전 모드(Safe Mode) 상태로 들어가며
• 충분한 블록 리포트/복제 상태가 확인되면 Safe Mode를 벗어남
• 이때부터 클라이언트 요청 처리 정상화

9. 클라이언트/데이터노드가 새 NN을 바라보게 전환

• fs.defaultFS 등 설정에서 NameNode 주소 변경(또는 DNS/호스트명 매핑)
• 데이터노드/클라이언트가 새 네임노드로 접속하도록 반영 및 재시작

40. "HDFS HA에서는 대기 네임노드가 보조 네임노드 역할을 대체" 한다는 말의 의미는?

HDFS HA 환경에서는 Standby NameNode가 Secondary NameNode가 하던 체크포인트(메타데이터 병합 관리) 역할까지 수행하므로, 별도의 Secondary NameNode가 필요 없다는 뜻이다.

41. 블록 캐싱이란 무엇이며 어디에 캐싱되는가?

블록 캐싱은 HDFS에서 자주 읽는 데이터 블록을 디스크가 아닌 데이터노드의 메모리(off-heap 메모리)에 올려두고 재사용하여 읽기 성능을 높이는 기능이다.

42. 오프힙(off-heap) 캐시를 쓰는 이유는?

오프힙(off-heap) 캐시는 JVM 힙이 아닌 OS 메모리를 사용해 GC 부담을 줄이고, 더 큰 메모리를 안정적으로 사용하며, 읽기 성능을 높이기 위해 사용한다.

43. 잡스케줄러가 캐싱된 데이터노드에서 태스크를 실행하면 어떤 이점이 있는가?

잡스케줄러가 캐싱된 데이터노드 에서 태스크를 실행하면 얻는 핵심 이점은 "데이터 지역성"과 "성능 최적화"입니다.

1) 네트워크 I/O 최소화

• 데이터가 이미 해당 데이터노드의 메모리에 존재함.
• 다른 노드에서 데이터를 가져올 필요가 없어짐 → 네트워크 트래픽 감소
• 대규모 클러스터일수록 효과가 큼.

2) 실행 속도 향상

• 디스크 읽기보다 매모리 캐시(off-heap 포함)접근이 훨씬 빠름.
• MapReduce, Spark 같은 분산 처리에서 태스크 시작 후 바로 데이터 처리 가능
• → 지연시간(latency) 감소, 처리시간 단축.

3) 클러스터 자원 효율 증가

• 네트워크 대역폭을 아껴 다른 작업이 사용할 수 있음.
• 디스크 I/O도 줄어 전체 노드 부하 감소.
• 동일 하드웨어로 더 많은 작업 처리 가능.

4) 반복 작업 성능 최적화

• 자주 접근하는 데이터(머신러닝 학습 데이터, 로그, 피처 데이터 등)를 캐싱.
• 동일 데이터 기반 작업이 반복될 때 성능이 크게 개선됨.

5) 스케줄링 정확도 향상 (데이터 지역성 단계)

잡 스케줄러는 보통 다음 우선순위로 태스크 배치함

1. Node-local : 캐시된 데이터가 있는 동일 노드에서 실행 (최적)

2. Rack-local: 같은 랙 내 다른 노드에서 실행

3: Off-rack: 네트워크 넘어 다른 랙에서 실행(비효율)

캐싱된 데이터노드에서 실행하면 항상 1번 상태를 유지할 수 있음.

 

정리 : 캐싱된 데이터 노드에서 태스크를 실행하면 "데이터 이동 없이 계산만 수행"하게 되어 네트워크·디스크 비용이 줄고, 처리 속도와 클러스터 효율이 동시에 올라간다.

 

44. 조인에서 작업 룩업 테이블 캐싱이 좋은 사례인 이유는?

조인(join)에서 작은 룩업 테이블을 캐싱하는 것이 좋은 사례인 이유는 분산 처리 환경(Hadoop,Spark 등)에서 성능을 크게 좌우하는 요소가 데이터 이동량과 I/O 비용이기 때문이다.

 

구조적으로 좋은이유

 

분산 조인의 비용 구조 : 비용 = 데이터 이동량 + 디스크 I/O + 정렬 + 조인 계산

작은 룩업 캐싱 시 : 비용 = 조인계산만

45. 캐시풀(cache pool)이란 무엇이고 왜 필요한가?

캐시풀(Cache Pool)은 HDFS 같은 분산 파일시스템에서 어떤 데이터(파일/블록)를 메모리에 캐싱할지, 누가 얼마나 캐시를 사용할 수 있는지 관리하는 논리적 단위입니다.

HDFS에서 블록 캐싱은 DataNode 메모리(주로 off-heap)에 데이터를 올려 빠르게 읽도록 하는 기능인데,
이때 캐시풀은 다음을 정의합니다.

• 어떤 파일을 캐시할지
• 어떤 사용자/그룹이 캐시를 사용할 수 있는지
• 캐시 사용량(쿼터)
• 캐시 우선순위/정책

캐시풀 없이 캐싱하면 생기는 문제들

 

• 메모리 선점 경쟁
• 중요한 데이터가 밀려남
• 예측 불가능한 성능
• 운영 통제 불가

→ 대규모 클러스터에서는 사실상 필수 개념

46. HDFS 페더레이션이란 무엇이며 어떤 문제를 해결하는가?

HDFS 페더레이션(Federation)은 하나의 HDFS 클러스터에서 여러 개의 네임노드(NameNode)가 서로 독립적으로 메타데이터를 관리하도록 확장한 구조 입니다.

HDFS 페더레이션 개념

페더레이션에서는

 

클러스터
 ├─ NameNode A → namespace A
 ├─ NameNode B → namespace B
 ├─ NameNode C → namespace C
 └─ DataNodes (공유)

 

• 네임노드가 여러개
• 각각 독립된 파일시스템 메타데이터 관리
• 데이터노드는 여러 네임노드에 동시에 연결됨

47) 네임스페이스 볼륨과 블록 풀은 무엇인가?

HDFS 페더레이션을 이해하려면 네임스페이스 볼륨(namespace volume)과 블록 풀(block pool) 개념을 같이 알아야합니다.

둘은 "네임노드가 관리하는 영역"과 "데이터노드에 실제 저장되는 블록 묶음"을 구분하는 핵심 구조 입니다.

네임스페이스 볼륨(Namespace Volume)

하나의 네임노드가 관리하는 파일시스템 메타데이터 전체를 의미합니다.

• 파일
• 디렉토리 구조
• 파일 권한
• 파일 → 블록 매핑 정보

블록 풀(Block Pool)

각 네임노드 namespace에 속한 실제 데이터 블록들의 집합

• 파일은 블록으로 쪼개져 DataNode에 저장됨
• 네임노드마다 자기 블록 그룹을 따로 가짐
• 이 블록 묶음을 block pool이라 부름

 

• Namespace volume: 네임노드가 관리하는 파일시스템 메타데이터 영역
• Block pool: 해당 namespace의 실제 데이터 블록들이 DataNode에 저장된 물리적 집합

그리고 페더레이션에서는
네임노드마다 namespace + block pool이 한 쌍으로 존재하며, DataNode는 여러 block pool을 동시에 저장한다.

 

48) 네임노드가 SPOF인 이유는 무엇인가?

네임노드가 SPOF(Single Point Of Failure, 단일 장애 지점)인 이유는 HDFS에서 파일시스템의 모든"메타데이터"를 유일하게 관리하는 중앙 컴포넌트 이기 때문입니다.

쉽게 설명하면

네임노드는 HDFS에서 파일 위치와 메타데이터를 관리하는 유일한 중앙 컴포넌트이기 때문에 장애가 발생하면 데이터는 남아 있어도 접근 자체가 불가능해져 전체 시스템이 멈추며, 그래서 SPOF가 된다.

49) HA의 기본구조(Active/Standby NN)는 어떻게 동작하는가?

HDFS의 HA(High Availability) 기본구조는

두개의 네임노드 Active / Standby 형태로 동시에 존재하면서, 장애 발생 시 자동으로 역할을 교체해 서비스 중단 없이 HDFS를 유지하는 구조입니다.

Active NameNode

• 실제 서비스 담당
• 모든 클라이언트 요청 처리
• 메타데이터 변경 수행
• edit log 기록

Standby NameNode

• 대기 상태
• Active의 edit log를 계속 동기화
• 언제든 Active로 전환 가능

장애 발생시 동작

Active NameNode가 장애 발생

① Zookeeper 감지

• ZKFC가 heartbeat 확인
• Active NN 다운 감지

② Failover 시작

• Standby NN을 Active로 승격

③ fencing 수행

• 기존 Active가 다시 쓰기 못하도록 차단
  (중복 Active 방지)

④ 서비스 지속

Client → 새로운 Active NN

→ 서비스 중단 없이 이어짐

 

HDFS HA는 Active 네임노드가 서비스를 처리하고 Standby 네임노드가 edit log를 실시간 동기화하며 대기하다가, Active 장애 시 Zookeeper 기반 자동 failover로 Standby가 즉시 Active로 전환되어 서비스 중단을 막는 구조다.

50) HA 공유 스토리지로 NFS와 QJM을 선택할 수 있는데 차이는?

HDFS HA에서 Active/Standby 네임노드가 edit log를 공유하기 위한 저장소(Shared Storage)로 대표적으로 NFS 방식과 QJM(Quorum Journal Manager)을 선택할 수 있습니다. 둘의 차이는 "어디에 edit log를 저장하고 어떻게 동기화 하느냐"입니다.

NFS 기반 HA

Active NN ─┐
           ├─ NFS 공유 스토리지 (edit log)
Standby NN ─┘

 

• 하나의 NFS 서버에 edit log 저장
• Active가 쓰고 Standby가 읽어 동기화

QJM (Quorum Journal Manager)

Active NN → JournalNode 1
          → JournalNode 2
          → JournalNode 3

Standby NN → 동일하게 접근

• edit log를 여러 JournalNode에 분산 저장
• 과반수(quorum) 동의로 commit

 

• NFS: edit log를 단일 공유 스토리지에 저장하는 단순하지만 SPOF가 남아있는 방식
• QJM: edit log를 여러 JournalNode에 분산 저장해 과반 합의로 기록하는 고가용성 방식

NFS는 “공유 디스크 기반 HA”,
QJM은 “분산 합의 기반 HA”라고 보면 된다.

51) QJM의 저널 노드 그룹은 어떻게 동작하는가? (동시쓰기, 3개 노드)

QJM(Quorum Journal Manager)에서 저널 노드(JournalNode) 그룹(보통 3개)은 Active 네임노드가 발생시키는 edit log를 동시에 여러 노드에 기록하고, 과반수(Quorum)성공 시에만 commit으로 인정하는 방식으로 동작합니다.

52) 펜싱(fencing)이 필요한 이유는?

HDFS HA에서 펜싱(fencing)이 필요한 이유는 장애 상황에서 이전 Active 네임노드가 계속 쓰기를 시도하는 것을 강제로 차단해 데이터 충돌(split-brain)을 막기 위해서 입니다.

53) fs.defalutFS

fs.defalutFS는 하둡 클라이언트가 기본으로 접속할 파일시스템(HDFS,viewfs 등)의 URI를 지정하는 설정이며, 모든 HDFS 접근의 출발점이 되기 때문에 잘못 설정되면 전체 데이터 접근과 작업 실행이 실패할 수 있어 매우 중요하다.

54) dfs.replication 기본값이 3인 이유는?

dfs.replication은 HDFS에서 파일 블록을 몇개의 복제본으로 저장할지를 정하는 설정이며, 기본값이 3인 이유는 데이터 안정성, 성능, 저장 비용 사이의 균형이 가장 잘 맞는 값이기 때문이다.

의사 분산모드에서는 dfs.replication을 기본값을 1로 둔다.

왜냐면 실제로는 단일머신에서 Hadoop이 동작하기 때문에 복제 자체가 의미가없고, 불필요한 자원사용만 발생하기 때문이다.

55) libwebhdfs는 무엇인가?

libwebhdfs는 HDFS에 직접 접속하지 않고 HTTP 기반(WebHDFS REST API)으로 파일을 읽고 쓰게 해주는 클라이언트 라이브러리(C library)입니다.