728x90

docker 설치 중 오류를 발견했다. 

 

 

$ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

 

File "/bin/yum-config-manager", line 135 except yum.Errors.RepoError, e: ^ SyntaxError: invalid syntax

 

 

- Python 2.x 와 Python 3.x의 문법 차이로 인한 문제이다.

   (yum-config-manager가 Python 2.x 구문을 사용하여 작성된 스크립트인데, 현재 시스템에서 기본 Python이 3.x로 설정되어 있어서 발생하는 문제)

- yum-utils 패키지를 재설치하고, yum-config-manager를 다시 사용할 수 있는 방법을 찾아야 한다.

 

 

1. yum-utils 패키지 설치

sudo yum install -y yum-utils

 

: yum-config-manager를 사용할 수 있도록 한다.

 

 

 

2. yum-config-manager 재실행

sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

 

 

 

3. Docker 설치

 

$sudo yum install -y docker-ce docker-ce-cli containerd.io

$sudo systemctl start docker
$sudo systemctl enable docker

$sudo systemctl status docker

728x90

1. ORC (Optimized Row Columnar)

create table orc_table (
col1 string, 
col2 string, 
col3 int
)
 STORED AS ORC
;

 

  • 특징:
    • Hadoop에서 최적화된 컬럼 기반 저장 포맷.
    • 데이터를 컬럼 단위로 저장해 쿼리 성능이 빠름.
    • Zlib과 Snappy와 같은 고압축 지원.
    • Hive 전용 포맷으로 다른 시스템과의 호환성이 낮음.
  • 장점:
    • 압축률이 높고, 읽기 성능이 뛰어남.
    • 복잡한 분석 쿼리에서 최적화된 성능 제공.
  • 단점:
    • 데이터 적재 전에 포맷 변환이 필요하며, LOAD DATA 명령어를 지원하지 않음.

 

 

 

 

 

2. Parquet

CREATE TABLE parquet_table (
    col1 STRING,
    col2 STRING,
    col3 INT
)
STORED AS PARQUET;

 

 

  • 특징:
    • Hadoop에서 최적화된 컬럼 기반 저장 포맷.
    • 데이터를 컬럼 단위로 저장해 쿼리 성능이 빠름.
    • Zlib과 Snappy와 같은 고압축 지원.
    • Hive 전용 포맷으로 다른 시스템과의 호환성이 낮음.
  • 장점:
    • 압축률이 높고, 읽기 성능이 뛰어남.
    • 복잡한 분석 쿼리에서 최적화된 성능 제공.
  • 단점:
    • 데이터 적재 전에 포맷 변환이 필요하며, LOAD DATA 명령어를 지원하지 않음.

 

!! STORED AS PARQUET는 내부적으로 올바른 InputFormat 및 OutputFormat 클래스를 자동으로 설정합니다.

 

 

 

 

 

 

3. CSV (Textfile)

CREATE TABLE csv_table (
  col1 STRING,
  col2 STRING,
  col3 INT
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
STORED AS TEXTFILE;

 

CREATE TABLE csv_table_partitioned (
  col1 STRING,
  col2 STRING,
  col3 INT
)
PARTITIONED BY (part_col STRING)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
STORED AS TEXTFILE;

 

  • 특징:
    • 텍스트 기반 포맷으로 간단하고 가독성이 좋음.
    • Hadoop에서 기본적으로 지원되며, 별도 라이브러리가 필요하지 않음.
    • 대량 데이터 처리에서는 비효율적(압축 없음, 스키마 없음).
  • 장점:
    • 데이터 적재와 읽기가 매우 간단하며, LOAD DATA 명령어 사용 가능.
  • 단점:
    • 데이터 스키마를 보장하지 않으며, 크기가 크고 느림.

 

 

 

 

4. Avro

create table avro_table (
col1 string, 
col2 string, 
col3 int
)
 STORED AS AVRO
;

 

 

  • 특징:
    • 행 기반 포맷으로 스키마를 데이터와 함께 저장.
    • JSON 기반으로 직렬화/역직렬화가 쉬움.
    • Hive 외에 Kafka, Spark 등 다양한 환경에서 사용.
  • 장점:
    • 스키마 변경에 유연하며, 스키마와 데이터를 함께 관리 가능.
    • 다양한 언어와 도구에서 지원됨.
  • 단점:
    • 스키마 저장으로 인해 데이터 크기가 커질 수 있음.
    • LOAD DATA를 지원하지 않음.

 

728x90

PostgreSQL에서 replica identity는 Logical Replication 또는 Change Data Capture (CDC)를 사용할 때 중요합니다.

replica identity가 설정되지 않으면 DELETE 작업을 포함한 일부 작업이 실패하게 됩니다. 오류 메시지가 말하는 바는 다음과 같습니다.

원인

  • Replica Identity 미설정: 테이블이 복제 식별자가 설정되지 않았기 때문에, PostgreSQL은 DELETE 요청을 처리할 수 없습니다. PostgreSQL의 기본 설정은 replica identity가 없는 테이블에서 DELETE 작업을 지원하지 않으며, 이는 데이터 변경 사항이 소비자에게 올바르게 전달될 수 없도록 합니다.

해결 방법

cdc_table에 대한 replica identity를 설정하여 이 문제를 해결할 수 있습니다. PostgreSQL에서는 다음과 같은 방법으로 설정할 수 있습니다:

  1. REPLICA IDENTITY 설정: 다음 SQL 명령어를 사용하여 cdc_table의 replica identity를 설정합니다.
    • FULL: 전체 행의 데이터를 복제하는 설정입니다. 이 방법은 DELETE 요청을 포함한 모든 변경 사항을 처리할 수 있게 합니다.
    • USING INDEX <index_name>: 특정 인덱스를 사용하여 복제 식별자를 설정할 수도 있습니다. 이 경우 인덱스가 필요합니다.
  2.  
    코드 복사
    ALTER TABLE public.cdc_table REPLICA IDENTITY FULL;
  3. sql
  4. REPLICA IDENTITY 상태 확인: 테이블의 현재 replica identity 상태를 확인하려면 다음 쿼리를 사용할 수 있습니다.
    • relreplident의 값이 d인 경우 (d는 'default'를 의미) 설정이 되어 있지 않은 것입니다. f는 full 설정을, i는 인덱스 기반 복제를 의미합니다.
  5. sql
    코드 복사
    SELECT relname, relreplident FROM pg_class WHERE relname = 'cdc_table';
  6. 변경 사항 확인: REPLICA IDENTITY 설정 후, DELETE 작업을 다시 시도하여 문제가 해결되었는지 확인합니다.
728x90

배경 : 

환경변수 설정 전에 백그라운드 실행(nohup) 한 스크립트가, 환경변수 설정을 여전히 적용하지 못함

 

 

해결 : 

 

환경변수 설정 후에는 반드시 스크립트를 재실행해야 그 환경변수가 적용된다.
이전에 nohup으로 실행한 스크립트는 당시의 환경변수로만 작동하며, 환경변수를 변경해도 이미 실행 중인 프로세스에는 반영되지 않는다.

1. 환경변수 적용 시점

스크립트에서 사용하는 환경변수는 스크립트 실행 당시의 쉘 환경에 따라 결정된다.

nohup을 통해 백그라운드에서 스크립트를 실행했을 때, 그 스크립트는 당시 실행된 쉘에서 설정된 환경변수를 그대로 사용한다.

2. 백그라운드에서 실행된 스크립트

백그라운드에서 실행된 스크립트는 실행 시점의 환경변수를 참조한다.

즉, nohup으로 실행한 스크립트는 실행 당시의 환경을 복사하여 사용.

그 후에 환경변수를 수정하더라도 이미 실행 중인 프로세스에는 그 변경 사항이 반영되지 않는다.

예를 들어:

  • nohup으로 스크립트를 실행할 당시, Hive 환경변수가 설정되어 있지 않았다면 그 스크립트는 환경변수가 없는 상태에서 실행되며, 이후 환경변수를 설정해도 이미 실행 중인 스크립트에는 영향을 주지 않음.
  • 다시 말해, 그 스크립트는 이전에 설정되지 않은 환경변수를 계속 사용.

3. 해결 방법

환경변수를 적용한 후에 스크립트를 제대로 실행하려면, nohup으로 다시 실행.

환경변수 변경 후에 실행하지 않으면, 스크립트는 이전에 적용된 상태로만 실행!

스크립트를 재실행하지 않는다면, 그 스크립트는 여전히 이전 환경에서 작동할 것이므로 hive -e 명령이 실패하거나, 올바른 Hive 설정을 찾지 못할 수 있다

728x90

 

오류 내용 :

Caused by: java.io.IOException: javax.security.sasl.SaslException: DIGEST-MD5: No common protection layer between client and server at org.apache.hadoop.ipc.Client$Connection$1.run(Client.java:755) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1899) at org.apache.hadoop.ipc.Client$Connection.handleSaslConnectionFailure(Client.java:709) at org.apache.hadoop.ipc.Client$Connection.setupIOstreams(Client.java:813) at org.apache.hadoop.ipc.Client$Connection.access$3800(Client.java:363) at org.apache.hadoop.ipc.Client.getConnection(Client.java:1649) at org.apache.hadoop.ipc.Client.call(Client.java:1474)

 

 

For more detailed output, check the application tracking page: http://호스트:38088/cluster/app/application_1727638811672_0119 Then click on links to logs of each attempt. . Failing the application. at org.apache.tez.client.TezClientUtils.getAMProxy(TezClientUtils.java:945) at org.apache.tez.client.FrameworkClient.getProxy(FrameworkClient.java:187) at org.apache.tez.client.FrameworkClient.shutdownSession(FrameworkClient.java:176) at org.apache.tez.client.TezClient.stop(TezClient.java:738) at org.apache.hadoop.hive.ql.exec.tez.TezSessionState.closeAndIgnoreExceptions(TezSessionState.java:480) at org.apache.hadoop.hive.ql.exec.tez.TezSessionState.startSessionAndContainers(TezSessionState.java:473) at org.apache.hadoop.hive.ql.exec.tez.TezSessionState.access$100(TezSessionState.java:101) at org.apache.hadoop.hive.ql.exec.tez.TezSessionState$1.call(TezSessionState.java:376) at org.apache.hadoop.hive.ql.exec.tez.TezSessionState$1.call(TezSessionState.java:371) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.lang.Thread.run(Thread.java:748) 2024-10-17 15:03:35,913 INFO client.TezClient: Could not connect to AM, killing session via YARN, sessionName=HIVE-4141fb36-7eda-485a-964d-2e41d72d815f, applicationId=application_1727638811672_0119 2024-10-17 15:03:35,917 INFO impl.YarnClientImpl: Killed application application_1727638811672_0119 2024-10-17 15:03:35,918 ERROR tez.TezSessionState: Failed to start Tez session org.apache.tez.dag.api.SessionNotRunning: TezSession has already shutdown. Application application_1727638811672_0119 failed 2 times due to AM Container for appattempt_1727638811672_0119_000002 exited with exitCode: 1 Failing this attempt.Diagnostics: [2024-10-17 15:03:35.842]Exception from container-launch. Container id: container_e16_1727638811672_0119_02_000001 Exit code: 1

 

 

 

 

 

 

 

그 전에 Hadoop 에서 고객사가 요청한 보안 사항을 적용 후 Hadoop 재실행을 했는데, 

Yarn 은 하지 않았다. 

 

 

Yarn 을 재실행하니 해결됐는데, 그 이유는 

 

YARN이 재시작되면서 클러스터 내 모든 노드 간의 통신과 인증이 다시 설정되었기 때문.
YARN의 NodeManagerResourceManager 간의 통신이나 인증 문제가 초기화되고, Hive와의 SASL 연결이 정상적으로 설정되었을 가능성이 크다.

 

 

 

또, Tez가 실행될 때 HDFS를 읽는 것이 일반적이며, Tez는 대규모 데이터 처리 엔진으로, 주로 HDFSYARN과 통합되어 동작하며, 데이터를 처리하는 과정에서 HDFS에 저장된 데이터를 읽고 쓸 수 있다.

728x90

- Kafka Connector?

 

Kafka ConnectorApache Kafka의 데이터 파이프라인을 구성하기 위한 구성 요소로, 외부 시스템(데이터베이스, 메시징 시스템, 파일 시스템 등)과 Kafka 클러스터 간의 데이터 전송을 자동화하는 역할을 합니다.

 

 

 

1. Connector 의 Log 및 설정 변경

 

- connector 설정 변경
vi /usr/local/kafka/config/connect-distributed.properties
# plugin.path=/usr/local/share/java,/usr/local/share/kafka/plugins,/opt/connectors,
plugin.path=/usr/local

- connector 로그 설정
vi /usr/local/kafka/config/connect-log4j.properties
log4j.rootLogger=INFO, stdout, connectAppender,file
log4j.appender.connectAppender.File=/usr/local/kafka/logs/connect.log

 

 

 

 

2. Connector 실행

$ bin/connect-distributed.sh config/connect-distributed.properties

 

 

 

 Connector가 실행되면 INFO 가 계속 뜨고, 

설정한 Log 에서도 동일하게 로그가 뜬다. 

 

 

만약 디비지움에서 성공적으로 커넥터에 연결 시 위처럼 연결 성공 로그가 뜨니 참고 ! 

728x90

Debezium 2.5 버전 기준으로 PostgreSQL은 10부터, Java는 11 이상부터 활용 가능합니다. 

kafka, Zookeeper 가 실행중임을 가정합니다.

 

 

 

 

1. Debezium Download

 

디비지움 공홈에서 plugin 다운받기!

- 필자는 debezium-connector-postgres-2.5.1.Final-plugin.tar 파일 활용했습니다.

https://debezium.io/releases/2.5/#installation

 

Debezium Release Series 2.5

Debezium is an open source distributed platform for change data capture. Start it up, point it at your databases, and your apps can start responding to all of the inserts, updates, and deletes that other apps commit to your databases. Debezium is durable a

debezium.io

 

 

 

 

 

2. Connector 설정 변경

(1) Connector 설정 변경

plugin.path 설정 변경해주기. (Debezium 설치된 상위디렉토리)

$ vi 카프카디렉토리/config/connect-distributed.properties

 

#plugin.path=/usr/local/share/java,/usr/local/share/kafka/plugins,/opt/connectors,
plugin.path=/opt/

 

 

(2) Connector 로그 설정

$ vi 카프카디렉토리/config/connect-log4j.properties

 

log4j.rootLogger=INFO, stdout, connectAppender,file
log4j.appender.connectAppender.File=/usr/local/kafka/logs/connect.log

 

 

커넥터 로그를 확인할 수 있게 file 옵션 추가 및 디렉토리 지정.

 

 

 

 

3. Connector 설정

Kafka 연결할 수 있는 Json 파일 설정

참고 : https://debezium.io/documentation/reference/stable/connectors/postgresql.html#postgresql-server-configuration

 

Debezium connector for PostgreSQL :: Debezium Documentation

Tombstone events When a row is deleted, the delete event value still works with log compaction, because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that same key, the message value must

debezium.io

 

 

postgresql-connector-db.json

plugin.name 을 pgoutput 으로 설정해줘야 한다 !

 

 

 

4. Kafka Connector 실행

 

https://2youz.tistory.com/104

 

Kafka Connector 설정 / 시작 (PostgreSQL Debezuim)

- Kafka Connector? Kafka Connector는 Apache Kafka의 데이터 파이프라인을 구성하기 위한 구성 요소로, 외부 시스템(데이터베이스, 메시징 시스템, 파일 시스템 등)과 Kafka 클러스터 간의 데이터 전송을 자

2youz.tistory.com

 

 

5. Debezium Connector Curl 등록

 

 

 

6. 테스트 및 결과 확인

 

 

디비지움은 Insert, Delete, Update 만 추적 가능하고, 
payload 의 결과값을 보고 확인 가능!

 

해당 값을 보고 Topic 을 예쁘게 수정해서 다양하게 활용할 수 있다. !!!

728x90

Postgresql 의 CDC 관리를 위해 Postgresql 설정 변경 하는 법 !

 

 

1. wal 상태 변경 (default : minimal)

Write-Ahead Logging (WAL) - Database의 변경 사항을 기록하는 로그
: 얼마나 많은 정보를 기록할지를 결정하는 설정입니다. 이 옵션은 데이터 복구, 복제, 또는 Change Data Capture(CDC) 등의 기능을 위해 중요한 역할을 합니다.

postgresql.conf

 

1. minimal

  • 설명: 최소한의 WAL 로그만 기록합니다. 주로 데이터베이스의 성능을 극대화하기 위한 용도로 사용됩니다.
  • 용도: 데이터베이스 복구만을 목표로 하고, **복제나 PITR(시점 복구)**를 사용하지 않을 경우에 적합합니다.
  • 제한사항: 이 설정은 복제(replication)나 **백업에서 시점 복구(PITR)**를 할 수 없습니다.

2. replica

  • 설명: WAL 로그에 데이터 복구와 복제(replication)를 위한 정보를 추가로 기록합니다.
  • 용도: 동기식 또는 비동기식 복제를 사용할 때 적합하며, 데이터베이스 복구와 **백업에서 시점 복구(PITR)**를 지원합니다.
  • 특징: 대부분의 기본적인 복제 시스템에서 사용되는 옵션입니다.

3. logical

  • 설명: replica에서 기록하는 정보에 더해, 논리적 복제와 **Change Data Capture (CDC)**에 필요한 추가 정보를 기록합니다.
  • 용도: 테이블 데이터의 변경 사항을 논리적 복제Kafka와 같은 스트리밍 시스템으로 전송하고 싶을 때 설정합니다. 주로 CDC 작업을 위해 사용됩니다.
  • 특징: 이 설정은 테이블의 구조 및 행 단위의 변경 사항을 추적할 수 있으며, 이를 통해 외부 시스템과의 연동이 가능합니다.

 

 

 

 

 

 

 

2. pgoutput 변경

postgresql.conf

 

PostgreSQL의 WAL을 기록하는 로그인데, WAL은 텍스트가 아닌 바이너리 형식으로 저장됨.

wal 데이터 중 일부.

하여 이 파일을 읽기 위해 다양한 디코더를 제공하는데, 이 디코더는 WAL 파일의 형식을 이해하고, 필요한 정보를 추출하여 논리적 형식으로 변환함. 

 

 

(1) pgoutput

  • 정의: pgoutput은 PostgreSQL의 논리적 복제에서 사용되는 기본 디코더입니다. 이 디코더는 WAL의 변경 사항을 논리적 데이터 변경 이벤트로 변환합니다.
  • 특징:
    • 논리적 복제: pgoutput은 기본적으로 PostgreSQL의 논리적 복제를 지원합니다. 이를 통해 사용자는 데이터를 복제하는 다른 서버에 데이터를 전송할 수 있습니다.
    • 변경 사항 표현: 데이터 변경(INSERT, UPDATE, DELETE) 시 각각의 변경 사항을 명확하게 식별하여 출력합니다.
    • 유연성: 여러 테이블과 필드를 포함한 복제 및 구독을 설정할 수 있어 유연한 데이터 복제 환경을 제공합니다.
  • 용도: 주로 Debezium과 같은 CDC(변경 데이터 캡처) 도구에서 사용하여 데이터베이스의 변경 사항을 Kafka와 같은 메시징 시스템으로 전송할 때 활용됩니다.

(2) decoderbufs

  • 정의: decoderbufs는 PostgreSQL의 논리적 복제에 사용되는 또 다른 디코더입니다. 이 디코더는 데이터를 보다 효율적으로 압축하여 처리할 수 있는 기능을 제공합니다.
  • 특징:
    • 압축된 형식: decoderbufs는 변경 사항을 보다 압축된 형식으로 출력하므로 데이터 전송량을 줄이고 성능을 향상시킬 수 있습니다.
    • 모든 변경 사항 기록: 이 디코더는 INSERT, UPDATE, DELETE를 포함하여 모든 데이터 변경 사항을 기록합니다.
    • 전문가용: decoderbufs는 주로 성능이 중요한 대규모 데이터베이스 환경에서 사용됩니다.
  • 용도: 고속 데이터 전송이 필요한 상황에서 사용되며, Debezium과 같은 CDC 도구와 함께 사용할 수 있습니다.

요약

  • pgoutput: PostgreSQL의 기본 디코더로, 논리적 복제를 지원하며 데이터 변경을 명확하게 출력.
  • decoderbufs: 압축된 형식으로 데이터를 전송하여 성능을 향상시키는 디코더로, 고속 데이터 전송이 필요한 경우에 적합.

 

 

 

 

3. Postgresql 재시작

 

 

 

- 변경사항 확인 

 

 

 

 

 

728x90

NiFi 2.0에서 이전 버전에서 사용되었던 템플릿 기능이 제거되었습니다.

 

하지만, NiFi 2.0에서는 템플릿 기능을 대체할 수 있는 방법이 있습니다.

 

 

 

- Flow Definition Export

NiFi 2.0에서는 템플릿 기능을 대체하기 위해 데이터 흐름을 JSON 형식으로 내보내고 가져오는 기능이 있습니다.

 

 

 

 

1. Flow Export (내보내기)

  • NiFi UI에서 원하는 프로세스 그룹을 선택합니다.
  • 메뉴에서 "Download flow definition"  옵션을 사용해 흐름을 JSON 파일로 내보낼 수 있습니다.

 

 

 

import 할 그룹을 우클릭 → Download flow definition → with external services

 

 

  • With external services를 사용하는 경우:
    • 데이터베이스 연결, HDFS 설정, 또는 다른 컨트롤러 서비스를 포함한 복잡한 환경을 다른 NiFi 인스턴스에 그대로 옮기고자 할 때 유용합니다.
  • With external services를 사용하지 않는 경우:
    • 기본적인 데이터 흐름만을 공유하고, 외부 서비스는 현지 환경에 맞춰 설정하려는 경우에 유용합니다. 예를 들어, 다른 데이터베이스나 시스템을 사용하는 환경으로 흐름을 이식할 때 이 옵션을 해제할 수 있습니다.

 

 

 

 

2. Flow Import (가져오기)

 

 

 

Add Process group → Browse → 다운받았던 Json 파일 선택

 

 

 

 

 

 

 

이렇게 하면 손쉽게 import 기능 사용 가능!

 

 

+ 이전 버전에서도 있던 기능이기에 버전 상관없이 사용할 수 있습니다!

다만 모든 프로세서가 동작하는지는 확인이 필요할 듯 합니다.

 

728x90

du

현재 디렉토리 기준으로 하위 디렉토리의 용량을 확인하는 명령어

 

 

 

옵션

-a : 모든 파일표시

-b : 표시단위 (Byte)

-k : 표시단위 (KB)

-h : 사용량을 K(키로바이트), M(메가바이트), G(기가바이트) 등의 형태로 보여준다

-s : 총 사용량만 표시한다

 

 

 

 

자주 사용하는 옵션

du -sh ./*

: 하위 모든 디렉토리의 총 사용량을 표시단위까지 출력

+ Recent posts