1. Ambari

URL : url정보
user : admin
password : admin

1.0. Ambari란

Ambari는 Hadoop 클러스터에 대하여 프로비저닝, 모니터링, 그 외 다른 관리 작업을 수행 할 수 있는 프로젝트

1.1. Ambari UI 접속

Dashboard 탭
- 설치된 서비스들의 상태를 지표 및 그래프로 확인할 수 있습니다.

YARN Memory : 노드별 사용 메모리 sum
- 전체 노드 메모리사용량의 합을 나타냅니다. 현재는 4.0TB 가 MAXIMUM
- 각 노드별 사용량 확인은

↓

HDFS Disk Usage : HDFS 디스크 사용량 sum
- HDFS(Hadoop 분산 파일 시스템)에서 사용하는 디스크 공간의 양에 대한 정보를 제공하고 클러스터를 관리하고 데이터 저장 및 처리에 사용할 수 있는 디스크 공간이 충분한지 확인해줌

Log 디스크 공간이 부족한 경우 조치사항

log위치 ambari -> Airflow -> Advanced airflow-logging-site -> Base log floder : /var/log/airflow
airflow log 삭제

2-1. 폴더 크기 :

du -sh /var/log/airflow

[613M /var/log/airflow]

2-2. du -hd1 /var/log/airflow

[5.5M    /var/log/airflow/dag_id=DAT_ST_TEST1

32M      /var/log/airflow/dag_id=DAG_ST_TEST2

12M      /var/log/airflow/dag_id=DAG_ST_TEST3

...

]

2-3. 전 노드 airflow log size 조사

dn1 205M

dn2 189M

dn3 212M

dn4 227M

dn5 670M

dn6 613M

dn7 918M

dn8 941M

dn9 924M

mn2 225G

**2-4.**기준 : domain로그는 수동 삭제, 대신 확인하는 쉘 생성

mn2 직전 한달치만 남기고 다 삭제 - 한달에 한번 실행

NGIOS_UTIL/airflowLogDelete.sh

로그 폴더에서 60일 보다 오래된 모든 폴더 삭제.

0 0 * * * sh /usr/hmg/2.2.1.0-552/airflow/dags/NGIOS_UTIL/airflowLogDelete.sh

각 노드별 사용량 확인은 Hosts - Disk Usage 에 직접 들어가서 확인

CPU Usage : 노드별 CPU사용량 sum
1. 클러스터 성능 모니터링 : 관리자는 클러스터에 있는 각 노드의 CPU 사용량을 모니터링하여 클러스터가 얼마나 효과적으로 데이터를 처리하고 작업을 실행하는지파악 가능.
2. 병목 현상 식별 : CPU 사용량이 높은 노드를 식별함으로써 관리자는 병목 현상을 해결하고 성능개선 가능.
- 각 노드별 사용량 확인은 Hosts - Summary - Host metric

1.2. Services - HDFS - Summary

hdfs �구성 및 로그, Config정보 관리

DATANODES : 각 노드 별 상태 확인 및 노드 HOST정보 연결

1.3. Services - HDFS - config

NameNode/DataNode Java Heap Size 설정(튜닝포인트 : sparkJob 성능 튜닝없이 부스팅 할 경우 사용)
- DataNode Java Heap Size :
  1. 성능 향상 : Datanode Java 힙에 더 많은 메모리를 할당하면 메모리에서 더 많은 데이터를 처리할 수 있으므로 Datanode 프로세스의 성능을 잠재적으로 향상
  2. 안정성 향상 : Datanode 프로세스의 메모리가 부족하고 메모리 부족 오류가 발생하는 경우 Java 힙 크기를 늘리면 프로세스를 안정화하고 충돌을 방지.
  3. 리소스 할당 : 데이터노드 프로세스에 대한 Java 힙 크기를 조정하여 노드에서 리소스 할당을 최적화하고 데이터노드가 작업을 효과적으로 수행하기에 충분한 메모리를 갖도록 할 수 있음.
- 너무 많은 메모리를 할당하면 가비지 수집 시간 증가 또는 다른 프로세스와의 메모리 경합과 같은 노드 또는 클러스터에서 다른 문제가 발생할 수 있으므로 Datanode프로세스에 대한 Java 힙 크기 설정은 주의해서 수행해야 함
- 운영 할 시 긴급으로 heap size를 늘려서 속도를 개선 할 수는 있지만 위험성이 크므로 긴급시에만 사용.

1.4. Services - YARN - SUMMARY

2. YARN

2.1.YARN의 역할

리소스 관리 : YARN은 Hadoop 클러스터에서 실행되는 다양한 어플리케이션에 CPU 및 메모리와 같은 리소스 할당.
작업 예약 : YARN은 애플리케이션이 제출한 작업(예: MapReduce 작업, spark 작업 )이 클러스터 내의 적절한 노드에서 실행되도록 예약.
확장성: YARN을 사용하면 클러스터에 더 많은 노드를 추가하여 Hadoop이 수평으로 확장할 수 있으므로 더 많은 수의 애플리케이션과 더 큰 데이터 세트 처리 가능.
다중 처리 프레임워크 지원: MapReduce 처리 모델과 밀접하게 결합된 Hadoop 1.0과 달리 YARN은 다양한 데이터 처리 프레임워크 (예: Apache Spark, Apache Flink 및 Apache Tez)를 통합하여 Hadoop에서 실행할 수 있음.
내결함성 : YARN은 클러스터에서 실행되는 애플리케이션 및 작업의 상태를 모니터링. 작업이 실패하거나 노드가 응답하지 않는 경우 YARN은 다른 노드에서 작업을 다시 예약하여 오류가 나도 애플리케이션이 계속 실행되도록 할 수 있음.

2.2. YARN의 구성 요소

ResourceManager: 클러스터 리소스를 관리하고 애플리케이션을 예약하는 중앙 구성 요소. ResourceManager는 다양한 경쟁 응용 프로그램 간의 리소스 할당을 중재하고 리소스가 효율적으로 사용되도록 함.
NodeManager: Hadoop 클러스터의 각 작업자 노드에서 실행되는 노드별 에이전ㅌ. NodeManager는 노드에서 컨테이너(격리된 실행 환경)를 관리하고 리소스 사용량을 모니터링하며 노드의 상태를 ResourceManager에 보고하는 역할을 함.

pyspark log 확인하는 방법:

↓

↓

hdfs log 용량 확인하는 방법 hdfs dfs -du -h /user/mbsadmin
Memory Used : 현재 사용중인 메모리
Memory Total : 전체 사용할 수 있는 메모리(현재 : 4.0TB)
Memory Reserved : 사용 예정인 메모리 + 현재 사용중인 메모리 > 전체 사용할 수 있는 메모리 이면은 Reserved에서 대기하고 있음.
Vcoresd Used : 현재 사용중인 코어 수
Vcores Total : 전체 사용할 수 있는 코어 수(현재 : 576)
Vcores Reserved : 사용 예정인 코어 수 + 현재 사용중인 코어 수 > 전체 사용할 수 있는 코어 수 이면 Reserved에서 대기 하고있음.
Allocated CPU Vcores : 현재 할당된 코어 수
Allocated Memory : 현재 할당된 메모리
Reserved CPU Vcores : 사용 예정인 코어 수가 전체 사용할 수 있는 코어 수 보다 크면 Reserved에서 대기 하고 있음.
Reserved Memory : 사용 예정인 메모리가 전체 사용할 수 있는 메모리 보다 크면 Reserved에서 대기 하고 있음.
% of Cluster : 전체 4.0TB에서 얼마나 사용하는지 퍼센트로 나누어져서 표현.

↓

↓

JOBS에서 최근 프로그램 실행 이력을 파악할 수 있고, 사용 하지 않는 세션은 죽여도 된다.

yarn kill 방법 : yarn application -kill [application 명]
ex) yarn application -kill application_123491123_1234

1. JOBS

1. JOBS - spark 애플리케이션이 실행하는 모든 작업을 나타냄 - 각 Job은 일련의 Stage로 구성되어 있으며, Job에서 실행되는 Stage의 수와 진행 상황등을 모니터링 할 수 있음

로그 파일 확인 : Spark 애플리케이션의 로그 파일을 확인하여 문제가 발생한 원인을 파악할 수 있음. 예를 들어, 오류 메시지나 예외가 발생한 경우 로그 파일에서 자세한 정보를 확인할 수 있음.
메모리 사용량 모니터링 : 메모리 사용량이 너무 높으면 애플리케이션이 느려지거나 실패할 수 있음. 따라서, Spark UI에서 메모리 사용량을 모니터링 하여 애플리케이션의 성능을 개선할 수 있음
Executor 개수 조정 : Executor의 개수를 조정하여 애플리케이션의 성능을 개선할 수 있음. Executor의 갯수가 너무 적으면 애플리케이션의 처리속도가 느려질수 있고, Executor의 갯수가 너무 많으면 클러스터의 부하가 커지면서 애플리케이션의 성능이 저하될 수 있음. 따라서, Executor의 개수를 적절하게 조정하여 애플리케이션의 성능을 최적화 할 수 있음
모니터링 : Spark 애플리케이션에서는 GC(Garbage Collection)의 발생 빈도와 시간이 매우 중요합니다. GC가 너무 자주 발생하거나 GC시간이 오래걸리면 애플리케이션의 처리 속도가 느려지거나 실패 할 수 있음. 따라서, GC모니터링을 통해 애플리케이션의 성능을 개선할 수 있음.
캐시 사용 여부 확인 : Spark에서는 RDD나 DataFrame등을 캐시하여 동일한 연산을 반복할 때 성능을 개선할 수 있음. 따라서, 캐시를 적절하게 사용하여 애플리케이션의 처리 속도를 개선할 수 있음. Spark UI에서 캐시 사용여부를 확인할 수 있음.

2. STAGES

2. STAGES - Spark 애플리케이션이 실행하는 모든 Stage를 나타냄. 각 Stage는 RDD(Distributed Resilient Dataset)를 처리하고, 새로운 RDD를 생성하는 연산을 수행. - Stage에서 수행되는 Task들은 동일한 데이터셋을 사용하여 동시에 실행. Stages 탭에서는 각 Stage의 ID, 상태, 수행시간, 메모리 사용량등의 정보를 제공

Stage의 종류 파악 : Spark에서는 다양한 종류의 Stage가 있음. Shuffle Stage, Result Stage, Cache Stage등이 있음. 각각의 Stages는 다른 종류의 작업들을 처리하므로 Stage의 종류를 파악 가능
Stage의 수와 크기 파악 : Spark UI에서는 Stage의 수와 크기를 확인 할 수있음. Stage의 수가 많고 크기가 큰 경우, 클러스터에서의 부하가 커져서 애플리케이션의 처리 속도가 느려질 수 있음. 따라서, Stage의 수와 크기를 파악하여 애플리케이션의 처리 속도를 최적화할 수 있음
Stage의 의존성 파악 : Stage간에는 의존성이 있음. 즉, 이전 Stage의 결과를 다음 Stage에서 사용하는 경우가 많음. Stage 간의 의존성을 파악하여 애플리케이션의 처리 흐름을 이해할 수 있음.
Shuffle 수행 여부 파악 : Shuffle은 데이터를 섞는 작업. Shuffle이 수행되는 경우, 클러스터에서의 부하가 커져서 애플리케이션의 처리 속도가 느려질 수 있음. 따라서 Shuffle이 수행되는 Stage를 파악하여 애플리케이션의 처리 속도를 개선할 수 있음.
Stage의 수행 시간 모니터링 : Stage의 수행 시간이 너무 긴 경우, 애플리케이션의 처리속도가 느려질 수 있음. 따라서, Stage의 수행시간을 모니터링 하여 애플리케이션의 처리 속도를 개선할 수 있음. Spark UI에서 Stage의 수행시간을 확인할 수 있음

3. STORAGE

3. STORAGE - Spark 애플리케이션이 사용하는 모든 메모리 및 디스크 스토리지에 대한 정보를 제공. 이 탭에서는 RDD의 크기, 캐싱 여부, 메모리와 디스크 스토리지의 사용량 등을 확인. 또한, Storage Level을 설정하여 RDD를 어떻게 저장할지 결정할 수 있음.

스토리지 레벨 확인 : Spark에서는 메모리와 디스크에 데이터를 저장. 메모리는 빠르지만 제한된 용량을 가지고 있고, 디스크는 용량은 더 크지만 느릴수 있음.
메모리 사용량 파악 : Spark에서 메모리 사용량이 많아지면 성능이 떨어질 수 있음. STORAGE 섹션에서는 메모리 사용량에 대한 정보를 확인할 수 잇음. 메모리 사용량이 높으면, 스파크 애플리케이션의 성능 문제가 발생할 가능성이 높음
디스크 사용량 파악 : 디스크는 메모리보다 용량이 크지만, 더 느림. STORAGE섹션에서 디스크 사용량에대한 정보를 확인할 수 있음. 디스크 사용량이 높으면, 디스크 I/O병목 현상이 발생할 가능성이 높으므로, 성능 개선을 위해 디스크 용량을 늘리는 등의 방법을 고려해야함.
데이터 파티셔닝 확인 : Spark에서는 데이터를 파티션으로 나누어 처리. STORAGE 섹션에서 파티션 수와 각 파티션의 크기를 확인할 수 있음. 데이터 파티셔닝은 데이터 처리 성능에 매우 중요하므로, 파티션 수와 크기를 최적화하는 것이 중요합니다.
캐시 데이터 확인: Spark에서는 데이터를 캐시하여 재사용할 수 있음. STORAGE 섹션에서 캐시된 데이터 크기와 갯수를 확인할 수 있음. 캐시된 데이터가 많아지면 메모리 사용량이 늘어나므로, 캐시 데이터를 적절히 관리하여 메모리 사용량을 줄이는 것이 중요.

4. ENVIRONMENT<

4. ENVIRONMNET - Spark 애플리케이션의 환경정보를 제공. 이탭에서는 Spark의 설정 값, JVM 환경, 로그 파일등을 확인. Spark애플리케이션을 싱행하는 클러스터의 구성과 운영체제등의 정보도 확인 할 수 있음.

자원 할당 및 사용량 파악 : ENVIRONMENT 섹션에서는 애플리케이션이 사용할 수 있는 자원 및 할당 된 자원에 대한 정보를 제공. 메모리, CPU, 디스크 및 네트워크 등 자원 사용에 대한 정보를 파악하면 애플리케이션의 성능을 최적화할 수 잇음.
설정 값 확인 : Spark의 환경 설정 값은 애플리케이션의 성능에 매우 중요. ENVIRONMNET 섹션에서 설정 값에 대한 정보를 확인가능. 설정 값이 잘못 구성되면 애플리케이션의 성능에 영향을 미치므로, 올바른 설정 값으로 구성하는 것이 중요.
라이브러리 및 의존성 확인 : 애플리케이션의 성능에 영향을 미치는 라이브러리 및 의존성 정보를 확인할 수 있음. ENVIRONMNET 섹션에서는 사용되는 라이브러리 및 의존성에 대한 정보를 제공.
스파크 버전 확인 : ENVIRONMENT 섹션에서는 Spark 버전 정보도 확인 가능.
JVM 설정 확인 : JVM은 Spark 애플리케이션 실행에 매우 중요. ENVIRONMENT 섹션에서 JVM설정 값을 확인할 수 있음. JVM 설정 값을 최적화하면 애플리케이션의 성능을 최적화할 수 있음.

2.3. Services - YAN - Configs

ResourceManager가 각 노드별 메모리/CPU 및 컨테이너의 사이즈를 통제함

Memory : ResourceManager로 각 노드 별 메모리를 설정/대시보드에서 보이는 전체 가용량을 늘링 경우 각 노드별 가용량의 sum을 증가시켜야함 (개인 노드별로는 설정 불가능)
- 현재 전체 4.0TB로 세팅되어있음.

3. Sqoop 사용

Sqoop : RDBMS(Relational Database Management System)과 Haddop 사이의 데이터 이전을 쉽게 할 수 있도록 지원

3.1. Sqoop 명령어

--> 마스터노드에서 실행

sqoop import --connect jdbc:oracle:thin:[ip주소] \
--username "gios_test" \
--passowrd "gios_test" \
--connection-manager "org.apache.sqoop.manager.OracleManager" \
--query "SELECT * FROM GIOS_TEST.TEST_TABLE WHERE DATE = 20230223 \
--target-dir /user/hive/warehouse/NGIOS_TEST.db/NEW_TABLE \
--delete-target-dir \
--fields-terminated-by '\007' \
--lines-terminated-by '\n' \
--input-escaped-by ',';

4. HUE

4.0. HUE란

데이터 분석가, 개발자 및 명령줄 인터페이스에 익숙하지 않은 기타 사용자를 위한 그래픽 사용자 인터페이스(GUI)를 제공하는 오픈 소스 웹 기반 인터페이스
Hadoop내의 파일을 관리하는데 사용함 �

4.1. Hue 접속 계정

URL : url정보
user : mbsadmin
password : mbsadmin

4.2. HUE

접속 하는 방법

↓

↓

원하는 파일 위치로 접속

& darr;

4.3. 디렉토리 권한 부여 방법

디렉토리 권한 부여 방법

hdfs로 유저 변경(하둡 super user계정)
권한 부여 2-1. 단일 유저 권한 부여 : hadoop fs -setfacl -R -m user:{유저명}:rwx {권한 변경할 디렉토리 경로}

2-2. 유저 그룹 권한 부여 : hadoop fs -setfacl -R -m group:{그룹명}:rwx {권한 변경할 디렉토리 경로}
- 유저 속한 그룹 확인 방법: groups {유저명}
- mbsadmin 및 dt 유저가 포함된 유저 그룹: mbs
권한 부여 확인 : hadoop fs -getfacl {권한 변경한 디렉토리 경로}

5. pyspark job 제출

5.1. spark3-submit으로 pyspark3로 실행 할시 이점

spark-submit 명령어:

spark-submit을 활용하면 대화형 shell에서 개발한 프로그램을 운영용 어플리케이션으로 전환가능.
spark-submit명령은 어플리케이션 코드를 클러스터에 전송해 실행시키는 역할을 수행
전송된 어플리케이션은 종료되거나 에러가 발생할 때까지 실행.
Spark-submit 실행시 옵션 지정을 통해 필요한 자원과 실행 방식을 지정 가능.

spark3-submit
--master yarn
--driver-memory 5G
--executor-memory 10G
--num-executor 10
--executor-cores 4
--conf "spark.kryoserializer.buffer.max=512m"
--conf "spark.dynamicAllocation.enabled=false"
--conf "spark.memory.storageFraction=01."
--conf "spark.memory.fraction=0.8" /usr/hmg/2.2.1.0-552/airflow/dags/main.py
--job PKG_TEST.PR_TEST
--conf /usr/hmg/2.2.1.0-552/airflow/dags/NGIOS_CONFIG/DAG_TEST/test_config.json

--master yarn : 사용할 클러스터 관리자를 지정. Hadoop에서 일반적으로 사용되는 YARN으로 설정
--driver-memory : Spark 애플리케이션의 기본 기능을 실행하는 드라이버 프로세스에 할당할 메모리 양을 지정. 실행자가 실행하는 작업을 조정하는 역할.
--num-executors : 애플리케이션에 대해 실행할 실행기 프로세스 수를 지정. executor가 사용하는 총 메모리 양은 executor-memory에 num-executors를 곱하여 결정됨
--executor-cores : 매개변수는 각 실행기에 할당할 CPU 코어 수를 지정. 기본적으로 각 실행기에는 하나의 코어가 할당되지만 워크로드가 여러 코어에서 병렬화될 수 있는 경우 이 매개변수를 사용하여 코어 수를 늘릴 수 있음.
--conf "spark.kryoserializer.buffer.max=512m": Kryo 직렬 변환기 버퍼의 최대 크기를 512MB로 구성. Kryo직렬 변환기는 spark에서 효율적인 처리 및 저장을 위해 객체와 데이터를 직렬화하는 데 사용.
--conf "spark.dynamicAllocation.enabled=false" : 실행기 리소스의 동적 할당을 비활성화. 동적 할당을 통해 Spark는 워크로드에 따라 실행기 및 해당 리소스의 수를 조정할 수 있지만 경우에 따라 오버헤드 및 속도 저하가 발생할 수 있음.
--conf "spark.memory.storageFraction=0.1": 실행기 메모리의 저장 부분을 0.1로 설정. 이 비율은 캐시된 데이터 및 임시 셔플 파일을 저장하는데 사용되는 메모리 양을결정.
--conf "spark.memory.fraction=0.8": Spark에 할당되는 총 메모리의 비율을 설정. 이예에서 메모리의 80%는 Spark에 할당되고 나머지 20%는 다른 프로세스에 할당.

6. Hive/Delta

6.1. DESCRIBE HISTORY

spark.sql(f""" DESCRIBE HISTORY delta.'/user/hive/warehouse/NGIOS_TEST.db/table_name`""").show(truncate=False)

6.2. CREATE DELTA DATA

data = spark.range(1,100)
data.write.format("delta").load("tmp/delta_table")

6.3. HUE에 있는 DELTA 데이터 읽어오기

df = spark.read.format("delta").load("tmp/delta_table")
df.show()

6.4. WRITE TO A TABLE

6.4.1. APPEND

df.write.format("delta").mode("append").save("tmp/delta_table2")
df.write.format("delta").mode("append").saveAsTable("ngios_test.delta_table")

6.4.2. OVERWRITE

df.write.format("delta").mode("overwrite").save("tmp/delta_table2")
df.write.format("delta").mode("overwrite").saveAsTable("ngios_test.delta_table")

6.4.3. HUE에 있는 데이터 업데이트

data = spark.range(5,10)
data.write.format("delta").mode("overwrite").save("tmp/delta_table")

6.5. DELTA HISTORY로 과거 테이블로 복원하는 방법

# >>> Define Variables
# - rest_tblnm : 테이블 명
# - rest_ver   : 복원할 version ID

rest_tblnm = "BK_TABLE"
rest_ver = 1

# >>> Select Version Data
df_restore = spark.read.format("delta").option("versaionAsOf", rest_ver).load("/user/hive/warehouse/NGIOS_TEST.db/" + rest_tblnm)

# df_restore.count()
# df_restore.show()

# >>> Create TempView
df_erstore.createOrReplaceTempView("R_"  + rest_tblnm)

# spark.sql(f""" select * from """ + "R_" + rest_tblnm).show()

# >>> Insert Overwrite
spark.sql("f""" insert overwrite NGIOS_TEST.""" + rest_tblnm + " select * from R_" + rest_tblnm)

spark.sql(f""" select * from NGIOS_TEST.""" + rest_tblnm).count()

↑ 필요한 version을 고르고 그 버전의 snapshot을 임시테이블로 만들고 그 snapshot만든 임시테이블로 기존 테이블을 overwrite하는 형식이다.

6.6. TABLE SCHEMA 포맷 확인하는법

spark.sql(f"" desc formatted NGIOS_TEST.TEST_TABLE""").show(100)

6.7 CREATE TABLE 하는 방법

6.7.1. PARTITON이 없는 경우

CREATE EXTERNAL TABLE IF NOT EXISTS NGIOS_TEST.TEST_TABLE ( NAME string,
  ID string,
  NO decimal(38,7),
  CREAETE_DTTM timestamp
) USING DELTA
LOCATION '/user/hive/warehouse/NGIOS_TEST.db/TEST_TABLE'

6.7.2. PATITION이 있는 경우

CREATE EXTERNAL TABLE IF NOT EXISTS NGIOS_TEST.TEST_TABLE ( NAME string,
  ID string,
  NO decimal(38,7),
  CREAETE_DTTM timestamp
) USING DELTA
LOCATION '/user/hive/warehouse/NGIOS_TEST.db/TEST_TABLE'
�PARTITIONED BY (NAME)

6.7.3. COMMENT가 있는 경우

CREATE EXTERNAL TABLE IF NOT EXISTS NGIOS_TEST.TEST_TABLE (
  NAME string COMMENT "이름",
  ID string COMMENT "아이디",
  NO decimal(38,7) COMMENT "번호",
  CREAETE_DTTM timestamp COMMENT "생성시간"
) USING DELTA
LOCATION '/user/hive/warehouse/NGIOS_TEST.db/TEST_TABLE'
PARTIOTNED BY (NAME)
COMMENT "테스트 테이블"

외부 테이블 (External Table) : 외부 테이블(External Table)은 이미 HDFS에 존재하는 원본 데이터를 기반으로 테이블을 만들기 때문에 스키마만 정해주면 됨. 파일이 HDFS 상에 이미 있을 떄 외부 테이블을 사용하고, 테이블이 삭제 되더라도 파일은 남아 있음.
내부 테이블 (Internal or Managed Table) : 관리형 테이블을 생성하면 파일이 기본 위치인 /user/hive/warehouse/databasename.db/tablename/에 저장됨. 외부 테이블과는 다르게, 관리 테이블 또는 파티션이 삭제 (drop)되면 해당 테이블 또는 파티션과 연관된 데이터 및 메타 데이터가 삭제됨.

7. spark jdbc 사용

7.1 jdbcdml ahrwjr

Spark JDBC의 목적은 Spark 애플리케이션이 JDBC(Java Database Connectivity) API를 사용하여 관계형 데이터베이스에서 데이터를 읽고 쓸 수 있도록 하는것

# ex) etl_conf.py
# _etl.py

# mysql
MYSQL_HOST = 'ip주소'
MYSQL_PORT = port주소
MYSQL_USER = 'sql_test'
MYSQL_PASSWoRD = 'sql_password'
MYSQL_DATABAES = 'sql_test'

# oracle
ORACLE_USER = 'oracle_test'
ORACLE_PASSWORD = 'oracle_paswd'
ORACLE_DSN = 'oracle주소'

oacle spark read jdbc

1. select etl_old_table,partition_col from sql_test.etl_table_info

df = spark.read.format("jdbc")
.option("url", f"jdbc:oracle:thin:@{ORACLE_DSN}")
.option("user", ORACLE_USER)
.option("passowrd", ORACLE_PASSWORD)
.option("dbtable", "test_table")
.option("fetchsize", 100000).load()

 # 저장로직은 똑같음.
 .write
 .format("csv") #csv/elta/parquet
 .mode("overwrite") #overwrite/append
 .option("delimiter", "\007")
 .save("/user/hive/warehouse/NGIOS_TEST.db/TEST_TABLE")

 # oracle spark read jdbc


----
# 8. 클러스터
----
## 8.1 클러스터 접속 권한 부여

* 계정 추가 및 확인

1. 사용자 정보 수집
이름 : 여기현
ID  : 12345
이메일 : [email protected]

2. 권한 확인 [권한 확인]

mbsadmin:x:1000:1000:mbsadmin:/home/mbsadmin:/bin/bash

3. 접속 대상 확인
:: 보안정책에 따라 실제 사용하는 계정말고는 전 노드에 접속이 안됨.

4. 계정 추가(:: 대상: 전 노드)

    **4-1.** 관리자(root) 권한 얻기

    su

    **4-2.** 계정 추가: useradd 명령어를 사용하여 새로운 사용자 계정을 추가

    useradd yeo0109

    **4-3.** 패스워드 설정: passwd 명령어를 사용하여 새로운 사용자 계정의 패스워드를 설정

    password : P@ssw0rd
    passwd yeo0109

    **4-4.** (선택 사항) 사용자 정보 추가: usermod 명령어를 사용하여 사용자의 기본 정보를 추가하거나 변경

    ex) uesrmod -c "사용자의 성명, 전화번호, 주소" newuser

usermod -c "여기현, [email protected]" yeo0109

5. 확인

vi /etc/passwd

yeo0109:x:10043:10043:여기현, [email protected]:/home/yeo0109:/bin/bash

::mbsadmin과 같은 권한으로 올려주고싶을 시

  * [수정] yeo0109:x:10043:1000:여기현, [email protected]:/home/yeo0109:/bin/bash

6. 접속테스트

yeo0109 로 접속.

## 8.2 Thrift Server 확인

* Thrift Server가 spark history 상으로는 살아있는거처럼 보이나 실제로는 실행이 안되고 있는 상황 발생

<img width="863" alt="스크린샷 2023-07-13 오후 7 17 53" src="https://github.com/herehyun/manuals/assets/82385436/69455d18-5fc4-46e7-8aae-8d8a5b467bf5">

* [mbsadmin@mn01p ~]$ ps aux | grep 'hiveserver2' | grep -v 'grep' 으로 조회되는 프로세스가 없음

[root@mn01p _CMD]# ./thriftCheckAndRestart.sh 을 이용해서 shell 실행

&rarr; 현재는 root안에있는 crontab에 1분 간격으로 thrift서버가 죽었는지 모니터링하고 죽었을경우 shell을 실행 시키게 되어있음.

### 8.3 GPU 사용량 확인 하기

1.G/W node 에서 아래 명령어 실행

  -  현재시점 GPU 사용량 확인
  'nvidia-smi'

  - 1초마다 GPU 사용량 업데이트, 모니터링용
  'watch -d -n 1 nvidia-smi'

* 출력 ex)
<img width="823" alt="스크린샷 2023-07-13 오후 7 21 22" src="https://github.com/herehyun/manuals/assets/82385436/0ef6eae8-0e6f-48a7-85d0-2fa19a08888d">

2. G/W 노드에 2개 GPU가 존재 : 0번, 1번

위 상태에서는 1번 GPU가 사용 중 (Memory-Usage 0 & GPU-Util의 퍼센테이지 올라가고 있음)

만약 Memory-Usage은 있지만 GPU-Util의 퍼센테이지가 0%이면, 모델 훈련이나 예측은 실행되는 중이 아님.

Memory-Usage에 남는 용량이 없다면 GPU사용 불가

3. 누가 GPU 사용 중인지 확인

아래 Processes 표에서 PID 복사 후 아래 명령어 사용 {pid}에 복사한 텍스트 붙여넣기

'ps -f {pid}'

4. 사용중인 GPU KILL
강제종료 : kill -9 {pid}


### 8.4 MariaDB 사용법
### Airflow with MariaDB 접속 정보

<div align="center">
DBeaver접속
</div>
<div align="center">
&darr;
</div>
<div align="center">
<img width="861" alt="스크린샷 2023-07-13 오후 7 28 00" src="https://github.com/herehyun/manuals/assets/82385436/d091907b-6ec9-4a0b-b0da-a89afd677a57">
</div>
<div align="center">
&darr;
</div>
<div align="center">
MariaDB 클릭
</div>
<div align="center">
&darr;
</div>
<div align="center">
<img width="859" alt="스크린샷 2023-07-13 오후 7 28 12" src="https://github.com/herehyun/manuals/assets/82385436/e474a7cd-794a-4208-8724-1679a8308aa2">
</div>
<div align="center">
&darr;
</div>

  Server Host : ip주소
  port        : port주소
  database    : ngios_test
  username    : ngios_test
  password    : ngios_password

<div align="center">
&darr;
</div>
<div align="center">
<img width="860" alt="스크린샷 2023-07-13 오후 7 32 42" src="https://github.com/herehyun/manuals/assets/82385436/0bbf1f3f-d48e-4258-a942-dcd5cc59f2b8">
</div>
<div align="center">
&darr;
</div>
<div align="center">

</div>
<div align="center">
&darr;
</div>

### 8.5 GitLab
### GitLab 초대

  -  Master계정으로 접속

  - 추가할 프로젝트 클릭 > 프로젝트 홈으로 이동

  - Invite member 탭 > GitLab member or Email address

  <img width="563" alt="스크린샷 2023-07-13 오후 7 43 54" src="https://github.com/herehyun/manuals/assets/82385436/1fa0b1a8-193a-4dfa-886e-eabc43f346f0">

  - GUEST로 권한을 부여할 경우 데이터소스가 보이지 않을 수 있으므로 DEVELOP으로 올린다.

  - 초대할 멤버가 GitLab 회원가입되어 있으면 GitLab 계정 입력, 가입되어 있지 않으면 메일 주소로 invite 메일 발송됨

herehyun / abmari-yarn-hue-hive-cluster-manual Goto Github PK

abmari-yarn-hue-hive-cluster-manual's Introduction

목차