02. About HDFS..

 

목차
HDFS 기초
HDFS 아키텍처
HDFS 명령어 사용

정리

HDFS 기초

HDFS는 수십 테라바이트 또는 페타바이트 이상의 대용량 파일을 분산된 서버에 저장하고, 많은 클라이언트가 저장된 데이터를 빠르게 처리할 수 있게 설계된 파일 시스템 입니다.

HDFS과 기존 대용량 파일 시스템(DAS, NAS, SAN)의 가장 큰 차이점은 저사양 서버를 이용해 스토리지를 구성할 수 있다는 것 입니다.

HDFS는 다음과 같이 네 가지 목표를 가지고 설계됐습니다.

1) 장애 복구

     HDFS를 구성하는 분산 서버는 다양한 장애가 발생할 수 있습니다. 그러나 장애를 빠른 시간에 감지하고, 대처할 수 있게 설계돼 있습니다.(Really??)

     HDFS는 데이터를 저장하면, 복제 데이터도 함께 저장해서 데이터 유실을 방지! 또한 분산 서버 간에는 주기적으로 상태를 체크해 빠른 시간에 장애를 인지하고, 대처할 수 있게 도와줍니다.

2) 스트리밍 방식의 데이터 접근

    HDFS에 파일을 저장하거나, 저장된 파일을 조회하려면 스트리밍 방식으로 데이터에 접근해야 합니다.

    기존의  파일 시스템은 사용자가 빠르게 데이터에 접근하는 것을 목표로 하지만, HDFS는 기존 파일 시스템들과는 달리 배치 작업에 적합하도록 설계돼 있고, 낮은 데이터 접근 지연 시간보다는 높은 데이터 처리량에 중점을 두고 있습니다.

Tip. Hadoop Streaming - 하둡 스트리밍

Hadoop streaming is a utility that comes with the Hadoop distribution. The utility allows you to create and run Map/Reduce jobs with any executable or script as the mapper and/or the reducer. For example:

발번역.. => 하둡 스트리밍은 하둡배포에 딸려있는 하나의 유틸리티 입니다.  이 유틸리티는 당신이 어떤 실행 가능한 것이나 스크립트를 가지고 mapper나 또는 reducer를 생성하거나 Map/Reduce jobs를 실행 시킬수 있습니다. 예를 들어서:

$HADOOP_HOME/bin/hadoop  jar $HADOOP_HOME/hadoop-streaming.jar \
    -input myInputDirs \
    -output myOutputDir \
    -mapper /bin/cat \
    -reducer /bin/wc

참고 URL : http://hadoop.apache.org/docs/r1.2.1/streaming.html#Hadoop+Streaming

 3) 대용량 데이터 저장

     HDFS는 하나의 파일이 기가바이트에서 테라바이트 이상의 사이즈로 저장될 수 있게 설계 됐습니다. 높은 데이터 전송 대역폭과 하나으 ㅣ클러스터에서 수백 대의 노드를 지원할 수 있어야 합니다. 또한 하나의 인스턴스에서는 수백만 개 이상의 파일을 지원 합니다.

4) 데이터 무결성

    HDFS는 한번 저장한 데이터는 더는 수정할 수 없고, 읽기만 가능하게 해서 데이터 무결성을 유지 합니다. 데이터 수정은 불가능하지만 파일 이동, 삭제, 복사할 수 있는 인터페이스는 제공합니다. Hadoop 2.0 알파ver 부터는 HDFS에 저장된 파일에 append가 제공.

HDFS 아키텍처

 1) HDFS는?

     -  블록 구조의 파일 시스템 입니다.

     - HDFS에 저장하는 파일은 특정 사이즈의 블록으로 나눠져 분산된 서버에 저장 됩니다.

     - 블록 사이즈는 기본적으로 64MB로 설정되어있고 변경이 가능 합니다.

     - 여러 개의 블록은 동일한 서버에 저장되는 것이 아니라 여러 서버에 나눠서 저장 됩니다.

★ 왜 64MB 인가?? 외국인형이 stackoverflow에 질문 올린 글! 참조~

   HDFS blocks are large compared to disk blocks, and the reason is to minimize the cost of seeks

   발번역  - HDFS 블록들은 디스크 블록들과 비교했을 때 크다. 그리고 이유는 최저의 비용으로 찾을 수 있다는 것이다.

 

그림_a) HDFS의 파일 복제 구조

 

 

 

320MB의 파일을 HDFS에 저장했을 때 블록이 복제되는 것을 나타낸 그림 입니다. 

파일은 다섯 개의 블록으로 분리 된 후, 블록당 3개씩 HDFS에 저장돼 있습니다. 

HDFS는 블록을 저장할 때 기본적으로 3개씩 블록의 복제본을 저장 합니다.(default) 

역시나! HDFS의 블록사이즈처럼 복제본의 수도 하둡 환경 설정 파일에서 수정할 수 있습니다. 

어떻게 복제가 되는지는 뒷부분에 자세히 다루도록 하겠습니다.^0^~good~ 

복제단위는 위와같이 블록단위라는것만 기억하도록 합시다!

 

 2) 네임노드(NameNode)와 데이터 노드 (DataNode)

HDFS는 마스터(Master)-슬레이브(Slave) 아키텍처로 구성 됩니다. 

즉, 마스터 역할을 하는 네임노드(NameNode)서버가 한대, 슬레이브 역할을 하는 데이터노드(DataNode) 서버가 여러 대로 구성 됩니다. 

그림을 보기전에 용어와 역할을 조금 살펴보면.. 

 - 네임노드 :  HDFS의 모든 메타데이터를 관리하고, 클라이언트가 HDFS에 저장된 파일에 접근 할 수 있게 함.(접근 가능케하는 정보가 있겠죵?-디렉토리명, 파일명 등) 

 - 데이터노드 : HDFS에 저장할 때 블록으로 나눠진 데이터는 여러 대의 데이터노드에 분산저장 됨. 

 - 애플리케이션 : 사용자가 구현한 애플리케이션은 HDFS에 파일을 저장하거나. 저장된 파일을 읽기 위해 HDFS 클라이언트(이하 클라이언트)를 사용하며, 클라이언트 API 형태로 사용자에게 제공 됩니다.  

 - RACK : Hadoop data nodes (servers) are installed in racks. Each rack typically contains multiple data node servers with a top of rack switch for network communication. 

               “Rack awareness” means that the name node knows where each data node server is and in which rack. 

              영어라서 당황 스러우셨죠? 발번역 -  하둡 데이터노드들은 rack에 설치가 되어져있습니다. 

               각각의 rack은 보통 네트워크 통신을 하기 위한 상위 rack switch에 여러개의 데이터노드들로 구성되어져있습니다.

              "Rack awareness"는 노드네임이 각 rack의 데이터노드서버들이 어디에 있는지 아는 의미 입니다.

 

   참고 사이트 : http://www.ibmbigdatahub.com/blog/running-hadoop-cloud 

                         http://wiki.apache.org/hadoop/topology_rack_awareness_scripts

 

자! 아래의 네임노드 관련 그림을 보시면!

그림_b) HDFS 아키텍처

 

 

네임노드와 데이터노드의 구조를 살펴보았습니다.

 

3) 파일 저장

이제 전체 아키텍처를 알았으니 조금 detail하게 HDFS에 파일을 저장할 때의 동작 방식을 알아보겠습니다.

 우선 그림_c를 보도록 하겠습니다.

 

그림_c) HDFS의 파일 저장 과정

 

 

 

 1) 사용자가 개발한 프로그램인 애플리케이션이 클라이언트에게 파일 저장을 요청합니다.

 2) 클라이언트는 네임노드에게 사용자가 요청한 파일 경로를 생성할 것을 요청합니다.

 2-1) 네임노드는 해당 파일 경로가 기존에 존재할 경우 에러 처리를 합니다. 기존에 존재하지 않는 파일 경로라면 메모리에 파일 경로를 생성한 후, 다른 클라이언트가 해당 경로를 수정하지 못하게 락(lock)을 겁니다.

 3) 네임노드는 클라이언트에게 해당 파일을 저장할 데이터노드의 목록을 반환 합니다. 이러한 데이터노드의 목록은 하나의 파이프라인을 형성합니다. 파이프라인에는 HDFS의 환경설정 파일에 설정된

     블록의 복제 개수(dfs.replication)만큼 데이터노드가 들어 있습니다.

 4) 클라이언트는 첫 번째 데이터노드에게 데이터를 전송합니다.

 5) 첫번째 데이터노드는 전송받은 데이터를 로컬 디스크에 저장한 후, 두번째 데이터노드로 데이터를 전송합니다. 두번째 데이터노드도 전송받은 데이터를 로컬에 저장한 후, 세 번째 데이터노드로 데이터를 전송합니다.

     세번째 데이터도 전송받은 데이터를 로컬 디스크에 저장합니다.

 6) 첫 번째 데이터노드는 클라이언트에게 파일 저장이 완료됐음을 응답합니다.

 7) 클라이언트는 애플리케이션에게 파일 저장이 완료됐음을 응답합니다.

 

Q) 파이프라인 형성이라함은?

     How? 디자인 패턴 중 Chain of responsibility Pattern으로 구현이 되어있을라나?? 네임노드의 메타데이터(conf)를 가지고??

 

4) 파일 읽기

  이제는 HDFS에 저장된 파일을 어떠한 방식으로 읽게 되는지 알아보겠습니다. 그림_d 참조!

 

그림_d)

 

 

    1) 사용자가 개발한 프로그램인 애플리케이션이 클라이언트에게 파일 읽기를 요청 합니다.

    2) 클라이언트는 네임노드에게 애플리케이션이 요청한 파일이 어떤 블록에 저장돼 있는지 블록의 위치 정보를 요청 합니다.

    3) 네임노드는 메타데이터에서 요청된 파일의 복제 블록이 저장된 위치를 확인한 후 해당 데이터노드의 목록을 반환 합니다.

        이때 데이터노드의 목록은 요청 중인 클라이언트와 가까운 순서대로 정렬해서 반환 됩니다. 만약 클라이언트가 데이터노드라면 클라이언트는 로컬에 있는 파일을 읽게 됩니다.

        Q) 가까운 순서의 기준은???? 데이터노드에서 다른 데이터노드를 접근한다는 말??? 갑자기 클라이언트가 데이터노드라면..에서 헷깔리는 문구 임.

    4) 클라이언트는 데이터노드에게 블록을 조회할 것을 요청합니다.

    5) 데이터노드는 클라이언트에게 요청한 데이터를 전송합니다.

    6) 클라이언트는 애플리케이션에게 전송받은 데이터를 전달합니다.

 

5) 보조 네임노드(Secondary Name Node)

HDFS에서 보조 네임노드라는 친구가 있습니다.  왜 보조 네임노드가 나왔을까요? 네임노드에 무슨 문제가????

네임노드는 HDFS의 메타데이터를 관리하기 위해 에디트(EditLog)와 파일 시스템 이미지(FsImage)파일을 사용합니다.

•  에디트 로그는 HDFS의 메타데이터에 대한 모든 변화(저장,삭제, 파일 위치 변경 등)를 기록하는 로그 파일 입니다.
  또한 에디트 로그는 용량에 제한 없이 커질 수 있으며, 네임노드의 로컬 파일 시스템에 파일로 저장 됩니다.
• 파일 시스템 이미지 파일은 파일 시스템의 네임스페이스(디렉토리명, 파일명, 상태정보)와 파일에 대한 블록 매핑 정보를 저장하는 파일입니다.
  한마디로 표현하면 HDFS의 스냅샷 이라고 할 수 있습니다. 파일 시스템 이미지도 에디트 로그처럼 네임노드의 로컬 파일 시스템에 파일로 저장 됩니다.

그렇다면 네임노드는 메타데이터를 관리하기 위해 위의 두파일을 어떻게 사용할까요???

네임노드는 파일 시스템의 네임스페이스(디렉토리명, 파일명, 상태정보)와 블록 매핑 정보를  메모리에서 유지하며, 네임노드가 구동할 경우 다음과 같은 단계로 파일 시스템 이미지 파일과 에디트 로그를 사용 합니다.

1. 네임노드가 구동되면 로컬에 저장된 파일 시스템 이미지 파일과 에디트 로그 파일을 조회.
2. 에디트 로그 파일에 있는 내용을 토대로 메모리에 올라와 있는 파일 시스템 이미지를 갱신.(메모리 갱신)
3. 메모리에 올라와 있는 파일 시스템 이미지를 로컬 파일에 있는 파일 시스템 이미지 파일에 적용.(로컬 갱신)
4. 에디트 로그 파일을 초기화.

앞서 에디트 로그의 파일은 용량에 제한 없이 커질 수 있다고 하였습니다. 만약 에디트 로그 파일이 너~~~무 크다면 2번 단계에서 진행할 때 많은 시간이 소용될 것 입니다.

또한 파일 시스템 이미지 파일을 파일에 변경이 있을 때마다 갱신한다면 파일 시스템 이미지 파일은 기가바이트 이상으로 커지게 되며, 메모리에 로딩하지 못하는 사태가 일어날 수도 있습니다.

이러한 문제를 해결하기 위해 HDFS는 보조 네임노드를 사용 합니다.

보조 네임노드는 주기적으로 네임노드의 파일 시스템 이미지 파일을 갱신(메모리, 로컬 갱신)하는 역할을 하며, 이러한 작업을 체크포인트(Check Point)라고 합니다.

※ 보조 네임노드를 체크포인팅 서버라고 표현하기도 함.

 

그림_f) 보조 네임노드의 체크포인팅 단계

 

 

 

 1) 보조 네임노드는 네임노드에게 에디트 로그 파일을 롤링할 것을 요청.

    ※ 로그롤링은 현재 로그파일의 이름을 변경하고, 원래 이름으로 새 로그 파일을 만드는 것 입니다.

 2) 네임노드는 기존 에디트 로그 파일을 롤링한 후, 새로운 에디트 로그 파일을 생성.

 3) 보조 네임노드는 롤링된 에디트 로그 파일과 파일 시스템 이미지 파일을 다운로드 합니다.

 4) 보조 네임노드는 기존 파일 시스템 이미지 파일을 메모리에 올리고, 에디트 로그 파일에 있는 로그를 메모리에 올라와 있는 파일 시스템 이미지에 갱신. 

     갱신이 완료되면 새로운 파일 시스템 이미지 파일이 생성되며, 이 파일이 체크포인트용으로 사용 됩니다.(병합)

 5) 보조 네임노드는 체크포인트용 파일 시스템 이미지 파일을 네임노드에게 전송.

 6) 네임노드는 기존의 파일 시스템 이미지 파일을 체크포인트용 파일 시스템 이미지 파일로 롤링!

     또한 에디트 로그 파일도 2단계에서 생성된 에디트 로그 파일로 변경합니다.

 

 체크포인팅이 완료되면 파일 시스템 이미지 파일은 최신 내역으로 갱신되며, 에디트 로그 파일의 크기고 축소 됩니다.

 체크 포인팅은 1시간마다 한번씩 일어나며, 하둡 환경설정 파일에서 fs.checkpoint.period 속성값을 수정해서 제어할 수 있습니다.

 보조 네임노드는 네임노드의 파일 시스템 이미지를 축소 시켜주는 역할을 담당하지, 백업 서버가 아닙니다!

 

HDFS 명령어 사용

하둡은 사용자가 HDFS를 쉽게 제어할 수 있게 쉘 명령어를 제공 합니다. 이 쉘 명령어는 FileSystem Shell(이하 fs 쉘) 이라고 하며, 다음과 같은 형식으로 하둡 홈 디렉토리에서 실행할 수 있습니다.

./bin/hadoop fs -cmd [args] 

cmd는 사용자가 설정한 명령어이고, args는 해당 명령어를 실행할 때 필요한 파라미터를 의미 합니다.

fs쉘에서 어떤 명령어가 제공되는지는 "hadoop fs -help"라고 입력하면 확인할 수 있습니다.

 

명령어

명령어	내용	사용법	비고
파일 목록 보기 - ls, lsr
ls	현재 디렉토리만을 출력	./bin/hadoop fs -ls [디렉토리|파일...]
lsr	현재 디렉토리의 하위 디렉토리 정보까지 출력	./bin/hadoop fs -lsr [디렉토리|파일...]
파일 용량 확인 - du, dus
du	지정한 디렉토리나 파일의 사용량을 확인,  바이트 단위로 결과를 출력!	./bin/hadoop fs -du
dus	전체 합계 용량만 출력	./bin/hadoop fs -dus <디렉토리/파일...>	경로를 지정하지 않을 경우, 사용자 계정의 홈 디렉토리에 있는 모든 디렉토리의 사용량을 합산해서 출력
파일 내용 보기 - cat, text
cat	지정한 파일의 내용을 화면에 출력	./bin/hadoop fs -cat [파일...]	텍스트 파일만 출력할 수 있습니다.
text	지정한 파일의 내용을 화면에 출력	./bin/hadoop fs -text [파일...]	zip파일 형태로 압축된 파일도 텍스트 형태로 화면에 출력
파일 복사 - put, get, getmerge, cp, copyFromLocal, copyToLocal
put	지정한 로컬 파일 시스템의 파일 및 디렉토리를 목적지 경로로 복사합니다.	./bin/hadoop fs -put [로컬 디렉토리|파일...] [목적지 디렉토리|파일...]
copyFromLocal	put 명령어와 동일한 기능을 제공.	./bin/hadoop fs -copyFromLocal[로컬 디렉토리|파일...] [목적지 디렉토리|파일...]
get	HDFS에 저장된 데이터를 로컬 파일 시스템으로 복사	./bin/hadoop fs -get<ignoreCrc> <-crc> [소스 디렉토리|파일...] [로컬 디렉토리|파일...] ※ -crc 옵션을 사용하면 로컬 파일 시스템에 체크섬 파일도 복사 됨.      -ignoreCrc 옵션을 사용하면 해당 파일의 체크섬을 확인하지 않음.	HDFS는 파일의 무결성을 확인하기 위해 체크섬(checksum) 기능을 사용하는데, 체크섬을 숨김파일로 저장하고, 해당 파일을 조회할 때 체크섬을 사용해 무결성을 확인.
getmerge	지정한 경로에 있는 모든 파일의 내용을 합친 후, 로컬 파일 시스템에 단 하나의 파일로 복사.	./bin/hadoop fs -getmerge [소스 디렉토리|파일...] [로컬 파일명]
cp	지정한 소스 디렉토리 및 파일을 목적지 경로로 복사하는 기능을 제공.	./bin/hadoop fs -cp [소스 디렉토리|파일...] [목적지 디렉토리|파일]
copyToLocal	get 명령어와 동일한 기능을 제공.	./bin/hadoop fs -copyToLocal<ignoreCrc> <-crc> [소스 디렉토리|파일...] [로컬 디렉토리|파일...]
디렉토리 생성 - mkdir
mkdir	지정한 경로에 디렉토리를 생성할 수 있음.	./bin/hadoop fs -mkdir [디렉토리]	HDFS에 이미 존재하는 디렉토리를 생성할 경우 오류가 발생.
파일 이동 - mv, moveFromLocal
mv	소스 디렉토리 및 파일을 목적지 경로로 옮김.	./bin/hadoop fs -mv [소스 디렉토리|파일...] [목적지 디렉토리|파일]	여러 개의 파일을 이동시킬 경우, 반드시 목적지 경로를 디렉토리로 설정해야 함.
moveFromLocal	put 명령어와 동일하게 동작하지만 로컬 파일 시스템으로 파일이 복사된 후 소스 경로의 파일은 삭제 됨.	./bin/hadoop fs -moveFromLocal [소스 디렉토리|파일...] [로컬디렉토리|파일]
파일 삭제하기 - rm
rm	지정한 디렉토리나 파일을 삭제 함.	./bin/hadoop fs -rm [디렉토리|파일...]	디렉토리는 반드시 비어 있는 경우에만 삭제할 수 있음.
디렉토리 삭제하기 - rmr
rmr	지정한 파일 및 디렉토리를 삭제 함.	./bin/hadoop fs -rmr [디렉토리|파일...]	비어있지 않은 디렉토리도 정상적으로 삭제 함.
카운트값 조회 - count
count	기본적으로 지정한 경로에 대한 전체 디렉토리 개수, 전체 파일 개수, 전체 파일 사이즈, 지정한 경로 이름을 출력.	./bin/hadoop fs -count <-q> [디렉토리|파일...]	HDFS는 디렉토리에서 생성할 수 있는 파일 개수나 파일 용량을 제한할 수 있음. -q 옵션을 사용할 경우, 이러한 쿼터 정보를 확인.
파일의 마지막 내용 확인 - tail
tail	지정한 파일의 마지막 1KB의 내용을 화면에 출력 함.	./bin/hadoop fs -tail <-f> [파일]	-f 옵션 사용시 해당 파일에 내용이 추가될 때 화면에 출력된 내용도 함께 갱신.
권한 변경 - chmod, chown, chgrp
chmod	지정한 경로에 대한 권한을 변경.	./bin/hadoop fs -chmod <-R> [권한모드...] [디렉토리|파일...]	-R 옵션 사용 시 하위 디렉토리 설정도 모두 변경 됨.
chown	지정한 파일과 디렉토리에 대한 소유권을 변경하는 명령어.	./bin/hadoop fs -chown <-R> [변경 사용자명:변경 그룹명] [디렉토리|파일...]	-R 옵션 사용 시 하위 디렉토리 설정도 모두 변경 됨.
chgrp	지정한 파일과 디렉토리에 대한 소유권 급만 변경.	./bin/hadoop fs -chown <-R> [변경 그룹명] [디렉토리|파일...]	-R 옵션 사용 시 하위 디렉토리 설정도 모두 변경 됨.
0 바이트 파일 생성 - touchz
touchz	크기가 0바이트인 파일을 생성.	./bin/hadoop fs -touchz [파일...]	지정한 파일이 이미 0바이트 이상인 상태로 저장돼 있다면 오류 발생.
복제 데이터 개수 변경 - setrep
setrep	설정한 파일의 복제 데이터 개수를 변경할 수 있음.	./bin/hadoop fs -setrep <-R> -w [복제데이터개수] [디렉토리|파일...]	-R 옵션 사용 시 하위 디렉토리에 있는 파일의 복제 데이터 개수도 변경 됨.
휴지통 비우기 - expunge
expunge	주기와 상관 없이 휴지통을 비운다.	./bin/hadoop fs -expunge	HDFS에서는 삭제한 파일을 ".Trash/"라는 임시 디렉토리에 저장한 후,  일정 시간이 지난 후에 완전히 삭제합니다.
파일 형식 확인 - test
test	지정한 경로에 대해[-ezd] 옵션으로 경로가 이미 존재하는지 파일 크기가 0인지, 디렉토리인지 확인 함.	./bin/hadoop fs -test -ezd [디렉토리|파일]	체크 결과가 맞을 경우 0을 출력 한다.
통계 정보 조회 - stat
stat	지정한 경로에 대한 통계 정보를 조회	./bin/hadoop fs -stat <출력 포맷> [디렉토리|파일...]	별도의 옵션을 설정하지 않을 경우, 해당 디렉토리 혹은 파일이  최종 수정된 날짜를 출력 함.

 

 ※ 표 stat 명령어의 출력 포맷 옵션

옵 션	내 용
%b	블록 단위의 파일 크기
%F	디렉토리일 경우 "directory", 일반 파일일 경우 "regular file" 출력
%n	디렉토리명 혹은 파일명
%o	블록 크기
%r	복제 파일 개수
%y	디렉토리 및 파일의 갱신일자를 yyyy-MM-dd HH:mm:ss 형식으로 출력
%Y	디렉토리 및 파일의 갱신일자를 유닉스 타임스탬프 형식으로 출력

 

 

참고하면 좋을 것 같은 사이트

 http://wiki.apache.org/hadoop/FAQ

 

2014/08/27 - [BigDATA/Hadoop] - 01. 하둡 소개

 

참고 BOOK

시작하세요! 하둡프로그래밍(기초부터 실무까지 하둡의 모든 것), 정재화 저

 

    - END -