Hive Thrift Service (쓰리프트 서비스)

 

·       Version : Hive

 

Hive 하이브 서버(Hive Server) 또는 하이브 쓰리프트(Hive Thrift) 불리는 구성요소를 가지고 있다. 쓰리프트는 확장성과 서로 다른 언어간에 통신이 가능한 소프트웨어 프레임워크이다. 구성요소를 통해 클라이언트는 하나의 포트(Port) 하이브에 접근할 있다.

CLI 하이브를 접근하는 가능 일방적인 방식이다. CLI 모든 하이브 구성요소 설정이 로컬에 복사본으로 존재해야만 동작한다. 마찬가지로 하둡 클리아언트와 하둡 설정도 있어야 한다. 하이브 CLI HDFS 클라이언트, 맵리듀스 클라이언트, JDBC 클라이언트(메타스토어 접속용) 동작한다.

 

하이브 서비스는 쓰리프트를 이용한다. 쓰리프트는 인터페이스 언어를 제공한다. 쓰리프트 컴파일러는 인터페이스를 해석하여 다양한 언어로 네트워크 RPC 클라이언트 코드를 생성한다. 하이브는 자바로 작성되었고, 자바 바이트 코드(bytecode) 범용 플랫폼이므로 쓰리프트 서버를 위한 자바 클라이언트를 하이브 배포에 포함하고 있다. 클라이언트를 사용하는 방법중 하나는 자바 통합 개발 환경으로 프로젝트를 시작해 관련 라이브러리를 직접 포함시키거나 메이븐을 통해 가져오는 방법이 있다.

 

하이브 서비스는 쓰리프트를 통해 하이브 메타스토어에 접속한다. 일반적으로 사용자는 메타스토어를 직접 수정하는 메타스토어 메소드를 사용하지 말고 하이브를 통해 HiveQL 언어를 이용해야한다. 사용자는 테이블에 관한 메타 정보만 제공하는 읽기 전용 메소드를 사용하는것이 좋다.

 

하이브 CLI /tmp hadoop.tmp.dir 디렉터리에 .hivehistory 같은 산출물을 만들어 낸다. 하이브 서비스는 하둡 잡이 실행되는 시작점이기 때문에 하이브 서비스를 배치할 몇가지 고려할 점이 있다. 특히 클라이언트 장비에서하던 태스크 계획, 관리 작업이 서버에서 실행되기 때문에 여러 클라이언트의 동시 실행시 서비스 오버헤드를 줄이기 위하 부하 분산으로 TCP load balance 이용하거나 백엔스 서버의 pool 접속하는 프록시를 만들어 사용하는것이 좋다. 또한 하이브는 hive.start.cleanup.scratchdir 이라는 속성을 통해 재시작시 scratch 디렉터리를 비운다. 기본값은 false이며, true 변경하여 재시작시 디렉터리를 클린업 있다.

 

일반적으로 하이브 세션은 메타스토어로 이용하는 JDBC 데이터베이스에 직접 연결된다. 하이브는 쓰리프트 메타스토어(ThriftMetastore)라는 선택적 구성요소를 제공하는데, 이를 설치하면 하이브 클라이언트는 쓰리프트 메타스토어로 연결되고 쓰리프트 메타스토어가 JDBC 데이터베이스에 연결된다.

 

 

 

 

 

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

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, Hive tunning, 하이브 쓰리프트, Hive Thrift, 하이브 관리, Hive Management

Hive 보안 인증, 권한 부여

 

·       Version : Hive

 

하둡은 보안강화를 위해 커버로스(Kerberos)인증을 지원한다. 커버로스 인증은 서버와 클라이언트 간의 상호 인증을 지원한다. 더이상 hadoop. job.ugi 속성을 설정하여 다른 사용자인척 없다. 하지만 이렇게 동작하려면 모든 하둡 구성요소는 커버로스 보안을 양쪽 끝에서 지원해야한다.  모든 하둡 에코 시스템이 커버로스 인증을 지원 못하듯이, 하이브 인증도 완전하지 않다. 하이브는 메타스토어에 접속하기 위해서 JDBC 데이터베이스 연결을 사용하거나 사용자를 대신해서 동작을 수행하는 쓰리프트를 사용한다. 쓰리프트 기반의 하이브 서비스 역시 다른 사용자인척 해야한다. 소유자와 그룹이 파일에 대한 소유권을 갖는 하둡의 파일 소유 모델은 테이블에서 로우나 컬럼 기반 방식으로 접근을 허용하고 금지하도록 구현된 많은 데이터베이스의 방식과 다르다.

앞에 설명한 파일 소유 모델 때문에 파일과 디렉터리의 소유가 서로 다른 사용자라면 파일에 퍼미션(permission) 부여하는 일이 중요하다.  HDFS 퍼미션 시스템은  user, group, others 요소가 있으며 read, write, execute라는 퍼미션이 있다. 하이브는 hive.files.umask.value 속성을 가지고 있는데 설정으로 새롭게 생성하는 파일의 기본 퍼미션을 비트 마스크를 통해서 설정한다. Hadoop Hive 사용자의 구성에 따라 664 권한인 0002 파일 권한 비트 마스크를 만들 있다.

<property> 

  <name>hive.files.umask.value</name> 

  <value>0002</value> 

  <description>The dfs.umask value for the hive created folders</description> 

</property>

 

hive.metastore.authorization.storage.checks 속성을 true 설정하면 테이블 내부에 사용자가 지울 있는 퍼미션을 갖지 못한 파일이 있을때 하이브는 해당 테이블을 드롭하는 것을 방지한다. 속성의 기본값은 false 이며 true 설정해야 한다.

<property> 

  <name>hive.metastore.authorization.storage.checks</name> 

  <value>true</value> 

  <description>Should the metastore do authorization checks against 

  the underlying storage for operations like drop-partition (disallow 

  the drop-partition if the user in question doesn't have permissions 

  to delete the corresponding directory on the storage).</description> 

</property>

 

동시에 Hive hive.metastore.execute.setugi 가능한 true 설정한다. 안전하지 않은 모드에서 속성을 true 설정하면 메타 스토어가 사용자 그룹의 권한을 정의하는 DFS 작업을 수행한다.

 

Hive 인증을 활성화 하는 방법은 hive.security.authorization.enabled true 설정한다. 기본값은 false이다.

<property> 

  <name>hive.security.authorization.enabled</name>  

  <value>true</value> 

  <description>Enable or disable the hive client authorization</description> 

</property>

 

hive.security.authorization.createtable.owner.grants 속성에서는 테이블 생성자가 접근할 있는 권한을 구성한다. 기본값은 null이며, ALL 설정하여 사용자가 자신이 만든 테이블에 액세스 있도록 한다.

<property> 

  <name>hive.security.authorization.createtable.owner.grants</name> 

  <value>ALL</value> 

  <description>The privileges automatically granted to the owner whenever 

  a table gets created.An example like "select,drop" will grant select 

  and drop privilege to the owner of the table</description> 

</property> 

 

아래 스크립트는 Hive명령으로 사용자 인증을 활성화 한다. 권한이 없을 경우 아래 예제 스크립트와 같이 테이블 생성시 오류가 발생한다.

hive> set hive.security.authorization.enabled=true;   

 

hive> CREATE TABLE auth_test (key int, value string);   

 

Authorization failed:No privilege 'Create' found for outputs { database:default}.   

Use show grant to get more details

 

권한을 부여하기 위해서는 아래 스크립트를 사용할수 있다. 사용자(USER), 그룹(GROUP), 역할(ROLES) 같은 다양한 주제에 권한을 부여할 있다.

hive> set system:user.name; 

 

system:user.name=hadoop 

 

hive> GRANT CREATE ON DATABASE default TO USER hadoop; 

 

hive> CREATE TABLE auth_test (key INT, value STRING); 

 

Confirm the permissions we have with the SHOW GRANT command:

hive> SHOW GRANT USER hadoop ON DATABASE default;   

database default   

principalName hadoop   

principalType USER   

privilege Create   

grantTime Sun May 06 17:18:10 EDT 2018   

grantor hadoop

 

사용자별로 퍼미션을 부여하는 작업은 사용자와 테이블이 많을수록 관리 부담이 증가한다. 이런경우 그룹 단위로 퍼미션을 부여할 있다. 하이브에서 그룹은 사용자의 번째 POSIX 그룹과 동일하다.

hive> CREATE TABLE auth_test_group(a int,b int); 

 

hive> SELECT * FROM auth_test_group;

 

Authorization failed:No privilege 'Select' found for inputs 

{ database:default, table:auth_test_group, columnName:a}. 

Use show grant to get more details. 

hive> GRANT SELECT on table auth_test_group to group hadoop; 

hive> SELECT * FROM auth_test_group; 

OK 

Time taken: 0.119 seconds

 

사용자와 그룹 퍼미션이 충분히 유연하지 않은경우 역할(role) 사용할 있다. 사용자에게 역할을 부여하고 특권이 역할에 부여될수 있다. 시스템 외부에서 제어하는 그룹과는 달리 역할은 하이브 내부에서 제어되므로 좀더 유연성을 제공한다.

hive> set system:user.name; 

 

system:user.name=hadoop 

 

hive> GRANT CREATE ON DATABASE default TO USER hadoop; 

 

hive> CREATE TABLE auth_test (key INT, value STRING); 

 

Confirm the permissions we have with the SHOW GRANT command:

hive> SHOW GRANT USER hadoop ON DATABASE default;   

database default    

principalName hadoop   

principalType USER   

privilege Create   

grantTime Sun May 06 17:18:10 EDT 2018   

grantor hadoop

 

기본적으로 파티션 테이블의 권한은 테이블의 권한을 따르거나  파티션에 대한 권한 메커니즘을 설정할 있다. 테이블 속성의 PARTITION_LEVEL_PRIVILEGE true 설정하여 사용할 있다.

hive> ALTER TABLE auth_part 

> SET TBLPROPERTIES ("PARTITION_LEVEL_PRIVILEGE"="TRUE"); 

Authorization failed:No privilege 'Alter' found for inputs 

{database:default, table:auth_part}. 

Use show grant to get more details.

 

일반 사용자는 쿼리를 수행하기 위해서 스스로 특권을 부여하는 번거로움 없이 테이블을 생성하고 싶을 것이다. 또는 기본 동작으로 모든 특권을 부여하여 사용하고 싶을 것이다. 아래 스크립트는 SELECT DROP 특권을 자신 소유의 테이블에 자동으로 권한을 부여한다.

<property> 

  <name>hive.security.authorization.createtable.owner.grants</name> 

  <value>select,drop</value> 

</property>

 

비슷하게 특정 사용자는 생성한 테이블에 대한 특권을 자동으로 부여받을수 있다. 아래 스크립트는 sungwook, sqlmvp 사용자가 모든 테이블을 읽을수 있는 권한을 부여한다. 그리고 tom 테이블 생성만 가능하다.

<property> 

  <name>hive.security.authorization.createtable.user.grants</name> 

  <value>sungwook,sqlmvp:select;tom:create</value> 

</property>

 

동일한 구성을 그룹 권한 역할 권한에도 적용할 있다.

hive.security.authorization.createtable.group.grants 

hive.security.authorization.createtable.role.grants

 

권한을 회수하는 방법은 아래 스크립트를 사용한다.

revoke create on database default from user sungwook;

revoke select on database default from group sungwook; 

 

 

 

[참고자료]

·       Hive - Authority Management (Authorization) : https://www.programmersought.com/article/1095315821/

 

 

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

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, Hive tunning, 하이브 튜닝, 하이브 보안, 하이브 인증, 하이브 권한, Hive Security, Hive Authorization, Hive Authority Management

Hive 잠금(lock)

 

·       Version : Hive

 

HiveQL SQL 유사하지만 잠금(locking) 대한 메커니즘은 완전히 다르다. SQL 비교한다면 매우 부족한 lock 모델을 가지고 있다. 하둡이 제한된 의미의 이어쓰기 (append) 지원하고 있지만 전통적으로는 write-once(한번쓰면 변경이 불가능하다는 의미) 특성을 가지고 있기 때문에 이러한 특성과 맵리듀스의 스트리밍 읽기 방식으로 인해 세밀한 잠금에 대한 접근은 불필요하기 때문이다.

그러나 하둡은 다중 사용자 시스템이기 때문에 잠금과 코디네이션이 필요할수도 있다. 예를들어 INSERT OVERWRITE 쿼리는 테이블의 모든 내용을 덮어쓰고 다른 사용자가 동시에 테이블에 쿼리를 시도하면 쿼리가 실패하거나 잘못된 결과를 반환할 있기 때문에 명시적으로 테이블에 잠금이 필요할 수도 있다.

하이브는 아파치 주키퍼(Apache Zookeeper) 이용하여 잠금을 제공한다. 주키퍼는 분산 코디네이션을 구현한 오픈소스로 Kafka 분산 코디네이션이 필요한 환경에서 많이 사용 한다. 하이브에서 주키퍼를 코디네이션으로 사용하려면 주피커 쿼럼 노드를 등록해야한다. hive-site.xml에서 설정할 있다.

#통신할 주키퍼 목록을 등록, 읽기/쓰기 잠금을 위해서만 필요

<property>

  <name>hive.zookeeper.quorum</name>

  <value>hadoopcluster01:2181,hadoopcluster02:2181</value>

</property>

 

#동시성을 제공할지 설정, 최소 하나의 주키퍼가 등록되어 있어야 한다.

<property>

  <name>hive.support.concurrency</name>

  <value>true</value>

</property>

 

설정으로 하이브는 쿼리를 실행할때 자동으로 잠금이 지원되며 현재 모든 잠금 목록을 확인하기 위해서는 아래 스크립트를 실행한다.

hive> show locks;

hive>show locks 테이블명 extended;

 

동시성 기능이 true 설정되어 있는 경우 하이브는 자동으로 가지 종류의 잠금 기능을 제공한다. 테이블을 읽을 때에는 공유 잠금(shared lock) 사용하고, 테이블을 수정할 때는 배타적 잠금(exclusive lock) 사용한다. 테이블이 파티션닝 되어 있을때 파티션에 대한 베타적 잠금을 얻게 되면 파티션이 수정되는 동안 테이블 삭제 시도와 같은 동시 변경이 발생되지 못하도록 테이블 자체에 공유 잠금을 건다. 베타적 잠금은 테이블의 모든 파티션에 영향을 미친다.

 

명시적으로 잠금을 관리할수도 있으며 아래 스크립트는 명시적으로 베타 잠금을 생성한다.

hive>lock table 테이블명 exclusive;

 

명시적 잠금 해제는 unlock 명령을 사용한다.

hive>unlock table 테이블명;

 

 

[참고자료]

https://cloudera.ericlin.me/2015/05/how-table-locking-works-in-hive/

 

 

 

 

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

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, Hive tunning, 하이브 튜닝, 하이브락, hive lock, 하이브 잠금

MySQL InnoDB Buffer Pool Resizing Online

 

·       Version : MySQL 5.7.5, 8.0

 

MySQL 5.7.5 부터 InnoDB 버퍼풀의 크기를 서비스 가동중에도 동적으로 조절할 있다. 동적으로 버퍼풀 확대 또는 축소를 제공하기 위해 청크 크기를 정의하는 새로운 변수인 innodb_buffer_pool_chunk_size 도입되었으며, 변수는 동적이 아니며 잘못 구성되면 원하지 않는 상황이 발생할 수도 있다.

아래 그림은 innodb_buffer_pool_size, innodb_buffer_pool_instances , innodb_buffer_pool_chunk_size 상호작용하는 방식을 나타낸것이다.

 

버퍼풀은 여러 인스턴스를 보유할 있으며 인스턴스는 청크로 분할된다. 인스턴스의 수는 1 ~ 64 까지 있으며 청크의 양은 1000개를 초과하지 않도록 해야한다. 따라서 3GB RAM 있는 서버에서, 8개의 인스턴스가 있는 2GB 버퍼 기본값(128M) 청크를 가지고 있는 경우 인스턴스당 2개의 청크를 얻게 된다. 뜻은 16개의 청크가 있음을 의미한다.

 

현재 설정되어있는 버퍼풀 크기를 확인하는 방법은 아래 스크립트를 사용한다.

mysql> show global variables like 'innodb_buffer_pool_size';

+-------------------------+------------+

| Variable_name           | Value      |

+-------------------------+------------+

| innodb_buffer_pool_size | 1073741824 |

+-------------------------+------------+

 

버퍼 크기를 조절하는 방법은 아래 스크립트를 실행한다.  이때 파라메터는 바이트 값이므로 설정시 주의 한다.

mysql> set global innodb_buffer_pool_size=1610612736;

 

 

 

[참고자료]

·       InnoDB Buffer Pool Resizing: Chunk Change : https://www.percona.com/blog/2018/06/19/chunk-change-innodb-buffer-pool-resizing/

 

 

 

 

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

 

MySQL, Buffer Pool, innodb_buffer_pool_size, innodb_buffer_pool_instances , innodb_buffer_pool_chunk_size, 버퍼풀 사이즈 조절

+ Recent posts