26. 스토리지 측면
• 3 Copy (기본 옵션)
• 같은 랙에 하나, 다른 랙에 하나
• 64mb 블록
• 파일을 64mb 블록으로 나눠서 저장
• namenode 에서 각 파일 블록을 관리한다. (속도 위해 In-momory 관리)
• namenode 장애에 매우 취약하다.
• namenode 메모리가 매우 중요하다.
• 작은 크기의 매우 많은 파일에 매우 취약하다.
• secondary namenode 는 그냥 grace 종료를 위한 용도이다.
39. PIG
• 맵리듀스는 분석가가 만들기 어렵다.
• 하지만 보통 데이터 분석은 몇가지 기능만 사용된다.
• 그럼 기능을 스크립트로 제공하고 스크립트를 해석해서 맵리듀스 코드를 생성해서 돌리자
• 전용 스크립트 PigLatin 을 사용
• 스크립트를 분석해서 맵리듀스 코드 생성
• 코드를 하둡에 올리고 돌려서 결과 생성
40. 확 줄었다
데이터 로드
c = load '/user/bdh/data27/cite.TXT' using PigStorage(',') as (c1:int, c2:int);
/** 카운트를 위한 컬럼 그룹화 */
g = group c by c1, c2;
/** group 데이터 수를 카운트 */
f = foreach g generate flatten(group), COUNT($1) as cnt;
/** 결과를 확인해 볼 수 있다. */
L = limit f 10;
Dump L;
41. HIVE
• 전용 스크립트를 분석해서 맵리듀스를 생성하는 건 같다.
• 하지만 그 과정이 별도 테이블을 정의하고 SQL Query 를 통해서 분석 결과를 뽑고 결
과를 다시 테이블 형태로 저장 가능
• 멋있어 보이지만, 생각만큼 만만한 얘는 아니다.
42. 테이블 생성
create external table cite (
citing int , cited int
)row format delimited fields terminated by ',' lines terminated by 'n'
stored as textfile;
로컬데이터로드
load data local inpath '/home/bdh/data/cite.TXT' overwrite into table cite;
카운팅
select citing, count(citing) from cite group by citing limit 100;
43. HBASE
• 하둡의 심장!
• 이거 때문에라도 하둡을 써야 한다.
• 구글의 빅테이블을 구현한 데이터베이스 (하둡 생태계에서 유일한 스토리지)
• 컬럼 베이스 형태의 NoSQL DB(카산드라와 같다)
• RDBMS 랑 구조와 완전히 다르다 (DB 라는 생각을 버려야 한다)
• 하둡의 작은 파일에 대한 취약점을 극복
44. • 컬럼 패밀리를 미리 정의하고 컬럼패밀리 내의 컬럼은 무한히 증가될 수 있는 구조
• 각 컬럼 별 타임스태프로 버전관리가 된다.
• RowKey 를 통한 랜덤억세스에 특화되어 있다.
• Full Scan 은 뭘해도 느리다 (복잡한 문제를 한방에 푸는 방법은 없다.)
• 그래도 싱글머신에서 돌리는 것보단 훨 빠르다.
HBASE
45. HBASE 의 데이터 구조
• • 테이블 (Table)
• 로우(Row)들의 집합. - 각 로우는 로우키(Row Key)가있으며 다수의 컬럼패밀리로 구성됨 - 스키마 정의시 컬럼패
밀리(Column Family)만 정의
• • 로우키(Row Key)
• 임의의바이트열, 사전순으로 내림차순 정렬 - 빈바이트 문자열은 테이블의 시작과 끝을 의미
• • 컬럼패밀리 (Column Family)
• 컬럼들의그룹이며, 컬럼패밀리의 멤버컬럼은 같은접두사(prefix) - course:history와 course:math는
course라는 컬럼패밀리의 멤버컬럼임. history와 math를 컬럼 Qualifier라고 함
• • 셀(Cell)
• 로우키& 컬럼& 버전이 명시된 튜플 - 값은 임의의 바이트열이며 Timestamp가있음 StumbleUpon의
HBase의 선택 이유
46.
47. HBASE 의 특징
• 컬럼패밀리만 사전에 정의하고 컬럼은 무한정 늘어날 수 있다.
• RowKey 는 바이너리로 저장된다.
• 저장은 Cell 단위로 저장된다.
• 하나의 Cell 이 타임스탬프로 여러 버전이 저장될 수 있다.
• RowKey 로 엑세스가 빠르다.
• Query 문을 지원하지 않는다 (Get, Put, Del 등만 지원)
48. ZOOKEEPER
• 여러개의 머신에서 데이터를 동기화해주는 툴
• 머신을 죽었을 때 자동으로 리더를 새로 선출해서 결정한다.
• HBase 등의 다른 시스템에서 공유 데이터를 관리하기 위해서 사용한다.
• 굉장히 좋은 툴로, 비슷한 기능이 요구될 때 별도로 사용 가능해 보인다.
49. FLUME
• 로그 수집기
• 로그가 발생되는 머신에 Agent 를 띄운다.
• 로그는 Source – Channel – Sink 를 거치며 저장된다.
• Agent 는 다시 다른 Agent 로 연결될 수 있다.
• 최종적으로 HBase 와 같은 DB 에 저장된다.
50.
51. SKOOP
• 외부 DB 에서 하둡으로 데이터를 옮겨준다 (ETL 툴)
• JDBC 를 제공하는 모든 DB 에서 테이블 구조를 읽어서
• 데이터를 옮기는 맵리듀스 코드를 생성해주고
• 해당 코드를 실행함으로써 옮긴다.
• 주로 배치 잡으로 일정 간격으로 외부 DB 에서 데이터를 긁어오는데 사용
56. 데이터 적재
• Flume 을 이용해서 로그 데이터를 실시간으로 쌓거나
• Sqoop 을 이용해서 일정 간격으로 외부 DB 에서 데이터를 긁어서 적재한다.
• 일반적으로 적재는 HBase 를 이용한다.
57. 데이터 분석
• Hive 를 이용해서 데이터를 샘플링하고
• 샘플링 데이터를 데이터 분석가에게 넘겨서 R 을 이용해서 데이터 분석 모
델링을 만든다.
• 분석 모델링을 가지고 맵리듀스 스크립트를 만든다 (수동)
• 배치 잡으로 일정 간격 맵리듀스 스크립트를 만들어 결과를 생성한다.
• 생성한 결과를 외부 DB 에 저장한다.
