[Hadoop_기초] Udemy course - 섹션 2-1.HDFS

udemy - hadoop 기초강의를 보면서 정리한 내용입니다

 

두 번째 섹션에서는 하둡의 HDFS와 맵리듀스에 대한 대략적인 설명으로 이루어졌다. 

1. HDFS(현재글)
2. MapReduce(링크)

---

HDFS 정의 및 작동 방식

HDFS란?

HDFS는 하둡분산 파일시스템을 의미하며, 빅데이터를 전체 클러스터에 분산해 안정적으로 저장하는 시스템이다.
이를 통해 애플리케이션이 그 데이터를 신속하게 액세스해 분석할 수 있다.

무엇보다 데이터 파일 크기나 개별 장비의 파일 시스템 크기에 제한이 없으며,

만약에 주어진 노드들로도 처리가 힘들 정도로 데이터의 처리량이 늘면 노드를 추가하여 처리할 수 있다.

즉, HDFS는 대용량 파일들 즉 빅데이터를 다루기 위해 만들어졌다.
HDFS는 이런 대용량 파일들을 작은 조각으로 나누어 클러스터 전체에 걸쳐 분산시키는데 최적화되어있다.

 

 

HDFS 작동방식

- 이미 블로그에 유튜브 영상을 참고하여 정리한 글이 있으니 같이 참고하면서 정리하면 좋을듯 하다.(링크)

1) 파일을 먼저 '데이터 블록'으로 쪼갠다.

그 블록의 크기는 기본값으로 128MB이다.
대용량 파일을 이렇게 최대 128MB 크기의 블록으로 나눔으로써 각 하드 드라이브의 용량보다 훨씬 큰 파일을 저장할 수 있다.

2) 그리고 HDFS는 이 대용량 파일을 분산해서 처리한다.

각 컴퓨터는 자기에게 저장된 데이터 블록을 동시에 처리하게 되는 것이다.

그리고 데이터 유실에 대비하여 단 하나의 블록만 저장하지 않으며 모든 블록마다 두 개 이상의 복사본을 저장한다.
그래야 어떤 컴퓨터가 다운되더라도 HDFS가 그 블록의 백업 복사본을 갖고 있는 다른 컴퓨터에서 정보를 불러올 수 있게 된다.

단일 노드가 다운되더라도 그 어떤 블록도 잃어버리지 않게 된다.

3) 또한 분산된 서버간 주기적인 상태 체크를 하여, 데이터 처리를 위해 안정적으로 분산 서버(노드)가 작동하도록 관리한다(heart beat)

 

 

HDFS 아키텍쳐

Name Node

어느 블록이 어디에 있는지를 추적한다. 즉 이 노드에 큰 차트가 있고 거기에 주어진 파일의 이름과 HDFS 내의 가상 디렉터리 구조 등의

정보가 있으며 그 파일과 관련된 모든 블록과 해당 복사본들이 어떤 노드에 저장되어 있는지 기록되어 있는 것이다.

그리고 '편집 로그'(edit log)가 있는데 무엇이 생성되고, 어떤 게 수정되고 저장되는지 등의 변경사항이 기록된다.

 

또한 하둡에서 처리되는 파일 속성 정보나 파일 시스템 정보를 디스크가 아닌 메모리에서 직접 관리하는 역할도 한다.

이를 메타 데이터라고 말한다.

 Meta Data
메타 데이터에는 어떤 정보가 담기고 이를 네임노드가 관리하는 것일까?
1. 파일명  2.디렉토리  3. 데이터 블록크기  4. 소유자:소속그룹  5. 파일 속성
6. 데이터노드와 블록 대응 정보
- 블록 ID와 해당 블록을 보유한 데이터 노드 정보
- 데이터노드가 하트비트를 3초간격으로 전송할때 자신이 관리하는 블록 정보를 통지
- 전체 블록 정보를 구축 및 복제수가 충분한지 판단

fsimage
메타데이터의 타입 중 하나.
위의 1~5번 정보를 포함하고 있으며 메모리 사엥 관리되어 있는 메타 데이터 내의 파일 시스템 이미지이다.

edits
파일처리시 로컬 파일 시스템에 생성되는 편집로그로써 메모리 상에서 관리되고 있는 파일시스템 이미지에 적용된다.

 

모든 '데이터 노드'(Data Node)에 무엇이 있는지는 Name node에 기록되고 클라이언트 애플리케이션은 Name node에 쿼리해 어디로 가야할지 알아낸 다음 궁극적으로 그 '데이터 노드'와 연결되어 필요한 데이터를 얻게된다.

'데이터 노드'에 실제 파일의 블록을 저장하고 있고 이 때 서로 다른 두 노드는 블록의 복사본을 잘 유지하기 위해 서로 소통하기도 한다.

HDFS에서 파일을 읽는 예를 살펴보자

1) 클라이언트 노드에서 작동 중인 어떤 애플리케이션이 HDFS에 저장돼 있는 데이터를 액세스하려고 한다.
2) 애플리케이션은 먼저 Name node에게 파일 A가 필요하다고 말한다.
3) Name node는 파일 A는 이러이러한 '데이터 노드'의 요러요러한 블록들에 저장되어 있다고 알려준다.
4) 클라이언트 애플리케이션은 해당 '데이터 노드'에 방문해 그 블록들을 가져와 파일 A를 구성한다.

API가 특정 바이트(Byte)를 이 파일에서 읽고 싶다고 하면 HDFS 클라이언트 라이브러리가 내부적으로 어떤 블록을 어디서 찾아야 할지 그리고 어떻게 찾아가야 할지를 알아낸다.

 

그럼 HDFS에 파일을 쓰려면?

클라이언트 애플리케이션이 HDFS에 새 파일을 만들려고 할 때 먼저 블록의 위치를 추적하는 Namenode에게 물어본다.
그러면 Name node는 새 파일 항목을 확인하고 그 블록의 위치를 정한 후에 어느 '데이터 노드'에 가서 저장하라고 알려준다.
그러면 클라이언트는 정해진 '데이터 노드'에게 가서 파일을 건네주고 그 '데이터 노드'는 주변의 다른 '데이터 노드'에 복사본을 전달한다.

그리고 데이터가 저장되면 잘 받았다는 신호를 클라이언트를 통해 Name node로 보낸다. 그러면 Name node는 새로운 파일의 블록과 복사본의 위치를 기억한다.

 

 

Name Node 장애 방지/복구

그렇다면 '왜 Name node가 하나밖에 없을까? Name node에 문제가 발생하면 어떻게 될까?

기본적으로 한 번에 하나의 이름 노드만 사용해야 한다. 아니면 블록의 위치에 관해 클라이언트 간에 혼선이 생길 수 있기 때문이다.

그런데 단일 name node만 사용하면 단일 실패 지점이 발생하게 되는데 이 문제를 해결할 몇 가지 방법이 있는 것이다.

가장 간단한 방법은 메타데이터를 계속 백업하는 것이다.

1) 이름 노드가 편집 로그를 로컬 디스크와 NFS(네트워크 파일시스템)에 동시에 작성하도록 구성하는 것이다.
이때 NFS는 다른 랙이나 데이터 센터의 '백업 데이터 저장소'와 연결돼 있다.
이렇게 하면 그 Name node가 죽어도 NFS 백업에서 편집 로그라도 살릴 수 있다.
하지만 그 백업 데이터를 다시 작성하는 데는 렉이 좀 걸리기 때문에 어느 정도 정보 손실이 있을 수도 있다.
약간의 다운 타임이 있어도 괜찮다면 해당 방법이 가장 간단하다.

2) secondary Node 구성

이차적 Name node를 운영할 수 있다. 물론 이를 동시에 운영하진 않는다. 즉  '동적 백업'(hot backup)이 아니다.
이차적 Name node가 하는 일은 'main name node'의 편집 로그 복사본을 유지하는 것이다.
해당 방법은 첫번째 방법보다 좀 더 효율적인 방법이라고 할 수 있다. 다운된 Name node를 복구하는 상황에서 이차적 Name node에 보관된 더 최신의 편집 로그를 사용할 수 있기 때문이다.

 

3) HDFS 연합(Federation)

HDFS에 다수의 작은 파일만 있는 상황이라면 Name node는 한계점에 다다를 것이다. 즉 단일 Name node만으로는 충분하지 않은 시점이 올 것이다. 그러면 HDFS 연합은 HDFS 파일 구조 내에 '명칭 공간 볼륨'(namespace volume)이라고 부르는 서브디렉터리마다 분리된 Name node를 지정한다. 그러면 각 볼륨마다 데이터 파일을 읽거나 쓸 때 어떤 Name node와 얘기해야 하는지 알 수 있게 된다.
이렇게 하면 Name node의 업무를 분담하게 된다. Name node 중 하나가 다운되면 적어도 데이터의 전부를 잃게 되지는 않는다는 장점이 있다.

4) HDFS 고가용성(High Availability)

만약 Name node에 문제가 생겼더라도 클러스터에 그 어떤 다운 타임도 허용할 수 없다면 'HDFS 고가용성(High Availability)'을 사용해 '동적 예비 Name node'를 운영한다. 공유 편집 로그를 활용하는데, HDFS가 아닌 다른 안전한 공유 저장소에 편집 로그를 작성한다.
그리고 Name node가 다운되면 '동적 예비 Name node'가 바로 업무를 이어받게 된다.

 

-> secondary namenode와의 차이점은?

namenode자체에 데이터를 완벽하게 저장하느냐?

secondary namenode는 기존 네임노드에 edit log를 저장하고 예비로 복사본을 두는 개념이라면,

HA는 별도의 edit log 저장소를 두고 메인 네임 노드나 예비 네임 노드가 별도의 edit log에서 데이터를 읽어온다.

 

-> zookeeper의 역할

또한 이전 강의에서 설명한 Zookeeper는 어떤 Name node가 활성화돼있는지 파악하고 있게 되는데, 이 구성에서 클라이언트는 먼저 Zookeeper와 얘기해 어떤 Name node와 소통해야 하는지 알아내고 Zookeeper는 모든 클라이언트들이 한 번에 하나의 Name node만 사용하도록 통제한다.

하지만 이러한 예비 Name node를 두는 것은 복잡한 구성이고 실패 발생 시 더 까다로워진다. 예로 두 개의 Name node가 동시에 작동할 수도 있다. 그렇게 되면 문제가 발생하는데, 가령 쓰기 요청을 받을 때 한 Name node는 그 데이터가 어디에 있는지 알고 다른 노드는 모를 수 있기 때문이다.

그리고 읽기 요청이 각각 다른 Name node로 전달되어도 문제가 발생한다. 

이와 같은 상황을 미연에 방지하기 위해 'HDFS 고가용성'은 극단적인 조치를 취하는데 한 번에 하나의 Name node만 사용하도록, 사용하지 않는 Name node의 전원을 물리적으로 차단한다.
예로 Zookeeper가 어떤 Name node를 사용한다고 하면 다른 노드의 전원을 완전히 차단(??)해버려 어떤 클라이언트도 이 노드와 소통하지 못하게 하는 것이다.

결론적으로 단일 'Name node'만 갖는 것이 문제가 아니며 이와 관련하여 단일 실패 지점'을 다루는 방법들이 있다는 것 이다.

HDFS는 클러스터의 수많은 컴퓨터에 걸쳐 분산되어 있고 실패 회복력과 큰 가능성이 있지만 결국에는 파일 시스템을 갖춘 거대한 하드 드라이브이다.

 

HDFS 활용

이러한 HDFS를 다루기 위해서는 여러 방법이 있는데 첫번재로 명령줄 인터페이스가 있다. 윈도우의 'ls'나 'dir', 'cd'같은 명령어와 비슷한HDFS 명령어를 사용하는 것이다. ({hadoop fs -} 다음에 원하는 명령어를 입력함으로써)

또는 간편하게 인터페이스를 활용하는 방법이 있다.(Ambari)

HTTP로 HDFS를 다룰 수도 있다. 직접적으로 하거나 프락시 서버를 통해 할 수 있다. 프락시 서버는 HDFS 머신과 클라이언트 사이에 위치했다. 데이터를 분석하기 위해 스크립트를 작성하거나 애플리케이션 개발을 위해 이 프락시 서버에 웹 인터페이스를 구성할 수도 있다

이 과정에서 C나 Python 혹은 Scala 등을 사용할 수 있다.(하둡이 자바 베이스긴 하지만)

마지막으로 NFS 게이트웨이를 사용할 수 있다. 리눅스에 익숙하다면 이미 들어봤겠지만 NFS는 네트워크 파일 시스템으로써 원격 파일 시스템을 서버에 마운트한다. NFS 게이트웨이를 통해 HDFS를 리눅스 박스에 연결할 수 있다.

 

HDFS가 적절하지 않은 경우

1) low latency 데이터 엑세스

HDFS는 벌크의 데이터를 처리하는 것에 용이한 작업이다. 높은 처리량을 얻는 대신 latency를 포기하였다.

 

2) 많은 수의 작은 파일들을 다룰 경우

파일 시스템의 최대 파일수는 네임노드의 메모리크기에 좌우된다.

 

3) 다수의 쓰기작업과 랜덤파일 쓰기 작업

 

 

 

 

참고자료

https://nathanh.tistory.com/91

HDFS란? (Hadoop File System)

https://kadensungbincho.tistory.com/30

HDFS란? (하둡분산파일시스템)