하둡은 여러 서버에 걸쳐 있는 분산된 저장 리소스들을 논리적으로 하나로 엮은 상위 레벨의 파일시스템이라 볼수 있다.

물론 각 서버 내에서는 그 서버의 OS에 사용하는 NTFS나 EXT4와 같은 물리적 파일시스템을 이용한다.

하둡의 개념은 크게 storage와 computation으로 나뉜다. 이번에는 storage개념에 대해 알아보자.

HDFS는 큰 데이터를 잘 저장하기 위해 만들어진 것이다. 여기서 크다고 하는 건 기가바이트 단위가 아니고 테라바이트(Tera) 혹은 페타바이트(Peta) 정도를 의미한다. 이렇게 큰 데이터를 하나의 시스템에서 관리한다는 것은 비용이 너무 많이 들고 가능하지도 않기 때문에, 자연스럽게 여러대의 서버에 나누어 저장하는 분산 기술이 핵심이다.

일반적으로 HDFS 클러스터는 하나의 네임노드(Name Node)와 여러개의 데이터노드(Data Node)로 구성된다. 네임노드는 이름과 위치 등의 메타데이터를 관리하는 녀석(Master)이고, 데이터노드는 실제 데이터의 저장을 담당하는 녀석이다.

"하둡을 실행" 한다는 것은 같은 네트워크상의 서로 다른 서버에서 여러 개의 데몬(demon)또는 상주 프로그램들을 실행하는 것을 뜻한다.

하둡은 다음과 같은 데몬들을 가지고 있다.

- NameNode
- JobTracker
- Secondary NameNode
- DataNode
- TaskTracker

1. NameNode

- 하둡은 분산처리 연산에 대하여 Master/Slave구조를 가지고 있다. 이 분산 저장 시스템을 HDFS(Hadoop Distribute File System)라고 한다. 여기서 NameNode는 HDFS의 Master역할을 하며 Slave역할을 하는 DataNode에 I/O작업을 지시한다. 

- NameNode는 파일시스템의 트리와 그 트리안에 있는 모든 파일과 디렉토리에 대한 메타 데이터를 유지한다.

- NameNode는 하나의 단점을 가지고있는데 단일 실패 지점을 가지고 있어 실행중인 장비가 손상되면 파일을 재구성 하는 방법을 알 수 없다. 이러한 이유로, 네임노드는 장애 복구 능력을 갖추는 것이 중요하고 하둡은 이를위한 두가지 매커니즘을 제공한다.

           - 첫번째. 파일시스템 메타데이터의 지속상태(persistent state)를 보완해주는 파일을 백업하는 것이다. 따라서 네임노드의 장애가 발생하여도 백업한 파일로부터 필요한 메타데이터 정보를 가져다 사용 할 수 있다.

           - 두번째. 보조(Secondary)NameNode를 운영하는 것이다. 이때 보조 NameNode는 주 NameNode와는 사뭇 다르게 동작한다. 주 NameNode의 실패시 사용될 네임스페이스 이미지 복제본을 유지한다. 그러나 보조 네임노드의 상태는 주네임 노드의 상태에 뒤쳐지기 때문에, 주 네임노드 데이터의 총체적 장애가 발생하면 어느 정도 데이터손실이 발생한다.

2. JobTracker

- JobTracker는 Master로서 MapReduce의 전체적인 실행을 감독하는 역할.

   - 보통 Master Node와 같이 있고, 클러스터 노드에서 실행되는 사용자 애플리케이션을 관리한다. 사용자가 코드를 하둡 클러스터에 넘기고 나면, JobTracker는 여러가지 실행 계획을 결정하게 된다. 예를 들어, 처리 데이터 파일을 결정하고, 노드에 Task를 할당한다. 또한 JobTracker는 실행되는 모든 Task를 모니터링 하고, Task가 실패한 경우 자동으로 Task를 재실행한다.   

* 하둡 클러스터에는 하나의 JobTracker만 존재한다. JobTracker는 보통 master노드에서 실행된다

3. Secondary Namenode(SNN)

HDFS의 마스터 역할을 수행하는 네임노드(NameNode) 서버는 HDFS내에서 발생하는 모든 파일 트랜잭션을 edit log라는 파일에 저장한다. edit log파일의 용량은 별도의 제한이 없어서, 네임 노드가 다운되지 않는 한 무한대로 저장이 된다. HDFS가 재구동(restart)될 때, HDFS는 재구동을 할 때 edit log와 파일 시스템 이미지(fsimage)를 병합해서 인메모리 형태로 메타데이터를 로딩한다. 하지만 이때 edit log가 지나치게 크다면 HDFS가 인메모리에 메타 데이터를 로딩하지 못하거나, 로딩이 지연되어서 HDFS가 구동되지 못하는 상황이 발생할 하는경우가 생긴다.

이를 위해서 HDFS에는 보조 네임노드(Secondary Namenode)를 제공하며, 보조 네임노드는 네임노드의 edit log를 주기적으로 축약시켜주는 역할을 수행한다. 이러한 edit log의 축약 작업을 체크 포인트(check point)라고 하며, 보조 네임노드를 체크 포인팅 서버라고 부르기도 한다. 또한 네임노드의 파일 시스템 이미지나 edit log가 깨졌을 때, 보조 네임노드에 저장된 데이터를 이용해 복구도 가능하다. 물론 체크 포인팅 주기만큼의 유실은 감안해야 하지만, 트랜잭션이 매우 빈번하지 않다면 보조 네임노드 만으로도 일정한 백업 서버 역할을 감당 할 수 있다.

보조 네임노드를 운영할 때 주의할 점

보조 네임노드 데몬이 다운되어 있거나, 체크 포인팅을 안하고 있더라도 HDFS의 파일 읽기/쓰기는 아무런 문제가 없이 진행이 된다. 그래서 보조 네임노드가 제대로 동작하고 있지 않은 상태에서 HDFS를 재구동하면, 앞서 말씀 드린 것처럼 HDFS가 구동되지 않는 최악의 상황이 발생할 수도 있습니다. 이를 위해 하둡 클러스터를 구성하셨을 때 보조 네임노드가 정상적으로 동작하는 지 반드시 확인을 해야한다!

4. DataNode

사용자가 HDFS파일을 읽거나 쓸 때, 이 파일들은 블록 단위(보통 64MB)로 나누어진다. 이때 NameNode는 각 블록이 어느 DataNode에 위치하고 있는지 클라이언트(사용자)에게 알려준다. 클라이언트 HDFS블록들에 대응되는 로컬 파일을 처리하기 위해 DataNode와 직접 통신한다. 

아래 그림은 NameNode와 DataNode의 역할을 보여준다. 그림에서 시스템은 두개의 데이터 파일을 가지고 있다. 파일 data1은 세개의 블록으로 구성되어 있고 각 블록은 차례로 1,2,3이라 하자. 마찬가지로 data2는 블록 4,5로 구성되어 있다. 파일의 내용은 DataNode에 분산되어 있다.

  HDFS에서 NameNode와 DataNode의 상호작용.

NameNode는 파일의 메타데이터 정보를 보관한다. 메타데이터는 다음 정보를 포함한다(시스템 내에 어떤 파일들이 있는지, 각각의 파일은 어떻게 블록으로 나누어 지는지). DataNode는 블록의 백업 저장소 역할을 한다. 그리고 지속적으로 현재 시점의 메타 데이터를 가질 수 있도록 NameNode에게 계속 보고한다.

위의 그림을 보면 1번 블록은 그림에서 오른쪽으로부터 세개의 DataNode에 복사되어 있다. (Default = 3)그렇기 때문에 DataNode하나가 깨져도 사용자는 계속 파일을 읽을 수 있다. DataNode는 계속해서 로컬 디스크에서 발생한 변경이나 로컬 디스크에서 전달된 블록의 삭제나 생성, 이동과 같은 작업 정보를 NameNode에 알려준다.

5. TaskTracker

연산에 관련된 JobTracker와 TaskTracker도 Master/Slave구조를 가진다.  TaskTracker는 각 slave노드에 할당된 작업의 실행을 담당한다. 아래그림는 JobTracker와 TaskTracker의 연관되어있는 구조를 보여준다.

JobTracker와 TaskTracker의 연결구조

TaskTracker는 계속해서 JobTracker와 통신(용어 : HeartBeat)하는데 JobTracker는 heartbeat메시지가 TaskTracker로 부터 정해진 주기 내에 도착하지 않으면 해당 TaskTracker에 문제가 생긴것으로 판단하며 해당 작업을 다른 노드에 할당한다. 

하둡에서 자주 사용하는 명령어는 다음과 같다. 

* 폴더의 용량을 확인할 때 count 를 사용

* 파일의 내용을 확인할 때는 cat 보다는 text를 사용하면 더 좋다. 파일 타입을 알아서 판단하기 때문

local space 에서는 그냥 리눅스 명령어 사용

HDFS space 에서는 hadoop fs -~~~~ 명령어 사용

hadoop fs -ls / 

 ex) hadoop fs -ls /user/training

tar zxvf ㅇㅇㅇ.tar.gz

put local -> HDFS

get local <- HDFS

hadoop fs -put from(local) to(HDFS)

hadoop fs -get from(HDFS) to(local)

| 사용해서 압축을 풀고 바로 이동하게한다.

from 이 빠져도 된다.

hadoop fs -cat [경로]

    - 경로의 파일을 읽어서 보여줌

    - 리눅스 cat 명령과 동리함

hadoop fs -count [경로]

    - 경로상의 폴더, 파일, 파일사이즈를 보여줌

hadoop fs -cp [소스 경로] [복사 경로]

    - hdfs 상에서 파일 복사

hadoop fs -df /user/hadoop

    - 디스크 공간 확인

hadoop fs -du /user/hadoop

    - 파일별 사이즈 확인

hadoop fs -dus /user/hadoop

    - 폴더의 사이즈 확인

hadoop fs -get [소스 경로] [로컬 경로]

    - hdfs 의 파일 로컬로 다운로드

hadoop fs -ls [소스 경로]

    - 파일 목록 확인

hadoop fs -mkdir [생성 폴더 경로]

    - 폴더 생성

hadoop fs -mkdir -p [생성 폴더 경로]

    - 폴더 생성, 부모 경로까지 한번에 생성해 준다. 

hadoop fs -put [로컬 경로] [소스 경로]

    - 로컬의 파일 hdfs 상으로 복사

hadoop fs -rm [소스 경로]

    - 파일 삭제, 폴더는 삭제 안됨

hadoop fs -rmr [소스 경로]

    - 폴더 삭제

hadoop fs -setrep [값] [소스 경로]

    - hdfs 의 replication 값 수정

hadoop fs -text [소스 경로]

    - 파일의 정보를 확인하여 텍스트로 반환

    - gz, lzo 같은 형식을 확인후 반환해줌

hadoop fs -getmerge hdfs://src local_destination

- hdfs 경로상의 파일을 하나로 합쳐서 로컬로 가져온다. 

- 리듀스 결과가 여러개일 경우 하나의 파일로 만들기 위해 사용할 수 있다. 

- 주의할 점은 로컬 경로로 가져온다는 것이다. hdfs 상에는 생성 불가이다.