data_lab

spark 작업관리

Apache Livy는 REST 인터페이스를 통해 Spark 클러스터와 쉽게 상호 작용할 수 있는 서비스입니다. 간단한 REST 인터페이스 또는 RPC 클라이언트 라이브러리를 통해 Spark 작업 또는 Spark 코드 스니펫, 동기 또는 비동기 결과 검색, Spark 컨텍스트 관리를 쉽게 제출할 수 있습니다. 또한 Apache Livy는 Spark와 애플리케이션 서버 간의 상호 작용을 단순화하여 대화형 웹/모바일 애플리케이션에 Spark를 사용할 수 있도록 합니다. 추가 기능은 다음과 같습니다.

• 여러 클라이언트에서 여러 Spark 작업에 사용할 수 있는 장기 실행 Spark 컨텍스트 보유
• 여러 작업 및 클라이언트에서 캐시된 RDD 또는 데이터 프레임 공유
• 여러 Spark Context를 동시에 관리할 수 있으며, 우수한 내결함성과 동시성을 위해 Livy Server 대신 클러스터(YARN/Mesos)에서 Spark Context를 실행합니다.
• 작업은 미리 컴파일된 jar, 코드 조각 또는 java/scala 클라이언트 API를 통해 제출할 수 있습니다.
• 보안 인증 통신을 통한 보안 확보

https://www.mail-archive.com/common-dev@hadoop.apache.org/msg35272.html

zookeeper 3.4.14 의존성 문제로

zookeeper 3.4.13버전으로 진행해야함

소스를 mvn으로 빌드할 경우 해당 에러가 나오는 경우가 있다.

그런경우 -Drat.skip=true 옵션을 추가하여 빌드하면 해당 에러 없이 진행된다.

RAT 체크 생략 

RAT - 오픈소스 라이선스

mvn 명령어 예시

/mvn clean package -Dbuild-rpm -DskipTests -Drat.skip=true

목적

• 복제 비용이 많이 듭니다. HDFS의 기본 3배 복제 체계는 스토리지 공간 및 기타 리소스(예: 네트워크 대역폭)에서 오버헤드가 200%입니다.
• 상대적으로 I/O 작업이 적은 Warm및 Cold 데이터셋의 경우 일반 작업 중에는 추가 블록 복제본에 거의 액세스하지 않지만 첫 번째 복제본과 동일한 양의 리소스를 사용합니다.
  • Hot : 빠른 쿼리, fresh 데이터, 동시성높음
  • warm : hot, cold 데이터의 사이
  • cold data : 느린쿼리, not fresh 데이터, 리포팅, 플랜, 동시성 낮음
• 훨씬 적은 스토리지 공간으로 하둡 이전버전의 동일한 수준의 내결함성을 제공합니다. 일반적인 Eraser Coding(EC) 설정에서 스토리지 오버헤드는 50%를 넘지 않습니다. EC 파일의 복제 팩터는 의미가 없습니다. 이 값은 항상 1이며 -setrep 명령을 통해 변경할 수 없습니다.

배경

• RAID는 스트라이핑을 통해 EC를 구현
  • 스트라이핑
    • RAID-0
      • 스트라이핑 기술 이용해 빠른 입출력속도
      • 데이터를 중복이나 패리티없이 디스크에 분산 기록
      • 처리속도 빠르나 오류 발생시 복구 불가
    • RAID-2
      • 에러를 감지하고 수정하기 위해 ECC (Error Check & Correction) 정보 사용
    • RAID-3
      • 패리티 정보를 저장하기 위해 별도로 하나의 디스크 사용
      • 입출력 겹치게 할 수 없으며 보통 대형 레코드가 많은 시스템에서 사용
    • RAID-4
      • 블록 형태의 스트라이핑 기술을 사용하여 디스크 구성함
      • 단일 디스크로부터 레코드 읽을 수 있고 데이터 읽을 때 중첩 입출력의 장점이있음
      • 쓰기 - 패리티 연산사용, 입출력의 중첩이 불가능하고 시스템에 병목현상 발생할 수 있음
    • RAID-5
      • 패리티 정보를 이용하여 하나의 디스크가 고장이 발생한 경우에도 사용이 가능함 , 최소 3개 이상의 디스크
      • 패리티는 별도의 디스크를 사용하지 않고 디스크에 분산 기록해 데이터를 중복저장하지않음
  • 미러링
    • RAID-1
  • LVM - Logical Volume Manager
    • 리눅스 설치할 때나 하드디스크를 추가하면 파티션을 분할하고 할단하는데 크기가 고정되어 변경이나 증설이 어려움. LVM은 여러개의 하드디스크를 하나로 또는 하나를 여러개로 사용할 수 있다.
  • RAID 기술
    • 스트라이핑: 연속된 데이터를 디스크에 라운드로빈 방식으로 기록한다. 서로 겹쳐서 읽거나 쓸 수 있는 네개의 드라이브가 있을 경우, 네개의 섹터를 동시에 읽을 우 있다.
    • 미러링: 디스크에 에러 발생 시 데이터 손실을 막기위해 하나 이상의 장치에 중복 저장하는 기술. 결함 허용
• 스트라이핑은 논리적으로 순차적인 데이터(예: 비트, 바이트 또는 블록)를 더 작은 단위(예: 비트, 바이트 또는 블록)로 나누고 연속된 장치를 서로 다른 디스크에 저장 (RAID 에서 Reed-Solomon의 계산방식)
• 스트리핑 분포 단위를 스트리핑 셀이라고 한다.
• 인코딩 - 원본 데이터 셀의 각 스트라이프에 대해 특정 수의 패리티 셀이 계산되고 저장
• 디코딩 - 스트라이핑 셀의 오류는 남아 있는 데이터와 패리티 셀을 기반으로 계산하여 복구가능
• EC를 HDFS와 통합하면 스토리지 효율성을 향상시키는 동시에 기존 복제 기반 HDFS 구축과 유사한 데이터 내구성을 제공
• EC사용X - 6개인 3배 복제된 파일은 6*3 = 18블록의 디스크 공간을 사용
• EC(6개의 데이터, 3개의 패리티)를 구축하면 Disk 공간을 9개만 사용

아키텍쳐

• 온라인 EC(EC 형식으로 즉시 데이터 쓰기)를 지원하여 변환 단계를 피하고 스토리지 공간을 즉시 절약
• 온라인 EC는 여러 Disk 스핀들을 병렬로 활용하여 순차 I/O 성능을 향상
  • 하이엔드 네트워킹이 있는 클러스터에서 특히 유용
• 작은 파일을 여러 DataNode에 자연스럽게 배포하므로 여러 파일을 단일 코딩 그룹으로 묶을 필요가 없음
• 삭제, 할당량 보고 및 연합 네임스페이스 간 마이그레이션과 같은 파일 작업이 크게 간소화

NameNode Extensions

• 스트라이프 HDFS 파일은 논리적으로 블록 그룹으로 구성되며, 각 그룹에는 특정 수의 내부 블록이 포함되어 있습니다. 이러한 추가 블록으로부터 NameNode 메모리 소비를 줄이기 위해, 새로운 계층적 블록 명명 프로토콜이 도입되었습니다. 블록 그룹의 ID는 내부 블록의 ID에서 유추할 수 있습니다. 따라서 블록이 아닌 블록 그룹 수준에서 관리할 수 있습니다.

DataNode Extensions

• DataNode는 실패한 삭제 코드 블록의 백그라운드 복구를 위해 EraseCodingWorker(ECWorker) 작업을 추가로 실행합니다. 장애가 발생한 EC 블록은 NameNode에 의해 감지되고, NameNode는 복구 작업을 수행할 DataNode를 선택합니다. 복구 태스크는 하트비트 응답으로 전달됩니다. 이 프로세스는 복제된 블록이 실패 시 복제되는 방식과 유사합니다. Reconstruction(재구성)은 다음 세 가지 주요 작업을 수행합니다.
• 소스 노드에서 데이터를 읽습니다. 전용 스레드 풀을 사용하여 소스 노드에서 입력 데이터를 병렬로 읽습니다. EC 정책에 따라 모든 소스 대상에 대한 읽기 요청을 스케줄링하고 재구성을 위한 최소 입력 블록 수만 읽습니다.
• 데이터를 디코딩하고 출력 데이터를 생성합니다. 입력 데이터에서 새로운 데이터 및 패리티 블록이 디코딩됩니다. 모든 결측 데이터와 패리티 블록이 함께 디코딩됩니다.
• 생성된 데이터 블록을 대상 노드로 전송합니다. 디코딩이 완료되면 복구된 블록이 대상 DataNode로 전송됩니다.

The Difference Between Hot, Warm and Cold Data

NEW Hadoop3와 Erasure Coding

정전되고 나니 mstsc로 잘만 쓰던 GUI환경이 먹통이 되었다.

# systemctl status xrdp.service

명령어도 현재 xrdp 상태를 확인해준다.

없는 경우 설치먼저

# yum install xrdp

# systemctl start xrdp.service

# systemctl enable xrdp.service

# systemctl status xrdp.service

xrdp.service - xrdp daemon

Loaded: loaded (/usr/lib/systemd/system/xrdp.service; enabled; vendor preset: disabled)

Active: active (running) since 목 2021-09-30 13:29:16 KST; 3s ago

Docs: man:xrdp(8)

man:xrdp.ini(5)

Main PID: 44674 (xrdp)

Tasks: 1

CGroup: /system.slice/xrdp.service

└─44674 /usr/sbin/xrdp --nodaemon

hbase에는 주키퍼가 내장되어있다.

hbase-env.sh

export HBASE_MANAGES_ZK=true
export HBASE_MANAGES_ZK=false

true면 hbase에 내장되어 있는 zookeeper 사용

false면 zookeeper 사용

hbase-site.xml

    <property>
      <name>hbase.zookeeper.property.clientPort</name>
      <value>2181</value>
    </property>
    <property>
      <name>hbase.zookeeper.quorum</name>
      <value>hostname1,hostname2,hostname3</value>
    </property>

zookeeper 포트 번호와 주키퍼 실행하는 호스트 이름들을 적어줘야된다.

hbase 데몬 실행 후
JPS 명령어로 프로세스를 확인해보면
리젼서버의 경우 잘 올라오지만, HMaster가 실행됐다가 얼마안돼서 죽는경우가 있다.

이럴경우 hbase hmaster log와 hadoop namenode log 둘 다 확인해 주어야한다.
hbase 설정값이 잘못되었거나 hadoop에 설정값이 잘못된 경우가 있기 때문이다.

기본적으로 hbase localhost 값을 추가해주어야한다.

hbase-site.xml

<property> <name>hbase.master</name> <value>localhost:60000</value> </property>

hadoop core-site.xml

 <property> <name>hadoop.proxyuser.hadoop.hosts</name> <value>*</value> </property> <property> <name>hadoop.proxyuser.hadoop.groups</name> <value>*</value> </property>

yum 명령어로 설치하는했을 때 내가 원하는 버전과 다른 경우가 있다.

이미 설치하고나서 다시 지우고 할때 좀 번거로운 부분이 있어서 

설치할 때 원하는 버전으로 설치하는게 깔끔하다.

설치과정은 centos7버전 기준이며, OS와 OS버전에 맞게 공식사이트에서 명령어를 제공해주니 참고하면된다. 

sudo yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
sudo yum install -y postgresql12-server
sudo /usr/pgsql-12/bin/postgresql-12-setup initdb
sudo systemctl enable postgresql-12
sudo systemctl start postgresql-12

https://www.elastic.co/kr/downloads/kibana

키바나 다운로드 웹사이트에 접속하여

사용할 서버의 OS에 맞게 다운로드 받아서 설치하면 된다.

Linux CentOS7기준으로 설치를 진행하면

# wget https://artifacts.elastic.co/downloads/kibana/kibana-7.14.1-linux-x86_64.tar.gz

# tar xvzf kibana-7.14.1-linux-x86_64.tar.gz

# ./bin/kibana

압축해제 후 bin디렉터리로 이동해서 kibana 바이너리를 실행한다

접속할 수 있는 웹사이트 주소이다.

http://localhost:5601

curl -x http://localhost:5601 명령어 입력해서 확인해도 된다.

$KIBANA_HOME\config\kibana.yml

해당 파일 수정해서엘라스틱서치 포트번호나 키바나 포트번호를 설정해 준다.따로 포트번호를 수정하지않았다면 그대로 사용하면 된다. (주석되어있다면 제거)

https://www.notion.so/Elastic-Search-Install-73057f3b39ac4b26a8952f78e38e4e0d

해당 페이지에서 각자에 맞는 버전으로 다운로드를 받는다.

리눅스 Cent OS 7버전 기준으로 진행하면,

# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.14.1-linux-x86_64.tar.gz

# tar xvzf elasticsearch-7.14.1-linux-x86_64.tar.gz

#./bin/elasticsearch

bin폴더안에 위치한 elasticserch 바이너리를 실행하면 된다.

# curl -x http://localhost:9200/