임시

아파치 하둡 소개에 다음 버전으로 간단한 HDFS 사용법에 대해 소개하고자 한다.

소개는 http://kkn1220.tistory.com/120 를 참고

환경 구축: 가상 머신(Virtual box 또는 Vmware, Cloudera)

cloudera는 맵알(MapR), 호트웍스(Hortonworks)와 가장 많이 쓰이는 하둡 배포판이라 사용하게 되었음

또한, 퀵 스타트 버전으로 실행 시 너무 편해서...(귀찮아서 아님)

또한, 별도의 예제는 없고 파일을 올리는 방법 정도로만 소개

가상 머신은 설치가 되었다고 가정

1) Cloudera 설치: https://www.cloudera.com/downloads/quickstart_vms/5-8.html

-> 본 포스팅은 하둡에 대한 소개보다는 스파크로 가기 전 간단한 소개이기 때문에 Cloudera Manager를 설치하는 것이 아닌 Quick start버전 다운

가상 머신에 맞게 다운로드 받으면 된다. (용량이 꽤 크다. 실제로 압축 풀고 그러면 8GB 는 되는듯)

2) Cloudera 실행

-> 가상머신 가져오기 하면 엄청 쉽다.(이미지를 Vmware에서 불러오면 됨. 메모리 설정 등 자동으로 설정 되어 있음)

- 5.8 퀵 스타트 버전은 CentOS 6.7 버전으로 구성 되어 있다.

- 개인적으로 레드햇 계열의 cent os를 좋아하지 않는다. (뭔가 데비안 계열에 비해 딱딱해보임..)

- 키면 아래의 화면으로 처음 시작이 되는데 이클립스도 설치가 되어 있다.

3) Hue

-> Hue는 Hadoop의 Eco system으로 데이터 분석을 제공하는 웹 인터페이스이다.

브라우저 실행 시, 아래의 그림과 같이 Hue탭이 있어 클릭 하면 됨 (Id: cloudera, pw: cloudera)

Hue 로그인 후, 우측 상단의 노란색으로 칠한 부분을 누르면 파일 관리를 할 수 있는데, 초기에는 (당연히) 아무 것도 없음윽 확인할 수 있다.

터미널을 열고, $hadoop fs -mkdir test 를 입력하고, 새로고침을 누르면 정상적으로 폴더가 생성되는 것을 확인할 수 있다.

$hadoop fs -mkdir test

- $hadoop    : 시스템과의 상호 작용을 위해 hadoop명령어 사용

- $hadoop 을 입력하면 Usage를 확인할 수 있다.

- fs또한 마찬가지로 확인 가능....

- cat, chmod, chown, cp, mkdir, mv 등 다양하니 한번 확인해도 나쁘지 않겠다.

- 루트 디렉토리를 확인하면 아래와 같이 확인할 수 있다.

- user 디렉토리 내 하위 폴더를 본 결과, 좀 전에 만든 test폴더가 있는 것 또한 확인 가능하다.

- local에 샘플 데이터를 만들고 HDFS에 업로드 하는 화면은 아래와 같다. (local에서 put 명령어를 통해 HDFS에 업로드가 됨)

Hue에서 test디렉토리 밑에 test파일이 정상적으로 업로드 된 것을 확인할 수 있다.

(다운로드는 -get 명령어 사용   $hadoop fs -get <download_file> <다운로드 받고자 하는 local_path> )

즉, 구조를 확인하면 Cloudera라는 가상 머신을 설치하였고, 가상 머신 내 local영역의 파일을, 별도의 HDFS에 올리는 것으로 보면 되겠다.

위의 예제는 단순 작은 사이즈의 파일을 업로드 하였다.

하지만 큰 파일이라고 가정해보자.

File은 Block 단위로 분할이 된다. 이전 포스팅에서 설명했듯이, 초기에는 크기가 64MB였는데, 2.0부터는 128MB를 지원한다.

이 Block들은 여러 머신에 복제되어 Data Node에 저장이 된다. 그리고 Data Node에 저장이 될 때, Name Node는 어디에 저장이 되어 있는지, 어떻게 구성이 되어있는지에 대한 메타 데이터를 가지고 있게 된다.

위의 그림을 보면 3개씩 복제되어 저장 된 것을 확인할 수 있는데 default가 3개이다.

HDFS에 접근하기 위해서는 다양한 방법이 존재한다.

1) Shell 커맨드 사용: (ex: 위의 커맨드 창에서 $hadoop fs)

2) API 사용

3) 에코시스템: (ex: 위의 Hue 이용)

 최근 회사에서 빅데이터, 머신러닝, 딥러닝 등 데이터에 대한 수 많은 프로젝트가 진행됨에 따라

차근차근 알아보고자 한다.

그 중, 빅데이터 처리를 위한 방법 중 하둡에 대한 간단한 소개를 한 후, 스파크로 넘어가고자 한다. 

아파치 하둡이란?

- 빅데이터를 저장, 처리, 분석할 수 있는 소프트웨어 프레임워크

- 대량의 자료를 처리할 수 있는 큰 컴퓨터 클러스터에서 동작하는 분산 응용 프로그램을 지원하는 프리웨어 자바 소프트웨어 프레임워크(위키백과)

- 하둡에서 꼭 알아야 할 것: HDFS(Hadoop Distributed File System), 맵리듀스(실제 맵리듀스가 핵심)로 구성

아파치 하둡 특성

1) Distributed: 수십만대의 컴퓨터에 자료 분산 저장 및 처리

2) Scalability: 용량이 증대되는대로 컴퓨터 추가

3) Fault-tolerant: 하나 이상의 컴퓨터가 고장나는 경우에도 시스템이 정상 동작

Node가 Fail난 경우, 마스터 노드는 Fail을 감지하고 작업을 다른 Node에 할당함으로 해결

4) Open Source: 공개 소프트웨어

아파치 하둡 아키텍쳐

(사진 출처: http://blog.raremile.com/hadoop-demystified/)

- 하둡은 Master Node와 Slave Node로 구분된다. 위의 그림에서는 Master Node와 Slave Node로 표현이 되어있지만 사실 하둡은 Name Node와 Data Node라고 표현하는 것이 더 맞는 표현인 것 같다. (스파크에서는 Master/Slave로 표현)

- HDFS(Hadoop Distribution File System): 분산 데이터를 처리하기 위해 데이터가 저장되는 파일 시스템

수십 테라/페타 바이트 이상의 대용량 파일을 분산된 서버에 저장하고, 그 데이터를 빠르게 처리할 수 있도록 해주는 파일 시스템이라고 보면 된다. HDFS는 블록 구조의 파일 시스템인데 초기에는 크기가 64MB였는데 하둡 2.0부터 128MB로 증가 되었다.

이 HDFS의 구성 컴포넌트는 아래 Name/Data Node로 나뉘게 된다.

1) Name Node(Master Node): 메타 데이터 관리, Data Node 모니터링, 장애노드의 관리, 클라이언트의 권한 확인 

사용자가 파일을 HDFS로 업로드한다고 가정해보자. 이 때, Name Node는 파일을 가지고 있는 것이 아니라 각 Data Node에 분산 저장 되는 파일들의 메타 데이터를 가지고 있다. 쉽게 얘기하자면, 어떤 파일이 어떤 Data Node에 있는지에 대한 정보를 가지고 있다. 또한, Data Node를 모니터링 하는데, 3초마다 Heart Beat를 전송하게 되고, 이에 응답하지 않는 Data Node를 장애 노드로 판단한다.

Name Node의 장애가 발생 시, 전체에 영향을 줄 수 있다. 이에 대비하여 보조 네임 노드가 존재한다.
(Name Node의 백업이 아닌, 메타데이터 파일 시스템 이미지 갱신하는 역할 수행)

2) Data Node(Slave Node): 실제 task를 수행하는 노드.

아파치 하둡 아키텍쳐(1.0과 2.0 비교)
(http://www.oss.kr/oss_news/545626 발췌)

- YARN은 자원 관리와 스케쥴링이라는 두 가지 태스크를 별개의 개념으로 분리하는 기술

- YARN은 중앙 자언 관리자와 어플리케이션 마스터를 보유. 각 어플리케이션을 별개로 구성하기 위해 만들어짐

-> 이는 배치, Interactive, In memory, Streaming, Online, Graph, 기타 유형의 App을 동시에 실행시키도록 돕는 기술

- 하둡 1.0에서는 TaskTracker 수천 개와, 맵리듀스 태스크를 처리해야 하는 JobTracker가 하나 있음

-> 확장성과 관련된 선택권을 줄이며, 클러스터가 하나의 app만 실행

- 하둡 2.0에서는 하나의 Resource manager와 여러 개의 Application Master가 존재하여 별개의 Application Master가 각 Application을 관리하기 때문에 클러스터에서 병목 현상이 발생하지 않음

- 동시에 YARN은 Global Resource manager로 자원 활용도를 높이고, 이를 추가하여 클러스터 속도를 높일 수 있음. YARN에서는 공동 자원 풀을 공유하는 여러 다른 Application을 실행시킬 수도 있음. 맵리듀스 슬롯이 정해져 있지 않기 때문에, 클러스터 내부 자원을 더 효율적으로 활용하는데 도움을 줌

- Apache Giraph, Spark, Apache HAMA, Storm 등 새 아키텍쳐 들에 맞게 조정 되어 있음

아파치 하둡 프레임워크 (Hadoop Ecosystem 2.0)

(사진 출처: http://blrunner.com/99, 밑의 내용 포함)