2020-07-04 Big Bear Lake Camping (빅베어 호수 캠핑)

-      Serrano campground

 

 

202074, LA에서 약 2시간 거리인 빅베어 호수(Big Bear Lake)로 캠핑을 떠낫다. 지난 캠핑을 다년온후 1주일만에 다시 떠나는 캠핑이어서 그런지, 쉽게 준비가 되었다. 우스갯 소리로, “삼대가 덕을 쌓아야 74(미국 독립 기념일)에 스팟을 예약할 수 있다고 했는데, 매일 같이 예약 사이트를 리프레시 하면서 취소된 스팟을 잡을 수 있었다. 그것도 매우 좋은 자리로!

12일 일정으로 캠핑을 하였고, 낮에는 매우 더우면서도 밤에는 매우 추웠으며(고도 7000ft), 일주일 정도 머무르면서 호숫가 산책과 생각하는 시간을 가지고 싶은 장소였다. 특히 겨울에는 눈이 많이 오는 지역으로 다시 한번 겨울에 방문해야겠다는 생각이 들었다.

 

빅베어 호수에 아래쪽으로 위로 도는 방식으로 한바퀴 돌면서 캠프그라운드로 이동하였다. 아래 위치는 Boulder Bay Park로 많은 사람들이 카약, 보트 등 다양한 수상 레저를 즐기고 있었다. COVID19 임에도 정말 많은 사람이 있었으며, 마스크를 쓰고 있지않아 재빨리 다른 장소로 이동하였다. (마스크는 유일하게 우리 가족만 쓰고 있었던듯)

 

 

캠프사이트로 이동하는길에 반대편 저 멀리 스키장이 보였다. 빅베어는 겨울에 눈이 1미터이상 오기도 하기 때문에, LA에서 스키를 즐길수 있는 가까운곳중 하나이다.

 

 

고도 7000ft (2133m)에 위차한 캠프그라운드, 하이브리드를 타고 올라오느라 차가 고생이 많다. 특히나 하이브리드 배터리가 소진된 시점에서는 정말 뒷차들에게 민폐였다. 캠핑 때문에 심히 차를 바꿔야 하나 고민까지 드는 순간이었다. (그래도 연비하나는 정말 탁월하니, 개스값 걱정없이 돌아다닐수 있는 장점이 있다.)

 

오전에 출발해서 점심 시간에 맞춰 도착 하도록 계획하였기에, 짐을 풀자마자 점심 준비부터!! 이번에 새로 구입한 2버너 스토브! 화력 짱! (부르스타 바이바이~)

 

점심은 역시 짜장면과 짬뽕 라면이죠! 그런데 고산지대여서 그런지 물이 잘 안끓습니다. 면이 익기도 전에 불어버리네요.

 

 

깨끗한 파란 하늘과 구름. 그리고 나무 그늘.

 

 

지난번 조슈아트리 캠핑과 너무 대비되는 모습입니다. 물론 조슈아 트리는 사막, 빅베어는 숲이라 분위기가 많이 다르겠죠.

 

 

미국은 전화가 안되는 지역이 많아서, 이동시 연락을 하기 위해서 (트레일이나 기타 용무로 이동시) 무전기를 준비하였습니다. 분명 설명서에는 22마일이라고 했는데, 실제 사용지 1마일 정도 밖에 안되네요. (반품할까 하다가 개당 2만원에 3개 구입했기에 그냥 쓰기로 하였습니다.)

 

차콜과  LA갈비, 새우등 다양하게 준비하였지만, 편하게 먹을 있는 삼겹살부터 시작했는데, 결국 삼겹살로 배가 불러, 나머지 음식은 그대로 다시 집으로 고고싱하였습니다. 삼겹살은 역시 철판이죠.

 

 

항상 기대되는 불멍타임. 고산지대여서 그런지, 해가 기울어갈때쯤부터 온도가 확 떨어집니다. 그래서 불을 일찍 피웠더니, 장작이 부족한 사태가 발생했네요. 항상 장작은 넉넉히 준비해야겠습니다.

 

 

이튿날 아침, 산책. 간밤의 추위는 흔적도 없이 사라졌으며 해가 뜨니, 온도가 급격히 빠르게 상승합니다. 기온차가 20도 이상 나는, 감기 걸리기 딱 좋은 환경이죠. 멀리 트레일을 가지 않아도, 캠핑 그라운드 내부에 아름다운 자전거 길이 있어서 산책하기 좋았습니다.

 

캠핑 그라운드에서 조금만 걸으면 볼 수 있는 빅베어 레이크와 천문대. 천문대를 가보진 못했는데, 그냥 눈으로도 밤하늘의 쏟아지는 별을 볼 수 있었습니다.(하지만 내가 방문했떤 날은 대보름으로 아주 달이 밝았습니다.)

 

 

 

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

 

LA 여행, 서부 여행, 미국 여행, 빅베어, Big Bear, Big Bear Lake, 빅베어 호수, LA 캠핑, 미국캠핑, 서부캠핑

 

2020-06-27 Joshua Tree National Park Camping(조슈아트리 국립공원)

-      Indian Cove campground

 

 

2020627, COVID19로 인한 Stay at Home3개월이 지난 시점에서, 일부 사이트들이 오픈하면서 캘리포니아에 위치한 조슈아트리 국립공원에서 캠핑을 했다. 운좋게 사이트가 오픈한는날 캠핑을 계획하여서 바로 스팟을 예약할수 있었다. 어릴때 보이스카웃 외에 처음하는 캠핑이어서 (심지어 군대에서도 텐트에서 자본적이 없다.) 많은 준비와 함께 설레는 마음으로 캠핑을 기대하였으나, 사막의 뜨거운 기후와, 태풍급으로 부는 바람으로 인해서 험난하고도 기억에 남는 캠핑이었다.

 

국립공원 입구는 아닌데, (대부분 입구 간판을 찍었는데 난 바보같이 이걸 찍어왔다.) 가는 길에 만날 수 있는 간판이다.

 

Visit Center 가 오픈을 하였으나, 입장 제한 및 마스크 필수, 그리고 최대한 비대면 서비스로 운영되고 있어, 내부는 매우 한산하였다.

 

국립공원 내부의 Hidden Valley Trail이다. 조슈아 나무와 큰 바위들을 볼 수 있다.

 

푸른 하늘과 함께 화씨 106도에 이르는 뜨거운 태양과 사막의 건조한 공기는 건식 사우나에 있는듯 한 착각이 들었다.

 

파노라마 뷰

 

트레일을 도전하였으나, 너무나 뜨거운 태양에 일단 후퇴

 

 

공원의 트레이드마크인 조슈아 나무이다.

 

사막이라고 식물이 없는건 아니다. 일년 강수량이 기준치 미만이면 사막이라고 하는데, 많은 식물과 동물들이 살고 있다. (심지어 사막여우도 만났다. 로드킬 할뻔...)

 

 

 

Keys View

 

유명한 해골바위!

 

진짜 해골처럼 생겼다.

 

 

캠핑은 숯불에 구운 스테이크!! 역시 탄맛이 최고!

 

 

캠프 그라운드는 다양한 스팟중에 Indian Cove로 조슈아 트리 국립공원에서 다시 밖으로 나와서 뒷편으로 들어가야 한다. 큰 바위들에 둘러쌓여있었으며, 그룹 캠핑장이어서, 매우큰 스팟을 단도으로 사용 (거의 산과 산사이를 통째로 사용) 할 수 있었다.

 

 

어둠이 내리는 Indian Cove Campground.

 

 

조슈아트리하면 쏟아지는 밤하늘의 별이 포인트인데, 생각보다 달이 밝다. 아무런 불빛이 없는 곳에서 달이 이렇게 밝을줄 몰랐다. 그래도 쏟아지는 별, 별똥별을 볼 수 있다.

 

불멍타임!

 

태풍급의 바람으로 아수라장이 된 캠프사이트. 사진에는 어느정도 정리된 모습이지만 완전 초토화 되었다.

 

이틑날은 Barker Dam Trail 로 향하였다. 트레일 길이가 약 1마일 정도로 경사도 완만하다고 해서 도전했는데, 말그대로 힘들지는 않다. 그런데 한 낮의 뜨거운 태양은 살을 태울 정도다.

 

댐이라고 하지만 작게 물을 막아 놓은곳으로, 비가 거의 오지않아서 많이 마른 상태였다. 그래서 댐을 건너서 트래킹을 하였다.

 

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

 

LA 여행, 서부 여행, 미국 여행, 조슈아트리, Joshua Tree, LA 캠핑, 미국캠핑, 서부캠핑

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

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

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, 하둡 파일 시스템, 하둡 파일 압축, 분산 처리, 분산 저장

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

 

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, 임팔라 커넥션 오류

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, 하이브, 하이브 데이터 타입

NoSQL 특징및 분류

 

NoSQL 아래와 같은 속성을 가지고 있다.

·       Key-Value (-밸류) 또는 이를 응용한 데이터 모델

·       상대적으로 값싼 다수의 하드웨어를 이용

·       데이터는 분산된 노드에 파티션 복제되어 저장

·       데이터의 정합성 보다 단절내성에 대한 요구사항에 목적

·       2단계 커밋의 트랜잭션 수준보다, 정족수 기반의 트랜잭션 선호

 

데이터 모델은 아래와 같이 분류 있다.

·       Key-Value : 가장 단순한 데이터 모델로, 키와 바이너리 타입의 값을 저장소에 저장하는 구조이며, 데이터 조회또하 키로만 조회할 있다.

·       Column :  관계형 데이터베이스와 비슷하게 데이터는 컬럼에 저장되며, 트에빌, 컬럼등과 같은 스키마가 존재한다.

·       Document :  데이터의 저장단위가 문서가 되며 하나의 무서 내에는 여러 개의 필드와 필드에 대응하는 값이 있다.

·       Graph :  그래프에 있는 노드와 엣지를 저장하고 이를 쉽게 네비게이션할 있는 모델을 제공한다.

 

아래 표는 데이터 모델에 대한 대표적인 솔루션들이다.

Data Model

Solutions

Key-Value

Memcached, Dynamo, Volemort, Redis

Column

Google Bigtable, Cloudera, HBase, Hypertable, Cassandra

Document

MonhoDB, CouchDB

Graph

Neo4j, FlockDB, InfiniteGraph

 

대부분의 NoSQL 분산된 서버에 데이터를 저장한다. 이때 분산을 어떻게 하느냐에 따라 크게 메타데이터방식과 P2P 방식으로 분류할 있다.

·       메타데이터 : 데이터의 배치 정보가 중앙 집중적인 데이터 서버나 마스터 서버에 저장되어 있으며, 클라이언트는 데이터 연산을 위해 중앙(마스터) 서버를 경유해 실제 데이터를 처리할 서버로 접속하는 방식이다. 데이터 정보를 중앙에서 관리하기 때문에 관리가 편하며 맵리듀스와 결합하기도 용이하다. 단점으로는 중앙(마스터) 서버가 문제가 생기거나 데이터 관리 테이블에 문제가 발생하면 전체 데이터에 접근할 수가 없다. 대표적으로 빅테이블, 몽고DB 등이 방식을 사용한다.

·       P2P : 별도의 메타 정보가 없으며 해시 함수를 이용해 특정 키를 서비스하는 서버를 찾는 방식. 메타 정보를 관리하는 서버가 없기 때문에 장애범위가 지역적이다. 하지만 저장된 데이터를 이용해 분석 작업을 하는 경우 메타데이터 방석보다 어렵다.

 

파일 저장 방식에 따라 2가지로 구분할 있다.

·       데이터 파일은 분산 파일 시스템에 저장하고, 데이터 관리 시스템에서는 논리적인 관리만 담당하는 방식은 데이터의 복제, 장애 발생시 복제본의 재생성등은 분산 파일 시스템에서 제공하는 기능을 이용한다. 빅테이블, 클라우데이터, HBase 등이 있다.

·       데이터 관리 시스템 자체적으로 데이터 파이을 저장하는 방식은 데이터 관리 시스템 자체적으로 복제, 장애 복구 등에 대한 기능을 담당한다. 대부분의 NoSQL 솔루션들이 방식을 사용한다.

 

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

 

 

NoSQL, 분산 데이터 저장, NoSQL 특징, NoSQL 분류, 분산처리, 메타데이터, 데이터노드

'NoSql, MemoryDB' 카테고리의 다른 글

CAP 이론  (0) 2020.06.08
Redis Memory LFU(Least Frequently Used) 캐시  (0) 2019.06.07
Redis Memory LRU(Least Recently Used) 캐시  (0) 2019.06.04
Redis Memory 정보  (0) 2019.05.21
Redis Architecture  (0) 2019.05.18

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

CAP 이론

 

관계형 데이터베이스는 ACID 속성을 가지고 있으며 안전하게 저장하고 정합성을 보장하는데 주목적이 있다.

·       Atomicity(원자성) : 트랜잭션과 관련된 모든 작업들이 정상적으로 수행 되었는지, 아니면 모든 작업들이 수행되지 않았는지를 보장한다. 원자성은 중간 단계까지 실행되고 실행이 실패하는 일은 없도록 한다.

·       Consistency(일관성) : 트랜잭션 실행이 성공적으로 완료되면 언제나 일관성 있는 데이터베이스 상태로 유지한다.

·       Isolation(고립성) : 트랜잭션이 실행되는 동안 다른 트랜잭션의 작업이 끼어들지 못하게 보장한다. , 다른 트랜잭션에서 중간단계의 데이터를 확인할 없다.

·       Durability(지속성) : 성공적으로 수행된 트랜잭션은 영원히 유지되어야 한다.

 

최근 하드웨어가 발전하고, 검색 서비스, SNS 서비스 같은 대규모 데이터 처리 장애 상황에서도 서비스를 유지해야하는 특성을 반영하여 BASE 라는 속성에 맞는 데이터 관리 시스템이 필요로 하게 되었다.

·       Basically Available : 언제든지 데이터에 접근할 있는 속성

·       Soft state : 특정 시점에서는 데이터 일관성이 보장되는 않는 속성

·       Eventually consistent : 일정시간이 지나면 데이터의 일관성이 유지되는 속성

 

결국 확장성과 고가용성을 제공해야하지만, 표준 SQL이나 엔티티 간의 관계를 지원하지 않는 데이터 관리 시스템이 등장하게 되었으며, 이러한 시스템을  NoSQL이라고 한다. 분산환경의 NoSQL 시스템을 구성할 경우 CAP 이론이라는 것이 있다.

·       Consistency (정합성) : 모든 클라이언트는 항상 동일한 데이터를 보장 받는 속성

·       Availability (가용성) : 네트워크 단절 상황에서도 장애가 발생하지 않은 노드는 모든 요청에 대해서 정해진 시간 내에 응답해야하는 속성

·       Partition Tolerance (단절내성) : 네트워크가 단절된 상태에서도 시스템의 속성(정합성이나 가용성) 유지해야한다는 속성. 분산환경에서는 네트워크상에 서버들이 분산배치되기 때문에 속성은 반드시 포함해야하는 속성이다.

 

CAP 이론은 CAP 속성을 정의한것으로 적절한 응답 시간내에 가지 속성을 모두 만족시키는 분산 시스템을 구성할 없다라고 정의한 이론이다.

 

관계형 데이터베이스는 정합성(C) 가용성(A) 초점이 맞춰져 있는 반면, NoSQL 솔루션들은 가용성(A) – 단절내성(P) 또는 정합성(C)-단절내성(P) 특성을 제공한다. CAP 이론에 따라 분산된 환경에서는 가지 속성을 동시에 만족시킬 없기 때문에 저장되는 데이터의 속성과 요구사항을 파악해 요구사항에 어떤 속성을 갖는지를 알아야 한다.

 

 

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

 

 

NoSQL, 분산 데이터 저장, CAP이론, Consistency, Availability, Partition Tolerance

'NoSql, MemoryDB' 카테고리의 다른 글

NoSQL 특징및 분류  (0) 2020.06.09
Redis Memory LFU(Least Frequently Used) 캐시  (0) 2019.06.07
Redis Memory LRU(Least Recently Used) 캐시  (0) 2019.06.04
Redis Memory 정보  (0) 2019.05.21
Redis Architecture  (0) 2019.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, 분산 코디네이션

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

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, 분산 코디네이션

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, 서비스운영, 모니터링자동화, 시스템운영자동화

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