아파치 하둡 입문 강좌 정리

 

 

 

 

 

아파치 하둡 입문 강좌 정리 

이번 포스팅은 [토크 ON세미나] 아파치 하둡 입문 1강 ~ 4강의 내용과 추가적으로 공부한 내용을 정리한 글입니다.

 

강좌

[토크ON세미나] 아파치 하둡 입문

---

왜 하둡인가?

• 데이터 홍수의 시대, 하둡은 비정형 데이터를 포함한 빅데이터를 다루기 위한 가장 적절한 플랫폼

구글의 GFS 발표

• 웹 검색엔진을 만들려면 크롤링을 해야 하고 크롤링한 데이터를 저장한 다음에 인덱싱 라이브러리로 색인을 해야 함
• 하지만 웹에서 수집되는 데이터는 매우 많고 그것은 모두 인덱싱 하면 많은 데이터를 분산/병렬 처리를 해야 하는 이슈

위 같은 문제 해결을 위해 2003년에 구글에서 GFS 아키텍처를 발표함

---

MapReduce

• 2004년, 구글 개발자 제프 딘이 MapReduce 논문 발표
• 구글에서 큰 데이터를 분산/병렬 처리하기 위해 사용하는 알고리즘

Hadoop

• GFS와 MapReduce 논문은 동작 방식과 알고리즘만 나와있는데, 두 논문을 참고해 개발한 소프트웨어가 바로 Hadoop

구글의 논문과 아파치 프로젝트
구글의 논문은 아파치 프로젝트로 많이 탄생함

Google File System → Hadoop Distributed File System
Goolge MapReduce → Hadoop MapRedue
Google Bigtable → HBase(NoSQL)
Google Sawzall → Hive, pig
...

 

Hadoop 이 변화시킨 Big Data

• 과거 : 하둡으로 이제 많은 데이터 저장 가능 ㅋㅋ
• 현재 : 데이터 많은데 뭐하지? -> 새로운 insight & 사업기회를 찾기 위한 노력 및 시장 확대  

---

GFS

• Master - Slave 구조
• Slave를 계속확장해 나가면서 Scale out
• Master - Slave 구조에서 가장 중요한 점은 Master에 부하가 가지 않는 상황을 항상 만들어야 함.

---

아래 아키텍처에서 Chunk data 부분을 보면

• Client ↔ chunkserver가 디렉트로 트래픽을 주고받고 Client ↔ Master 하고는 데이터를 주고받는 연산이 없음
• 이유는 master에 맛탱이 가면 전체가 맛탱이 가버림

하둡 특성

• 수천 대 이상의 리눅스 기반 범용 서버들을 하나의 클러스터로 사용
• 마스터 - 슬레이브 구조
• 파일은 블록(block) 단위로 저장
• 블록 데이터의 복제본 유지로 인한 신뢰성 보장
• 높은 내고장성(Fault-Tolerance)
• 데이터 처리의 지역성 보장

하둡에서 블록(Block) 이란?

• 하나의 파일을 여러 개의 Block로 저장
• Block과 Rack Awareness

What's the Rack Awareness in HDFS

---

블록 크기 분할과 추상화에 따른 이점

• 블록 단위로 저장 -> 디스크 사이즈보다 더 큰 파일을 저장 가능
• 블록 단위로 추상화 -> 스토리지의 서브 시스템을 단순화 가능
• 내고장성을 제공하는데 필요한 복제(replication) 구현할 때 적합 (3.x 버전에서는 복제 방식이 아닌, Erase Coding 방식)
• 같은 파일 분산 처리 ->  데이터 처리 성능을 개선
• 노드에 복제 ->  노드 고장일 경우 다른 노드의 블록으로 복구 가능

블록 캐싱

• 자주 읽는 블록은 블록 캐시(block cache)라는 데이터 노드의 메모리에 명시적으로 캐싱 가능
• 파일 단위 캐싱도 가능

---

NameNode 역할

• 전체 HDFS에 대한 Name Space 관리
• DataNoded에 저장된 데이터 블록 조정 및 관리
• Data에 대한 Replication 유지를 위한 커맨더 역할 수행
• 파일 시스템 이미지 파일 관리 (fsimage)

Fsimage

• 파일, 디렉터리 및 관련 메타데이터(권한, 소유권 및 수정 시간)에 대한 정보 포함하는 전체 파일 시스템 네임스페이스의 직렬화된 표현
• 메타데이터의 스냅샷 역할을 하며 지속성을 위해 디스크에 저장

NameNode가 Fsimage를 사용하는 과정

1. 시작하는 동안 메모리 내 파일 시스템 상태 초기화
   - NameNode가 시작되면 디스크에서 메모리로 최신 fsimage를 로드하여 파일 시스템 네임스페이스 트리를 재구축함
   
   
2. 체크 포인트를 위한 기반 제공
   - SNN (Secondary NameNode)는 edit log(메타데이터에 대한 변경 사항을 기록하는 별도 파일)를 fsimage와 병합하여 업데이트된 fsimage를 생성
   - 이 프로세스를 체크포인트라고 하고, NameNode 장애 시 복구 시간을 최소화하고 편집 로그의 크기를 줄이는데 도움
   
   
3. 백업
   - fsimage는 파일 시스템 메타데이터 백업을 제공

---

Serialized representation(직렬화된 표현)

• 메모리 내 메타데이터 개체를 디스크에 쉽게 저장하기 위한 표현
• 직렬화에는 트리나 그래프 같은 복잡한 데이터 구조를 선형 바이트 시퀀스로 변환하는 작업이 포함됨

예를 들어

 

1. 루트 디렉토리(”/”) 와 각각 단일 파일(”/dir1/fil1.txt” or /dir2/file2.txt”)이 있다고 가정

/
|-- dir1
|   `-- file1.txt
`-- dir2
    `-- file2.txt

2. 그러면 fsimage로 저장하기 위해 namenode는 메타데이터를 직렬화함
3. 각 디렉토리와 파일을 inode ID, 파일 또는 디렉토리를 이름, 권한, 소유권 및 기타 속성 같은 정보를 포함하는 일련의 바이트로 나타낼 수 있음(실제로는 이진형식 → 사람이 못 읽음)

0001|D|/|755|user|group|timestamp|0002|D|dir1|755|user|group|timestamp|0003|F|file1.txt|644|user|group|timestamp|0004|D|dir2|755|user|group|timestamp|0005|F|file2.txt|644|user|group|timestamp

---

보조 네임 노드 (Secondary NameNode)

• fsimage와 edits 파일 주기적으로 병합

 

Edits log  및 fsimage 업데이트 프로세스(Feat. Name Node & Secandary NameNode)

1. 메타 데이터 변경

클라이언트가 파일 생성, 디렉터리 이름 변경 같은 파일 시스템 작업 수행 할 때, NameNode는 메모리 내 메타데이터를 업데이트하고 해당 변경 사항을 Edits log에 기록함, fsimage X

 

2. Edits log의 크기 증가

작업을 계속할수록(= 메타데이터 변경이 많아질수록) edits log의 크기가 커짐. 만약 변경 사항이 너무 많으면 오류 발생 후 복구하는 경우 많은 시간을 초래함

3. Secondary NameNode ckpt(체크포인트)

SNN는 체크포인트 프로세스 시작해서 edits logs랑 fsimage를 병합함

 

병합 과정

1. SNN은 NameNode에게 새로운 edits log 생성하고 현재 edits log를 마무리하게 함 
2. SNN은 NameNode에서 최신 fsimage 및 최종 edits log를 받음
3. SNN은 edits log 내용을 fsimage에 적용해서 최신 상태를 반영한 업데이트된 fsimage 생성
4. SNN은 업데이트된 fsimage를 NameNode에 업로드
5. NameNode는 과거 fsimage를 SNN에서 받은 업데이트된 fsimage로 대체
6. 반복

---

만약 SNN(보조 네임노드)가 죽어버리면?

• 아무 문제가 발생하지 않음
• 다만, edits log가 무한하게 커짐
• 그러면 네임노드 재시작되는 경우 edits log 너무 크면 OOM 날 수 있음

---

NameNode가 하나 일 때(버전 1.0일 때)

• fsimage가 NameNode의 로컬 디스크에 저장
• fsimage가 굉장히 중요한데  NameNode에서 날아가버리면 큰일 남. -> 그래서 물리적으로 다른 디스크에 복제해서 운영하는 게 1.0 버전

하지만 2.0에서 Standby NameNode가 생겼고 그럼 Active/Standby가 사용할 fsimage를 어디서 관리를 할까?

→ shared edits logs를 사용하기로 함

에디트 로그 공유 방식은 2가지가 있음

1. NFS (Network File System)

• 공유 스토리지를 이용하여 공유하는 방법
• 공유 스토리지에 에디트 로그를 공유하고 펜싱을 이용하여 하나의 네임노드만 에디트 로그를 기록함

Fencing  : 네임노드가 장애 나면 Stanby가 Active로 전환될 수도 있도록 처리하는 부분

---

2. Joural Node 그룹 사용(디폴트 방식)

• NFS 방식 같은 공유 스토리지 방식의 문제점을 해결하기 위한 방법
• QJM(Quorum Journal Manager)은 NameNode 내부에 구현된 HDFS 전용 구현체
• QJM은 저널 노드 그룹에서 동작하며, 각 에디트 로그는 전체 저널 노드에 동시에 쓰임

JN 방식 동작 과정

1. JN(JournalNodes)

• 최소 3개 JN가 클러스터에 구성. 이 노드는 Active NameNode에서 받은 Edits log를 저장

2. Write Transcation

• 메타데이터 업데이트 발생 → Active NameNode는 대부분의 JN(3개 중 2개 이상)에 트랜잭션을 write.
• JN 대다수가 트랜잭션을 승인하면 Active NameNode가 커밋된 것으로 간주

3. synchronization(동기화)

• Standby NameNode는 JN에서 커밋된 트랜잭션을 지속적으로 읽고 In-memory 메타데이터에 적용해서 Active NameNode와 동기화 상태를 유지함

4. FailOver(장애조치)

• Active NameNode가 Fail 이 발생해도 Stanby NameNode는  항상 상태를 동기화상태를 유지하고 있었음.  
• 조치가 필요한 경우 Zookeeper에 의해 매니징