HoonDongKim's BigData & AI

2015년 10월 6일 화요일

Spark Yarn Cluster vs Spark Mesos Cluster (vs 기타 다양한 모드) : [첫번째] 수행성능 및 활용성 비교

Spark Yarn Cluster 모드와 Spark Mesos Cluster 모드의 성능 비교를 하기에 앞서.....
Spark 를 여러 모드로 사용해본 기억을 더듬어 보았다..대략 이정도...

Spark + Shark + parquet
Spark + Shark
Spark + Tachyon + parquet
Spark + Shark + Tachyon
Spark + Tachyon + parquet
Spark + Tachyon
Spark Stand Alone Cluster
Spark Yarn Cluster

Yarn Client Mode
Yarn Cluster Mode

Spark Mesos Cluster

[1~2번 조합에 대하여..]

초창기에 실험했던 조합이다. 2~3년전인가... spark 가 0.6~0.7 요정도였던 시기였던 듯..
그때는 Scala 가 익숙치 않았었고, Spark가 지원하는 세세한 라이브러리들의 기능들이 빈약해서, SQL on Hadoop 용도로의 활용 에만 꼳혀 있었던 터라...Shark 를 써보려고 무던히 애를 썻었다.

-> [결론] Shark 쪽에 Error 가 너무 많아서.. Production 화 하지는 못했고, Adhoc 용도로만 사용했었다. Parquet 파일포맷과의 호환성도 최악이었다. 요즘은 조금 상황이 다르지만, 당시에는 버전업이 자주 되었고, 버전업 때마다 하위 호환성은 최악이었으며, 타 Legacy 와의 Compatibility 이슈가 매우 빈번하였다.

[3~6번 조합에 대하여..]

-> Tachyon 은 메모리 기반의 분산 NFS 형태로, Parquet 포맷 원천 HDFS 상 파일을 De-Normalize 하여 Plain 포맷으로 올려놓고(마치 DW와 Mart 의 조합처럼...), 빠르게 읽고 쓰고 하는 용도로 사용했었고, 꽤 성능이 우수하였다. HDFS 상의 Parquet 보다, Tachyon 상의 PLAIN TSV 포맷 텍스트 파일의 성능이 더 좋았으며, NFS 처럼 마운트가 가능하여, Legacy 와의 호환성도 매우 좋았다.

-> [결론] 이 시점 부터 월배치 수행 정도로 조금씩 Production에서도 활용하기 시작.. 여전히 약간 불안...일배치를 돌릴 정도로 안정적이진 못했음. ( 버전이 아직 1.0되기 전 시점인지라..)

[7~9번 조합에 대하여..]

-> 1.0 버전 이상이 되면서, 안정성과 SQL 자체 지원. 그리고, 다양한 특화 라이브러리 자체 지원등 여러가지 활용성이 좋아졌고, 드디어 Production 에 사용하기 시작했다.
-> 작년 중순부터였던 듯..

-> [결론] 전반적으로 Spark Stand Alone Cluster 모드가 테스트 시점에는 가장 쉽고, 성능도 단일 프로세스를 Serial 하게 쓸때는 나름 빠르게 나온다. Adhoc 분석 시스템일때는 이 모드로 쭉 써도 무방할듯. 그러나, 프로덕션 환경에서 동시에 병렬 수행되는 Spark Job 이 5~6개 이상일 정도로 활용성이 증가 된 환경에서는, Stand Alone 모드로 사용이 불가능에 가깝다. 즉, 이 시점부터 Spark Yarn Mode 로 사용할지, Mesos Mode 로 사용할지 고민에 빠지게 된다....

실험환경

HW 및 데이타

실험에 사용된 Data 는 수TB 이상의 데이타 이며, TSV 포맷이다. 두 시스템에서 사용된 HW는 100% 동일한 HW이다.

버전

Hadoop 2.7.1
Spark 1.4.1
Mesos 0.22.1

Business Logic 구현 언어

Scala

Spark Yarn Mode vs Spark Mesos Mode 성능 비교

CPU & Memory 자원을 거의 쓰지 않고, Disk IO 와 Network IO 를 극단적으로 많이 쓰는 Business Logic 수행.

mesos cluster (FAIR 모드)

605초 걸렸다. (2차 시도에서도 606초)
물론 mesos 모드에서는 Fair 모드 여부와 Fine Grain 여부 등등 성능과 좌우되는 다양한 옵션이 존재하긴 하지만...다소 느리지만 안정적인 General 옵션으로 수행하였음.

yarn client 모드

219초 무려 3배 가까이 빠르다. (2차 시도에서도 216초)

yarn cluster 모드

225초. Client 모드보다 살짝 느리지만...비슷한 수준. (2차 시도에서도 221초)

CPU 와 Memory 를 많이 쓰는 Group By & Sort & Aggregation 로직이 포함 된 Business Logic 수행.

mesos cluster 모드

29초 걸렸다. (2차 시도는 30초)

yarn client 모드

1차시도 57초. 2차 시도 59초. 결과는 Mesos 의 그것과 동일.
오홋....드디어 Mesos 가 저력을 발휘... Mesos 가 2배 정도 빠름. 다시말하여, Yarn Client 모드는 Mesos 보다 2배 정도 느렸다.

yarn cluster 모드

61초.
여전히 yarn client 보다 3~4초 느리고. mesos 보다 2배 느리다..

결론

Disk 와 Network 만 극단적으로 사용하고 CPU 나 Memory를 거의 쓰지 않는 극단적인 로직에선 Yarn이 성능이 좋았다. 그 이유는 Yarn 은 HDFS 에서 바로 연산을 하기 때문일 것이다.
반면, Mesos Layer 가 추가 된 아키텍처에서는 동일 머신에 Mesos Cluster 가 있음에도 불구하고, Mesos 의 Memory Cache Layer 로 다시한번 Data 셔플이 일어나면서 Over Head 가 한단계 더 있어서 일거라 예상이 된다.
실제, tmp 디렉토리에 Mesos 쪽에서 남기는 셔플된 데이타들이 꽤 된다.
그러나, IO 만 극단적으로 사용하는 Business Logic 은 극히 드물다. 사실 우리의 경우 그런류의 배치는 50개 중에 1개가 있을까 말까이다... 대부분은 컬럼 한두개 이상으로 Partition 되도록 Directory 정책을 Collection 시점에 적용하고 있어, Full Data 로딩이 거의 없고, Full Data 로딩을 하는 경우에도 Filter 로직으로 셔플은 일어나지 않고, N대의 분산 머신에서 RDD 자체에 로딩을 하지 않도록(mesos tmp 에 file block 들이 쌓이지 않도록), 데이타 로딩 시점에 제한 로직을 가하고 있다. (다 로딩하고 SparkSQL 에서 where 로 데이타를 줄이거나 하진 않는다는 의미이다..)
대부분의 경우 CPU와 Memory를 많이 먹는 Group By Aggregation 로직이 많은데, 이 경우는 역시 Mesos 가 2배 정도 빠른 성능을 보여주었다. ( Yarn 이 설치된 동일 HW에 Mesos 가 구동되었고, Yarn으로 할때는 Mesos 데몬을 내려주고 했어도 그렇다.)
성능과는 다른 이야기 이지만, Mesos 의 장점은 좀더 있다.. 바로 요런거...

Yarn 모드로 spark submit 할때는 core 사용갯수. executor 메모리, driver 메모리, executor 갯수를 실험적으로 매우 적절히 사용해야 한다.

물론 하드웨어가 핑핑 남아돌면, 다 충분히 크게 주면 되지 않냐는 반문이 있을 수 있다. 하지만, 메모리 등을 너무 크게 주면 GC 에서 예기치 못한 장애가 유발 될 수 있다.
Spark 메뉴얼은 아래처럼 권고하고 있다.
Use more executors with smaller heap sizes. This will reduce the GC pressure within each JVM heap.
그러나 heap size 를 줄이는 경우 반대로 heap memory 부족 에러도 훨씬 자주 접한다.
즉, 어느 한쪽으로 치우쳐도 안되고 job 에 따라 적절히 줘야 하는데...Job 이 수백개인 경우...그리고, 데이타 크기나 새로 인입되는 job 이 한달에 10개 이상이라고 한다면... 그러면, 적절히 최적화 해놓은 해당 값들이 다 틀어진다..TT
Mesos 는 그런거를 추상화 해준다.
Job 이 적을때랑 많을때 지가 알아서 cpu 코어 갯수나 memory 나 executor 의 갯수를 다이나믹하게 할당하고, job 이 좀 몰리면, 적절하게 분할 배분 수행시킨다.
관리적인 측면에서 이건 매우 큰 이점이며, 약간 이상의 성능은 충분히 커버하고도 남을 정도로 중요한 요소이기도 하다. 특히 안정성 측면에서..

( Yarn 도 이런 설정이 불가능 한것은 아니다.. Yarn Dynamic Resource Allocation 으로 검색 해 보시길.. 메커니즘은 약간 다른것 같다. 특히, excutor가 remove 될때 RDD 가 같이 사라지는 문제가 있어, 이 문제를 해결하기 위해 RDD 를 전달 하는 external shuffle 메커니즘이 Mesos 의 그것과 좀 다르다. 아키텍처 특성상.. Mesos 는 해당 Tier 자체가 공유 Memory 를 고려한 프레임워크 인지라 이런 공유 RDD 처리가 좀더 메크러운 것 같다.)

추가적으로 Hadoop Eco System 에는 Hadoop 보다 훨씬 많은 노드가 NoSQL 이나 다른 Service Layer 에 존재 할 수 있다.. 좀 헝그리하게 시스템을 운영하는 경우라면..(우리처럼 TT) Mesos 를 모든 장비에 깔아주면.. 모든 시스템을 쥐어 짜듯 죄다 활용할 수 있어서... 모니터링 콘솔들을 보고 있자면, 놀고 있어도 일하는 거 같고... 왠지 알아주는 사람 없지만, 회사에 수(or 수십)억원을 Save 시켜주고 있다는 느낌을 혼자(TT) 받을 수 있다.
모니터링 또한 Mesos 의 모니터링 콘솔이 훨씬 직관적이고 잘 되어 있다. 현재 얼마나 cpu 를 쓰고 있고, 메모리를 쓰고 있고, 몇개의 executor 가 job 별로 할당되어 있고.... 어떤 job 이 대기 타고 있는지 1초만에 확인 가능한 단일 view 를 제공한다. yarn 은 여러번의 클릭을 하고 머릿속에서 종합해야 할 일들이다. 물론 스케줄러가 좀더 큰 그림의 진행 상황을 별도로 보여주는 레이어로 존재할지라도..현 시점의 Job 상황을 HW 리소스 와 함께 맵핑하여 본다는 건 실무에서 꽤 필요한 부분이다.
Spark Streaming 이나 SparkR 에서도 할이야기들이 좀 더 있지만...요건 별도 Post 하는 걸로...

2015년 8월 31일 월요일

InfluxDB (Distributed time series database for RealTime Aggregation) - 설치기

InfluxDB는 오랫동안 예의 주시해오던 RealTime Layer의 TimeSeries (Aggregation도 되는) NoSQL DB 이다.( Go 랭귀지로 만들어져 있고, 요런류의 NoSQL 로는 신생에 속해서, 왠지 그냥 빠를것 같다는 선입견도 있었는데 진짜로 빠르고 직관적이라 사용하기도 쉽다.)
그러나, 오랫동안 Cluster 세팅이 베타 버전이었고, 0.9.1 과 0.9.2 는 three node 구성만 지원하는 제약이 있어, Production 에서 사용하기에 많이 부족한 면이 없지 않았다. 하지만 최근(본 글을 쓰는 시점으로 부터 4일전. 2015년 8월 27일) 0.9.3 버전이 오픈되면서 이 제약이 풀렸다. 7월초에 0.9.1이 정식 릴리즈 되었었고, 7월말에 0.9.2 이 정식 릴리즈 된바 있었는데, 한달이 지난 8월 27일 드디어 클러스터 세팅이 공식 지원되는 첫 버전이 릴리즈 된 것이다. ( 요놈도 마이너 버전이긴 하지만, 마이너 정식버전 릴리즈가 엄청나게 빠르다. )

아래는 클러스터 지원에 대한 공식 홈페이지에서의 언급 내용이다. 물론 아직 약간의 개선되어야 할 피처가 남아 있는게 사실이다. Computing Node 즉 분산쿼리에 있어서는 아직 Beta State 라고 언급하고 있고, 단지, Storage 입장에서 Data Node 가 3대 이상으로 확장되고, Size 분산되는 입장에서만 Release 가 정식버전이라 언급하고 있다.(3대 노드 이상일때 분산 쿼리가 지원이 안되는 것은 아니다, 좀더 해결해야 할 부분들이 더 남아 있다는 표현이 맞을 듯 하다.) 즉, 분산 쿼리 측면에서는 아직 Hybrid 한 느낌이다. (여하튼 아직까지는 3대 정도의 Node 갯수에서도 Spark Streaming 이 전처리를 한, 작은 Window Size 의 데이타에 대하여는 충분히 빠른 결과를 보여주고 있다.)

디렉토리 구성 및 설치 파일 다운로드. 그리고 간략 설치.

cd /data01
mkdir influxdb
cd influxdb
wget https://s3.amazonaws.com/influxdb/influxdb-0.9.3-1.x86_64.rpm
sudo yum localinstall -y influxdb-0.9.3-1.x86_64.rpm
sudo /etc/init.d/influxdb start <--- single node 구성이 아닐때는 요걸 먼저 수행하면 큰일 남... 이것땜에 삽질 많이 함. 모든 컨피그 끝나고 첫 수행을 해야 함. Cluster Mode 세팅 시에는 Cluster 관련 세팅 종료 후 구성해야 함.

일단 요기까지 하면, single node 구성 세팅 완료.

CLI 구동 ( Cluster Node 일때는 모든 세팅 끝나고 수행 )

우선 환경변수에 추가.( at .bashrc 에 /opt/influxdb 추가 )
influx 하면 CLI 가 구동 됨.
아래는 상세 옵션 들.... import 도 되고, 원격서버접속도 되고, format 옵션으로 json 이나 csv 로 output 을 뽑을 수도 있고, compressed import 옵션도 보인다.

Cluster 세팅

각 노드에서 설정 변경

sudo vi /etc/opt/influxdb/influxdb.conf

hostname = "localhost" 를 각 노드 hostname 으로 수정
port 를 1번노드는 :8088 , 2번노드는 :9099 , 3번노드는 :10101 로 수정.

1번 노드에서 재구동

sudo /etc/init.d/influxdb stop
sudo /etc/init.d/influxdb start

2번 노드에서 아래처럼 구동

sudo vi /etc/init.d/influxdb 에서 INFLUXD_OPTS="-join hostname1:8088"
sudo /etc/init.d/influxdb stop
sudo /etc/init.d/influxdb start

3번 노드에서 아래처럼 구동

sudo vi /etc/init.d/influxdb 에서 INFLUXD_OPTS="-join hostname1:8088,hostname2:9099"
sudo /etc/init.d/influxdb stop
sudo /etc/init.d/influxdb start

확인

influx 하여 CLI 콘솔을 띄우고, show servers 해서 node 들이 복수개 보여야 함.
그러나 위데로(메뉴얼데로) 했는데, 안되기도 함.TT
아래처럼 config 파일을 열어서 수동으로 세팅...
sudo vi /var/opt/influxdb/meta/peers.json
["<hostname 1>:<port 1>","<hostname 2>:<port 2>","<hostname 3>:<port 3>"]
정상 수행 완료 되면, show servers 명령에 아래처럼 3개 Node 가 보여져야 함.

Druid (Interactive Analytics at Scale) - Cluster Setting

RealTime Analytics Layer 에서 사용가능한 NoSQL 중 설치는 다소 복잡하지만, 튜닝을 적절히 해주면 꽤 좋은 성능을 얻을 수 있는 Druid.

아래는 Druid Production Cluster 를 위한 간략한 버전의 Cluster Setting 설치기 이다. 간략해 보이지만, 실제 웹사이트 메뉴얼에 부족한 부분 위주로 정리한거라 실제는 이것보다 훨씬 방대한 설치 세팅 작업이 필요하다. 한가지 아쉬운점은 웹상 메뉴얼데로 설치하면 난관을 30번쯤 만난 다는 점.. 아래는 난관을 해결한 Key 위주로만 적은 내용이라, 실제 설치시에는 메뉴얼과 함께 보면서 설치해야 한다.

우선 메뉴얼을 속독 하면서 보았던, 인상깊은 문구....
When talking about query speed it is important to clarify what "fast" means: with Druid it is entirely within the realm of possibility (we have done it) to achieve queries that run in single-digit seconds across a 6TB data set.

본 Cluster 노드 세팅 스크립트를 메모하면서 수행한 시점에 동원된 Node 는 총 7대 이며, 일전에 세팅한 Single Node 로 세팅된 환경을 VM Template 화 하여 7대로 증분 시키고, 필요없는 데몬을 끄거나, 재 설정 하는 식으로 세팅하였다.

[그림1] VM6대 노드 구성

구성한 노드의 구성은 아래와 같다.

vm-broker01 : broker (32core,244GB,SSD), 32G Heap
vm-druid01 : historical (32core,244GB,SSD), 32G Heap
vm-druid02 : middleManager (32Core,244GB,SSD), 32G Heap
vm-druid03 : realtime -> (32Core,244GB,SSD), 32G Heap
vm-druid04 : zookeeper01, coordinator (8Core)
vm-druid05 : zookeeper02, mysql , overlord (8Core) - for indexing Service

[그림2] web datasource 콘솔

[그림3] web task 콘솔

[그림4] middlemanager 모니터링

mysql 세팅 변경 ( at vm-druid05 )

default 패스워드 변경

http://blog.naver.com/gihyunkwak/220329365505

원격 접속 허용되도록 변경

http://nsinc.tistory.com/70

Template 화 Copy 된 Node 이므로 vm-druid06 Node 를 제외한 전체 노드에서 Mysql데몬 중지. 그리고 druid05에만 구동.

sudo service mysqld stop
sudo service mysqld start

zookeeper 세팅 변경 ( at vm-druid06 )

zoo.cfg 변경

dataDir=/data02/zookeeper/data

zookeeper 세팅 복제 및 복제 서버 세팅

상세 세팅 방법은 Zookeeper 페이지 메뉴얼에 잘 나와 있으므로 skip

zookeeper 구동

bin/zkServer.sh start & ( & 안해도 되긴 하지만... )

zookeeper AutoStart 설정

http://www.programering.com/a/MjNxQjNwATc.html 참조

~~dervy 설치:~~ 아래 dervy 모드는 최초 설치 테스트 시점에만 사용. dervy로 설치 성공 이후에는, 실 Production 용에서는 AWS 와 Hadoop Yarn 모드로 변경 세팅 해야 함. (설치 메뉴얼 그데로 구성하였으므로 이 부분은 설치 메뉴얼 정리 skip)

~~wget http://apache.mirror.cdnetworks.com//db/derby/db-derby-10.11.1.1/db-derby-10.11.1.1-bin.tar.gz~~
~~기타 세팅~~

~~http://db.apache.org/derby/papers/DerbyTut/ns_intro.html~~
~~서버 모드 실행~~

~~http://db.apache.org/derby/papers/DerbyTut/ns_intro.html~~
~~java -jar derbyrun.jar server start~~
~~lib 폴더로 가서 위 2를 수행하면 path 안잡아줘도 수행 가능.~~

common 세팅 ( all node )

config 수정 : 메뉴얼 내용과 유사하지만.. 수치 값에는 데이타 크기와 Job 성격에 따른 실험적 튜닝이 필요함.

SCP 로 전체 노드에 복사

scp common.runtime.properties moneymall@vm-druid01.cloudapp.net:/data01/druid/druid-0.7.0/config/_common/

overload 실행

config 수정 : 메뉴얼 내용과 유사하지만.. 수치 값에는 데이타 크기와 Job 성격에 따른 실험적 튜닝이 필요함.
SCP 로 전체 노드에 복사
run 스크립트 작성 : 메뉴얼 내용과 동일

middle manager node 실행

config 수정 : 메뉴얼 내용과 유사하지만.. 수치 값에는 데이타 크기와 Job 성격에 따른 실험적 튜닝이 필요함.
scp 로 전체 노드에 복사
run 스크립트 작성

coordinator 실행
historical 실행
broker 실행

config 수정

아래 부분 수치를 메뉴얼 데로 하면 안됨. 1의 자리 숫자 8을 7로 바꿈.

druid.processing.buffer.sizeBytes=2147483647

기타 장애 해결

중요 batch 수행 장애 해결 tip1

batch 수행을 05번 노드 (overload 노드)에서 수행하였는데, ddl 이 담겨져 있는 json 에서(overload 노드에 존재하는..) 가리키는 물리 path 는 실은 05번 노드가 아닌, middlemanager 가 접근하는 path 로 적어져 있어야 함. middlemanager 가 복수개 이므로, 어떤 manager 에 할당될지 모르는 환경에서는 hdfs 등 공유 스토리지가 아닌 경우 path 설정에 유의할 필요가 있음.

중요 batch 수행 장애 해결 tip2

config 디렉토리는 모두 실제 존재하고 적절한 퍼미션이 있어야 함.
특히, jvm 옵션중에 존재하는 tmp 디렉토리 또한 실제 물리적으로 존재하고 퍼미션이 적절해야 에러 없이 수행 됨.

인덱스가 다이나믹 하게 되도록 수정.

http://druid.io/docs/0.7.1.1/Indexing-Service-Config.html

2015년 8월 5일 수요일

Mesos 0.22.1 HA 구성 Test

Mesos Client 중 한대가 죽으면, 걍 죽은데로, 나머지 노드에서 Job 이 잘 돌아간다. 물론 죽는 시점에 죽는 노드에서 돌던 Job 자체는 Fail 이 될 수 있다. 그럼 master 가 죽으면 어떻게 될까?

최신 버전으로 실험을 해보았다. 실험에 사용한 버전은 Mesos 0.22.1 이다.

갑자기 Mesos Master 노드에서 Kill 로 Master 를 죽여 보았다. (실험시점 Master 를 구동할때 별도로 Zookeeper 세팅을 해준게 전혀 없는 상태이다.)

그랬던니, 첫번째 Client 에서 아래와 같은 로그를 볼수 있다. "Waiting for a new master to be elected" 그리고는, 갑자기 첫번째 Client 가 Master 가 되면서, 전체적으로 클러스터 자체는 동작하고 있는 상태가 되었다.

잘만들었네.. ^^ 물론 바뀐 Master 노드 주소를 찾아가게 하는 문제는 남아 있지만...그런거는 뭐 전통적인 방법으로 풀면 되니까..skip...

BigData 파트에서의 전통적인 방법이라 함은.... 예를 들어 요런거...(zookeeper 를 이용해서..)

Spark Submit 스크립트가 Mesos Master 주소를 Set 할때 요런식으로..

--master=zk://호스트1주소:port1,호스트2주소:port2,호스트3주소: port3,.../path

2015년 8월 4일 화요일

Spark Cluster Settings On Yarn : Spark 1.4.1 + Hadoop 2.7.1

spark + yarn 의 Cluster 세팅은 spark + mesos 의 Cluster 세팅에 비하여 매우 쉽다. spark stand alone Cluster 의 경우 client node 에 spark 를 모두 설치해 주어야 하지만, spark + yarn Cluster 의 경우에는, spark + mesos Cluster 의 경우와 마찬가지로, master 에만 설치해주면 동작한다. (물론 Yarn 위에서 구동되므로, Yarn 관련 설정은 모든 Node 에 동일하게 설정되어 있어야 한다. 그리고, Yarn 이나 Mesos Master 가 Spark Master 와 반드시 같은 Node 필요는 없다.)

기존 spark stand alone 클러스터 세팅에서 아래 정도만 신경 쓰면 설치가 완료 된다.

환경변수 세팅

기존 Hadoop 환경변수는 세팅되어 있다고 가정
HADOOP_CONF_DIR 라인을 Copy 하여 YARN_CONF_DIR추가(모든 Node 에서)

Spark.local.dir 관련 폴더 생성

모든 노드에 Disk 파티션이 큰 영역에 별도의 spark local dir 폴더 생성.
이것을 정의 하지 않으면, /tmp 가 차올라서 disk full 이 되기 십상이다.
mkdir /data02/spark_tmp/
spark.local.dir 관련 set 은 SparkConf().setAppName("AppName").set("","") 메소드를 이용.(프로그램 내부에서 정의 함. 물론 실행 시점이나, 글로벌 conf 파일에서 정의 할수도 있긴 하지만...)

Mode 선정

spark + yarn 모드는 두가지 모드가 있으며 아래와 같은 특징이 있다.

yarn cluster mode

job이 중앙에서 구동되는 방식이다. 좀더 Yarn 의 리소스에 의존하여 구동되는 느낌이다.
scala 소스 내에 println 을 넣으면, spark-submit 을 한 콘솔에 출력되지 않고, hadoop의 yarn Job 관리 UI 에서 stdout Log 를 통해 확인할 수 있다.
위 그림은 println 한 결과 출력 창이다. (MapReduce UI)

yarn client mode

특정 client 에서 spark-submit 을 날리면, 해당 머신에서 main 클래스가 구동되는 듯 하다. 물론 실제 잘게 쪼개진 sub task 들은 yarn 위에서 구동된다.
때문에, yarn cluster mode 와 달리, println 을 하면, 수행시킨 Console 에서 결과가 stdout 으로 바로 보여진다.
잘게 쪼깨진 sub task 만 yarn 에의해 관리되는것 같다.
동작방식이 mesos cluster 위에서 spark job 을 구동했을때와 매우 흡사해 보인다.
위 그림은 println 한 결과 출력 창이다. (수행 Console )

구동을 하면 아래처럼 Yarn 의 Job 관리 UI 에서 수행 상태를 확인 할 수 있다. 이러한 Job UI 자체는 Mesos나 Spark Stand Alone Cluster 의 그것에 비하여 좀 기능이 떨어진다. Application Type 이 MapReduce 인 경우 MAPREDUCE 라고 보이는 반면 Spark Job 은 SPARK 라고 보여 진다.

2015년 7월 29일 수요일

Hadoop 1.X -> Hadoop 2.X Data Copy with DISTCP

Hadoop 1.X 에서 Hadoop 2.X 로 Data 를 Copy 할때는 여전히 distcp 를 이용하면 MapReduce Job 을 이용 N대의 머신의 IO 를 모두 활용 빠르게 Copy 가 가능하다.

하지만, 동일 버전의 서로다른 2대의 클러스터에서 사용할때와는 좀 다르게 사용해야 한다.

우선 동일 버전의 Cluster 에서는 아래처럼 사용했었다.

hadoop distcp hdfs://source-masternodeURL:9000/path hdfs://destination-masternodeURL:9000/path

그러나, 버전이 다른, 특히 1.X 와 2.X 처럼 크게 버전이 다른 경우에는 아래와 같은 에러가 발생한다.

그래서, 위 명령어를 2.X 에서 수행하면서, 아래처럼 1.X 의 프로토콜을 변경해 주어야 호환성 있게 작동을 한다.

hadoop distcp hftp://source-masternodeURL:50070/path hdfs://destination-masternodeURL:9000/path

그러나, 위처럼 작업을 하면, 또 아래와 같은 에러가 발생하다가 MapReduce Job 이 죽어 버린다. 결과를 확인해 보면, Directory 만 잔뜩 에러 없이 만들어지고, 파일을 Copy 하는 과정에서는 아래처럼 CheckSUM 에러가 잔뜩 나다가 죽어 버리는 상황이 반복된다.

위 에러를 해결하는 방법은 아래와 같다.

에러메시지를 자세히 보면, using -skipCrc 요런 문구가 보인다. 그런데 옵션 메뉴얼상을 보면 -skipCrc 라는 옵션은 존재하지 않는다...아마도 에러메시지의 bug 인듯... 해당 옵션은 -skipcrccheck 이다. 그리고 해당 옵션만 넣고 수행하면, 또 -update 옵션과 함께 사용하라는 문구가 나온다. 결국 최종 컴멘드는 아래와 같다.

hadoop distcp -update -skipcrccheck hftp://source-masternodeURL:50070/path hdfs://destination-masternodeURL:9000/path

위 명령어 수행시 아래처럼 MapReduce Job 이 수행되면서 두 서로 다른 버전의 hadoop cluster 가 병렬 분산 Copy 가 이루어 진다.

2015년 7월 27일 월요일

Hadoop 2.7.1 - Cluster Setup 설치 적용기.

최근들어 hadoop 2.X의 버전업이 매우 긴박하게 이루어지고 있는 느낌이다. 작년 말 2.6.0 이 정식 릴리즈 된 이후, 잠시 Spark 때문에 Hadoop 버전업을 따라가고 있지 못한 사이, 불과 3달 전(2015년 4월말) Hadoop 2.7.0 이 4~5개월여 만에 또 다시 정식 릴리지가 된 바 있었기 때문이다. (그리고, 다시 언급하겠지만, 몇주전 Hadoop 2.7.1 이 정식 릴리지 되었다.)

그러나, Hadoop 2.6.0 을 Skip 하고 Hadoop 2.7.0 을 staging 에서 production 화 테스트 시작했던 두어달 전, 나는 작업 하던 중간 아래와 같은 문구를 발견하고, 한참 세팅하던 과정을 접고 다시 Hadoop 2.6.0 으로 Down Grade 하였던 아픈 기억이 있다.

바로 위에서 파란색으로 Highlight 한, 2.7.0 은 몇가지 critical issue 때문에 production 에서는 아직 이용하지 않는게 좋다는 문구 때문이었다.

위 이미지 내에 언급된것 처럼 2.7.0 에는 몇가지 매력적인 업그레이드가 있었다. 그중 하나는 Azure Storage 를 쓸 수 있게 된점이고(회사에서 그룹사 계약으로 Azure Storage 를 Amazon 보다 유리한 조건으로 사용이 가능하다.), 또 다른 점들은 (좀더 실험을 해 보아야 하겠지만) variable length 나 file truncate 를 사용할 수 있게 된 점 등이었다.

여하튼 그런 일부 매력적인 기능을 포기하고, 다시 2.6.0 으로 Down Grade 하였다가, 막 테스트를 끝내고 Production 환경 Rolling Upgrade Script 에 반영 Freezing 하려던 찰나...난 몇주전 또 한번 좌절하고 말았다.

바로, 2.7.0의 Critical Issue 가 해결된 2.7.1 의 안정버전이 발표 되었기 때문이었다.(정확히는 2015년 7월 6일 정식 릴리즈 발표가 있었다.) 버전 바꾸는 삽질을 많이했지만, 기저에 해당하는 Hadoop 의 버전업은 매우 조심하고 신중하게 처리해야 하고, 자주 하기도 힘든 작업인 까닭에, 어찌 되었든 다시 2주 정도를 할애하여, 신규 구성중인 New 시스템의 호환성 테스트를 마치고, Production Rolling Upgrade 버전을 다시 2.7.1 로 수정 하였다. 2.7.0 대비 131개의 Bug 패치가 더해졌다고 하니, 이 버전으로 한동안 안정적인 운영을 했으면 하는 바램이다. (대부분 2.6.0 과 호환성이 맞춰진 Legacy 들은 2.7.1 과 특별한 호환성 이슈가 발견되지 않았다.)

아래는 기본적인 테스트를 마친 Hadoop 2.7.1 설치 스크립트의 기본 버전이다. (일부 특수한 Legacy 및 자체환경 특화 Custom 세팅 부분은 제외한 기본 세팅 버전....)

초기세팅 ( at .bashrc )

환경변수 $JAVA_HOME 세팅 되어 있는지 확인
환경변수 $HADOOP_HOME , $HADOOP_CONF_DIR 세팅
환경변수 $HADOOP_PREFIX 세팅
환경변수 $LD_LIBRARY_PATH 세팅
source .bashrc

다운로드

wget http://apache.mirror.cdnetworks.com/hadoop/common/hadoop-2.7.1/hadoop-2.7.1.tar.gz

설치

tar xvzf hadoop-2.7.1.tar.gz
cd hadoop-2.7.1
mkdir /data02/log/hadoop

세팅

etc/hadoop/hadoop-env.sh 세팅

export HADOOP_NAMENODE_OPTS 에 -XX:+UseParallelGC 추가
export HADOOP_LOG_DIR=/data02/log/hadoop
export HADOOP_HEAPSIZE=4000
export HADOOP_NAMENODE_INIT_HEAPSIZE="4000"

etc/hadoop/core-site.xml 세팅

etc/hadoop/hdfs-site.xml 세팅

for NameNode

for DataNode

etc/hadoop/yarn-site.xml 세팅

우선 대부분 default 로...
위 Address 및 기본 옵션 추가

etc/hadoop/mapred-site.xml 세팅

etc/hadoop/slaves 세팅

모든 slave 노드의 hostname 혹은 ip를 등록

Rack Awareness

현재 Staging 배포 버전에선 skip. Production 할때 하는 걸로...

전체 노드로 설정파일 overwrite 복사

위에서 수정한 설정 파일들에 대하여 전체 노드에 복사.(with scp)
hdfs-site.xml 의 경우 NameNode 설정과 DataNode 설정값이 다소 다름.

전체 노드에 기본 디렉토리 생성

위 xml 파일에서 설정하였던 디렉토리들 mkdir

전체 노드에 기본 유저 생성

Stage 모드에서는 moneymall로 통일

password less 설정

master node 루트 에서

ssh-keygen -t rsa 하고 엔터 세번...
scp ~/.ssh/id_rsa.pub moneymall@각노드Domain:~/.ssh/authorized_keys

clinet node 에서

mkdir ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

각 노드 구동

master node 의 hadoop home 으로 이동
bin/hdfs namenode -format moneymall(<-cluster 이름)
sbin/hadoop-daemon.sh --config $HADOOP_CONF_DIR --script hdfs start namenode
```
sbin/start-all.sh
```

리소스메니저가 안뜨면...
./yarn-daemon.sh start nodemanager
./yarn-daemon.sh start resourcemanager

DataNode jps 확인

NameNode jps 확인

Web UI 띄움. (Classic 버전) <-- Classic UI 가 2.6.0 에서는 공존하였는데, 2.7.1 에서는 Default 로는 링크가 존재하지 않는다.

[내부 정보 유출 방지를 위하여 이미지는 Dev-Zone 이미지 임.]

Web UI 띄움. (New 버전) <-- New UI가 2.6.0 에서는 하단 링크로 존재하였었는데, 현재 버전에서는 Default 로 존재한다.

[내부 정보 유출 방지를 위하여 이미지는 Dev-Zone 이미지 임.]