웅이 IT 저장소

centos7 기준입니다.

갑작스레 yum 명령이 아래와 같은 에러를 뿜으며 동작하지 않았습니다.

Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error was
14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown error"

또한, install 명령 시 다운 받으려는 패키지의 URL 옆에 아래와 같은 에러문구가 지속해서 나왔습니다.
[Errno 14] HTTP Error 404 - Not Found

서버 네트워크, DNS 설정 등의 문제는 아니었고, 확인 결과,

2024년 6월 30일 CentOS 7 EOS에 따라 기존의 레포지토리 내 패키지들이 삭제된 것으로 확인되었습니다.

이에, 기존에 사용중이던 yum repository 주소를 변경하여 해결하였습니다.

# 경로 이동
cd /etc/yum.repos.d

# 백업 폴더 생성
mkdir old_repo

# 기존 파일 이동
mv CentOS-* old_repo

# 폴더 이동
mv old_repo /opt/apps/

# 새 레포지토리 파일 생성
# original이 기존, new가 새로운 URL입니다.
# mirrorlist 부분은 모두 주석하였습니다.
vi CentOS-Base.repo

[base]
name=CentOS-$releasever - Base
# original
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
# new
baseurl=http://centos.mirror.cdnetworks.com/7/os/x86_64
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

#released updates
[updates]
name=CentOS-$releasever - Updates
# original
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
# new
baseurl=http://centos.mirror.cdnetworks.com/7/updates/x86_64
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
# original
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
# new
baseurl=http://centos.mirror.cdnetworks.com/7/extras/x86_64
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
# original
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
# new
baseurl=http://centos.mirror.cdnetworks.com/7/centosplus/x86_64
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

# yum cache 삭제
yum clean all

# 테스트
yum install -y libtool

감사합니다.

centos7 기준입니다.

NiFi 클러스터 모드 사용 중에 알게 된 주의할만한 사항들입니다.

NiFi 버전 2.0.0

노드 3EA (node1, node2, node4)

정리 및 요약:

1. 클러스터 환경일 시, GetSFTP 같은 프로세서는 SCHEDULING 탭 -> Execution을 Primary Node로 설정합니다.

All Nodes로 하게되면, 클러스터에 속한 모든 노드가 해당 프로세서를 실행합니다.

(이는 같은 파일을 여러 노드가 가져가려고 하기에 경쟁상태에 빠지거나,

이미 한 노드가 가져가면 File Not Found 에러의 위험이 있습니다.)

또한 GenerateFlowFile같이 플로우의 시작을 알리는 프로세서도 한 번만 실행되어야 플로우가 한 바퀴 도는 것이기에 마찬가지로 Primary Node로 설정합니다.. (빈 플로우 파일 1개를 생성하는 용도가 아닌 다른 용도면은 제외입니다.)

2. 후의 프로세서들은 All Nodes로 해야 여러 노드가 분산 작업 진행합니다. 하지만 그냥은 안되고,

로드 밸런싱 기능을 활성화 해야합니다. NiFi 1.8 버전부터 큐 수준에서 로드밸런싱 기능이 도입되었습니다.

(* 여담으로 1.8버전 이후에 이 로드밸런싱 기능이 여러 버그가 있었고 수정 후 커밋이 된것으로 보입니다. 버그 수정이 적용된 버전은 몇인지 확인 하진 못하였고, 본 포스팅은 2.0.0버전으로 진행하였고 문제 없었습니다.)

만약 로드밸런싱 기능을 안쓰고 Execution이 Primary Node인 GenerateFlowFile이 5번 실행된다면, 추후에 프로세서들이 All nodes로 설정되어있어도, 무조건 하나의 노드에서만 작업이 진행됩니다. 이유는 GenerateFlowFile이 Primary Node에서만 실행되기에 5개의 큐 모두 Primary Node인 하나의 노드에서만 쌓일테고 다음 프로세서는 큐가 쌓여있는 노드에서 작업을 실행하기에 분산 처리가 되지않습니다. 

이에 큐 설정란의 Load Balance Strategy를 통해 큐를 어러 노드에 분배하여야 다음 프로세서가 각 큐가 쌓인 노드들에서 작업을 진행하여 분산 작업이 가능해집니다.

3. 5개의 큐가 쌓여있고, node1에 2개의 큐, node2에 2개의 큐, node3에 1개의 큐가 실제로 쌓여있다고 가정하면,

해당 5개의 큐를 받는 다음 프로세서의 작업은 node1에서 2번, node2에서 2번, node3에서 1번 실행됩니다. 이는 큐가 쌓인 노드에서 실제 프로세서에 대한 작업을 진행하기 때문입니다. 만약 작업한 프로세서 이후에 큐도 로드밸런싱을 했다면 5개의 큐는 또 다시 여러 노드에 재분배됩니다.

테스트:

해당 간단한 플로우로 테스트를 진행하였습니다.

GenerateFlowFile로 flowfile을 생성하고,

UpdateAttribute를 통해 임의의 변수를 할당합니다.

LogAttribute는 큐 소진용으로 사용하였습니다.

첫 번째 주의 사항:

node 3개로 이루어진 NiFi 클러스터 환경입니다. 여기서 GenerateFlowFile을 실행하면,

큐 내의 플로우파일이 하나가 아닌, 3개가 생성됩니다.

GenerateFlowFile은 보통 해당 플로우의 시작으로 많이 사용되기에, 하나의 플로우파일이 생성되어야하는데 3개가 생성되었습니다. 이는 플로우 자체가 3번 돌기에 원하는 상황이 아닙니다.

이는, 모든 클러스터에 속한 노드들이 해당 프로세서를 실행했기에 나타난 현상입니다.

저는 3대의 노드를 가진 클러스터이기에 GenerateFlowFile이 3번 실행되어, 3개의 큐가 쌓였습니다.

GenerateFlowFile 같이 한 번, 즉, 한 노드만 실행하게끔 설정하기 위해선,

프로세서 설정 -> SCHEDULING 탭 -> Execution을 All Nodes -> Primary node로 변경 해줍니다.

설정 후 재 실행 시, 원하는 대로 하나의 큐가 쌓인 모습입니다.

해당 설정은 모든 노드가 아닌, Primary Node로 선출된 하나의 노드에서만 해당 프로세서를 실행하겠다는 뜻입니다.

만약 GetSFTP같은 특정 서버의 파일을 가져오는 프로세서라면,

무조건 해당 프로세스를 Primary Node로 설정해야합니다.

All Nodes로 설정하게 된다면, 하나의 파일을 여러 노드가 가지고오는 것을 요청하게되어 경쟁 상태에 놓일 수 있고,

이미 다른 노드에서 가져갔다면, 또 다른 노드가 같은 파일을 요청하게 될테고, 이에 file not found 에러가 발생할 수 있습니다. 또한, 본 포스팅의 예제처럼 플로우의 시작을 알리는 GenerateFlowFile 같은 경우도 한 번만 실행하는 것이 원하는 의도이기에 Primary Node로 설정해야합니다.

2번 째 주의 사항:

로드 밸런싱에 관한 주의 사항입니다. 아래처럼 GenerateFlowFile을 5번 실행하여 5개의 큐가 쌓였습니다.

큐를 우클릭하고 List Queue 클릭하여 상태를 체크 해보겠습니다.

5개의 큐가 모두 node2라는 서버에 쌓였습니다.

그 다음, UpdateAttribute를 실행한 후, 마찬가지로 List Queue 클릭하여 상태를 체크 해보겠습니다.

또 다시 5개의 큐가 모두 node2라는 서버에 쌓였습니다.

이번엔 GenerateFlowFile과 UpdateAttribute 우클릭 -> View Data provenance를 클릭하여 어떤 노드가 해당 프로세서의 작업을 수행했는지 보겠습니다.

GenerateFlowFile

node2번에서 5번 작업

UpdateAttribute 

node2번에서 5번 작업

뭔가 이상합니다. 클러스터 모드를 사용한다는 건, 하나의 노드만 일하는 것이 아니라, 여러 노드들이 분산 작업을 하는 것을 원한다는 것입니다. 하지만 위 예제는 계속 하나의 노드에서만 작업이 진행되고 큐가 쌓였습니다.

이러한 현상을 해결하기위해 RPG(Remote Processor Group)을 추가로 만들어, 다른 노드들에게 큐를 배분하는 방식으로 사용한 케이스도 있었습니다.

하지만 NiFi 1.8 버전 부터 큐 수준에서 로드 밸런싱 기능을 지원하여 손쉽게 클러스터에 속한 다른 노드들에게 큐를 분배할 수 있습니다.

(* 여담으로 1.8버전 이후에 큐 수준의 로드밸런싱 기능에 몇가지 버그가 있었다합니다. 수정 후 커밋된것으로 확인되었으나, 몇 버전부터 적용되었는 지는 확인하지 못하였습니다. 본 포스팅인 2.0.0버전에서는 정상 동작합니다.)

이제 로드밸런싱 기능을 통해 큐를 여러 노드에 배분하고 작업 또한, 여러 노드가 나누어 실행하도록 설정해보겠습니다.

GenerateFlowFile과 UpdateAttribute 사이의 큐, UpdateAttribute 와 LogAttribute사이의 큐를

우클릭 -> Configure클릭으로 설정화면에 진입합니다.

SETTINGS 탭의 Load Balance Strategy를 Round robin으로 변경해줍니다. (두 큐 모두 설정해줍니다.)

다시 프로세서들을 각각 실행 후, 각 큐를 우클릭 -> List queue로 상태를 체크 해보겠습니다.

GenerateFlowFile과 UpdateAttribute 사이의 큐

node1서버에 2개의 큐

node2서버에 2개의 큐

node4서버에 1개의 큐 

UpdateAttribute 와 LogAttribute사이의 큐

node1서버에 3개의 큐

node2서버에 2개의 큐

각 큐가 클러스터에 속한 여러 노드에 분배됨을 확인할 수 있습니다.

그렇다면 각 프로세서는 어느 노드에서 작업이 진행되었는지 확인해보겠습니다.

이전과 같이 GenerateFlowFile과 UpdateAttribute 우클릭 -> View Data provenance을 클릭하여 확인해보겠습니다.

GenerateFlowFile

GenerateFlowFile 프로세서는 항상 Primary node인 node2 서버에서 작업이 진행됨을 알 수 있습니다.

이는 포스팅 초반, 실행되는 노드를 All Nodes가 아닌 Primary node로 설정해두었기 때문입니다.

node2서버에서만 작업 진행

UpdateAttribute

이전 아무 로드밸런싱 설정을 하지 않는 5개의 큐는 node2서버에서만 작업이 진행되었지만,

로드밸런싱 설정 후 5개의 큐는 여러 노드에서 실행되었음을 알 수 있습니다.

node1서버에 2개 작업 진행

node2서버에 2개 작업 진행

node4서버에 1개 작업 진행

이렇게 클러스터링의 이유 중 하나인 로드밸런싱 기능을 통해 큐와 프로세서의 작업을 여러 노드로 분산하였습니다.

여기서 중요한 점은, 프로세서는 받는 큐 상의 각 플로우파일이 저장된 노드에서 작업이 실행된다는 점입니다.

위 예제를 다시 보시면, GenerateFlowFile에서 Primary Node로 지정했기에

GenerateFlowFile 프로세서는 모두 node2 서버에서 작업이 진행된 것을 알 수 있었고, 후

5개의 큐, 즉, 5개의 플로우 파일을 각각 node1에 2개, node2에 2개, node4에 1개를 분배하였습니다.

그리고 이 큐들을 받는 UpdateAttribute프로세서는 각 플로우파일이 저장되어있는 노드에서 작업이 진행되기에

UpdateAttribute 프로세서는 node1에서 2번 node2에서 2번 node4에서 1번 작업이 진행된 것 입니다.

그 후 UpdateAttribute 프로세서가 5개의 큐를 node1번에 3개, node2번에 2개를 배분하였는데,

그 다음 프로세서인 LogAttribute가 실행된다면 이 프로세스는 node1번에서 3번, node2번에서 2번 작업이 진행될 것입니다.

감사합니다.

참조:

https://gist.github.com/cheerupdi/bffb331447abc78934ad5a40feb83f16

centos7 기준입니다.

지난 포스팅에서 Hive 3.1.3 버전에서 Iceberg 테이블을 사용해보았는데요.

Update, Delete 등의 트랜잭션 기능이 원활이 되지않았습니다.

Hive 버전은 3.1.3으로 유지하되 Trino를 통해 Hive에 Iceberg 테이블을 생성 시,

문제없이 트랜잭션 기능이 동작하는 것을 확인하여,

이번 포스팅에서는 기 구축된 Hive 3.1.3 + Iceberg를 Trino를 통해 사용해보겠습니다. 

환경:

Hadoop 3.3.6

Hive 3.1.3

Trino 435

* 기존 Hive 3.1.3과 Trino가 카탈로그로 연동되어있음을 가정합니다.

1. Trino에서 사용할 DB 미리 생성

# Hive 콘솔 진입
hive

# DB 미리 생성
create database trinoiceberg;

2. Trino Iceberg Catalog 생성

# 코디네이터, 워커가 설치된 모든 서버에서 진행
# 카탈로그 파일 생성
vi ${TRINO_HOME}/etc/catalog/iceberg.properties

# 기존에 Hive와 연결된 Trino 카탈로그 명입니다.
# connet.name이 hive인 properties파일을 찾습니다. 해당 경우 hive.properties였습니다.
iceberg.hive-catalog-name=hive
iceberg.file-format=ORC
connector.name=iceberg
# Hive Metastore를 통해 접속
hive.metastore.uri=thrift://node3:9083
hive.config.resources=${HADOOP_HOME}/etc/hadoop/core-site.xml,${HADOOP_HOME}/etc/hadoop/hdfs-site.xml
iceberg.catalog.type=hive_metastore
iceberg.compression-codec=GZIP

# Trino 재실행
${TRINO_HOME}/bin/launcher restart

3. 쿼리 테스트

* DBeaver 혹은 Trino CLI를 통해 테스트 가능합니다.

# 테이블 생성
create table iceberg.trinoiceberg.tb1 (
col1 varchar,
col2 integer)
WITH (
    format = 'ORC',
    format_version = 2,
    # hive-site.xml의 hive.metastore.warehouse.dir을 참조해주세요.
    location = 'hdfs://${HIVE_WAREHOUSE_DIR}/trinoiceberg.db/tb1'
    );
    
# INSERT
insert into iceberg.trinoiceberg.tb1 values ('a',1), ('b',2), ('c',3);

# SELECT
select * from iceberg.trinoiceberg.tb1;

# SELECT COUNT(*)
select count(*) from iceberg.trinoiceberg.tb1;

# UPDATE
update iceberg.trinoiceberg.tb1 set col2 = 5 where col1 = 'a';

# UPDATE 확인
select * from iceberg.trinoiceberg.tb1;

# DELETE
delete from iceberg.trinoiceberg.tb1;

Hive 3.1.3 버전에서 만든 Iceberg 테이블은 기본적으로 Update, Delete 등의 트랜잭션 질의가 원활치 못했는데,

만약 버전을 유지해야한다면 이렇게 Trino를 통해 Hive에 저장되는 Iceberg 테이블을 조작할 수 있습니다.

감사합니다.

centos7 기준입니다.

이전 포스팅엔 Hive 3.1.3에서 Iceberg를 수동으로 임포트하여 사용해보았는데요.

이번 포스팅엔 Hive 4.0.0에 기존 내장되어있는 Iceberg를 사용해보겠습니다.

환경:

Hadoop 3.3.6

Hive 4.0.0 (node4라는 호스트네임을 가진 서버에 설치되었습니다.)

Tez 0.10.3

(* Iceberg 공식홈페이지에 Hive 4버전부터는 쿼리 실행 엔진이 Tez일 때, DML이 동작한다고 언급되어있습니다.)

1. 사전 라이브러리 싱크 맞추기

# libfb303-0.9.3.jar을 적절한 위치에 이동시킵니다. 추후 임포트됩니다.
mv /opt/apps/libfb303-0.9.3.jar

# RoaringBitmap 라이브러리 싱크 맞추기
# Hive 4.0.0은 0.9.22, Tez 0.10.3은 0.7.45를 사용중이어서 Hive에 맞추었습니다.
rm -r ${TEZ_HOME}/lib/RoaringBitmap-0.7.45.jar
cp ${HIVE_HOME}/lib/RoaringBitmap-0.9.22.jar ${TEZ_HOME}/lib/

# tez 재압축
tar cvfz tez-0.10.3-bin.tar.gz ./tez-0.10.3

# tez-site.xml의 tez.lib.uris 값을 참조합니다.
hdfs dfs -put /apps/tez/ tez-0.10.3
hdfs dfs -put /apps/tez/ tez-0.10.3-bin.tar.gz

# 후 Hive를 재기동합니다

2. Beeline 진입 및 환경 세팅

# Hive 4버전부터 기본 커맨드라인 인터페이스가 Beeline으로 변경되었습니다.
hive

# Hive Server를 통해 접속
!connect jdbc:hive2://node4:10000

# 필요 라이브러리 임포트
add jar /opt/apps/libfb303-0.9.3.jar;

# 필요 설정 값 세팅
set hive.vectorized.execution.enabled=false;
set hive.execution.engine=tez;
set iceberg.engine.hive.lock-enabled=false;
set tez.mrreader.config.update.properties=hive.io.file.readcolumn.names,hive.io.file.readcolumn.ids;

3. 쿼리 테스트

# DB 생성
create database icebergtest;

# DB 선택
use icebergtest;

# 테이블 생성
CREATE TABLE tb1 (
  col1 STRING,
  col2 INT
)
STORED BY ICEBERG
STORED AS ORC
TBLPROPERTIES (
  'format-version'='2',
  'write.orc.compression-codec'='zlib'
);

# INSERT
insert into tb1 values ('a',1), ('b',2), ('c',3);

# SELECT
select * from tb1;

# SELECT COUNT(*)
select count(*) from tb1;

# UPDATE
update tb1 set col2 = 5 where col1 = 'a';

# UPDATE 확인
select * from tb1;

# DELETE
delete from tb1;

이전 포스팅과 마찬가지로각 쿼리를 진행하면서 hive-site.xml에 hive.metastore.warehouse.dir의 값을 참조하여,

hive 데이터가 저장되는 hdfs 경로를 함께 보는 것이 도움이 됩니다.

또한 Hive 3.1.3버전에서 테스트했던것과 가장 큰 차이점은 역시 트랜잭션 즉,

Update, Delete 질의가 원활히 되는 점입니다.

감사합니다.

centos7 기준입니다.

Hive 3.1.3이 설치되어있고, MR 엔진으로 실행되는 환경임을 가정합니다.

(* Iceberg 공식홈페이지에 Hive 2.x.x, 3.1.2, 3.1.3 버전은 MR 엔진에서만 DML이 동작한다고 언급되어있습니다.)

준비 라이브러리: 

iceberg-hive-runtime-1.5.1.jar

libfb303-0.9.3.jar

1. 환경 세팅 (Hive 3.1.3이 설치된 서버에서 진행)

# 필요 라이브러리 적정한 위치에 이동
mv /opt/apps/iceberg-hive-runtime-1.5.1.jar
mv /opt/apps/libfb303-0.9.3.jar

# Hive CLI 접속
hive

# 필요 라이브러리 임포트
add jar /opt/apps/iceberg-hive-runtime-1.5.1.jar;
add jar /opt/apps/libfb303-0.9.3.jar;

# 필요 설정값 세팅
set hive.vectorized.execution.enabled=false;
set hive.execution.engine=mr;
set iceberg.engine.hive.lock-enabled=false;

2. 쿼리 테스트

# DB 생성
create database icebergtest;

# DB 선택
use icebergtest;

# Table 생성
CREATE TABLE tb1 (
  col1 STRING,
  col2 INT
)
STORED BY 'org.apache.iceberg.mr.hive.HiveIcebergStorageHandler'
TBLPROPERTIES (
  'format-version'='2',
  'write.format.default'='orc',
  'write.orc.compression-codec'='zlib'
);

# INSERT
insert into tb1 values ('a',1), ('b',2), ('c',3);

# SELECT
select * from tb1;

# SELECT COUNT(*)
select count(*) from tb1;

각 쿼리를 진행하면서 hive-site.xml에 hive.metastore.warehouse.dir의 값을 참조하여,

hive 데이터가 저장되는 hdfs 경로를 함께 보는 것이 도움이 됩니다.

예를 들어, 위처럼 쿼리를 진행했을 때,

hdfs상 ${HIVE_WAREHOUSE_DIR}/icebergtest.db/tb1 경로를 살펴보면,

iceberg의 기본 틀인 temp, metadata, data 폴더 구조로 이루어진 것을 확인 가능하고,

data 내에는 테이블에 지정한 데이터 파일 포맷대로 확장자가 .orc인 것을 확인 가능합니다.

추가로 Hive 2버전, 3.1.2, 3.1.3 버전에서는 Iceberg 테이블에 대해 Update, Delete 등 트랜잭션 설정 및 쿼리가

동작하지 않는 것으로 확인됩니다.

이에 Hive 4버전(Iceberg 테이블이 기본 내장)을 사용하는 방법과,

https://developer-woong.tistory.com/109

Hive 3.1.3 버전을 유지하되, Trino를 통해 트랜잭션 설정 및 쿼리를 실행하는 방법이 있겠습니다.

https://developer-woong.tistory.com/110

감사합니다.

centos7 기준입니다.

환경:

Hive 4.0.0

Iceberg Hive 4.0.0 내장 라이브러리

Tez 0.10.3

Hadoop 3.3.6

위 환경에서 create, insert, select, update 까지 성공하였으나,

delete 구문 실행 시 아래와 같은 에러가 추출되었습니다.

Vertex did not succeed due to OTHER_VERTEX_FAILURE

이에 yarn 로그를 살펴보니,

java.lang.NoSuchMethodError: org.roaringbitmap.ArrayContainer.add(C)Lorg/roaringbitmap/Container

라는 에러가 발견되었고, 해당 라이브러리는 RoaringBitmap 라이브러리 관련이었습니다.

Hive 4.0.0 버전이 사용하는 RoaringBitmap 버전은 0.9.22였고,

Tez 0.10.3 버전이 사용하는 RoaringBitmap 버전은 0.7.45 버전이었습니다.

이에 기존 tez가 사용하는 RoaringBitmap 라이브러리를 삭제, Hive가 사용하는 RoaringBitmap 라이브러리를 tez lib폴더에 복사한 후, tez-site.xml의  tez.lib.uris 값을 참조하여 tez폴더와 재압축한 파일을 해당 hdfs 경로에 put한 후,

hive를 재기동하여 에러를 해결하였습니다.

감사합니다.

Hive 3.1.3 기준입니다.

Update, Delete등의 질의를 사용하기위해 Hive에 트랜잭션을 설정하겠습니다.

// 영구 적용을 위한 hive_site.xml 설정 값 추가
vi ${HIVE_HOME}/conf/hive-site.xml

        <property>
                <name>hive.support.concurrency</name>
                <value>true</value>
        </property>
        <property>
                <name>hive.enforce.bucketing</name>
                <value>true</value>
        </property>
        <property>
                <name>hive.exec.dynamic.partition.mode</name>
                <value>nonstrict</value>
        </property>
        <property>
                <name>hive.txn.manager</name>
                <value>org.apache.hadoop.hive.ql.lockmgr.DbTxnManager</value>
        </property>
        <property>
                <name>hive.compactor.initiator.on</name>
                <value>true</value>
        </property>
        <property>
                <name>hive.compactor.worker.threads</name>
                <value>2</value>
        </property>

저장 후 hive 재기동 필요

update, delete 테스트

// hive 콘솔 진입
hive

// DB 생성 및 테이블 생성
create database test;
create table test.myOrcTable (col1 string, col2 string) STORED AS ORC TBLPROPERTIES ('transactional' = 'true');

// INSERT
insert into test.myOrcTable values ('1', 'a');
insert into test.myOrcTable values ('2', 'b');

// UPDATE
update test.myOrcTable set col2 = 'c' where col2 = 'b';

// SELECT 확인, 'b' 였던 col2가 'c'로 변경되었는지 확인
select * from test.myOrcTable

// DELETE
delete from test.myOrcTable where col2 = 'a';

// SELECT 확인, col2가 'a'인 행이 삭제되고, 'c' 인 행만 남아있는지 확인
select * from test.myOrcTable

감사합니다.

yarn-site.xml을 통해 모든 작업이 사용 가능한 메모리, 코어를 설정하였습니다.

하지만 어떤 큰 작업을 실행했을 때, 아래 화면과 같이 설정한 vcore를 넘게 사용하는 상황이 발생했습니다.

전체 vcores를 초과하여 사용중

가용가능한 코어가 -로 된 화면

현상을 보시면, 전체 메모리는 넘지않고, 코어는 넘는 상황입니다.

이는 yarn-site.xml의 yarn.scheduler.capacity.resource-calculator값이 org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator  일 때 발생하였는데,

해당 값이 디폴트이고, 이 자원계산기는 오직 메모리만을 기준으로 자원을 할당합니다.

이에 yarn.scheduler.capacity.resource-calculator 값을 org.apache.hadoop.yarn.util.resource.DominantResourceCalculator로 바꾼 후

yarn을 재기동하여 vcore가 설정된 값보다 초과되지않는 것을 확인하였습니다.

감사합니다.

centos7 기준입니다.

ranger-admin이 설치된 환경입니다.

ranger-admin 설치:

https://developer-woong.tistory.com/96

저의 환경에선 mast02,mast03서버가 리소스매니저, mast02서버가 ranger-admin입니다.

1. ranger-2.4.0-yarn-plugin.tar.gz 압축 해제

action server: mast02,mast03

user: root

pwd: -

cmd:

# 기존 ranger 빌드가 완료되어 해당 파일이 존재함을 가정합니다.
cp /opt/apps/ranger/target/ranger-2.4.0-yarn-plugin.tar.gz /opt/apps/ranger-2.4.0-yarn-plugin.tar.gz

# 압축해제 및 권한 부여
cd /opt/apps
tar xvfz ranger-2.4.0-yarn-plugin.tar.gz
chown -R hadoop:hadoop ./ranger-2.4.0-yarn-plugin
su - hadoop
cd /opt/apps/ranger-2.4.0-yarn-plugin

2. enable, disable 스크립트 수정

* root가 아닌 hadoop 계정으로 설치하고, policy cache, conf등의 경로를 직접 설정하는 과정입니다.

action server: mast01,mast02

user: hadoop

pwd: /opt/apps/ranger-2.4.0-yarn-plugin

cmd:

# hdfs-plugin을 root 계정이 아닌 hadoop 계정으로 설치하기위해 아래와 같이 수정합니다.
vi enable-yarn-plugin.sh

if [ ! -w /etc/passwd ]
then
    echo "ERROR: $0 script should be run as root."
    # exit 1 <-- 해당 부분 주석 처리
fi

# vi 화면에서 esc를 누른 후 해당 명령을 실행하고 y로 문자열을 변경해줍니다.
:%s?/etc/${PROJ_NAME}?/opt/apps/ranger-2.4.0-yarn-plugin/etc/${PROJ_NAME}?c

# disable-yarn-plugin.sh 역시 위와 같은 과정으로 수정합니다.

3. install.properties 수정

action server: mast02,mast03

user: hadoop

pwd: /opt/apps/ranger-2.4.0-yarn-plugin

cmd:

vi install.properties

POLICY_MGR_URL=http://mast02:6080
REPOSITORY_NAME=yarn-policy
COMPONENT_INSTALL_DIR_NAME=/opt/apps/hadoop-3.3.5
XAAUDIT.SUMMARY.ENABLE=true
XAAUDIT.SOLR.ENABLE=true
XAAUDIT.SOLR.URL=http://mast02:8983/solr/ranger_audits
XAAUDIT.SOLR.USER=hadoop
XAAUDIT.SOLR.ZOOKEEPER=mast01:2181,mast02:2181,mast03:2181/solr-cloud
XAAUDIT.SOLR.FILE_SPOOL_DIR=/opt/apps/ranger-2.4.0-yarn-plugin/spool
CUSTOM_USER=hadoop
CUSTOM_GROUP=hadoop

mkdir spool

4. 필요 라이브러리 이동

action server: mast02,mast03

user: hadoop

pwd: /opt/apps/ranger-2.4.0-yarn-plugin

cmd:

# 플러그인 활성화에 필요한 라이브러리들을 추가로 복사해줍니다.
cp commons-logging-1.1.3.jar /opt/apps/ranger-2.4.0-yarn-plugin/install/lib/
cp commons-lang3-3.7.jar /opt/apps/ranger-2.4.0-yarn-plugin/install/lib/
cp htrace-core4-4.1.0-incubating.jar /opt/apps/ranger-2.4.0-yarn-plugin/install/lib/ 
cp commons-compress-1.18.jar /opt/apps/ranger-2.4.0-yarn-plugin/install/lib/

5. 플러그인 활성화

action server: mast02,mast03

user: hadoop

pwd: /opt/apps/ranger-2.4.0-yarn-plugin

cmd:

./enable-yarn-plugin.sh

6. ranger service 생성

action server: mast02:6080

user: hadoop

pwd: /opt/apps/ranger-2.4.0-yarn-plugin

cmd:

7. yarn 재시작

action server: mast02

user: hadoop

pwd: /opt/apps/ranger-2.4.0-yarn-plugin

cmd:

/opt/apps/hadoop-3.3.5/sbin/stop-yarn.sh
/opt/apps/hadoop-3.3.5/sbin/start-yarn.sh

mast02:6080 (ranger UI) 내 Audit -> Plugin Status에 플러그인이 연동되었는지 확인합니다.

8. policy 생성

action server: mast02:6080

user: hadoop

pwd: /opt/apps/ranger-2.4.0-hdfs-plugin

cmd:

ranger UI 메인 화면 -> 생성한 hadoop-policy 클릭 -> 우측 상단 Add New Policy 클릭하여 생성 화면으로 진입합니다.

1. 정책 이름을 설정합니다.

2. 기존 정책들을 Override할 것인지 체크합니다.

3. 접근을 제어할 Yarn의 큐입니다. * 표시는 전체 큐에 대해 접근을 제어하겠다는 의미입니다.

4. 접근 가능한 user입니다.

5. 해당 Role, Group, User가 어떤 엑세스에 접근할 수 있는 지 설정합니다.

6. 위 Allow Conditions, 즉, 허용된 Role, Group, User를 제외한 모든 엑세스를 거부한다는 뜻입니다.

7. 해당 사항을 저장합니다.

9. policy 다운로드 확인

action server: mast02:6080

user: hadoop

pwd: /opt/apps/ranger-2.4.0-yarn-plugin

cmd:

mast02:6080 (ranger UI) 내 Audit -> Plugin Status에 플러그인이 변경 혹은 생성된 정책을 다운로드 받았는지 알 수 있습니다. 변경 직후, 느낌표가 뜨게 되며, 느낌표가 사라지면, 다운로드가 완료되었다는 뜻입니다.

10. 접근제어 적용확인

action server: mast02,mast03

user: hadoop

pwd: /opt/apps/ranger-2.4.0-yarn-plugin

cmd:

# hadoop 유저이므로 모든 큐에 대한 엑세스가 통과됩니다.
/opt/apps/spark-3.2.3/bin/pyspark --master yarn --queue test

# hadoop 이외 유저는 모든 큐에 대해 권한이 없습니다.
su - admin
/opt/apps/spark-3.2.3/bin/pyspark --master yarn --queue test

만약 admin이라는 유저도 YARN queue에 접근 가능하게끔하려면, 8. policy 생성 내

USER에 admin을 추가합니다.

감사합니다.

centos7 기준입니다.

ranger 2.4.0, hive 3.1.3이 설치되어있음을 가정합니다. 제 환경에서는 mast02서버에 설치되어있습니다.

hive 설치

https://developer-woong.tistory.com/44

ranger 설치

https://developer-woong.tistory.com/96

ranger 빌드

https://developer-woong.tistory.com/95

1. ranger-2.4.0-hive-plugin.tar.gz 압축 해제

action server: mast02

user: root

pwd: -

cmd:

# 기존 빌드된 파일을 가져와 압축해제합니다.
cp /opt/apps/ranger/target/ranger-2.4.0-hive-plugin.tar.gz /opt/apps

# hadoop 계정으로 설치할 것 입니다.
tar xvfz ranger-2.4.0-hive-plugin.tar.gz
chown -R hadoop:hadoop ranger-2.4.0-hive-plugin

su - hadoop
cd /opt/apps/ranger-2.4.0-hive-plugin

2. enable, disable 스크립트 수정

* root가 아닌 hadoop 계정으로 설치하고, policy cache, conf등의 경로를 직접 설정하는 과정입니다.

action server: mast02

user: hadoop

pwd: /opt/apps/ranger-2.4.0-hive-plugin

cmd:

# hdfs-plugin을 root 계정이 아닌 hadoop 계정으로 설치하기위해 아래와 같이 수정합니다.
vi enable-hdfs-plugin.sh

if [ ! -w /etc/passwd ]
then
    echo "ERROR: $0 script should be run as root."
    # exit 1 <-- 해당 부분 주석 처리
fi

# vi 화면에서 esc를 누른 후 해당 명령을 실행하고 y로 문자열을 변경해줍니다.
:%s?/etc/${PROJ_NAME}?/opt/apps/ranger-2.4.0-hive-plugin/etc/${PROJ_NAME}?c

# disable-hdfs-plugin.sh 역시 위와 같은 과정으로 수정합니다.

3. install.properties 수정

action server: mast02

user: hadoop

pwd: /opt/apps/ranger-2.4.0-hive-plugin

cmd:

vi install.properties

POLICY_MGR_URL=http://mast02:6080
REPOSITORY_NAME=hive-policy
COMPONENT_INSTALL_DIR_NAME=/opt/apps/hive-3.1.3
XAAUDIT.SOLR.ENABLE=true
XAAUDIT.SOLR.URL=http://mast02:8993/solr/ranger_audits
XAAUDIT.SOLR.USER=hadoop
XAAUDIT.SOLR.PASSWORD=NONE
XAAUDIT.SOLR.ZOOKEEPER=mast01:2181,mast02:2181,mast03:2181/solr-cloud
XAAUDIT.SOLR.FILE_SPOOL_DIR=/opt/apps/ranger-2.4.0-hive-plugin/spool
SSL_KEYSTORE_FILE_PATH=/opt/apps/ranger-2.4.0-hive-plugin/conf/ranger-plugin-keystore.jks
SSL_TRUSTSTORE_FILE_PATH=/opt/apps/ranger-2.4.0-hive-plugin/conf/ranger-plugin-truststore.jks
CUSTOM_USER=hadoop
CUSTOM_GROUP=hadoop

# 경로 생성
mkdir conf

4. 플러그인 활성화

action server: mast02

user: hadoop

pwd: /opt/apps/ranger-2.4.0-hive-plugin

cmd:

./enable-hive-plugin.sh

4. ranger 서비스 생성

action server: mast02:6080

user: hadoop

pwd: /opt/apps/ranger-2.4.0-hive-plugin

cmd:

5. hive 재시작

action server: mast02

user: hadoop

pwd: /opt/apps/ranger-2.4.0-hive-plugin

cmd:

# hiveserver, hivemetastore 프로세스 2개를 종료합니다.
kill -9 [RunJar_PID] 

# 재기동합니다.
nohup hive --service hiveserver2 >> /data/hive/log/hiveserver2.log 2>&1 &
nohup hive --service metastore >> /data/hive/log/hive-metastore.log 2>&1 &

mast02:6080 (ranger UI) 내 Audit -> Plugin Status에 플러그인이 연동되었는지 확인합니다.

6. policy 생성

action server: mast02:6080

user: hadoop

pwd: /opt/apps/ranger-2.4.0-hive-plugin

cmd:

ranger UI 메인 화면 -> 생성한 hive-policy 클릭 -> 우측 상단 Add New Policy 클릭하여 생성 화면으로 진입합니다.

1. 정책 이름을 설정합니다.

2. 기존 정책들을 Override할 것인지 체크합니다.

3. 어떤 Hive 정보에 접근을 제한 및 허용할지 선택합니다. * 표시는 전체를 뜻합니다.

4. 접근 가능한 user입니다.

5. 해당 Role, Group, User가 어떤 엑세스에 접근할 수 있는 지 설정합니다.

6. 위 Allow Conditions, 즉, 허용된 Role, Group, User를 제외한 모든 엑세스를 거부한다는 뜻입니다.

7. 해당 사항을 저장합니다.

7. policy 다운로드 확인

action server: mast02:6080

user: hadoop

pwd: /opt/apps/ranger-2.4.0-hive-plugin

cmd:

mast02:6080 (ranger UI) 내 Audit -> Plugin Status에 플러그인이 변경 혹은 생성된 정책을 다운로드 받았는지 알 수 있습니다. 변경 직후, 느낌표가 뜨게 되며, 느낌표가 사라지면, 다운로드가 완료되었다는 뜻입니다.

8. 접근 제어 확인

action server: mast02

user: hadoop

pwd: /opt/apps/ranger-2.4.0-hive-plugin

cmd:

* 확인은 DBeaver를 통해 확인하겠습니다.

hadoop 유저로 접근하였습니다.

hadoop 유저는 모든 엑세스 권한을 가지고있기에 모든 데이터베이스들이 표출됩니다.

admin 유저로 접근하였습니다.

admin 유저는 엑세스 권한이 없기 때문에 데이터베이스가 표출되지않습니다.

ranger를 통해 hive 접근 제어 시, HDFS와도 밀접한 연관이 있습니다.

예를 들어, 이전 포스팅에서 ranger와 hdfs가 통합되어있고, hadoop 계정 이외에 모든 HDFS 엑세스를 거부했다면,

admin이라는 계정으로 hive 콘솔 진입 시, 나타나는 Access Deniend는 HDFS 플러그인에서 보안이 걸린 경우도 발생합니다. 이는 Hive 관련 임시 폴더나, 데이터 들은 HDFS 상에 저장되기 때문입니다.

이에, Ranger 내 HDFS, HIVE 정책을 유심히 설정해야 관리가 쉬워질 수 있습니다.

감사합니다.