하둡 기초 -1

1장_하둡 소개

빅데이터?

3V = Volume + Velocity + Variety

왜하둡?

RDBMS 유지비용 비쌈.

하둡은 여러개의 싸구려 피씨에 리눅스만 깔면, 

분산 컴퓨팅으로 작동하므로 굿. 

기존 RDBMS 보다 존나 싸고 좋음.

(구글스토리에서 읽었던 GFS 랑 비슷)

하둡에코시스템(하둡생태계)?

하둡에 대한 오해?

RDBMS 를 대체하지 않음; 상호보완.

데이터무결성 보장, 트랜잭션에 적절치 않음.

고로, 중요한 데이터는 RDBMS 에, 

배치성 데이터는 하둡에 ..

그리고, 하둡은 NoSql 아님.

단점?

- 수정불가

- 파일 네임스페이스 제한

- 고가양성 지원

2장_하둡 개발 준비

실행모드?

- Standalone : 로컬에서만 지원되며, 분산 지원 안됨. 맵리듀스 프로그램 개발, 디버깅 할 때

- Pseudo-distributed mode : 하나의 장비에서 가상으로 분산처리

- Fully distributed mode : 실제 여러대의 서비스에 설치

하둡실행계정생성

호스트파일수정

인코딩방식설정

ssh  설치

기타설정 등등등 ... 실제 설치해보면 버전따라 약간씩 다름 .. 인터넷 참고 ..

3장_하둡 분산 파일 시스템

HDFS 의 기초?

일단, 기존 DB 서버와 다르게

저사양 서버를 이용해 스토리지를 구성할 수 있음.

보통 대용량 데이터를 배치잡으로 처리할 경우 hdfs 를 이용하면됨.

전자상거래 이런거 안됨.

HDFS 의 목표는 아래와 같다.

- 장애복구 : 장애인지 및 대처에 좋음 ... ;;

- 스트리밍 방식의 데이터 접근 : 배치작업에 적합하도록 설계되었고, 낮은 접근 지연시간보다는 높은 데이터 처리량에 중심.

- 대용량 데이터 저장

- 데이터 무결성 : 수정할 수 없고, 읽기만 가능해서 무결성 유지.

HDFS 아키텍처?

블록 구조 파일 시스템은 기본 64MB 로 설정돼있고(수정가능),

여러개의 블록은 여러개의 서버의 분산해서 저장되는데,

블록당 3개씩 HDFS 에 저장된다. 근데, 왜 64MB ??

파일의 크기가 클수록 메타데이터가 적어지므로. 

반면, 크기가 작은 파일들은 그에 맞게 블록사이즈가 줄어드는데,

그렇게 되면, 네임노드안에 인메모리 방식으로 관리되는 메타정보가

많아지므로, 그만큼 비효율적인 데이터 접근이 발생하게 된다.

(근본적으로 대용량의 데이터를 스트리밍 형식으로 접근하게 돼있음)

기타, 읽기 제어같은 경우는 API 를 제공한다.

또, HDFS 는 마스터(네임노드) - 슬레이브(데이터노드) 아키텍처로 구성되어 있다.

네임노드 한대, 데이터노드 여러대로 구성된다. 

네임노드는 HDFS의 모든 메타데이터를 관리하고,

클라이언트가 HDFS 에 저장된 파일에 접근할 수 있게 해줍니다.

네임노드는 HDFS 클라이언트의 요청에 의해,

직접적으로 파일 혹은 디렉토리를 만들지 않는다.

HDFS 클라이언트는 네임노드를 통해 파일 경로를 생성한 후,

직접 디렉토리를 만들고 파일을 저장한다.

그리고, 데이터 노드는 주기적으로 

heartbeat(정상동작여부), blockreport(데이터노드의 모든 블록을 확인) 를 

네임노드에게 보내준다.

조회시에는 클라이언트가 네임노드에 접속 목록의 위치를 조회하고,

해당 블록이 지정된 데이터노드에서 직접 데이터를 조회한다.

<파일 읽기>

<파일 쓰기>

네임노드는 HDFS 의 메타데이터를 관리하기 위해,

에디트로그(EditLog) 와 파일시스템이미지파일(FsImage)을 사용한다.

파일상태의 모든 변화는 에디트 로그에 기록되고,

에디트 로그는 용량에 제한이 없으며, 

네임노드의 로컬 파일 시스템에 파일로 저장된다.

파일 시스템 이미지 파일은 HDFS 의 스냅샷과 같다.

역시, 로컬에 저장된다.

네임노드가 구동되면,

- FsImage 와 EditLog 파일을 조회한다.

- 에디트 로그 파일에 있는 내용을 토대로 메모리에 올라와 있는 

  파일 시스템 이미지 파일을 갱신한다.

- 메모리에 파일 시스템 이미지를 로컬에 적용한다.

- 에디트 로그파일을 초기화한다.

만일 로그 파일 사이즈가 크다면,

두번째 단계의 시간이 많이 소요될 것이고,

FsImage 를 변경이 있을 때마다 갱신한다면,

FsImage 파일은 많이 커질(?갱신하는데 왜커짐?) 것이다.

이런 점을 해결하기 위해서 보조 네임노드(Secondary Name Node) 라는 노드를 사용한다.

보조네임노드는 1시간마다 한번씩 네임노드의 FsImage 를 갱신하는데, 

이를 체크포인팅이라고 한다.그래서 보조네임노드를 체크포인팅 서버라고도 부른다.

<체크 포인팅 단계>

- 보조에서 네임노드로 롤링을 요청

- FsImage, Edit Log 는 HTTP GET 으로 다운로드. 네임노드는 새로운 에디트 로그 생성

- FsImage 를 메모리에 올리고 Edit Log 와 병합해서 CheckPoint 생성

- HTTP POST 로 네임노드로 UPLOAD

- 새로만든 EditLog 로 변경, 업로드된 FsImage 로 변경

보조네임노드를 우습게 보는데 그라믄 안돼 ~ 

그리고,

하둡 명령어 정리 !!

http://blog.acronym.co.kr/370