이유즈 데엔 여정

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를 지원하지 않음.

오류 내용 :

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의 NodeManager와 ResourceManager 간의 통신이나 인증 문제가 초기화되고, Hive와의 SASL 연결이 정상적으로 설정되었을 가능성이 크다.

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

배경) 

스탠바이 네임노드, 데이터노드에서 각 소프트웨어( 저널노드, 네임노드, zkfc , datanode 등)

root 계정이 아닌, 다른 계정으로 실행 하고

Actuve NameNode에서 root 계정으로 저널노드, 네임노드, zkfc 를 실행했을 때

yarn 실행 시 

실행이 안된다. 

https://bloodguy.tistory.com/m/entry/Hadoop-hdfs-yarn-%EA%B4%80%EB%A0%A8-%EB%8D%B0%EB%AA%AC%EC%9D%84-root%EB%A1%9C-%EC%8B%A4%ED%96%89%ED%95%A0-%EB%95%8C-%EC%97%90%EB%9F%AC-%EB%B0%9C%EC%83%9D%EC%8B%9C

- 가장 최선의 방법은 root 로 실행한 프로세서를 kill 하고, 처음 실행했던 계정으로 다시 실행하기. 

- 혹은, 위의 블로그처럼 etc/hadoop/hadoop-env.sh 에 각 사용자를 root로 등록해주기.

Hadoop에서 "split brain"은 주로 고가용성(High Availability) 설정에서 발생하는 문제를 가리킵니다.

Split brain은 네트워크 분할이나 네임노드 간 통신 장애로 인해 클러스터의 네임노드들이 서로 독립적으로 운영되는 상태를 의미합니다.

일반적으로 Hadoop의 고가용성 구성에서는 두 개의 네임노드가 서로 통신하여 클러스터 상태를 동기화합니다.

하지만 네트워크 분할이 발생하거나 네임노드 간 통신이 실패하는 경우,

각 네임노드는 자신이 활성(active)인지 스탠바이(standby)인지 판단할 수 없게 됩니다.

이렇게 되면 각각의 네임노드가 독립적으로 파일 시스템에 대한 읽기 및 쓰기 작업을 수행할 수 있게 됩니다.

이러한 상황에서는 데이터의 불일치가 발생할 수 있으며, 클러스터의 안정성과 일관성이 보장되지 않습니다.

Split brain을 방지하기 위해 Hadoop은 주로 주키퍼(ZooKeeper)와 같은 조정자 서비스를 사용하여 네임노드 간의 통신 및 상태 동기화를 관리합니다.

주키퍼를 사용하면 네임노드 간의 네트워크 분할이나 통신 장애를 탐지하고,
정확한 활성 네임노드를 선정하여 클러스터의 일관성을 유지할 수 있습니다.

따라서 split brain은 Hadoop 클러스터에서 중대한 문제를 발생시킬 수 있는 상황이며, 이를 방지하기 위해서는 적절한 고가용성 설정과 조정자 서비스의 사용이 필요합니다.

배경 )

호스트명 test1, test2 --> namenode 이중화

현상 )

1. 정상동작

일 때, 

test1 namenode stop 시

-->

test2 namenode active 정상 변경 완료

2. 비정상동작

일 때, 

test2 namenode stop 시

-->

test1 namenode active 변경 실패. (standby상태 유지)

2-1. 

위의 상태에서, 

test2 namenode start 시 

test1, test2 모두 standby 상태.

해결 )

1번 현상에서 failover가 정상동작하는걸로 보아, 

zkfc 실행 자체에는 문제가 없다고 판단, 

fencing 작업에 문제 가능성 발견.

test1의 

zkfc logs 파일 ( hadoop-유저명-zkfc-test2.log )  에서

 PATH=$PATH:/sbin:/usr/sbin fuser -v -k -n tcp 8020 via ssh: bash: fuser: command not found

fuser의 command not found 발견 !

--> test1 내 fuser 설치해주기. 

# yum -y install psmisc

참고 : https://coconuts.tistory.com/730

정리 ) 

1. test1, test2 에서 zkfc가 각각의 실행상태를 바라보고있을 때, 

2. test1 이 종료되어

3. test2를 zkfc가 standby  -->  active상태로 변경하기 위해

4. test1 에 접속시도를 할 때, fuser 사용.   --> split brain 현상 발생

5. test1 fuser 설치

6. 해결완료

Sol2 ) 

https://hadoop.apache.org/docs/r3.2.2/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html

sshfence 로 설정했을 시 

1. 이 포스팅 내용과 같이 패키지설치가 안되어 오류가 나거나, 

2. 누가 랜선을 뽑으면 ssh 연결이 안되어 오류가 날 수 있다. 

이를 방지하기 위해 

다양한 옵션이 있는데

shell 로 옵션을 주면, 

연결 시 True 값을 반환하며 연결 완료를 확인할 수 있다. 

Sol3)

sshfence 와 shell 옵션을 둘 다 주어

sshfence 로 연결이 완료될 때까지 timeout 상태로 대기 후

shell 의 True 로 연결을 확인하는 방법도 있다 !

vi workers

hadoop 1인가? 에서 master 도 있었다는데 

지금은 없음. 

원래 데이터노드만 적어야 하는데 
데이터노드 원래 필수 3대 있어야 하는데 우리는 서버 3대밖에 없으니 일단 다 적음. ( 네임노드든 데이터노드든 다 적어도 되긴 함 ) 
원래는 데이터노드들만 적긴 함

/home/hadoop/etc/hadoop/core-site.xml

- 클러스터 내의 네임노드에서 실행되는 하둡 데몬에 관한 설정

-로그파일, 네트워크 튜닝, I/O튜닝, 파일 시스템 튜닝, 압축 등 하부 시스템 설정 파일

- HDFS(hdfs-site.xml)와 맵리듀스(mapred-site.xml)에서 공통적으로 사용할 환경정보 설정

-만약 core-site.xml 이 없을 경우 core-default.xml 에 있는 기본값을 사용한다.

vi core-site.xml

fs.defaultFS

- hdfs의 기본 이름. 

    hdfs dfs -ls 명령어 가능하게 하기 위해 쓴다 !

    만약 안쓴다면 hdfs dfs -ls hdfs://HA ~... 이렇게 써야할 것이다. 참으로 귀찮은 일이 아닐 수 없다.

- URI 형태

- 데이터 노드는 여러 작업을 진행하기 위해 반드시 네임노드의 주소를 알아야 함

ha.zookeeper.quorum

- 주키퍼 HA 구성시 사용

- 구성 갯수는 3, 5, 7과 같은 홀수개로 구성

    ( 짝수개여도 문제는 없지만, 장애 발생 시 과반수 이상이 동의해야 중단되어야 하는데 짝수는 의미가 없기 때문이다. )

     ( 참고 : https://paulsmooth.tistory.com/156 )

- 주키퍼 설정파일에서 포트를 2181로 설정하지 않았으면 설정한 포트로 수정할 것

< 다른 옵션 >

fs.default.name

- hdfs-site.xml 에서 설정한 하둡 클러스터의 이름으로 설정

hadoop.tmp.dir

- hdfs와 yarn이 사용할 임시 디렉토리

- 하둡에서 발생하는 임시 데이터를 저장하기 위한 공간

- 디폴트로 /root/tmp 에 데이터를 생성함

네임노드, 보조 네임노드, 데이터노드 등과 같은

- dfs.namenode.name.dir : 네임노드가 영속적인 메타데이터를 저장할 디렉토리 목록을 지정한다. 네임노드는 메타데이터의 복제본을 목록에 디렉토리별로 지정한다. 

- dfs.datanode.name.dir : 데이터노드가 블록을 저장할 디렉토리의 목록. 각 블록은 이 디렉터리 중 오직 한 곳에서만 저장한다. 

참고 : https://velog.io/@anjinwoong/Hadoop

fencing ? 

--> active 노드에서 장애발생으로 standby 가 active 로 전환될 때, 

    그 찰나에 active 노드의 장애가 해결되어 다시 정상으로 돌아와 active 중복이 되는 상황을 막기 위해 

    장애복구컨트롤러(failover) 가 기존 active 노드를 확실히 죽인다.

Namenode 를 HA 구성하여 SPOF(Single Point Of Failure)에서 벗어났지만,

이번엔 리소스관리자인 YARN이 또다른 SPOF입니다.

Resource Manager를 HA 구성해야 합니다. 

참고 : https://tdoodle.tistory.com/entry/Hadoop-Resource-Manager-HA-%EA%B5%AC%EC%84%B1%ED%95%98%EA%B8%B0

- framework.name : yarn 을 사용하겠다. 

<configuration>

	<!-- Site specific YARN configuration properties -->
	<property>
		<name>yarn.nodemanager.aux-services</name>
		<value>mapreduce_shuffle</value>
	</property>
	<property>
		<name>yarn.nodemanager.aux-services.mapreduce_shuffle.class</name>
		<value>org.apache.hadoop.mapred.ShuffleHandler</value>
	</property>
	<property>
		<name>yarn.nodemanager.local-dirs</name>
		<value>/home/hadoop/hadoopdata/yarn/nm-local-dir</value>
	</property>
	<property>
		<name>yarn.resourcemanager.fs.state-store.uri</name>
		<value>/home/hadoop/hadoopdata/yarn/system/rmstore</value>
	</property>
	<property>
		<name>yarn.resourcemanager.hostname</name>
		<value>hadoop01</value>
	</property>
 	<property>
		<name>yarn.web-proxy.address</name>
		<value>0.0.0.0:8089</value>
	</property>

	<!-- for Resource Manager HA configuration -->
	<property>
		<name>yarn.resourcemanager.ha.enabled</name>
		<value>true</value>
	</property>
	<property>
		<name>yarn.resourcemanager.cluster-id</name>
		<value>cluster1</value>
	</property>
	<property>
		<name>yarn.resourcemanager.ha.rm-ids</name>
		<value>rm1,rm2</value>
	</property>
	<property>
		<name>yarn.resourcemanager.hostname.rm1</name>
		<value>hadoop01</value>
	</property>
	<property>
		<name>yarn.resourcemanager.hostname.rm2</name>
		<value>hadoop02</value>
	</property>
	<property>
		<name>yarn.resourcemanager.webapp.address.rm1</name>
		<value>hadoop01:8088</value>
	</property>
	<property>
		<name>yarn.resourcemanager.webapp.address.rm2</name>
		<value>hadoop02:8088</value>
	</property>
	<property>
		<name>hadoop.zk.address</name>
		<value>hadoop01:2181,hadoop02:2181,hadoop03:2181</value>
	</property>

</configuration>

- yarn.nodemanager.aux-services 속성은 mapreduce.shuffle이라는 보조 서비스를 사용할지를 노드매니저에 알려준다. 보조 서비스를 구현하는 노드매니저에 전달한 후, 서비스를 구현하는 수단으로서 클래스 이름을 전달한다. 이런 특정 설정을 통해 어떤 방식으로 셔플이 일어날지를 맵리듀스에게 알려준다. 기본적으로 비 맵리듀스 잡에 대해서는 노드매니저가 데이터를 셔플하지 않기 때문에, 맵리듀스 서비스를 설정할 필요가 있다.

- yarn.resourcemanager.recovery.enabled : ResourceManager 시작 시 state 복구 여부

https://bloodguy.tistory.com/entry/Hadoop-YARN-ResourceManager-HA-HighAvailability

* 중요 yarn 데몬 속성

https://wikidocs.net/23575

vi hadoop-env.sh  

jdk , hadoop 경로 설정

NTP: 네트워크로 연결되어있는 컴퓨터들 끼리 클록 시각을 같게 동기화 시키는 프로토콜

하둡에 저장되는 데이터의 신뢰성을 위해 각 서버간 시각을 같게 동기화

https://mindnet.tistory.com/entry/NTP

빅데이터는 노드들이 서로 상호작용하며 처리하는 것이기 때문에 

메인서버를 정해두고, 

나머지 서버들이 그 메인서버의 시간을 기준으로 작업하겠다! 라는 의미.

-> hdfs 실행 자체에는 문제가 없지만, 혹시라도 나중에 데이터 안맞아서 오류가 발생하는 것을 방지한다!

$ ssh-keygen

$ ssh-copy-id -p 포트번호 -i ~/.ssh/id_rsa.pub root@test2

1. hostname 설정

- 통신할 서버의 hostname 지정해주기. 

$ vi /etc/hosts

127.0.0.1 localhost 는 살려둬야 한다.

서버 간 통신을 위해 모든 노드에서 지정해주기!

Yarn이란 ? 

하둡의 클러스터 자원 관리 시스템. 

맵리듀스의 성능 향상을 위해 Hadoop2 에서 처음 도입되었지만, 

맵리듀스 뿐 아니라 다른 분산 컴퓨팅 도구도 지원한다. 

Yarn 은 클러스터의 자원을 요청하고 사용하기 위한 API 를 제공한다.

맵리듀스, 스파크 등과 같은 분산 컴퓨팅 프레임워크는

클러스터 계산 계층 (Yarn) 과 클러스터 저장 계층 (HDFS) 위에서 YARN 애플리케이션을 실행한다. 

** Yarn 애플리케이션 수행

리소스 매니저 / 노드 매니저 

두 유형의 장기 실행 데몬을 통해 핵심 서비스를 제공한다. 

- 리소스 매니저 : 전체 자원의 사용량 관리 

- 노드 매니저 : 컨테이너를 구동하고 모니터링

실무에서 데이터를 조회하거나,
우리 회사같은 경우
insert overwrite 를 하는 경우가 굉장히 많은데
( 매일 정합성체크를 하는 입장에서 사용자들 또한
데이터 중복 건을 피하기 위해 insert into 가 아닌 overwrite 를 쓰기를 강력히 권고...)

이 때 테스트를 위함이든 데이터 소급을 위함이든,

특정 컬럼은 제외하고 모든 컬럼을 조회하고싶은 경우가 있다.

이 때 유용하게 쓸 수 있는 쿼리.

<hive-site.xml>
hive.support.quoted.identifiers=none

위의 설정 후

SELECT `(제외컬럼)?+.+` FROM <TABLE_NAME>;


굉장히 편리하다.