HDFS 데이터노드 블록 스캐너 (손상된 블록을 검색하여 수정)

 

·       Version : HDFS

 

HDFS 에서 데이터를 쓰거나 읽을때 체크섬을 사용하여 데이터 손상을 확인하고 수정한다. 이러한 작업으로 데이터 손상을 감지 할 수 있지만 해당 작업은 데이터를 쓰거나 읽을때만 발생하므로 클라이언트가 데이터를 요청하기 전에는 손상된 부분을 찾는것이 쉽지 않다. 이러한 손상된 부분을 찾기 위해 모든 데이터노드는 블록스캐너를 실행하여 데이터노드에 저장된 모든 블록을 주기적으로 점검한다. 이 작업으로 문제 있는 블록은 클라이언트가 읽기 전에 삭제하거나 수정한다.

데이터 블록 스캐너는 점검할 블록 리스트를 관리하며 체크섬 오류를 찾기 위해 모든 블록들을 점검한다. 스캐너는 데이터노드의 디스크 대역폭을 보존하기 위한 조절 메커니즘을 사용한다. 데이터 블록 스캔 주기는 hdfs-site.xml 파일에 dfs.datanode.scan.period.hours 속성 값으로 제어할 수 있며 단위는 시간(hour)이다. 속성값을 0 으로 설정시 데이터 블록 스캔 작업을 비활성화 한다.

블록 스캐너가 실행될때마다 보고서가 생성되며 각 데이터 노드의 웹 인터페이스 URL에서 보고서를 확인할 수 있다.

http://datanode:50075/blockScannerReport

 

 

 

2020-09-22 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, 체크섬 오류, 하둡 데이터 복구, 데이트 블록 스캔, Data block scan, Corrupted blocks, Block Scanner report

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

HDFS Cluster Balancing(데이터 블록 분포의 불균형 해소)  (0) 2020.09.26
Hive LIMIT 튜닝 (데이터 샘플링으로 빠르게 응답하기)  (0) 2020.09.23
Hive EXPLAIN (실행계획) 사용  (0) 2020.09.22
Hive 인덱스(index)  (0) 2020.08.28
Hive View  (0) 2020.08.25

Hive EXPLAIN (실행계획) 사용

 

·       Version : Hive

 

하이브에서 EXPLAIN 명령을 사용하면 실행계획을 확인할 수 있다. 즉, 쿼리를 어떻게 맵리듀스 잡으로 변환하지를 살펴 볼 수 있다. 실행계획을 사용하는 방법은 아래 스크립트 처럼 쿼리문 앞에 EXPLAIN 명령을 함께 실행한다.

EXPLAIN

SELECT

       col_1, date_local, count(*) as cnt

FROM tbl_a

where col_1 = 'aaa.com'

group by date_local, col_1;

 

아래 실행 계획은 위 쿼리를 실행하였을때 반환된 결과이다.

1      STAGE DEPENDENCIES:

2        Stage-1 is a root stage

3        Stage-0 depends on stages: Stage-1

4     

5      STAGE PLANS:

6        Stage: Stage-1

7          Map Reduce

8            Map Operator Tree:

9                TableScan

10                 alias: tbl_a

11                 filterExpr: (col_1 = 'aaa.com') (type: boolean)

12                 Statistics: Num rows: 5275084 Data size: 1039193932 Basic stats: COMPLETE Column stats: PARTIAL

13                 Filter Operator

14                   predicate: (col_1 = 'aaa.com') (type: boolean)

15                   Statistics: Num rows: 2637542 Data size: 485307728 Basic stats: COMPLETE Column stats: PARTIAL

16                   Select Operator

17                     expressions: date_local (type: string)

18                     outputColumnNames: date_local

19                     Statistics: Num rows: 2637542 Data size: 485307728 Basic stats: COMPLETE Column stats: PARTIAL

20                     Group By Operator

21                       aggregations: count()

22                       keys: date_local (type: string), 'aaa.com' (type: string)

23                       mode: hash

24                       outputColumnNames: _col0, _col1, _col2

25                       Statistics: Num rows: 1010 Data size: 291890 Basic stats: COMPLETE Column stats: PARTIAL

26                       Reduce Output Operator

27                         key expressions: _col0 (type: string), 'aaa.com' (type: string)

28                         sort order: ++

29                         Map-reduce partition columns: _col0 (type: string), 'aaa.com' (type: string)

30                         Statistics: Num rows: 1010 Data size: 291890 Basic stats: COMPLETE Column stats: PARTIAL

31                         value expressions: _col2 (type: bigint)

32           Reduce Operator Tree:

33             Group By Operator

34              aggregations: count(VALUE._col0)

35               keys: KEY._col0 (type: string), 'aaa.com' (type: string)

36               mode: mergepartial

37               outputColumnNames: _col0, _col1, _col2

38               Statistics: Num rows: 202 Data size: 58378 Basic stats: COMPLETE Column stats: PARTIAL

39               Select Operator

40                 expressions: 'aaa.com' (type: string), _col0 (type: string), _col2 (type: bigint)

41                 outputColumnNames: _col0, _col1, _col2

42                 Statistics: Num rows: 202 Data size: 58378 Basic stats: COMPLETE Column stats: PARTIAL

43                 File Output Operator

44                   compressed: false

45                   Statistics: Num rows: 202 Data size: 58378 Basic stats: COMPLETE Column stats: PARTIAL

46                   table:

47                       input format: org.apache.hadoop.mapred.SequenceFileInputFormat

48                       output format: org.apache.hadoop.hive.ql.io.HiveSequenceFileOutputFormat

49                       serde: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe

50    

51       Stage: Stage-0

52         Fetch Operator

53           limit: -1

54           Processor Tree:

55             ListSink

56    

 

·       1 ~ 2 : 하이브 잡은 하나 이상의 스테이지(stage)로 구성된다. 스테이지 사이에는 의존관계가 있으며 복잡한 쿼리는 많은 스테이지로 구성되며 많은 시간이 소요된다. 스테이지는 맵리듀스 잡 스테이지, 샘플링(sampling) 스테이지, 병합 스테이지, limit 스테이지 등 하이브가 필요한 일을 하는 스테이지로 구성된다. 하이브는 각 스테이지를 하나씩 실행한다.

·       5 : STAGE PLANS 절은 매우 길고 복잡하다.

·       6 : 잡을 위한 처리 묶음이고 맵리듀스를 통해 실행된다.

·       7 : Map Operator Tree: 이후의 모든 부분은 잡의 맵 부분에서 실행한다.

·       9 : TableScan 태스크는 테이블을 입력으로 받아 결과 컬럼을 만든다.

·       13 : Filter Operator에서 조회 조건을 필터 한다

·       16 : Select Operator에서 출력할 대상을 선정한다.

·       20 : Group By Operator에서 쿼리에서 요청한 카운트 작업을 한다.

·       32 : Reduce Operator Tree : 이후의 부분은 모두 리듀스 부분에서 실행한다.

·       33 : Reduce에서도 Group By Operator를 확인하 수 있는데, 각 맵에서 전달받은 값을 count 한다.

·       43, 48 : 마지막으로 파일을 출력하며, 해당 문자열 출력 포맷을 사용한다.

·       51 : 쿼리에서 limit 절이 없기 때문에 Stage-0은 no-op 스테이지 이다.

 

2020-09-21 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, 쿼리 실행계획, Hive 쿼리, Hive Query execution plan

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive LIMIT 튜닝 (데이터 샘플링으로 빠르게 응답하기)  (0) 2020.09.23
HDFS 데이터노드 블록 스캐너 (손상된 블록을 검색하여 수정)  (0) 2020.09.23
Hive 인덱스(index)  (0) 2020.08.28
Hive View  (0) 2020.08.25
Hive에서 샘플 데이터 추출  (0) 2020.08.14

Hive 인덱스(index)

 

·       Version : Hive

 

하이브 인덱스는 연산 속도를 향상시키기 위해 컬럼에 인덱스를 생성할 수 있으나, RDBMS의 인덱스랑 다르게 기능이 많이 제한적이다. 하이브는 인덱스 데이터를 원본 테이블이 아닌 별도 테이블에 저장한다. 그래서 인덱스 생성시 별도의 디스크 공간이 필요하고 생성에 따른 비용이 발생한다. 그래서 인덱스를 생성할때 사용 유무 및 효율을 잘 고려해서 생성해야 한다.

하지만 하이브에서 인덱스는 논리적 파티션의 크기가 작고 개수가 많은 경우 파티셔닝을 대신해서 사용할 수 있으며, 맵리듀스의 잡의 입력으로 사용할 테이블 블록을 푸루닝(pruning)하는데 도움을 줄 수 있다. 위에서 언급했듯이 모든 쿼리가 인덱스로 효율적인 것은 아니므로 실행계획을 분석하여 쿼리가 어떤 인덱스를 사용하는지 확인이 필요하다.

 

아래 스크립트는 인덱스를 생성하는 예제이다. AS 절은 인덱스를 구현한 자바 클래스를 인덱스 핸들러로 지정한다.

CREATE INDEX ix_tbl_a

ON TABLE tbl_a (col_1)

AS 'org.apache.hadoop.hive.ql.index.compact.CompactIndexHandler'

WITH DEFERRED REBUILD;

 

인덱스 핸들러는 인덱스 데이터를 무조건 테이블에 저장하지 않는다. 테이블에 저장하려면 IN TABLE 절을 함께 명시한다.

CREATE INDEX ix_tbl_a

ON TABLE tbl_a (col_1)

AS 'org.apache.hadoop.hive.ql.index.compact.CompactIndexHandler'

WITH DEFERRED REBUILD

IN TABLE tbl_a_index_table

PARTITION BY (par = 'XX');

 

WITH DEFERRED REBUILD는 인덱스가 비어있는 상태에서 시작한다. ALTER INDEX 구문을 사용하여 언제든지 리빌드가 가능하다. 만약 파티션을 생략하면 모든 파티션에 대해서 인덱스 리빌드가 발생한다.

ALTER INDEX ix_tbl_a

ON TABLE tbl_a

PARTITION (par = 'XX')

REBUILD;

 

인덱스 삭제는 아래 명령을 사용한다.

DROP INDEX IF EXISTS ix_tbl_a ON TABLE tbl_a;

 

아래 명령은 테이블에 생성된 모든 인덱스 정보를 나타낸다.

SHOW FORMATTED INDEX ON tbl_a;

 

 

 

 

2020-08-27 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, HIVE Index, Hive 인덱스, 하이브 인덱스, 하이브 튜닝

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

HDFS 데이터노드 블록 스캐너 (손상된 블록을 검색하여 수정)  (0) 2020.09.23
Hive EXPLAIN (실행계획) 사용  (0) 2020.09.22
Hive View  (0) 2020.08.25
Hive에서 샘플 데이터 추출  (0) 2020.08.14
Hive ORDER BY, SORT BY, DISTRIBUTE BY, CLUSTER BY  (0) 2020.08.04

Hive View

 

·       Version : Hive

 

하이브에서 뷰(View)는 일반 RDBMS 뷰와 동일하게 데이터를 저장하지 않는 논리적 테이블 구조이다. 뷰는 테이블과 같은 데이터베이스에 저장되기 때문에 뷰 이름은 데이터베이스 내에서 유니크해야한다.  아래 스크립트는 하이브에서 뷰를 생성하는 예제이다.

create view vw_a

as

select

       col_1, col_2, col_3

from tbl_a

where col_1 = 'a';

 

뷰를 생성할때 새로운 컬럼 이름 전체나 일부분에 COMMENT를 추가할 수도 있다. 뷰는 원본 테이블로 부터 주석을 상속받지 않는다. 뷰는 INSERT나 LOAD 명령의 대상으로 사용할 수 없으며 읽기 전용이다.

 

하이브는 뷰를 먼저 수행한 후에 쿼리를 수행한다. 그러나 옵티마이저는 뷰와 쿼리절을 하나의 실제 쿼리로 결합하여 실행할 수도 있다. 하지만 하나의 쿼리로 실행되었다고 하더라도 뷰와 뷰를 사용하는 쿼리 둘다 ORDER BY 절이나 LIMIT 절을 가지고 있으면 뷰의 개념이 적용되어 뷰 절을 먼저 수행한다.

 

 

 

2020-08-24 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, HIVE view, 하이브 뷰, Hive 뷰, 하이브 테이블

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive EXPLAIN (실행계획) 사용  (0) 2020.09.22
Hive 인덱스(index)  (0) 2020.08.28
Hive에서 샘플 데이터 추출  (0) 2020.08.14
Hive ORDER BY, SORT BY, DISTRIBUTE BY, CLUSTER BY  (0) 2020.08.04
Hive Map-Side-Join, Bucket-Map-Join, Sort-Merge-Join  (0) 2020.07.29

Hive에서 샘플 데이터 추출

 

·       Version : Hive

 

하이브에서 큰 데이터 테이블이 있을때, 일부 데이터 샘플을 추출하는 방법에 대해서 알아본다. 하이브는 테이블을 버킷으로 구성하여 샘플을 만드는 쿼리로 아래와 같은 방식으로 사용할 있으며, 예제 스크립트는 1에서 10까지 값을 가진 컬럼에서 난수를 발생시키는 rand() 함수를 사용하여 샘플 데이터를 추출한다.

select * from tbl TABLESAMPLE (BUCKET 3 OUT OF 10 ON rand());

 

 BUCKET절에서 분모는 데이터가 해시될 수 있는 버킷 개수를 표현하며, 분자는 선택되는 버킷 숫자이다.

 

아래 스크립트는 PERCENT 함수를 사용하여 테이블 블록의 백분율로 샘플 데이터를 추출한다.

select * from tbl TABLESAMPLE (0.1 PERCENTS);

 

 

 

2020-08-13 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, TABLESAMPLE, 샘플데이터, 랜덤데이터추출

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive 인덱스(index)  (0) 2020.08.28
Hive View  (0) 2020.08.25
Hive ORDER BY, SORT BY, DISTRIBUTE BY, CLUSTER BY  (0) 2020.08.04
Hive Map-Side-Join, Bucket-Map-Join, Sort-Merge-Join  (0) 2020.07.29
Hive Left Semi Join (세미 조인) 과 Cartesian Product Join (카테시안 프로덕트 조인)  (0) 2020.07.28

Hive ORDER BY, SORT BY, DISTRIBUTE BY, CLUSTER BY

 

·       Version : Hive

 

하이브 또는 RDBMS에서 ORDER BY는 쿼리 결과 집합에 대해서 전체 정렬을 수행한다. 하이브에서 ORDER BY는 모든 데이터가 하나의 리듀서로 처리되기 때문에 데이터 셋이 클수록 시간이 오래 걸린다. ORDER BY에 오랜 시간을 수행될 수 있기 때문에 하이브는 hive.mapred.node가 strict로 설정되었을 경우 ORDER BY절에 대해서 LIMIT 를 요구한다. 기본값은 nonstrict 이다.

 

 

하이브에서 ORDER BY 대신 SORT BY를 사용하면 각 리듀서에서 지역 정렬하여 출력한다. ORDER와SORT를 사용할 경우 어떠한 컬럼이라도 지정할 수도 있고 ASC(기본값), DESC를 사용하여 정렬할 수도 있다.  SORT BY를 사용하는 경우 하나 이상의 리듀서로 처리될 경우 각 리듀서의 파일이 정렬되어 있더라도 전체적으로는 다른 리듀서의 출력된 정렬 결과가 겹치기 때문에 전체 정렬순서는 보장되지 않는다.

 

DISTRIBUTE BY는 맵의 출력을 리듀서로 어떻게 나누어 보내는지를 제어한다. 하이브는 쿼리를 맵리듀스 잡으로 변환할때 내부적으로 이 기능을 사용하기도 한다. 기본적으로 맵리듀스는 맵퍼가 출력하는 키에 대해서 해시값을 계산하고 해시값을 이용하여 카-값 쌍을 가용한 리듀서로 균등하게 분산하려고 노력한다. 이때 SORT BY를 사용할때 하나의 리듀서 출력이 다른 리듀서의 출력과 정렬 결과가 겹칠수 있다. 하지만 리듀서 출력 내에서는 정렬되어 있다. 하둡이 같은 데이터 레코드는 같은 리듀서로 보내는 것을 보장하기 위해서 DISTRIBUTE BY를 사용할 수 있다. 그리고 리듀서 별로 데이터를 정렬하기 위해 SORT BY를 사용한다.

 

 

SORT BY는 리듀서 안에서 데이터 정렬을 제어하는 반면 DISTRIBUTE BY는 리듀서가 처리할 로우를 어떻게 받는지 제어한다는 점에서는 GROUP BY처럼 동작한다. 하이브는 SORT BY절 전에 DISTRIBUTE BY 절을 사용할 것을 요구하므로 주의해야한다.

 

CLUSTER BY는 같은 쿼리를 표현하는 간단한 방법이다.

 

 

2020-08-03 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, 하이브 정렬,  ORDER BY, SORT BY, DISTRIBUTE BY, CLUSTER BY

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive View  (0) 2020.08.25
Hive에서 샘플 데이터 추출  (0) 2020.08.14
Hive Map-Side-Join, Bucket-Map-Join, Sort-Merge-Join  (0) 2020.07.29
Hive Left Semi Join (세미 조인) 과 Cartesian Product Join (카테시안 프로덕트 조인)  (0) 2020.07.28
Hive JOIN 및 조인 최적화  (0) 2020.07.23

Hive Map-Side-Join,  Bucket-Map-Join, Sort-Merge-Join

 

·       Version : Hive

 

Hive에서 조인 명령을 실행할때, 크기가 작은 테이블은 메모리에 캐시하고 크기가 큰 테이블은 맵퍼로 흘려 보낼 수 있다. 하이브는 메모리에 캐시한 작은 테이블로 부터 일치하는 모든 것을 찾아 낼 수 있기 때문에 맵에서 모든 조인을 할 수 있다. 이렇게 하면 일반 조인 시나리오에서 필요한 리듀스 단계를 제거할 수 있다.

 

데이터가 작을 수록 맵 사이드 조인은 일반 조인보다 효율이 좋다. 리듀스 단계를 제거할 뿐만 아니라 맵 단계 역시 줄어들기 때문이다.맵 사이드 조인을 활성화 하기 위해서는 hive.auto.convert.join 속성을 true로 설정해야한다. 기본값은 false 이다. 맵 사이드 조인을 사용하기 위한 테이블 크기 임계치는 hive.mapjoin.smalltable.filesize 속성값을 설정한다. 단위는 바이트 이다.

hive> set hive.auto.convert.join=true;

hive> set hive.auto.convert.join.noconditionaltask=true;

hive> set hive.auto.convert.join.noconditionaltask.size=20971520

hive> set hive.auto.convert.join.use.nonstaged=true;

hive> set hive.mapjoin.smalltable.filesize = 30000000;

 

 

맵 사이드 조인은 특정 조건에서는 큰 테이블에서도 사용할 수 있다. 이러한 조건은 ON 절에서 사용할 키에 대해서 버킷팅이 되어 있어야 하고, 한 테이블의 버킷 수가 다른 테이블 버킷 수의 배수이어야 한다. 이러한 조건이 충족되면 하이브는 다른 테이블의 각 버킷을 매칭하기 위해 모든 테이블의 내용을 가져올 필요 없이 테이블 간의 버킷에 대해 맵 사이드 조인을 할 수 있다.  이 옵션을 사용하기 위해서는 hive.optimize.bucketmapjoin 속성값을 ture로 설정해야 한다.

hive> set hive.optimize.bucketmapjoin=true;

 

만약 버킷팅되어 있는 테이블이 같은 수의 버킷을 가지고 있고, 데이터는 조인/버킷 키로 정렬되어 있다면 하이브는 정렬-병합 조인(Sort Merge Join)을 수행하여 빠르게 조인할 수 있다.

 

이 옵션을 사용하기 위해서는 아래 설정을 활성화 해야 한다.

hive> set hive.input.format=org.apache.hadoop.hive.ql.io.BucketizedHiveInputFormat;

hive> set hive.optimize.bucketmapjoin=true;

hive> set hive.optimize.bucketmapjoin.sortedmerge=true;

 

 

 

참고자료

·       Map Join in Hive | Map Side Join : https://data-flair.training/blogs/map-join-in-hive/

·       Bucket Map Join in Hive – Tips & Working : https://data-flair.training/blogs/bucket-map-join/

·       Sort Merge Bucket Join in Hive – SMB Join : https://data-flair.training/blogs/hive-sort-merge-bucket-join/

 

 

 

2020-07-28 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, JOIN, Hive Map Join, Hive Bucket Join, Hive Sort Merge Join, 조인 최적화, 하이브 튜닝

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive에서 샘플 데이터 추출  (0) 2020.08.14
Hive ORDER BY, SORT BY, DISTRIBUTE BY, CLUSTER BY  (0) 2020.08.04
Hive Left Semi Join (세미 조인) 과 Cartesian Product Join (카테시안 프로덕트 조인)  (0) 2020.07.28
Hive JOIN 및 조인 최적화  (0) 2020.07.23
Hive LIKE 와 RLIKE  (0) 2020.07.22

Hive Left Semi Join (세미 조인) 과 Cartesian Product Join (카테시안 프로덕트 조인)

 

·       Version : Hive

 

Hive에서 Left Semi Join (왼쪽 세미 조인)은 오른쪽 테이블에서 ON 조건을 만족하는 레코드를 찾을 경우 왼쪽 테이블의 레코드를 반환한다.

 

일반적인 RDBMS의 SQL은 조건을 만족하기 위해 IN 또는 EXISTS 구문을 지원하지만, 하이브에서는 동작하지 않는다. 하이브는 기본적으로 Right Semi Join (오른쪽 세미 조인) 을 지원하지 않으며 SELECT 와 WHERE절에서 오른쪽 테이블의 컬럼을 참조 할 수 없음에 주의해야 한다.  아래 스크립트는 하이브에서 사용할 수 있는 Left  Semi Join의 예시이다.

select

       a.col_1, a.col_2

from tbl_a as a

       left semi join tbl_b as b on a.col_1 = b.col_1 and a.col_2 = b.col_2

 

하이브에서 세미 조인이 일반 내부 조인보다 효율적인 이유는 왼쪽 테이의 한 레코드에 대해서 오른쪽 테이블에서 일치하는 레코드를 찾으면 더 이상 일치하는 레코드를 찾지 않고 바로 데이터를 반환하고 멈추기 때문이다.

 

카테시안 프로덕트 조인(Cartesian Product Join)은 조인의 왼쪽 테이블에 있는 튜플(tuple)과 오른쪽에 있는 튜플이 모든 쌍을 맺는다. 다른 조인 유형과 달리 하이브에서는 카테시안 프로덕트를 병렬로 실행하지 않는다. 또한 맵리듀스에서 최적화되어 있지도 않다. 아래 스크립트는 하이브에서 전체 카테시안 프로덕트(Full Cartesian Product)를 실행한다.

select

       a.*, b.*

from tbl_a as a

       join tbl_b as b

where a.col_1 = b.col_1

 

일반적인 RDBMS에서는 위와 같은 쿼리에 대해서 내부 조인에 최적화되어 있으나, 하이브에서 이런 종류의 쿼리는 WHERE 절을 적용하기 전에 전체 카테시안 프로덕트를 실행한다. 그래서 쿼리가 아주 오래 걸릴 수 있다. 사용자 부주의로 카테시안 프로덕트를 방지하기 위해 hive.mapred.mode 속성이 strict 로 되어 있으면 카테시안 프로덕트의 실행을 방지 할 수 있다.

 

 

2020-07-27 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, JOIN, HIVE LEFT SEMI JOIN, 하이브 최적화, 하이브 튜닝, Hive Tuning, Hive Query Hint, CartesianProductJoin, 카테시안조인

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive ORDER BY, SORT BY, DISTRIBUTE BY, CLUSTER BY  (0) 2020.08.04
Hive Map-Side-Join, Bucket-Map-Join, Sort-Merge-Join  (0) 2020.07.29
Hive JOIN 및 조인 최적화  (0) 2020.07.23
Hive LIKE 와 RLIKE  (0) 2020.07.22
HDFS fsimage와 에디트 로그  (0) 2020.07.15

Hive JOIN 및 조인 최적화

 

·       Version : Hive

 

Hive는 RDBMS와 같은 JOIN(조인) 구문을 제공하며 기능도 거의 유사하지만 동등조인(EQUI-JOIN)만 제공한다.

 

내부조인(INNER JOIN)의 경우 조인하는 모든 테이블에서 일치하는 레코드만 반환한다. ON 절은 두 테이블에서 조인할 레코드의 조건을명시한다.

select

       a.col_1, b.col_2

from tbl_a

       inner join tbl_b on a.col_1 = b.col_1

 

RDBMS의 표준 SQL의 경우 조인 키에 대해서 비동등 조인(NON-EQUI-JOIN)을 허용하지만 하이브에서는 제공하지 않는다. 또한 하이브에서는 ON절에서 OR 조건의 사용을 허용하지 않는다. 만약 ON 절에 OR를 사용하려고 한다면 아래 스크립트와 같이 UNION ALL으로 쿼리를 풀어서 사용할 수 있다.

select

       *

from test1 as t1

       join test2 as t2 on (t1.col1 = t2.col1 and t1.col1 = 1) or (t1.col1 = t2.col2 and t1.col1 = 2);

 

/* OR 대신 UNION ALL 사용 */

select

       *

from test1 as t1

       join test2 as t2 on (t1.col1 = t2.col1 and t1.col1 = 1)

 

union all

 

select

       *

from test1 as t1

       join test2 as t2  on (t1.col1 = t2.col2 and t1.col1 = 2);

 

 

대부분의 하이브는 조인할 각각의 쌍에 대해서 별도의 맵리듀스 잡을 사용한다. 또한 하이브는 왼쪽에서 오른쪽으로 쿼리를 처리하며 조인 순서 또한 왼쪽에서 오른쪽(from 절 순서)으로 처리한다. 3개 이상의 테이블을 조인할 때, 모든 ON 절에서 같은 조인키를 사용한다면 하나의 맵리듀스 잡을 사용한다.

 

하이브에서 조인을 처리할때, 마지막 테이블을 가장 크다고 가정한다. 다른 테이블을 버퍼링하려고 시도하고, 각 레코드에 대해서 조인을 수행하면서 마지막 테이블을 흘려보낸다. 그러므로 조인쿼리를 구성할때, 가장 큰 테이블을 가장 마지막에 위치하도록 해야한다. 가장 큰 테이블을 쿼리의 마지막에 위치하지 못하였더라도 힌트를 사용하면 마지막에 처리할 수 있다. 아래 스크립트는 힌트를 사용하여 from의 첫 테이블을 마지막에 처리할 수 있도록 한다.

SELECT

       /*+ STREAMTABLE(s) */ s.*, b.*

from tbl_s   

       inner join tbl_b ON s.col_1 = b.col_1

where s.col_1 = ?

 

 

데이터 조회시 검색 최적화를 위해 파티션 필터를 사용하는데 OUTER JOIN (외부조인)의 경우 파티션 필터를 무시한다. 하지만 내부 조인의 ON절에 파티션 필터를 사용하면 잘 동작한다. 따라서 모든 조인에서 파티션 필터를 사용하기 위해 중첩 SELECT를 사용하여 해결할 수 있다.

select

       a.col_1, b.col_1

from (select * from tbl_a where partition_filter = ? and col_1 = ?) as a

       left outer join (select * from tbl_b where partition_filter = ? and col_1 = ?) as b on a.col_1 = b.col_1

 

중첩 SELECT 문은 데이터 조인 전에 파티션 필더를 적용하는데 필요한 푸시다운(push down)을 수행한다. 하이브는 조인을 수행한 후에 WHERE 절을 평가한다. 따라서 WHERE 절은 NULL이 되지 않는 컬럼값에 대해서만 필터를 적용할 수 있도록 해야한다.

 

 

2020-07-22 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, JOIN, INNER JOIN, 하이브 최적화, 하이브 튜닝, Hive Tuning, Hive Query Hint

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive Map-Side-Join, Bucket-Map-Join, Sort-Merge-Join  (0) 2020.07.29
Hive Left Semi Join (세미 조인) 과 Cartesian Product Join (카테시안 프로덕트 조인)  (0) 2020.07.28
Hive LIKE 와 RLIKE  (0) 2020.07.22
HDFS fsimage와 에디트 로그  (0) 2020.07.15
Hive는 무조건 MapReduce를 사용할까?  (0) 2020.07.15

Hive LIKE 와 RLIKE

 

·       Version : Hive

 

Hive에서 LIKE 구문은 RDBMS의 LIKE 구문과 동일한 동작으로, 어떤 서브 문자열(substring)이 문자열의 시작이나 끝, 혹은 문자열 내에서 일치하는지 확인할 수 있다.

 

아래 스크립트는 LIKE 구문으로 검색한 것이며, OR 절을 사용하여 여러개의 LIKE 구문을 사용하였다.

DROP TABLE IF EXISTS TBL_A;

CREATE TABLE TBL_A(

COL_1 STRING

);

 

INSERT INTO TBL_A(COL_1) VALUES ('CHICAGO'), ('NEWYORK');

 

SELECT * FROM TBL_A WHERE COL_1 LIKE '%CA%' OR COL_1 LIKE '%YO%';

 

 

 

하이브는 LIKE 절을 자바 정규표현식으로 사용할 수 있는 RLIKE 절로 확장하여 LIKE 절 조합으로 검색하기 어려운 문자열을 표현할 수 있다. 아래 스크립트는 RLIKE 예제이다.

select * from tbl_a where col_1 RLIKE '.*(ca|Yo).*';

 

 

위 예제에서 마침표(.)는 어떤 한 문자와 일치하고 별(*)은 왼쪽에 있는 것이 0번에서 여러 번 반복되는 것을 의미한다. 따라서 앞, 뒤에서 마침표가 반복된다. (x|y)  표현식은 x또는  y의 문자열이 일치하는 것을 의미한다.

 

2020-07-21 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, Hive SQL, LIKE, RLIKE

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive Left Semi Join (세미 조인) 과 Cartesian Product Join (카테시안 프로덕트 조인)  (0) 2020.07.28
Hive JOIN 및 조인 최적화  (0) 2020.07.23
HDFS fsimage와 에디트 로그  (0) 2020.07.15
Hive는 무조건 MapReduce를 사용할까?  (0) 2020.07.15
Hive에서 SELECT 결과를 테이블로 INSERT 하기  (0) 2020.07.14

HDFS fsimage와 에디트 로그

 

·       Version : HDFS

 

HDFS 에서 클라이언트가 파일을 생성하거나 이동할때 에디트 로그에 먼저 기록한다. 네임노드는 파일시스템 메타데이터를 메모리로 로드하여 인-메모리 자료구조로 관리하며 에디트 로그가 수정된 후 업데이트를 진행한다. 인-메모리 메타데이터는 읽기 요청을 수행하는데 사용되며 각 디렉터리에 쓰기 동작이 끝나고 나서 성공했다는 결과가 클라이언트로 반환 되기전에 에디트 로그를 플러시하여 동기화한다. 이렇게 함으로서 장애가 발생해도 데이터 유실을 방지할 수 있다.

 

fsimage는 파일시스템 데이터의 영속적인 체크포인트 파일이다. 하지만 개별 쓰기 동작 때마다 갱신되지는 않는다. fsimage는 파일 시스템에서 존재하는 모든 디렉터리와 파일 아이노드(inode) 정보를 바이트로 직렬화 한다. 각 아이노드는 파일의 복제 단위, 변경 및 접근시간, 접근권한, 블록 크기와 파일을 구성하는 블록 조합들 같은 정보를 가진다. 디렉터리는 변경 시간, 권한 할당, 크기 같은 메타데이터가 저장된다. fsimage 파일은 블록이 저장되는 데이터노드 정보를 기록하지는 않는다. 대신 네임노드는 메모리상에 이 블록과 데이터 노드 매핑정보를 유지한다. 네임노드는 데이터 노드가 클러스터에 참여할 때 블록 리스트를 요청하여 매핑정보를 구성하며 주기적으로 정보를 받아 매핑정보를 최신상태로 유지한다.

 

에디트 파일은 크기 제한없이 증가할 수 있다. 네임노드가 구동 중일 때에는 에디트 파일이 커지더라도 특별한 영향을 주지는 않지만 네임노드가 재시작될 경우, 많은 에디트 로그의 개별 동작들을 메모리에 반영하기 위해 상당한 시간이 소요된다. 이 시간 동안은 파일 시스템을 사용하지 못하는 상황이 발생한다. 이와 같은 문제를 방지하기 위해 보조 네임노드를 구성한다. 보조 네임노드는 주 네임노드의 인-메모리 메타데이터에 체크포인트를 생성하는 것이다. 체크포인트는 아래와 같은 순서로 진행된다.

1.       보조 네임노드는 주 네임노드에 edits 파일을 순환 사용하도록 요청하고 주 네임 노드에서 새로운 edits 로그는 새로운 파일에 저장된다.

2.       보노 네임노드는 HTTP GET을 이용해서 주 네임노드의 fsimage와 edits를 가져온다.

3.       보조 네임노드는 fsimage를 메모리에 로드하고 edits의 각 동작을 반영한다. 그리고 나서 새롭게 통합된 fsimage 파일을 생성한다.

4.       보조 네임노드는 HTTP POST를 이용하여 새로운 fsimage 파일을 주 네임노드에 전송한다.

5.       주 네임노드는 이전 fsimage를 보조 네임노드로부터 받은 새로운 이미지로 교체하며, 이전 edits 파일을 1단계에서 시작한 새로운 edits로 교체한다. fsimage 파일도 체크포인트가 발생한 시간을 기록하기 위해 변경된다.

 

아래 그림은 위 체크포인트 과정을 이해하기 쉽도록 그림으로 표현한 것이다.

 

 

2020-07-14 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, edit log, fsimage, 체크포인트, checkpoint, namenode, 네임노드

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive JOIN 및 조인 최적화  (0) 2020.07.23
Hive LIKE 와 RLIKE  (0) 2020.07.22
Hive는 무조건 MapReduce를 사용할까?  (0) 2020.07.15
Hive에서 SELECT 결과를 테이블로 INSERT 하기  (0) 2020.07.14
Hive 테이블 삭제, 수정  (0) 2020.07.08

Hive는 무조건 MapReduce를 사용할까

 

·       Version : Hive

 

Hive에서 쿼리를 실행할때, 무조건 맵리듀스(MapReduce)를 사용할까?  하이브에서 대부분의 쿼리를 실행할 경우 맵리듀스가 사용된다. 하지만 일부 쿼리의 경우 로컬 모드 환경에서 맵리듀스를 사용하지 않고도 쿼리가 동작 할수도 있다. 예를 들어 아래 스크립트 처럼 단순히 테이블을 조회하는 쿼리는 맵리듀스를 사용하지 않는다.

select * from tbl_a;

 

단순히 SELECT와 같은 쿼리는 하이브가 테이블로 부터 레코드를 읽고 형식에 맞춰서 콘솔로 출력한다. 이 경우 맵리듀스 작업대신 파일에서 Fetch Task로 전체 데이터를 가져온다. 마치 아래 하둡 명령과 유사하다.

hadoop fs -cat $ file_name

 

일반적으로 min / max / count와 같은 모든 종류의 집계에는 맵리듀스 작업이 필요하다.  또한 컬럼을 사용하게 되면 하이브는 파일에서 구문을 분석하여 각 행에서 컬럼을 추출해야 하므로 맵리듀스 작업이 필요하다.

 

hive.exec.mode.local.auto 속성을 true로 설정하면 다른 연산도 로컬 모드로 실행을 시도한다.

hive.exec.mode.local.auto = true;

 

 

 

 

2020-07-14 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 테이블, Hive table, 하이브쿼리, Hive SQL, 맵리듀스, MapReduce

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive LIKE 와 RLIKE  (0) 2020.07.22
HDFS fsimage와 에디트 로그  (0) 2020.07.15
Hive에서 SELECT 결과를 테이블로 INSERT 하기  (0) 2020.07.14
Hive 테이블 삭제, 수정  (0) 2020.07.08
Hive 파티션 테이블에서 where 없는 쿼리 실행 방지  (0) 2020.07.02

Hive에서 SELECT 결과를 테이블로 INSERT 하기

 

·       Version : Hive

 

Hive에서 쿼리 결과를 테이블에 입력할때, 이미 존재하는 테이블에 데이터를 입력할수도 있으며, 새로운 테이블을 생성하며 데이터를 입력할 수도 있다. 이미 존재하는 테이블에 SELECT된 결과를 저장할 때는 INSERT 구문을 사용한다. OVERWRITE 예약어를 사용하여 해당 파티션의 데이터를 교체할 수 있다. OVERWRITE 예약어를 INTO로 변경하면 하이브는 데이터를 교체하지 않고 원래 데이터에 추가한다.

INSERT OVERWRITE TABLE tbl_new PARTITION (month = '1', day = '1')

select * from tbl_origin as origin

where origin.month = '1' and origin.day = '1';

 

만약 여러 파티션 데이터를 만들때, 각 파티션별로 INSERT 구문을 만들면 반복해서 데이터를 읽어야 하는 비효율적인 부분이 발생한다. 하이브는 입력 데이터를 한번 읽어서 이를 다수의 테이블로 분산하는 문법을 제공한다.

from tbl_origin as origin

INSERT OVERWRITE TABLE tbl_new PARTITION (month = '1', day = '1')

       select * where origin.month = '1' and origin.day = '1'

INSERT OVERWRITE TABLE tbl_new PARTITION (month = '2', day = '1')

       select * where origin.month = '2' and origin.day = '1'

INSERT OVERWRITE TABLE tbl_new PARTITION (month = '3', day = '1')

       select * where origin.month = '3' and origin.day = '1';

 

 

SELECT 결과물을 새로운 테이블을 생성하면서 저장하는 방법은 CREATE 구문을 사용할 수 있다.

CREATE TABLE tbl_create

AS SELECT col1, col2, col3

from tbl_origin

where month = '1' and day = '1';

 

 

 

2020-07-13 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 테이블, Hive table, 하이브쿼리, Hive SQL, 데이터 저장, INSERT SELECT

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

HDFS fsimage와 에디트 로그  (0) 2020.07.15
Hive는 무조건 MapReduce를 사용할까?  (0) 2020.07.15
Hive 테이블 삭제, 수정  (0) 2020.07.08
Hive 파티션 테이블에서 where 없는 쿼리 실행 방지  (0) 2020.07.02
Hive 매니지드 테이블 및 외부 테이블  (0) 2020.06.25

Hive 테이블 삭제, 수정

 

·       Version : Hive

 

하이브에서 테이블을 삭제하는 명령은 DROP TABLE 명령어를 사용한다.

DROP TABLE IF EXISTS table_name;

 

테이블을 삭제할때, 하둡의 휴지통기능이 활성화되어 있으면 데이터는 분산 파일 시스템의 .Trash 디렉터리로 이동된다. 휴지통 기능에 설정된 시간이후 데이터가 완전히 삭제 된다. 휴지통 기능이 비활성화 되어 있는 경우 즉시 삭제된다. 또한 삭제하려는 테이블이 외부 테이블인경우, 테이블의 메타데이터만 삭제되며 데이터는 그대로 남아있다.

 

테이블 수정은 ALTER TABLE 명령을 사용하여 변경한다. 테이블 수정은 메타데이터만 변경할 뿐 데이터 자체는 변경시키지 않는다.

[테이블명 변경]

Table_name 테이블명을 table_name_new 테이블명으로 변경한다.

ALTER TABLE table_name TO table_name_new

 

[파티션 추가/변경/삭제]

파티션 추가는 ADD PARTITION 명령을 사용한다.

ALTER TABLE table_name ADD IF NOT EXISTS

PARTITION(year = 2020, month = 1, day = 1) LOCATION '/user/data/20200101'

PARTITION(year = 2020, month = 1, day = 2) LOCATION '/user/data/20200102'

PARTITION(year = 2020, month = 1, day = 3) LOCATION '/user/data/20200103';

 

파티션 위치 변경은 SET LOCATION 명령을 사용한다.

ALTER TABLE table_name PARTIOTN(year = 2020, month = 1, day = 1)

SET LOCATION '/user/data/…';

 

파티션 삭제는 DROP PARTITION 명령을 사용한다.

ALTER TABEL table_name DROP IF EXISTS PARTITION (year = 2020, month = 1, day = 1);

 

 

[컬럼 변경]

컬럼명, 컬럼 위치, 주석 및 데이터 타입을 변경할 수 있다. old_column 컬럼명을 new_column 이름으로 변경하고 데이터 타입은 INT, 컬럼의 위치는 col2 뒤에 위치한다.

ALTER TABLE table_name

CHANGE COLUMN old_column new_column INT

COMMENT 'Input comment'

AFTER col2;

 

컬럼 이름이나 데이터 타입을 변경하지 않더라도, 컬럼의 예전이름과 새이름, 데이터 타입을 지정해야 한다.컬럼을 이동하지 않는다면 AFTER 명령은 필요하지 않으며, 컬럼을 맨 앞으로 위치할 경우 FIRST 를 사용할 수 있다.

 

[컬럼 추가 / 삭제  및 교체]

컬럼 추가는 이미 존재하는 컬럼의 마지막과 파티셔닝 컬럼 앞에 추가된다.

ALTER TABLE table_name ADD COLUMNS (

add_col1 STRING COMMENT 'Input Comments',

add_cpl2 LONG COMMENT 'Input Comments');

 

이미 존재하는 모든 컬럼을 삭제하고 새로운 컬럼으로 교체한다. 메타 데이터만 변경된다.

ALTER TABLE table_name REPLACE COLUMNS(

col1 INT COMMENT 'Input Comments',

col2 STRING COMMENT 'Input Comments',

col3 LONG COMMENT 'Input Comments');

 

 

 

 

2020-07-07 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 테이블, Hive table, 하이브쿼리, Hive SQL, 하이브파티션, 테이블삭제, 테이블수정

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive는 무조건 MapReduce를 사용할까?  (0) 2020.07.15
Hive에서 SELECT 결과를 테이블로 INSERT 하기  (0) 2020.07.14
Hive 파티션 테이블에서 where 없는 쿼리 실행 방지  (0) 2020.07.02
Hive 매니지드 테이블 및 외부 테이블  (0) 2020.06.25
HDFS 저장소에 데이터를 압축해서 저장하면 더 좋을까?  (0) 2020.06.23

Hive 파티션 테이블에서 where  없는 쿼리 실행 방지

 

·       Version : Hive

 

하이브에서 테이블 파티셔닝을 하는 가장 큰 이유는 빠르게 데이터를 검색하기 위해서이다. 아주 큰 데이터가 있더라도 파티션 스키마가 검색하려는 범위 필터링을 반영한다면 파티셔닝 테이블은 쿼리의 성능을 극적으로 올려준다. 그래서 특정값을 필터하는 WHERE 절에 파티션 조건을 포함하는데 이러한 조건을 “파티션 필터”라고 부른다.

그러나 파티셔닝이 잘 되어 있다고 하더라도, 테이블 데이터가 많거나 파티션 개수가 많다면 거대한 맵리듀스 작업을 유발할 수 있다. 이러한 맵리듀스의 부하를 방지하기 위해 WHERE 절에  파티션 필터가 없는경우 쿼리 실행이 되지 않도록 옵션을 설정할 수 있다.

 

아래 스크립트는 WHERE절에 파티션 필터가 없는경우 쿼리가 실행되지 않도록 적용한 예시이다.

hive> set hive.mapred.mode = strict;

hive> select * from campaign;

FAILED: SemanticException [Error 10056]: Queries against partitioned tables without a partition filter are disabled for safety reasons. If you know what you are doing, please set hive.strict.checks.no.partition.filter to false and make sure that hive.mapred.mode is not set to 'strict' to proceed. Note that you may get errors or incorrect results if you make a mistake while using some of the unsafe features. No partition predicate for Alias "campaign" Table "campaign"

hive>

 

 

 

아래 스크립트는 WHERE 절에 파티션 필터가 없을 경우에도 쿼리가 실행된다.

hive> set hive.mapred.mode = nonstrict;

hive> select * from campaign;

OK

Time taken: 0.671 seconds

hive>

 

현재 테이블에 생성되어 있는 파티션키 정보를 확인하려면 아래 명령을 실행한다.

hive> show partitions campaign;

OK

date_local=20200616

date_local=20200617

date_local=20200630

Time taken: 0.13 seconds, Fetched: 3 row(s)

hive>

 

 

 

 

2020-07-01 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 테이블, Hive table, 하이브쿼리, Hive SQL, 하이브파티션, 파티션필터, partition filter

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive에서 SELECT 결과를 테이블로 INSERT 하기  (0) 2020.07.14
Hive 테이블 삭제, 수정  (0) 2020.07.08
Hive 매니지드 테이블 및 외부 테이블  (0) 2020.06.25
HDFS 저장소에 데이터를 압축해서 저장하면 더 좋을까?  (0) 2020.06.23
Hive 테이블  (0) 2020.06.23

Hive 매니지드 테이블 및 외부 테이블

 

·       Version : Hive

 

하이브에는 매니지드 테이블과 외부 테이블이라고 불리는 테이블 저장 방식이 있다. 이 둘의 차이점은 데이터 소유자가 하이브이냐, 아니냐로 크게 구분할 수 있다.

 

매지니드 테이블 (Managed Table)은 내부 테이블이라고도 불리며 하이브 속성(hive.metastore.warehouse.dir)에서 정의한 디렉터리의 하위 디렉터리를 만들어서 데이터를 저장한다. 하이브에서 매니지드 테이블을 삭제할때 테이블내의 데이터가 삭제된다.

 

외부 테이블은 테이블을 생성할때, EXTERNAL 키워드를 사용하며, LOCATION절에서 지정한 위치에 데이터가 존재한다는것을 하이브에게 알려준다. 하이브에서 외부 테이블을 삭제하면, 하이브 내에서 스키마만 삭제될 뿐 데이터는그대로 존재한다. 그래서 중요한 데이터의 경우 실수를 방지하기 위해 외부 테이블로 만드는것을 권장한다.

 

테이블의 속성이 매니지드 또는 외부인지 확인할 수 있는 방법은 DESCRIBE EXTENDED 명령을 사용한다.

DESCRIBE EXTENDED 테이블명;

  

 

 

아래 스크립트는 매니지드 테이블처럼 스키마만 복사하여 외부 테이블로 생성한다.

create external table if not exists testdb.tbl_b

like testdb.tbl_a

location '/user/data/';

 

스키마를 복사하려는 원본 테이블이 외부 테이블인 경우 EXTERNAL 명령을 생략하여도 외부 테이블로 생성된다.

 

 

 

2020-06-24 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 테이블, Hive table, 하이브쿼리, Hive SQL

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive 테이블 삭제, 수정  (0) 2020.07.08
Hive 파티션 테이블에서 where 없는 쿼리 실행 방지  (0) 2020.07.02
HDFS 저장소에 데이터를 압축해서 저장하면 더 좋을까?  (0) 2020.06.23
Hive 테이블  (0) 2020.06.23
HiveQL과 Hive 데이터베이스  (0) 2020.06.17

HDFS 저장소에 데이터를 압축해서 저장하면 더 좋을까?

 

·       Version : HDFS

 

HDFS 클러스터에서 데이터를 저장할때, 압축을 해서 보관하는것이 더 좋을까? 그냥 저장하는 것이 좋을까? 결론부터 말하면 반은 맞고 반은 틀리다. 즉, 압축의 특성을 잘 이해하고 사용하면 좋지만, 그렇지 못할경우 오히려 HDFS의 장점을 활용하지 못할 수도 있다.

 

맵리듀스가 처리할 데이터를 압축하는 방법을 고려할때, 압축 포맷이 분할을 지원하는지 여부를 이해하는것이 중요하다. 예를들어 HDFS에 1GB의 데이터 파일을 저장한다고 가정한다.  64MB 블록으로 처리할 경우 16개의 블록으로 나뉘어 HDFS에 저장된다. 맵 리듀스에서 이 파일을 입력 데이터로 사용할 경우 16개의 독립적으로 처리되는 입력 분할을 생성할 것이다.

 

 

 

그런데 압축 크기가 1GB인 하나의 gzip 압축 파일이 있다고 가정한다. 기존처럼 HDFS는 16개의 블록에 저장할 것이다. 그러나 각 블록에 대한 분할 생성은 gzip 스트림이 특정 위치에서 읽기를 지원하지 않기 때문에 동작을 하지 않을것이다.  즉, 맵태스크가 나머지 블록의 각 분할을 개별적으로 읽는것은 불가능하므로 gzip 포맷을 저장하기 위해 DEFLATE를 사용하고, DEFLATE는 데이터를 일련의 압축된 블록으로 저장한다. 리더가 다음 블록의 시작으로 이동하려면 스트림과 동기화되어 그 스트림의 특정 지점에 있을 수 있는 어떤 방법을 지원해야 하는데, DEPLATE 압축 방식은 각 블록의 시작점을 구분할 수 없기 때문에  gzip은 분할을 지원하지 않는다. 그래서 맵리듀스는 gzip 은 분할을 지원하지 않는다는 것을 인식하고, 그 파일을 분할하려고 하지 않을것이다. 그러면 단일 지역으로 데이터가 편향되어 지역성 비용이 증가하게 된다. 즉, 단일 맵이 16개의 HDFS 블록을 처리할 것이고, 그 블록은 대부분 그 맵의 로컬에 있지 않을 가능성이 크다. 소수의 맵과 함께 그 잡은 일반적인 잡보다 세분화 되지 않아 더 오랫동안 수행될 확률이 크다.

 

압축파일이 bzip2는 어떨까? bzip2 파일은 블록 사이에서 동기화 표시가를 제공(파이의 48비트 근사치)하고 결과적으로 분할을 지원한다.

 

ZIP파일은 아카이브 포맷이기 때문에 다중 파일을 단일 ZIP 아카이브로 결합시킬 수 있다. 각 파일은 개별적으로 압축되고 그 아카이브에 있는 모든 파일 위치는 ZIP 파일의 끝에서 중앙 디렉터리에 저장된다. 이러한 속성은 ZIP 파일이 파일 단위로 분할을 지원한다는 것을 의미한다. 그리고 각 분할은 ZIP 아카이브로부터 하나 이상의 파일들을 포함한다. (zip 지원 여부는 확인이 필요하다.)

 

LZO 파일의 경우 기존의 압축 포맷의 리더가 그 스트림과 동기화되는 방법을 제공하지 않기 때문에 분할이 불가능하다.

 

아래표는 하둡에서 지원하는 압축 및 분할 여부이다.

Compression format

Tool

Algorithm

File extention

Splittable

gzip

gzip

DEFLATE

.gz

No

bzip2

bizp2

bzip2

.bz2

Yes

LZO

lzop

LZO

.lzo

Yes if indexed

Snappy

N/A

Snappy

.snappy

No

 

이 외에도 시퀀스 파일을 사용하거나,  청크 단위로 파일을 나누어서(이때 각 청크는 HDFS 블록 하나 정도 크기로 생성한다.) 개별적으로 압축을 하여 사용하면 압축 파일 분할 여부와 관계없이 어느정도 효율성을 발휘할 수 있다.  

 

 

[참고자료]

·       Choosing a Data Compression Format : https://docs.cloudera.com/documentation/enterprise/5-3-x/topics/admin_data_compression_performance.html

·       Data Compression in Hadoop : http://comphadoop.weebly.com/

 

 

 

2020-06-22 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, 하둡 파일 압축, 분산 처리, 분산 저장

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive 파티션 테이블에서 where 없는 쿼리 실행 방지  (0) 2020.07.02
Hive 매니지드 테이블 및 외부 테이블  (0) 2020.06.25
Hive 테이블  (0) 2020.06.23
HiveQL과 Hive 데이터베이스  (0) 2020.06.17
Hive 텍스트파일 인코딩  (0) 2020.06.12

Hive 테이블

 

·       Version : Hive

 

하이브에서 테이블을 생성 할때에는 SQL 규칙을 따르지만 테이블의 데이터 파일 생성 위치나 사용할 포맷등 확장기능을 사용하여 유연성을 제공한다.

CREATE [TEMPORARY] [EXTERNAL] TABLE [IF NOT EXISTS] [db_name.]table_name    -- (Note: TEMPORARY available in Hive 0.14.0 and later)

  [(col_name data_type [column_constraint_specification] [COMMENT col_comment], ... [constraint_specification])]

  [COMMENT table_comment]

  [PARTITIONED BY (col_name data_type [COMMENT col_comment], ...)]

  [CLUSTERED BY (col_name, col_name, ...) [SORTED BY (col_name [ASC|DESC], ...)] INTO num_buckets BUCKETS]

  [SKEWED BY (col_name, col_name, ...)                  -- (Note: Available in Hive 0.10.0 and later)]

     ON ((col_value, col_value, ...), (col_value, col_value, ...), ...)

     [STORED AS DIRECTORIES]

  [

   [ROW FORMAT row_format]

   [STORED AS file_format]

     | STORED BY 'storage.handler.class.name' [WITH SERDEPROPERTIES (...)]  -- (Note: Available in Hive 0.6.0 and later)

  ]

  [LOCATION hdfs_path]

  [TBLPROPERTIES (property_name=property_value, ...)]   -- (Note: Available in Hive 0.6.0 and later)

  [AS select_statement];   -- (Note: Available in Hive 0.5.0 and later; not supported for external tables)

 

“IF NOT EXISTS” 명령은 테이블의 존재 유무를 확인하여, 테이블이 없을 경우 명령을 실행한다. 이 명령을 사용하면, 동일한 이름의 테이블이 있을경우 에러를 발생시키지 않고 다음 단계로 진행 할 수 있다. 하지만 이름만 확인할 뿐 스키마 구조까지 확인하는것은 아니다.

 

아래 스크립트는 Hive에서 테이블의 데이터를 제외한 스키마만 복사한다.

CREATE [TEMPORARY] [EXTERNAL] TABLE [IF NOT EXISTS] [db_name.]table_name

  LIKE existing_table_or_view_name

[LOCATION hdfs_path];

 

ex) CREATE TABLE IF NOT EXISTS testdb.mytable2 LIKE testdb.mytable;

 

테이블 정보를 확인하기 위해서는 DESCRIBE 명령을 사용한다.

describe tlb_a;

 

 

테이블의 정보를 자세히 확인할 때에는 EXTENDED 명령을 추가한다. EXTENDED 를 사용할 경우 자세한 정보가 출력되지만, 사람이 읽기에는 줄바꿈 등이 되지 않아 가독성이 불편하다.

describe extended tlb_a;

 

 

 

EXTENDED 대신 FROMATTED를 사용하면 줄바꿈등이 적용되어 가독성이 뛰어나다.

describe formatted tlb_a;

 

 

EXTENDED 옵션을 사용한 출력에서 location 항목은 테이블의 데이터를 저장하는 HDFS 내 디렉터리 전체 URI 경로를 보여준다.

 

 

[참고자료]

 

 

 

2020-06-22 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 테이블, Hive table, 하이브쿼리, Hive SQL

 

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive 매니지드 테이블 및 외부 테이블  (0) 2020.06.25
HDFS 저장소에 데이터를 압축해서 저장하면 더 좋을까?  (0) 2020.06.23
HiveQL과 Hive 데이터베이스  (0) 2020.06.17
Hive 텍스트파일 인코딩  (0) 2020.06.12
Impala Connection refuse Error  (0) 2020.06.12

HiveQL과 Hive 데이터베이스

 

·       Version : Hive

 

HiveQL은 Hive에서 사용하는 쿼리 언어이다. SQL과 유사하지만 SQL과 다르며 표준 ANSI SQL을 지원하지 않는다. 하이브는 로우(ROW) 레벨의 삽입과 변경, 삭제를 지원하지 않으며, 트랜잭션 또한 지원하지 않는다. 하지만 하둡이 지원하는 범위 안에서 성능 확장을 위해 다양한 기능을 제공하며, 사용자가 정의한 확장과 외부 프로그램을 하이브와 연동할 수도 있다.

 

하이브에서 데이터베이스 개념은 단지 테이블의 카탈로그 또는 네임스페이스이다. 데이터베이스는 논리적인 그룹을 구성할 수 있으며 대규모 작업시 동일한 테이블명의 충돌을 방지할수도 있다. 데이터베이스를 별도로 지정하지 않으면 기본 데이터베이스(default)를 사용한다. 아래 스크립트는 데이터베이스를 생성한다.

create database testdb;

 

create database if not exists testdb;

  

하이브는 각 데이터베이스마다 별도의 디렉터리를 생성하고 테이블을 그 하위 디렉터리에 저장한다. 데이터베이스 디렉터리는 “hive.metastore.warehouse.dir” 속성에 설정한 최상위 디렉터리 밑에 생성된다.  아래 스크립트는 데이터베이스 생성시 디렉터리 위치를 변경할 수 있다.

create database testdb

location '/user/data/testdb';

 

현재 생성되어 있는 데이터베이스의 디렉터리 경로를 확인하려면 describe 명령을 사용한다.

describe testdb;

 

데이터베이스 삭제 명령은 drop 명령을 사용한다. 하이브는 가본적으로 테이블이 있는 데이터베이스를 삭제하는것을 허용하지 않는다. 테이블을 모두 삭제 후 데이터베이스를 삭제 또는 cascade 명령을 사용하여 테이블이 존재하는 데이터베이스를 삭제할 수 있다. 데이터베이스가 삭제되면 해당 디렉터리도 같이 삭제 된다.

drop database if exists testdb cascade;

 

 

 

2020-06-16 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 데이터베이스, HiveQL, 하이브쿼리

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

HDFS 저장소에 데이터를 압축해서 저장하면 더 좋을까?  (0) 2020.06.23
Hive 테이블  (0) 2020.06.23
Hive 텍스트파일 인코딩  (0) 2020.06.12
Impala Connection refuse Error  (0) 2020.06.12
Hive 데이터 타입  (0) 2020.06.09

Hive 텍스트파일 인코딩

 

·       Version : Hive

 

텍스트 데이터의 필드를 구분할때, 탭(TAB) 또는 콤마(,)를 많이 사용한다. 이러한 일반적인 구분 기호는 데이터안에 콤마나 탭이 포함되어 있을 경우 전체 데이터 필드가 맞지 않는문제가 발생할 수 있어 주의해야 한다. 하이브도 탭 또는 콤마 같은 필드 구분자를 지원하지만 앞에서 말한 이유 때문에 일반적으로 잘 사용하지 않는 여러 제어 문자를 기본 구분 기호로 사용한다. 아래표는 하이브에서 제공하는 구분기호이다. 만약 필드에서 탭으로 분리하려면 ‘\t’를 사용하고, 콤마의 경우 ‘,’를 사용한다.

구분기호

설명

\n

레코드 줄 바꿈

^A

모든 컬럼을 분리한다. CREATE TABLE 문에서 명시적으로 지정할때는 8진수 코드 ‘\001’을 사용한다.

^B

ARRAY, STRUCT, MAP의 Key-Value 요소를 분리한다. CREATE TABLE 문에서 명시적으로 지정할때는 8진수 코드 ‘\002’를 사용한다.

^C

MAP의 Key-Value 에서 키를 관련된 값과 분리한다. CREATE TABLE 문에서 명시적으로 지정할때는 8진수 코드 ‘\003’을 사용한다.

 

CREATE TABLE HIVE_TABLE (

       COL1 STRING,

       COL2 FLOAT,

       COL3 ARRAY<STRING>,

       COL4 MAP<STRING, FLOAT>,

       COL5 STRUCT<C_1:STRING, C_2:STRING, C_3:STRING, C_4:INT>

)

ROW FORMAT DELIMITED

FIELDS TERMINATED BY '\001'

COLLECTION ITEMS TERMINATED BY '\002'

MAP KEYS TERMINATED BY '\003'

LINES TERMINATED BY '\n'

STORED AS TEXTFILE;

 

일반적으로 데이터베이스는 스키마 구조를 가지고 있으며, 데이터를 입력할때 스키마 구조에 맞춰서 입력한다. 이것을 ‘schema on write’라고 부른다. 하지만 하이브는 저장소에 대해 이런 쓰기 제어 구조를 가지고 있지 않으며 데이터를 읽을때 스키마를 적용한다. 이것을 ‘schema on read’라고 한다. 그래서 스키마와 파일의 내용이 일치하지 않으면 하이브는 그 값을 모두 null로 채운다. 만약 숫자 필드가 정의되어있는데 문자열을 만나면 하이브는 null을 반환한다.

 

 

 

2020-06-11 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 텍스트파일 인코딩, 필드 구분, 문자열 구분

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive 테이블  (0) 2020.06.23
HiveQL과 Hive 데이터베이스  (0) 2020.06.17
Impala Connection refuse Error  (0) 2020.06.12
Hive 데이터 타입  (0) 2020.06.09
HDFS 데이터 저장소에는 RAID구성이 필요할까  (0) 2020.06.08

Impala Connection refuse Error

-          Couldn't open transport for hd-master:26000 (connect() failed: Connection refused)

 

·       Version : CDH 6.3

 

파이썬의 pyimpala를 사용하여 Hadoop Impala에 데이터를 입력하는 클라이언트가 있는데, 어느날부터 아래와 같은 오류를 출력하며 데이터가 입력되지 않았다.

InternalException: Error requesting prioritized load: Couldn't open transport for hd-master:26000 (connect() failed: Connection refused)

Error making an RPC call to Catalog server.

 

위와 같은 오류 메시지가 발생하였을경우,  impala 환경설정에서 Java Heap Size of Catalog Server in Bytes사이즈를 넉넉하게 할당함으로써 문제를 해결할 수 있다.

Java Heap Size of Catalog Server in Bytes

 

 

2020-06-11 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, 임팔라, Impala, Connection refuse, 임팔라 커넥션 오류

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

HiveQL과 Hive 데이터베이스  (0) 2020.06.17
Hive 텍스트파일 인코딩  (0) 2020.06.12
Hive 데이터 타입  (0) 2020.06.09
HDFS 데이터 저장소에는 RAID구성이 필요할까  (0) 2020.06.08
Hive에서 하둡(dfs)명령 실행  (0) 2020.05.19

Hive 데이터 타입

 

·       Version : Hive

 

Hive는 여러 크기의 정수형과 부동소수점, 불린형과 임의의 길이를 가지는 문자열, TIMESTAMP, BINARY 타입등을 제공한다. 각각의 데이터형은 자바로 구현되어 있어 자바 데이터 타입과 동일하게 하이브에서 사용된다.

타입

크기

리터럴 문법 예제

TINYINT

1바이트 정수형

20

SMALLINT

2바이트 정수형

20

INT

4바이트 정수형

20

BGINT

8바이트 정수형

20

BOOLEAN

TRUE 또는 FALSE

TRUE

FLOAT

단정도 부동 소수점

3.14159

DOUBLE

배정도 부동 소수점

3.14159

STRING

문자의 시퀀스, 또는 문자열  설정가능. 작은 따옴표 및 큰따옴표 사용가능

‘Hello Hive’, “Hello Hive”

TIMESTAMP

정수형, 부동소수점, 문자열형

유닉스 TIMESTAMP, JDBC 호환 java SQL Timestamp 포맷. 소수점 9자리(nano second) 까지 가능

BINARY

바이트 배열의 형태 지원

 

 

BYNARY 데이터형은 관계형 데이터베이스의 VARBINARY와 비슷하지만 관계형 데이터베이스는 BLOB 데이터 형은 별도의 저장소에 보관하는반면에, 하이브는 BINARY 데이터형의 데이터를 레코드에 모두 저장한다.

 

하이브는 다른 SQL 호환 언어처럼, 데이터형 이름의 대소문자 구분을 무시한다. 하지만 SQL 에서 일반적으로 지원하는 최대 허용 길이를 갖는 “문자배열”을 지원하지 않는다. 관계형 데이터베이스와 목적이 다를뿐더러 다양한 파일 포맷을 지원해야 하기 때문에 필드를 구분할 수 있는 구분기호에 의존한다. 또한 하둡 및 하이브는 디스크의 읽기, 쓰기 성능 최적화를 강조하기 때문에 컬럼값이 길이를 고정하는것은 상대적으로 중요하지 않다.

 

하이브에서 단점도 부동소수점(FLOAT)와 배정도 부동소수점(DOUBLE) 컬럼을 비교하거나, 정수형 값을 비교하는 쿼리를 실행하면, 묵시적으로 두 개의 데이터 타입중에 더 큰 크기의 데이터  타입으로 변환하여, 동일한 데이터 타입으로 만든 후 비교한다. 문자열의 값을 숫자로 해석하려는 경우 명시적으로 다른 데이터형으로 변환하여 사용할 수 있다.

 

하이브는 struct, map, array 같은 컬럼을 지원한다. 또한 컬렉션 데이터 타입의 이름 대소문자 구분을 무시한다.

타입

설명

리터럴 문법 예제

STRUCT

C 의 구조체나 객체와 유사. 각 필드는 점 표기법으로 사용

struct(‘Sungwook’, ‘Kang’)

MAP

Key-Value 처럼 필드를 배열 표기법으로 사용

map(‘first’,’Sungwook’,’last’,’Kang’)

ARRAY

0으로 시작하는 정수로 색인할 수 있는 동일한 데이터형의 순차 시퀀스

array(‘Sungwook’, ’Kang’)

 

하이브는 키 개념을 가지고 있지 않다. 하지만 색인 테이블은 사용이 가능하다. 컬렉션 데이터 타입은 자바의 제네릭(generics) 문법 규칙을 따를 것에 유의해야한다. 예를들어 MAP<STRING, FLOAT>의 모든 키는 STRING 데이터 타입을 가지고, 모든 값은 FLOAT 이다. ARRRAY <STRING>도 마찬가지로 모든 아이템은 STRING 데이터 타입을 가진다. STRUCT는 서로 다른 데이터 타입을 섞어 사용할 수 있으나 STRUCT 안에서 선언된 위치는 고정된다.

 

 

 

[참고자료]

·       Hive Data Types : https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Types

 

 

2020-06-08 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 데이터 타입

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive 텍스트파일 인코딩  (0) 2020.06.12
Impala Connection refuse Error  (0) 2020.06.12
HDFS 데이터 저장소에는 RAID구성이 필요할까  (0) 2020.06.08
Hive에서 하둡(dfs)명령 실행  (0) 2020.05.19
ZooKeeper 옵저버와 CLI  (0) 2020.05.19

HDFS 데이터 저장소에는 RAID구성이 필요할까

 

·       Version : HDFS

 

HDFS 클러스터에서 데이터노드 저장소 용도로 RAID(Redundant Array of Independent Disks)를 사용하면 이득이 있을까?

결론부터 이야기하면 이득이 없다. HDFS는 노드간에 복제하는 기능이 있어 RAID가 제공하는 중복성(redundancy)은 필요하지 않기 때문이다. 또한 성능 향상을 위해 흔히 사용하는 RAID 0 (Striping)은 모든 디스크에 DHFS 블록을 연속적으로 배열하는 HDFS의 JBOD (Just a Bunch of Disks)방식보다 느리다는 것이 밝혀졌다. 그 이유는 RAID 0의 읽기/쓰기 동작의 경우 RAID 배열에서 가장 느린 디스크의 속도에 의해 제한을 받기 때문이다. 반면 JBOD에서는 디스크 동작들이 독립적이며 이러한 동작들의 평균속도는 가장 느린 디스크보다 빠르다. 실제로 동일한 제조사의 동일 모델의 디스크여도 큰 편차를 보이는 경우가 있다. 또한 JBOD 환경에서는 디스크 하나가 고장날 HDFS는 고장난 디스크 없이도 계속해서 동작할 수 있지만  RAID는 하나의 디스크 고장이 전체 디스크 배열을 불능 상태로 만들 수 있다. 이 뜻한 RAID 0에서 디스크 한개의 불량이 노드 하나를 통째로 불능 상태로 만들 수 있다는 뜻이다.

 

그렇다면  HDFS에서 RAID는 정말 필요 없을까?  네임노드에는 RAID 1 (Mirroring)으로 구성하여 가용성을 높일 수 있다.

 

디스크 목록을 dfs.data.dir 매개변수에 전달하면 하둡은 사용 가능한 모든 디스크를 사용한다. 디스크가 오프라인 상태가 되면 사용가능 대상에서 제외한다. 그리고 제외된 디스크가 다시 사용가능한 상태가 되었는지 검사하지는 않는다.

 

Note : 하둡 시스템에 사용하는 메모리는 ECC 메모리를 사용하도록 한다. ECC 메모리가 아닌 경우 하듭 클러스터에서 체크섬 오류가 발생할 수 있다.

 

 

[참고자료]

 

 

2020-06-07 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, 하둡 RAID, 분산 처리, 분산 저장

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Impala Connection refuse Error  (0) 2020.06.12
Hive 데이터 타입  (0) 2020.06.09
Hive에서 하둡(dfs)명령 실행  (0) 2020.05.19
ZooKeeper 옵저버와 CLI  (0) 2020.05.19
Hive에서 쉘 명령 실행  (0) 2020.05.18

Hive에서 하둡(dfs)명령 실행

 

·       Version : Hive

 

하이브(Hive)에서 하둡(dfs) 명령을 수행할 수 있다. 하이브에서 하둡 명령어를 사용하는 방법은 dfs 를 사용하고 마지막에 세미콜론(;)을 입력한다.

dfs -ls /;

 

 

하이브에서 dfs 명령을 사용하는것이 배시쉘에서 hadoop dfs 로 동일한 명령을 사용하는것보다 효율적이다. 하이브는 현재 프로세스에서 명령을 수행하는 반면, 배시쉘을 사용할때에는 새로운 jvm 인스턴스를 구동하여 명령을 실행하기 때문이다. 아래와 같이 -help 를 사용하면 dfs에서 제공하는 도움말을 볼 수 있다.

 

 

 

 

 

2020-05-18 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, 하이브, 하둡 쿼리, 하이브쿼리, hive query

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive 데이터 타입  (0) 2020.06.09
HDFS 데이터 저장소에는 RAID구성이 필요할까  (0) 2020.06.08
ZooKeeper 옵저버와 CLI  (0) 2020.05.19
Hive에서 쉘 명령 실행  (0) 2020.05.18
ZooKeeper 클라이언트 요청 처리  (0) 2020.05.18

ZooKeeper 옵저버와 CLI

 

·       Version : Zookeeper

 

주키퍼는 리더가 모든 서버에 쓰기 요청을 보내고 과반수 이상의 응답을 받은 후 처리한다. 주키퍼 서버에 연결되는 클라이언트수가 많으면, 서버를 확장하여 읽기에 대한 부하분산이 가능하다. 하지만 서버가 늘어날 경우, 쓰기 연산 발생시 전체 서버에 대해서 응답을 기다려야 하기 때문에, 그만큼 성능 저하가 발생할 수 있다. 이러한 문제를 해결하기위해 옵저버 개념이 도입되었다.

옵저버는 투표에 참여하지 않는 서버를 뜻한다. 리더는 쓰기 요청을 받고 각 서버로 쓰기에 대한 응답을 보내고 받을때, 옵저버 서버에는 보내지 않는다. 그리고 일반 서버의 투표에 의한 정상 처리인 경우, 쓰기 요청을 옵저버로 보내 옵저버의 로컬 메모리에 데이터를 기록한다. 서버가 옵저버로 동작하게 하려면 옵저버 서버의 환경설정에 아래와 같은 값을 입력한다.

peerType=observer

 

그리고 모든 서버의 환경 설정에 옵저버 서버의 정보를 추가하여 투표 요청을 하지 않도록 한다. 아래 예시는 192.168.0.2 서버가 observer 서버라는 정보를 환경 설정에 등록한 것이다.

Server.1:192.168.0.2:2181:3181:observer

 

주키퍼는 CLI(Command Lind Interface)기반의 쉘 프로그램을 제공한다. 클라이언트 쉘을 실행하려면 아래와 같은 명령을 입력 한다.

bin.zkCli.sh ?server 127.0.0.1:2181

 

아래표는 CLI 명령어와 설명이다.

command

Description

connect host:port

주키퍼 서버에 접속한다.

get path

노드에 저장된 데이터를 보여준다.

ls path

노드의 자식 노드 목록을 조회한다.

set path data

노드의 데이터를 수정한다.

delquota [-n|-b] path

노드의 사용 용량 설정 정보를 삭제 한다.

quit

쉘을 종료 한다.

printwatches on|off

와처에서 받은 이벤트 정보를 콘솔에 출력할지 여부를 설정한다.

create [-s][-e] path data acl

노드를 생성한다. -s옵션은 순차노드를 생성, -e는 임시노드를 생성한다.

stat path

패스의 상태 정보를 조회한다.

close

주키퍼 접속을 종료한다.

ls2 path

ls와 stat명령을 동시에 수행시킨 내용을 보여준다.

history

수행한 명령어 목록을 보여준다.

listquota path

패스에 설정된 용량 설정 정보를 보여준다.

setAcl path acl

패스에 권한을 설정한다.

getAcl path

패스의 ACL 목록을 조회한다.

sync path

패스에 sync 명령을 보낸다.

redo cmdno

쉘에서 이전에 실행했던 명령을 다시 실행한다.

addauth scheme auth

현재 오픈되어 있는 쉘의 주키퍼 연결에 인증 정보를 추가한다.

delete path

패스를 삭제한다.

 

 

 

2020-05-18 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, 주키퍼, Zookeeper, 분산 코디네이션

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

HDFS 데이터 저장소에는 RAID구성이 필요할까  (0) 2020.06.08
Hive에서 하둡(dfs)명령 실행  (0) 2020.05.19
Hive에서 쉘 명령 실행  (0) 2020.05.18
ZooKeeper 클라이언트 요청 처리  (0) 2020.05.18
ZooKeeper 멀티 서버 구성  (0) 2020.05.17

Hive에서 쉘 명령 실행

 

·       Version : Hive

 

하이브(Hive)에서 간단한 배시 쉘(bash shell) 명령을 수행할 수 있다. 더이상 쉘을 수행하기 위해서 하이브 CLI를 빠져나갈 필요가 없다. 하이브에서 쉘을 실행하는 방법은 ! 뒤에 쉘 명령어를 입력하고, 명령어 마지막에 세미콜론(;)을 입력한다. 아래 예시는 간단히 에코로 문자를 반환하는 것과, 현재 경로를 표시한다.

! /bin/echo “Hello”;

! pwd;

 

 

쉘 명령을 실행할때, 사용자 입력이 필요한 명령은 실행해서는 안된다. 쉘 파이프와 파일 글로빙(globbing)은 동작하지 않는다. 예를들어 ! ls *.hql 명령은 *.hql 이름을 가지는 하나의 파일만 찾아줄뿐, .hql 확장자를 가진 모든 파일을 찾아서 보여주지는 않는다.

 

 

2020-05-17 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, 하이브, 하둡 쿼리, 하이브쿼리, hive query

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive에서 하둡(dfs)명령 실행  (0) 2020.05.19
ZooKeeper 옵저버와 CLI  (0) 2020.05.19
ZooKeeper 클라이언트 요청 처리  (0) 2020.05.18
ZooKeeper 멀티 서버 구성  (0) 2020.05.17
ZooKeeper 리더선출과 데이터 ACID 정책  (0) 2020.05.14

ZooKeeper 클라이언트 요청 처리

 

·       Version : Zookeeper

 

주키퍼의 모든 서버는 클라이언트로 부터 읽기, 쓰기 요청을 받을 수 있다. 읽기 요청은 클라이언트가 접속한 서버의 로컬 데이터를 이용한다. 쓰기 요청을 받은 서버는 리더 서버로 리다이렉트 한다.

 

 

리더는 새로운 트랜잭션아디이(zxid)를 생성한 후 모든 팔로워에게 쓰기 요청을 보낸다. 쓰기 요청을 받은 서버는 자기의 로컬 트랜잭션 로그 파일에 처리 내역을 저장하지만 실제 메모리에는 반영하지 않고, 리더로 ACK 신호를 보낸다. 리더는 과반수 이상의 팔로워로부터 ACK 신호를 받으면 메모리에 반영하라고 하는 커밋 신호를 보낸다. 커밋 신호를 받은 팔로워는 자신의 메모리에 쓰기 요청된 정보를 반영한다. 팔로워 중 클라이언트로 부터 요청을 받은 서버는 클라이언트로 처리 결과를 보낸다. 아래 그림에서 순서를 쉽게 확인할 수 있다.

 

 

 

 

주피커는 이벤추얼한 정합성을 가지고 있는데, 동일 데이터에 대해 쓰기나 읽기가 서로 다른 클라이언트에서 서로 다른 주키퍼 서버에 접속하면 읽기 연산을 수행하는 클라이언트에는 반영되기 전의 데이터가 읽혀질 가능성이 크다. 그래서 강한 정합성을 필요로 하는 애플리케이션이나 기능에서는 sync() 메소드를 이용하여 해결할 수 있다. Sync() 메소드는 파라미터로 전달된 패스에 대해 모든 주키퍼 서버가 처리 중인 쓰기 연산을 로컬 메모리에 모두 반영하는것을 보장하는 메소드다.

 

주키퍼 서버에 장애가 발생하면 클라이언트 측에서는 Disconnected 이벤트가 발생하고, 클라이언트 라이브러리에서는 자동으로 다른 서버로 접속을 시도한다. 주키퍼 클라이언트는 자신이 실행한 최종 트랜잭션 아이디(zxid)를 메모리에서 관리한다. 주키퍼 서버는 자신의 트랜잭션아이디보다 큰 값을 가지고 있는 클라이언트의 접속 요청은 거절한다.

 

 

 

2020-05-17 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, 주키퍼, Zookeeper, 분산 코디네이션

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

ZooKeeper 옵저버와 CLI  (0) 2020.05.19
Hive에서 쉘 명령 실행  (0) 2020.05.18
ZooKeeper 멀티 서버 구성  (0) 2020.05.17
ZooKeeper 리더선출과 데이터 ACID 정책  (0) 2020.05.14
Zookeeper 세션(Session)  (0) 2020.05.13

ZooKeeper 멀티 서버 구성

 

·       Version : Zookeeper

 

주키퍼를 멀티서버로 구성하려면 각 서버에 멀티서버에 대한 정보를 추가해야 한다. 주피커 설치 디렉터리에서 conf/zoo.cfg 파일에 아래와 같이 정보를 입력 한다.

tickTime=2000

initLimit=10

syncLimit=5

dataDir=/data/zookeeper

clientPort=2181

 

server.1=192.168.1.1:2888:3888

server.2=192.168.1.2:2888:3888

server.3=192.168.1.3:2888:3888

 

zoo.cfg 파일에서 서버 수 만큼 server.x=IP:Port:Port 를 입력한다. server는 예약어이며, x는 서버를 식별하는 ID로 숫자를 입력한다. IP는 각 서버의 IP를 입력하고, 첫번째 포트는 리더에 접속하기 위한 포트이며, 두번째 포트는 리더를 선출하는데 사용되는 포트이다. 위에서 생성한 설정 파일을 각 서버에 복사하고, 각 서버의 데이터 디렉터리에 myid 라는 파일을 만들어서 해당 서버의 아이디를 입력한다. 아래 예제는 서버1에서 데이터 경로가 /data/zookeeper 를 사용하였다.

vi /data/zookeeper/myid

1 #숫자 입력 후 종료

 

설정이 완료되고 각 서버에서 주키퍼 서버를 시작하면, 멀티서버 주키퍼 클러스터로 동작한다. 멀티서버 구성에는 실행되고 있는 서버의 수가 과반수(등록된 서버 수 + 1)/2) 이하이면 동작하지 않는다. 예를들어 클러스터가 3대일때, 2대의 서버 장애가 발생하면 서비스가 중지 된다. 아래 스크립트는 주키퍼 서버를 시작하는 명령어이다.

bin/zkServer.sh start

 

각 서버에서 주키퍼를 시작하면 첫번째 서버 시작시 오류 메시지가 나타나는데, 멀티서버로 설정된 주키퍼는 설정 파일에 있는 다른 서버에 접속해 리더 선출과정을 거쳐야 정상으로 작동되기 때문에 설정 파일에 등록된다른 서버를 시작하면 경고가 발생하지 않는다. 서버 메시지에서 “LEADING” 메시지가 표시된 서버가 리더로 선출된 서버이다.

 

아래 표는 주키퍼 환경 설정에 대한 속성과 설명이다.

속성

설명

clientPort

클라이언트로 요청을 받기 위한 포트

dataDir

메모리에 있는 데이터를 스냡샷으로 저장하는 디렉터리 경로

tickTime

주키퍼에서 사용되는 기본 시간 단위. 최소 세션타임아웃은 이 값의 2배이다.

dataLogDir

트랜잭션 로그를 저장하는 디렉터리. 특별한 설정을 하지 않으면 dataDir에 저장. 성능상 다른 디스크의 디렉터리에 분리하는것이 좋다.

globalOutstandingLimit

큐가 많이 쌓이게 되면 메모리 부족으로 정상 작동하지 못하게 된다. 큐 사이즈보다 더 많은 요청을 받지 못하도록 설정하는 값이며 기본값은 1000 이다.

preAllocSize

트랜잭션 로그 저장을 위해 미리 할당 받은 파일 사이즈. 기본값은 64MB로 스냅샷을 자주 만들경우 이 값을 줄여서 사용한다.

snapCount

트랜잭션 회수가 snapCount 값 이상되면 메모리 내용을 스냅샷 파일로 저장하고 새로운 트랜잭션 파일을 만든다.

traceFile

이 설정이 켜져 있으면 클라이언트 요청을 traceFile.year.month.day 형태의 파일명에 저장한다. 주로 디버그 용도로 활용하며 설정이 켜져 있으면 오버헤드가 발생한다.

maxClientCnxns

클라이언트로 부터 동시에 접속할 수 있는 연결 수를 지정. 연결수는 클라이언트 IP당 개수이며, 기본값은 10이며 0은 무제한이다.

clientPortBindAddress

서버의 네트워 카드 및 IP가 여러개 일때, 클라이언트가 접속할 서버의 IP주소나 호스트명을 지정한다. 기본값은 모든 IP 주소, 네트워크 카드에 접속 가능하다.

minSessionTimeout

최소 세션 타임아웃이며 단위는 밀리세컨드 (ms)이다. 기본값은 tickTime *2 이다.

maxSessionTimeout

최대 세션 타임아웃이며 단위는 밀리세컨드(ms)이다. 기본값은 tickTime *20 이다.

electionAlg

리더를 선출하는 알고리즘. 기본값은 3이다.
0 : UDP 기반의 기본 리더 선출

1 : UDP 기반의 비인증 빠른 리더 선출(FastLeaderElection)

2 : UDP 기반의 인증 빠른 리더 선출

3 : TCP 기반의 빠른 리더 선출

initLimit

초기에 팔로워가 리더에 접속하거나 데이터를 동기화 시키기 위한 시간으로 단위는 tickTime 이며 initLimit * tickTime으로 계산된다.

leaderServes

클라이언트의 요청을 리더가 받을 것인지에 대한 설정 기본값은 yes 이다. 쓰기 연산이 많은 경우, 리더가 클라이언트 요청을 받게되면 쓰기 연산에 대한 처리와 클라이언트로 부터의 읽기,쓰기 연산을 동시에 하게 되면서 많은 오버헤드가 발생한다. 이 경우 no로 설정하는 것이 좋다.

server.x=ip:port:port

멀티 서버를 구성할 경우 서버 목록 지정. 앞의 포트는 리더에 접속하기 위한 포트이며, 두 번째는 리더를 선출하는 포트이다.

syncLimit

Sync를 수행하는 시간으로 Tick기준이다. 이 시간동안 sync가 안되면 해당 팔로워는 클러스터에서 제외된다.

group.x=id[:id]

계층적 정족수를 설정한다 x는 그룹 아이디로 숫자 값을 설정한다. = 이후에는 그룹에 포함될 서버 아이디를 입력하며 구분자는 : 이다.

weight.x= n

서버간 정족수 투표를 할때 서버의 가중치를 설정. X는 서버 아이디이며 n은 가중치 값을 설정한다. 기본값은 1이다.

 

주키퍼는 자바로 개발되었으며 JVM(Java Virtual Machine)환경에서 운영된다. 그래서 JVM에 대한 설정도 고려해야한다. JVM은 GC(Garbage Collection)을 수행할때 모든 스레드가 멈추게 되는 경우도 있다. GC가 수행되는 모든 모든 스레드가 동작하지 못하게 되면 예기치 못한 타임아웃이 발생하고, 클라이언트, 서버 모두 정상적인 상황임에도 세션을 유지하지 못하는 상태가 발생한다. 주키퍼 서버를 실행할 때 GC옵션을 아래와 같이 설정하며 GC가 수행중에도 스레드가 동작할 수 있게 한다.

-XX:ParallelGCThreads=8 -XX:+UseConcMarkSweepGC

 

이 외에도 성능이 저하되지 않도록 JVM 힙 메모리 스왑이 발생하지 않도록 해야한다.

 

[참고자료]

·       Clustered (Multi-Server) Setup : https://zookeeper.apache.org/doc/r3.3.2/zookeeperAdmin.html#sc_zkMulitServerSetup

·       How To Install and Configure an Apache ZooKeeper Cluster on Ubuntu 18.04 : https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-an-apache-zookeeper-cluster-on-ubuntu-18-04

·       16 Tuning JVM Garbage Collection for Production Deployments : https://docs.oracle.com/cd/E40972_01/doc.70/e40973/cnf_jvmgc.htm#autoId0

 

 

 

2020-05-16 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, 주키퍼, Zookeeper, 분산 코디네이션

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive에서 쉘 명령 실행  (0) 2020.05.18
ZooKeeper 클라이언트 요청 처리  (0) 2020.05.18
ZooKeeper 리더선출과 데이터 ACID 정책  (0) 2020.05.14
Zookeeper 세션(Session)  (0) 2020.05.13
Zookeeper 접근제한(Access Control List)  (0) 2020.05.11

SRE (Site Reliability Engineering) 역할

 

SRE(Site Reliability Engineering)은 조직이 해당 시스템, 서비스 및 제품에서 적절한 수준의 안정성을 달성하도록 지원하는 엔지니어링 분야로,  실패 비용을 줄임으로써, 신속하게 올바른 방향으로 이동할 수 있도록 지원한다. 이 과정에서 SRE는 자동화, 수치화, 프로세스화를 진행한다. 특히 SRE 관점은 “근본적인 문제는 소프트웨어의 문제”라고 정의하고 접근한다. SRE가 하는 일은 크게 5가지 정도로 나누어 볼 수 있다.

 

[Metric & Monitoring]

모니터링 지표를 정의하고, 정의된 지표를 모니터링 시스템으로 구성한다. 인사이트를 통해 시스템이 안정적인 상황과 또는 장애가 나는 지표는 무엇인지, 왜인지? 그리고 이러한 지표를 어떻게 개선할 수 있는지를 고민한다.기본적으로 SRE에서 가장 중요한 부분은 모든것을 데이타화하고, 의사결정을 데이타를 기반으로 한다는 것이다.

 

[Capacity Planning]

시스템을 운영하는데 필요한 하드웨어 리소스(서버, CPU,메모리,디스크,네트워크 등)을 확보하는 작업을 진행한다. 수집된 데이터를 통해 서비스 안정성에 필요한 하드웨어를 미리 예측하는 것이다. SRE 엔지니어는 자원 활용의 효율성 측면에서 소프트웨어의 성능을 그리고 안정성 측면에서 소프트웨어의 안정성을 함께 볼 수 있어야 한다.

 

[Change Management]

대부분의 시스템 장애의 원인은 대략 70%가 시스템에 변경을 주는 경우에 발생한다. SRE는 점진적인 배포와 변경을 관리한다.배포 또는 장애시 빠르고 정확하게 해당 문제를 찾아낼 수 있도록 해야하며 마지막으로 문제가 발생하였을때 빠르게 롤백할 수 있도록 해야한다.

 

[Emergency Response]

일반적으로 장애 복구 단계에서 사람이 직접 매뉴얼로 복구를 하게 되면 장애 복구 시간이 더 많이 소요된다. 사람이 컨트롤을 하되 가급적이면 각 단계는 자동화 되는게 좋으며, 사람이 해야 하는 일은 되도록이면 메뉴얼화 되어 있는 것이 좋다. SRE는 자동화 뿐만아니라 메뉴얼, 프로세스를 함께 제공한다.

 

[Culture]

운영에 필요한 작업뿐만 아니라 SRE 문화를 전반적으로 만들고 지켜나가는 작업을 진행한다.  데이타에 기반한 합리적인 의사결정과 서로 비난하지 않고 장애 원인을 분석하고 이를 예방하는 포스트모템 문화, 그리고 책임을 나눠가지는 문화를 장려하고 선순환 구조를 만들 수 있도록 해야한다.

 

[참고자료]

·       IO116-Improving Reliability with Error Budgets, Metrics, and Tracing in Stackdriver : https://drive.google.com/file/d/1iOMaYIwlUBiGoG2mf8MFzl3EHy5xGJpq/view

·       Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템) : https://www.slideshare.net/deview/216sresearchreliabilityengineering

·       네이버 검색의 SRE 시스템 : https://d2.naver.com/helloworld/2047663

·       SRE(사이트 안정성 엔지니어링) 소개 : https://docs.microsoft.com/ko-kr/learn/modules/intro-to-site-reliability-engineering/

 

 

 

2020-05-13 / Sungwook Kang / http://sungwookkang.com

 

SRE, Site Reliability Engineering, DevOps, 사이트안정성엔지니어링, 사이트신뢰성엔지니어링, 시스템운영, SiteReliability, 서비스운영, 모니터링자동화, 시스템운영자동화

저작자표시 비영리 변경금지

'SW Engineering > DevOps, SRE' 카테고리의 다른 글

Kubernetes 장점  (0) 2021.07.31
Kubernetes 마스터 노드, 워커 노드  (0) 2021.07.29
SRE (Site Reliability Engineering)  (0) 2020.05.11
Docker Network  (0) 2019.03.27
Docker Compose-여러개의 컨테이너를 설정하고 생성하기  (0) 2019.03.27

ZooKeeper 리더선출과 데이터 ACID 정책

 

·       Version : Zookeeper

 

주키퍼를 사용하여 분산 시스템을 관리할 경우 주키퍼는 반드시 멀티 서버로 운영해야한다. 멀티서버로 운영할 경우 네트워크 단절, 트랜잭션 타임아웃등의 상황에 대비해야한다. 특히 일부 주키퍼 서버 장애발생시 해당 서버에 접속된 클라이언트의 세션에 대한 처리, 장애복구 후 서버간 데이터 동기화 등이 고려되어야 한다. 주키퍼는 이러한 문제를 자체적으로 해결하기 때문에 마스터 서버 구성시 주키퍼를 사용함으로써 상대적으로 쉽게 해결할 수 있다.

 

주키퍼를 멀티서버로 설치하면 모든 서버는 동일한 데이터를 가지고 있다. 클라이언트는 모든 서버에 접속해서 읽기, 쓰기 요청을 보낼수 있다. 읽기 연산은 모든 데이터가 동기화 되어 있기 때문에 자체 서버에서 제공할 수 있지만, 쓰기연산은 특정 서버가 마스터 역할을 수행하면서 쓰기 작업이 정상적으로 수행되었는지 확인할 필요가 있다. 이러한 역할을 하는 서버를 리더(leader)라고 한다.

주키퍼는 클러스터내에서 자동으로 리더를 선출한다. 클러스터가 재시작되거나 장애가 발생하면 자동으로 리더를 선출하며 리더를 선출하는 방법 및 순서는 아래와 같다.

1.       각 서버는 자신의 현재 트랜잭션ID(zxid)와 자신을 후보자로 지명해 모든 서버로 전송

2.       각 서버는 트랜잭션 아이디를 받은 후 자신이 최대값이 아니면 다시 최대값을 갖고 있는 서버를 후보자로 지명하여 모든 서버에 전송

3.       과반수 이상의 서버로부터 후보자로 지명된 서버는 리더로 선출

4.       다른 서버는 팔로워(follower)로 동작

 

분산처리 시스템에서 ACID 속성중 정합성(Consistency) 독립성(Isolation)을 보장하는것은 쉽지 않다. 주키퍼는 데이터 저장시 아래와 같은 사항을 보장한다.

·       순차적 정합성(Sequential Consistency) : 주키퍼 클러스터에 저장되는 데이터는 강한 정합성(Strong Consistency)를 보장하지 않고, 이벤추얼 정합성(Eventual Consistency)을 보장한다. 이벤추얼 정합성은 일정 시간이 지나면 정합성이 맞춰지는 속성이다. 특정 클라이언트로부터 데이터 저장에 대한 요청이 있을때 , 분산되어 있는 주키퍼 서버에 반영되는 순서는, 클라이언트에서 전송된 요청 순서대로 처리되는것을 보장한다.

·       원자성(Atomic) : 전체가 수행되거나 전체가 실패되는 행위로, 부분적인 성공은 존재하지 않는다.

·       단일 이미지 뷰 제공 (Single System Image) : 클라이언트는 어떤 주키퍼 서버에 접속하더라도 동일한 데이터 뷰를 제공 받는다.

·       안정성 (Reliability) : 주키퍼에 저장된 데이터는 클라이언트의 명시적인 호출에 의해 수정되지 않는한 영속성을 가지고 있다.

 

 

 

2020-05-13 / Sungwook Kang / http://sungwookkang.com

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, 주키퍼, Zookeeper, 분산 코디네이션

저작자표시 비영리 변경금지

'SW Engineering > Hadoop' 카테고리의 다른 글

ZooKeeper 클라이언트 요청 처리  (0) 2020.05.18
ZooKeeper 멀티 서버 구성  (0) 2020.05.17
Zookeeper 세션(Session)  (0) 2020.05.13
Zookeeper 접근제한(Access Control List)  (0) 2020.05.11
ZooKeeper Stat Structure  (0) 2020.05.08

+ Recent posts

티스토리툴바