[Hadoop_기초] 3. Hadoop 분산파일시스템 이해(2)

hadoop 유튜브 영상 참고하여 정리한 내용입니다.

 

HDFS 사용자 커맨드

- 위의 대표적인 작업을 위한 명령어와 더불어 대부분 리눅스 명령어와 비슷하다. 

 

하둡에서만 사용되는 명령어

1. hadoop fs -setrep <rep> <path>

: 하둡에 있는 특정 path에 있는 파일을 특정 복제서버로 보내는 것을 지정

2. hadoop fs -text <src>

: 하둡에 저장되어있는 데이터의 내용을 볼때 

3. hadoop fs -getmerge <src> <localdest>

: 하둡에 파일갯수가 많을 때 특정 파일을 merge하고 한 파일로 받고 싶을 때

 

---- 사실 프로그래밍 화면에서 작동하는 경우가 많고 커맨드언어는 리눅스와 비슷하다고 생각하고 그때 그때 필요에 따라서 검색해서 사용하면 된다. 

 

하둡 관련 명령어 설정 및 실습

 

1. 홈 디렉토리에서 vi .bash_profile 

2. hadoop home을 프로필에 path를 설정 / bash_profile에 아래 코드 추가하기

export HADOOP_HOME=/usr/local/Cellar/hadoop/3.3.2/libexec
export PATH=${HADOOP_HOME}/bin:${PATH}

-> 그러면 어느 위치에 있든 hadoop으로 하둡 명령어 실행 가능

-> 물론 홈 경로는 사람마다 다를 것. 위의 경로는 내가 설정한 홈 경로이다.

 

---

WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable

해당 경고발생

원인은 64비트 리눅스에서 32비트 하둡을 돌려서 생김

hadoop-env.sh 나 .bashrc나, 어디에든 다음을 추가해주면 해결.

원래는 $HADOOP_HOME/lib 으로 되어 있는 부분을 $HADOOP_HOME/lib/native 로 바꾼다.

혹은

하둡 설정파일 중 "hadoop-env.sh"에 다음과 같이 2줄을 추가해줌

그런데 단순 경고라서 기능 사용에는 큰 문제가 없다.

---

mkdir: `hdfs://localhost:9000/user/songhyeonju': No such file or directory

이런 에러가 발생한 이유는 최상위 디렉토리가 없기 때문이다. 따라서 만들어 주면 된다. (참고 링크)

원인은 -ls 뒤에 특정 path를 지정안해주면 hadoop에서 디폴트로  /home/[username]폴더를 탐색한다고 한다. 그런데 해당 폴더가 없으니 에러가 나는 것.

$ hadoop fs -ls

-> 해당 명령어로 디렉토리 존재 여부 확인하고 없다고 하면

$hadoop fs -mkdir /user

-> 최상위 디렉토리를 만들고 user 폴더 안에 hadoop폴더도 만들어 주기

$hadoop fs -mkdir /user/{loggedin user}

---

 

위의 여러 명령어는 우리가 하둡의 namenode에게 해당 명령어를 실행하라고 요청하는 것이다. 

 

 

HDFS 설정

Rach Awareness

- rack단위로 에러가 나는 경우도 있다. 하둡에 데이터를 적재할 때, 서로 다른 rack에 블록이 저장되도록 설정 하는 것이다.

 

HDFS 세이프 모드

• 데이터노드를 수정할 수 없는 상태
• 데이터는 읽기전용, 추가와 수정이 불가능하며 복제도 일어나지 않음
• 관리자가 서버 운영 정비를 위해 세이프 모드를 설정하기도 한다
• 네임노드가 문제 생겨서 정상적인 동작을 할수 없을 때 자동으로 전환된다. 
  -> 일반적으로 missing block
  -> 혹은 재구동시

 

커럽트 블록

• 어떠한 유실이 발생한 것이다. 
• 데이터 블록에 문제가 생겨서 복구해야 하는 것이다. 

하둡의 휴지통 설정 및 명령어

- 하둡에서 삭제를 하더라도 실제로 삭제가 아니라 일종의 휴지통으로 보내게 된다. 그 휴지통에서 얼마나 보관할지를 설정할 수 있다.

-> 보통 하둡을 장기 저장소로 활용하므로, 휴지통 복구 기능도 꽤 사용된다.

-> 영구 삭제는 비추천

 

운영자 커맨드 목록

- dfsadmin -report :  네임노드에게 각 노드들의 상태를 출력요청

 => hdfs dfsadmin -report -live / -dead

- dfsadmin -setQuota : 특정 디렉토리의 용량을 설정

 

HDFS Balancers

• 하둡 운영 시에 서로 다른 스펙의 데이터 노드를 하나의 클러스터로 구성하게 되는 경우 발생
• 이 경우 노드간 디스크 크기가 다를 수 있고 전체 데이터의 밸런싱이 되지 않는 문제가 발생.
• 신규 데이터 노드를 추가하는 경우에도
• 이러한 경우에, 네임노드에서 데이터 적재량이 적은 노드를 우선적으로 선정하여 블록을 추가하고, 이때 특정 노드에 부하가 몰릴 수 있다. 

-> 특히 온프레미스에서 운영하는 경우, 장비 도입 연도와도 여러 부분이 관련되어 있어서 이러한 밸런스 설정이 중요하다.

 

web hdfs rest api

• 원격으로 hdfs에 api를 통해 파일을 조회, 생성, 수정, 삭제하는 것이 가능 

 

HDFS 암호화 - KMS(key management server)

• Key Provider API를 기반으로 암호화 키 관리 서버다
• 하둡의 특정 영역을 암호화 영역으로 설정하고, 해당 부분에 저장되느 ㄴ데이터는 자동으로 암호화되도록 설정 할 수 있다. 어떤 방식으로 암호화할 것인지에 대해 

 

Hadoop 2.0 - 마스터 서버의 장애를 해결하기 위한 것이 가장 큰 변화 포인트

* 네임노드가 stanby 네임노드가 추가되었다. 평소에 동작하지 않다가, active가 장애가 났을때 네임노드 역할을 한다. 

-> 이때 active => standby 로 변경되는 과정에서 약간의 시간이 소요된다. (하둡에 들어가있는 파일의 양에 따라서)

 

* shared edit logs : 기존에는 fsimage가 로컬디스크에 저장된다. 따라서 기존에도 fsimage를 여러개로 복제하여 서로 다른 디렉토리에 저장해두었다. 2.0에서는 실제로 네임노드가 두개인데, 이러한 edit logs를 어떻게 공유할 것인가 하는 문제가 생겼다. 

-> 네임노드 고가용성 => 이로인해 zookeeper등장

• 이중화된 두대의 서버인 액티브/ 스탠바이 네임노드를 이용하여 지원
• 두개의 네임노드는 데이터 노드로부터 블록 리포트와 하트비트를 모두 받아서 동일한 메타데이터를 유지하고, 공유 스토리지를 이용하여 에디트 파일을 공유
• 액티브는 메인 네임노드의 역할을 수행하고, 스탠바이 네임노드는 액티브와 동일한 메타 데이터 정보를 유지하다가 액티브에 문제가 발생하면 스탠바이 네임노드가 액티브 네임노드로 동작
• 액티브 네임노드에 문제가 발생하는 것을 자동으로 확인하는 것이 어렵기 때문에 보통 주키퍼를 이용하여 장애 발생시 자동으로 변경할 수 있도록 구성
• 저널로드라는 개념이 등장 - 에디트 로그 , 스냅샷등의 파일이 공유되는 저널 로드를 세대이상 띄워서 각 네임노드가 공유하는 것이다. 이러한 저널로드도 일종의 서버이고, 이미지 파일을 결국 어딘가에 저장해야 한다. 
  • 공유 방식1 : NFS(Network File System) => 주키퍼의 알고리즘에 의해 의존
    -> 에디트 파일을 공유 스토리지를 이용하여 공유/ 펜싱(장애시, 스탠바이 네임노드가 액티브로 전환될 수 있도록 처리하는 부분)을 이용하여 하나의 네임노드만 에디트로그 기록
    -> 네트워크 장애 발생하는 경우 큰 문제, 액티브가 주키퍼와 스탠바이 네임노드와는 통신하지 않고 공유스토리지랑만 통신되는 경우/ 이런 경우 액티브 네임노드가 두개가 발생.
  • 공유방식2 : jounal node그룹 사용(디폴트 방식)
    -> 공유스토리지에 저장하지 않는 방식

 

 

 

HDFS Federation(이중화와 다른 개념)

• 하나의 네임노드에서 관리하는 파일, 블록 개수가 많아지면 물리적 한계 발생 
• 이를 해결하기 위해 2.0에서 등장 한것
• 이를 활용하면 파일, 디렉토리의 정보를 가지는 네임스페이스와 블록의 정보를 가지는 블록풀을 각 네임노드가 독립적으로 관리
• 네임스페이스 볼륨(네임스페이스, 블록풀)은 독립적으로 관리 되므로 하나의 네임노드에 문제가 생겨도 다르 ㄴ네임노드에 영향을 주지 않는다. 

 

apache zookeeper

- 분산 시스템의 코디네이터

• 설정관리
• 분산 클러스터 관리
• 명명 서비스
• 분산 동기화
• 분산 시스템에서 리더(액티브 네임노드)산출
• 중앙 집중형의 신뢰성 있는 데이터 저장소
• 분산 배타적 잠금
  -> 쓰기 작업에 대해서 lock을 관리

 

데이터 모델은 트리 모델이다

• 데이터는 항상 전체를 읽고 씀
• 즉 각 트리의 노드가 실제 서버 노드와 연결되어 데이터를 공유함
• 영구노드(persistent node) : 명시적으로 삭제되기 전까지 존재
• 임시 노드(Ephemeral node) : 세션이 유지되는 동안 활성, 자식노드를 가질 수 없다.
• 순차 노드(sequence node) :  경로의 끝에 일정하게 증가하는 카운터 추가, 영구 및 임시 노드 모두에 적용가능

-> watch 등록한 애한테, 변경됐다는 사실을 보낼 수 있다. 네임노드를 누구로 할 것인지 주키퍼에 등록된 znode 상태를 보고 이벤트를 노티 받아서 변화를 설정

 

주키퍼를 여러개의 프로그램들이 위와 같은 용도로 활용한다.