Data Science Lab

Impala Connection refuse Error

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

·       Version : CDH 6.3

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

위와 같은 오류 메시지가 발생하였을경우,  impala 환경설정에서 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 타입등을 제공한다. 각각의 데이터형은 자바로 구현되어 있어 자바 데이터 타입과 동일하게 하이브에서 사용된다.

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

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

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

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

하이브는 키 개념을 가지고 있지 않다. 하지만 색인 테이블은 사용이 가능하다. 컬렉션 데이터 타입은 자바의 제네릭(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, 하이브, 하이브 데이터 타입

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 메모리가 아닌 경우 하듭 클러스터에서 체크섬 오류가 발생할 수 있다.

[참고자료]

• Setting up Disks for Hadoop : https://cwiki.apache.org/confluence/display/HADOOP2/DiskSetup

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

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

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

·       Version : Hive

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

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

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

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

ZooKeeper 옵저버와 CLI

·       Version : Zookeeper

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

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

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

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

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

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

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

Hive에서 쉘 명령 실행

·       Version : Hive

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

쉘 명령을 실행할때, 사용자 입력이 필요한 명령은 실행해서는 안된다. 쉘 파이프와 파일 글로빙(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, 분산 코디네이션

ZooKeeper 멀티 서버 구성

·       Version : Zookeeper

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

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

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

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

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

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

이 외에도 성능이 저하되지 않도록 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, 분산 코디네이션

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

Zookeeper 세션(Session)

·       Version : Zookeeper

주키퍼에서 세션(session)은  주키퍼 서버와 클라이언트의 연결을 의미한다. 세션 상태는 5가지가 있다.

·       Connecting : 클라이언트가 주키퍼 서버와 연결을 시도하고 있는 상태이다.

·       Connected : 서버와 연결된 상태로, z노드에 연산을 수행할 수 있는 상태이다.

·       Closed : close() 메소드에 의해 명시적으로 연결을 종료했거나, 세션 타임아웃, 인증 실패 등으로 서버와 연결이 종료된 상태

·       Disconnected : 시스템 장애, 네트워크 장애등으로 서버와의 접속이 끊긴 상태이다. Disconnected 상태에서는 클라이언트가 자동으로 파라메터로 받은 서버 중 한 대에 다시 접속을 시도하며, 이때. 서버 접속시 발급받은 64비트의 세션 아이디를 재접속시 사용하여 세션값을 계속 유지 할 수 있다. Disconnected 상태에서는 임시노드는 삭제되지 않는다.

·       Session Expired : 세션 타임아웃 시간동안 세션 유지 요청이 없으면 세션을 무효화한다. 세션 타임아웃 시간을 너무 짧게 설정하면 세션이 너무 자주 끊겨 임시 노드가 삭제되는 문제가 있으며, 타임 아웃 시간이 너무 길면 Session Expired 상태에 대한 이벤트를 받는데 오래 걸린다.

주키퍼는 세션 연결과 읽기 연산시 이벤트를 받을 수 있는 와처(watcher)를 설정하는 기능을 제공한다. 와처는 세션의 상태가 변경되었거나 관심 있는 노드의 상태가 변경되었을때 클라이언트가 이벤트를 받아 처리할 수 있게 하는 기능을 제공한다. 와처는 옵저버(Observer) 패턴을 취하고 있어 이벤트 대상에 콜백 객체를 등록하고 조건에 만족한 이벤트가 발생하면 콜백 객체로 등록된 와처를 호출하는 방식을 취한다.

클라이언트가 주키퍼 서버에 연결되면 Peer-To-Peer FIFO 네트워크 채널을 생성한다. 이 네트워크 채널은 세션이 종료될 때까지 유지한다. 즉, 한번 생성된 소켓은 계속 사용한다. 특정 z노드에 와처를 등록하면 클라이언트에서는 메모라에 와처 객체를 등록한다. 주키퍼 서버로는 z노드의 패스와 클라이언트 호스트 정보를 전달하고, 서버에는 z노드와 와처를 등록한 클라이언트 목록을 가지고 있으며 z노드 상태가 변경되서을때 와처 목록에 있는 클라이언트로 변경 내역을 전송한다. 주키퍼 와처는 한버 이벤트를 받으면 등록된 와처는 삭제된다. 따라서 이벤트를 계속 받기 위해서는 와처를 계속 등록해야 한다.

[참고자료]

·       ZooKeeper Sessions : https://zookeeper.apache.org/doc/r3.3.5/zookeeperProgrammers.html#ch_zkSessions

·       ZooKeeper Watches : https://zookeeper.apache.org/doc/r3.3.5/zookeeperProgrammers.html#ch_zkWatches

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

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

Zookeeper  접근제한(Access Control List)

·       Version : Zookeeper

주키퍼의 패스와 노드에 대한 권한 관리는 상속되지 않는다. 이 뜻은 부모 노드와 자식 노드가 있을때, 부모의 노드의 권한 속성이 자식 노드로 권한 상속이 발생하지 않다는 것이다. 그리고 아무런 설정을 하지 않으면 누구나 접근이 가능하다.

접근권한은 [schema:id, permission] 같은 형태로 설정한다. Schema는 인증방법을 정의하고, id는 인증을 허용할 값을 정의, permission에는 처리할 수 있는 기능을 정의한다.

ex) 특정IP를 가진 클라이언트에 읽기(read) 권한 부여 : ip:192.168.0.1, READ

·       CREATE : 자식 노드를 생성할 수 있는 권한

·       READ : 데이터를 읽거나 자식노드를 조회할 수 있는 권한

·       WRITE : 데이터를 수정할 수 있는 권한

·       DELETE : 자식 노드를 삭제 할 수 있는 권한

·       ADMIN : 권한을 설정할 수 있는 권한

접근제한에서 사용할 수 있는 스키마 목록은 아래와 같다.

·       world : 모든 사용자가 접근 가능한 스키마

·       auth : 접근 권한을 설정하기 위한 스키마 (실제 클라이언트에서 사용할 경우는 거의 없음)

·       digest : “사용자명 : 패스워드” 방식으로 접근권한을 설정하기 위한 스키마

·       host :  호스트명을 이용해 접근 권한을 설정하기 위한 스키마

·       ip : 클라이언트 IP를 이용해 접근 권한을 설정하기 위한 스키마 (IP값은 addr/bits 형태의 비트마스크 사용 가능)

ACL 목록 생성시 동일한 퍼미션에 대해 다른 Id 객체가 있으면 마지막에 설정한 Id 객체의 설정만 반영된다.

아래 코드는Zookeeper ACL과 상호 작용하는 방법을 C로 만든 예제이다.

[참고자료]

·       ZooKeeper ACL Permissions : https://zookeeper.apache.org/doc/r3.1.2/zookeeperProgrammers.html#sc_ACLPermissions

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

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

ZooKeeper Stat Structure

·       Version : Zookeeper

주키퍼(Zookeeper)의 z노드에는 몇 가지 속성이 있다.

·       Stat : z노드의 상태 정보를 저장

·       Watcher : 세션의 상태가 변경 되었거나 관심 있는 노드의 상태변경(생성, 수정, 추가, 삭제)이 발생했을때 클라이언트가 이벤트를 받아 처리할 수 있게 하는 기능을 제공

·       Atomic : z노드에 대한 데이터의 조회와 저장은 원자성을 가진다.

·       Persistent Node : “Persistent” 옵션으로 생성된 z노드는 주키퍼 서버의 로컬 디스크에 영구히 저장되고 클라이언트의 삭제 요청에 의해서만 삭제된다. 따라서 주키퍼 서버가 재시작 되어도 데이터는 보존된다.

·       Ephemeral Node : 임시노드는 노드를 생성한 클라이언트와 세션이 종료되면 해당 노드도 자동으로 삭제된다. 임시 노드는 자식 노드를 가질수 없으며, 부모 노드는 반드시 Persistent 노드여야 한다.

·       Sequence Node : 시퀀스 노드는 특정 부모 노드의 아래에 있는 자식 노드에 노드의 이름 값이 순차적으로 증가하는 번호를 부여하는 노드를 만들때 사용한다.

아래 표는 Stats의 정보이다.

[참고자료]

·       ZooKeeper Stat Structure : https://zookeeper.apache.org/doc/r3.1.2/zookeeperProgrammers.html#sc_zkStatStructure

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

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

ZooKeeper 시간 동기화와 네임스페이스 z노드

·       Version : Zookeeper

주키퍼(Zookeeper)는 하나 이상의 서버에서 수행되기 때문에 클라이언트의 처리 요청에 따라 버전 정보나, 시간정보등에 대해서 모든 주키퍼 서버가 공유해야한다. 주피커는 아래와 같은 방법으로 시간이나 버전 정보를 관리한다.

·       Zxid (Zookeeper Transaction Id) : 주키퍼 노드의 상태를 변경하는 요청에 대해 부여되는 트랜잭션ID로, 모든 변경 요청에 대해서 순차적으로 부여된다. zxid가 낮을 수록 먼저 요청되었다는 것을 보장한다.

·       Version numbers : 노드의 데이터가 변경될때 마다 버전 값이 증가. 버전에는 z노드 데이터 변경, 자식 노드의 변경, AC 변경이 있으며 각각 다른 버전이 부여된다.

·       Tick time : 세션 타임아웃, 커넥션 타임아웃 등과 같은 이벤트의 경과 시간을 의미.

·       Real time : 대부분의 경우에 시스템 시간을 사용하지 않지만, 노드의 생성, 수정 일시에 대한 정보는 시스템 시간을 사용한다.

주키퍼는 파일 시스템과 유사한 계층적인 네임 스페이스를 제공한다. 이러한 각 노드를 z노드(znode)라고 한다. z노드는 아래와 같은 특징이 있다.

·       부모 노드에도 데이터 저장 가능

·       크기가 작은 데이터 위주로 저장 (서버의 상태, 락 정보, 환경 설정등과 같은 크기가 작은 메타 데이터)

·       버전 : z노드에 저장되는 모든 데이터는 버전을 가지고 있음

·       접근권한 : z노드 단위로 권한(ACL) 관리 가능

주키퍼 클라이언트는 라이브러리는 대부분 z노드 연산과 관련이 있으며 클라이언트 라이브러리는 JAVA, C, Python, Perl등을 지원한다. 주키퍼 클라이언트 API는 Zookeeper이라는 클래스를 사용하며 클래스의 생성자에는 3개의 파라메터가 있다.

·       주키퍼 서버 목록 : 콤마(,)로 구분하여 구분한다. (EX : server1:2181, server2:2181…) 서버 정보에 루트 패스를 지정할수도 있으며 노드 정보를 같이 입력해주면(EX : server3:2181/app/myapp1)  해당 노드를 루트 노드로 인식한다.

·       세션 타임아웃 : 주키퍼 서버와 클라이언트 연결에 대한 타임아웃으로 단위는 밀리초(ms) 이다.

·       와처(watcher) : 이벤트 리스너를 등록한다.

주키퍼 클라이언트 API는 동기, 비동기 방식을 모두 지원한다. 비동기 호출을 하더라도 처리되는 순서는 주키퍼 서버에 의해 보장 된다. 아래표는 주키퍼 클라이언트 API에 대한 설명이다.

[참고자료]

·       Time in ZooKeeper : https://zookeeper.apache.org/doc/r3.1.2/zookeeperProgrammers.html#sc_timeInZk

·       ZooKeeper | Command Line Utilities: "zkCli" : http://www.mtitek.com/tutorials/zookeeper/zkCli.php

·       Zookeeper - CLI : https://www.tutorialspoint.com/zookeeper/zookeeper_cli.htm

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

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

Zookeeper 소개

·       Version : Zookeeper

주키퍼(Zookeeper)는 분산 코디네이터 서비스(Distributed Coordinator Service)를 제공하는 아파치 오픈소스이다. 분산 환경에서 락, 네이밍 서비스, 클러스터 멤버십 등을 쉽게 구현할 수 있는 기능을 제공한다. (주키퍼 자체적으로 기능을 제공하지 않으며, 기능을 쉽게 만들 수 있는 메커니즘을 제공) 주키퍼를 이용하는 대표적인 사례는 아래와 같다.

·       네임 서비스, 환경설정, 그룹 멤버십

·       Double Barriers

·       우선순위 큐 (Priority Queues)

·       공유 락 제어

·       두 단계 커밋 (Tow-phased commit)

·       리더 선출

주키퍼는 n개의 서버와 클라이언트 API로 구성되어 있으며, 서버는 파일 시스템과 비슷한 형태로, 데이터를 계층적으로 저장한다. 저장된 데이터는 주키퍼 서버들 사이에 복제되어 운영되기 때문에 일부 서버에 장애가 발생하더라도 전체 장애로 이어지지는 않는다.

주키퍼 서버에 데이터 추가, 삭제, 변경 등과 같은 상태 변경이 발생하면, 주키퍼 서버는 클라이언트로 변경 사항을 전달하는 이벤트를 발생 시킨다. 주키퍼 클라이언트 라이브러리는 단순한 몇 가지 연산만 제공하며, 사용자 어플리케이션은 이 라이브러리를 이용하여 주키퍼 서버에 데이터를 저장, 삭제하는 연산을 수행하거나 이벤트를 등록한다.

·       create : creates a node at a location in the tree

·       delete : deletes a node

·       exists : tests if a node exists at a location

·       get data : reads the data from a node

·       set data : writes data to a node

·       get children : retrieves a list of children of a node

·       sync : waits for data to be propagated

주키퍼는 파일 시스템과 유사한 계층적인 네임스페이스를 제공한다. 하지만 일반적인 파일 시스템과 달리, 주키퍼에서는 모든 노드에 데이터를 저장할 수 있다. 주키퍼는 클라이언트 라이브러리를 이용해 네임 스페이스에 대한 조회나 노드에 저장된 데이터를 원격 클라이언트에서 접근할 수 있다.

주키퍼 노드를 식별하는 식별자는 파일 시스템 디렉터리 구조와 동일하게 ‘/’로 구분되는 문자열이다. 상대 경로를 나타내는 ‘.’, ‘..’ 사용시 주의해야한다. 패스(path)명으로 사용할 수는 있지만 상대 경로가 아닌 문자 자체로 인식하기 때문이다. 아래 케이스는 패스에 사용할 수 없다.

·       Null 문자(0x00)

·       \u001 - \u0019, \u007F - \u009F

·       \ud800 - \uF8FFF, \uFFF0 - \uFFFF, \uXFFE - \uXFFFF, \uF0000 - \uFFFF

·       zookeeper : 시스템에서 사용하는 예약어

주키퍼의 모든 데이터는 서버 메모리에 저장하기 때문에 주키퍼에 저장할 수 있는 데이터 용량은 주키퍼 데몬 서버가 할당받은 힙 메모리 영역을 초과할 수 없다. 따라서 일반적으로 시스템 관리, 모니터링, 락 관리등에 필요한 메타 정보만 저장한다. 데이터는 메모리에 존재하지만 트랜잭션 로그와 스냅샷 파일은 로컬 디스크에 저장하여 주키퍼 서버를 재시작 하였을 때에도 데이터는 그대로 유지된다.