물론 혹자는 특정 언어나 특정 기술로 많은 것을 처리하는 것을 선호하기도 하지만(전문성 증대, 기술의 장인정신 측면에서 이 방식의 유리한 점이 존재한다.), 혹자는(나를 포함) 다양한 언어나 기술을 섞어 쓰면서, 처한 상황(Problem)에 가장 최적화된 기술이나 언어로 유연하게 접근하는 것을 선호하기도 한다.
그러한(후자) 측면에서 보았을때, R은 다양한 기술을 섞어 쓰는 BigData Scientist(혹은 BigData 개발자나 Machine learning 개발자) 에게는 참 계륵 같은 기술이었다. 소위 보편적인 Data 모델러들은, BigData Scientist 보다 R(SAS, Matlab, SPSS 포함)을 더 잘 다루는 것이 일반적이기도 하거니와, 그들과 Co-Work 접근을 해야 하는 경우는, 이미, R이나 SAS 로 무언가 문제가 직면되어 있는 경우가 많기 때문이다. BigData Scale을 다루는 경우이거나, Heavy 한 Machine Learning 작업이 필요하거나, Deep learning 접근이 필요한 경우가 그러한 경우의 일예라 할 수 있다.
이 경우 서로가 잘하는 영역을 분담하려고 하기 시작하면, R 이외의 다양한 특화 대체 기술을 선택하는 경우가 많은데, 그럼에도 불구하고 R을 버릴수 없는 이유는(앞서 계륵이라고 표현하였다.), R로 만들어진 정교한 모델들이(비록 셈플 데이타만 수행된다 손 치더라도) R이외의 기술들에서는 구현체가 완벽하지 않거나, R에서 쉽게 구현된 모델이 다른 기술에서는 구현이 녹록치 않은 경우가 너무나도 많기 때문이다.
BigData Scale 모델링 Project에서 자주 접하는 시나리오는 아래와 같다.
- 순수 모델러들이 R이나 SAS 로 최적화된 알고리즘을 찾아낸다.
- 셈플 데이타 혹은 전수로 데이타를 돌려보고, 각종 파라미터나 로직을 거의 완성한다.
- But, 모델이 도는데 3박 4일 이상이 걸리거나, 전수 데이타로 돌리는 것 자체가 불가능하다.
- BigData 팀으로 Co-Work 요청이 들어온다. 즉, R 모델을 다른 기술을 이용하여 포팅하는 협의가 시작된다.
- SparkML 으로 우선 포팅 가능성을 타진한다.
- 초대용량의 경우 수십~수백대의 Spark Cluster 위의 SparkML 로도 답이 안나오는 경우가 많은데 이때는 1차로 Mahout 의 구버전으로 Hadoop Map/Reduce 경유 수행이 가능한지 검토한다.
- SparkML 이나 Mahout 으로 구현이 쉽지 않은 복잡한 복합 모델의 경우는 제삼의 기술을 검토한다. Weka, PredictionIO, H2O 등등... 하지만 이 프레임워크들은 좀 난잡해서 별로 선호하진 않는다. 오히려 아래 방식을 좀더 먼저 검토한다.
- Spark, Mahout 계열에 없거나, Method 가 빈약한 경우 Python을 뒤져본다. SparkML 은 기본 메소드는 있는데, 고급 옵션들이 아예 구현이 안되어 있는 경우가 많다. 예를 들어 Spark ML의 Word2Vec 에는 기본 Method 외에 다양한 고급 활용 메소드들이 거의 존재하지 않아 일일이 구현을 해주어야 하고, FPGrowth 등은 Lift 값 관련 Method가 없어 이를 구할때, 개발자가 수식을 일일이 구현 해줘야 가능하다. 반면에 R이나 Python 들은 논문에 언급된 대부분의 기법들은 거의 구현이 되어 있는 경우가 많다. 이 시점에 R을 보지 않고, Python 을 보는 이유는, SAS 가 그러하듯이 Python 은 메모리에 올려놓고 계산하지 않고, 머신 1대가 오래 걸리더라도 꾸역 꾸역 계산을 하긴 해내기 때문이다.(뒤에 이 부분에 있어서의 R의 역습을 언급하겠다.) 머신 1대가 담기 힘든 용량이면 Hadoop 같은 공유 저장소에 올려 놓고 loop 를 돌리면, 어쨋든 무한 루프를 돌면서도 뻗지 않고 돌아는 간다.
- 8의 기술이 죽지는 않지만, 1대라 너무 너무 오래걸릴때는 GPU 카드를 꺼내 든다. 모든 알고리즘이 GPU 버전이 존재하는 것은 아니지만, 조금 뒤져보면 github 에 다양한 공유 구현체 들이 가끔 큰 희망을 줄때가 많다. C로 최적화된 Gensim 등의 Python 라이브러리는 굳이 GPU까지 동원하지 않더라도, 1대에서 돌려도 Spark 5~7 대의 성능과 맞먹는 경우가 종종 있다. 어쨋든 Python 에는 Spark 에 없는 무수히 많은 알고리즘 중 상당수가 이미 구현된 경우가 왕왕 있다. 그리고 대부분의 알고리즘들이 지원하는 고급 기법들이나 옵션들이 더 풍성하게 구현되어 있다.
- Python 이 너무 느릴때도 있다. 병렬 수행이 목마를때도 있다. 이 경우 PySpark 로의 Hybrid 사용 가능성을 타진한다.
- PySpark 로도 답이 없는 경우는 TensorFlow 카드를 꺼내 든다. Word2Vec 도 그렇지만, TensorFlow 에는 Deep Learning 류의 거의 대부분과, 상당수의 Machine Learning 알고리즘들이 기본 지원되거나, github 구현체가 이미 존재하는 경우가 왕왕 있다. (deeplearning4j 나 theano, caffe, cntk 등 다른 대안도 존재한다.)
- 이도 없을 때는 제일 마지막 방법으로 구글링 후 해당 알고리즘의 구현체, 그게 c가 되었건, java 가 되었건을 찾아 내어, scala on Spark, java on Map/Reduce, python on tensorflow 등으로 포팅 가능한지 그 타당성을 타진한다.
위 12번까지 간 적이 몇번 있었다. 몇해전 (지금은 FPGrowth 라는 걸출한 대안이 있지만..) Spark 초기 버전에서 SparkML에 Apriori 가 없어 Java 구현체를 Spark 에서 돌도록 알고리즘을 포팅했던, 별로 유쾌하지 못했던 경험이 있다. (모든 것에 은총알은 없다. SparkML의 FPGrowth 는 Apriori 알고리즘의 훌륭한 대안이지만, 중 규모의 Large 볼륨 데이타에서 빠르고 병렬성을 훌륭하게 지원하지만... Very High 규모의 데이타의 경우에, 그리고, confidence 를 조금 올려놓고 수행하는 경우, 변동성이 큰 데이타의 경우에, disk 를 쓰기 시작 하면서는 무한 loop 틱한 오랜 수행과 리소스 점유로 Production 에 큰 부하를 주는 경우가 왕왕 있다. 이런 Size 의 Data 에는 Hadoop 경유 연산 등 다른 대안을 찾아야 한다.)
이쯤에서 항상 드는 생각이, 거의 모든 알고리즘(Deep Learning 류만 빼고)들이 구현되어 있는 R이 병렬 수행되면 얼마나 좋을까 라는 점이다. (위 Spark ML 의 예에서 처럼 모든 경우의 은총알을 바라는 것은 아니다. 단, R on Spark 와 R on hadoop 으로 나누어져 있다는 것 자체가 좀더 유연할 것이라는 기대를 해본다.)
서두가 좀 길었는데, 아직은 미완의 진행형이긴 하지만, 이러한 측면에서 SparkR 과 MS R(구 Revolution R)의 병렬성 지원을 위한 최근의 행보는 매우 매우 응원을 하는 바이다.
사실 SparkR은 1.X에서는 실무에서 사용하기가 다소 힘든 정도였고, 2.X가 되면서는 다시 실무 활용이 가능한 정도까지 그 가능성이 열리고 있는데, 하지만 여전히 병렬성을 지원하는 알고리즘들이 극히 적다는 단점을 가지고 있다.(Spark 2.X가 되면서 SparkML과의 연동성 지원이 추가되었다.) 이 측면에 있어, MS R은 과거 상용 Revolution R 을 인수한 엔진을 사용하고 있어, 훨씬 다양한 병렬 수행 메커니즘과 훨씬 다양한 병렬 알고리즘 패키지를 이미 지원하고 있으며, 발전 속도도 매우 빨라진 느낌이다.(이 분야의 대부분 솔루션들이 그러하듯이, 아직 완성형은 아니고 진행형이다.)
SparkR 과 MS R이 접근하는 병렬성 메커니즘 접근 방식(SparkR은 Spark엔진 입장에서 R에 접근해가고 있고, MS R은 R입장에서 Hadoop 과 Spark로 다가가고 있다.)이 다소 틀리고 각각의 방식에 장단점이 있는데, 더욱 좋은 점은 둘을 Hybrid 하게 쓰는 것 또한 가능 하다는 점이다.
아래부터는 On Premise Hadoop ( Apache Hadoop 2.7.1 )과 On Premise Spark ( Apache Spark 2.0.2 )위에서 설치 구동 테스트한 설치 세팅 스크립트 이다. 설치 가이드는 MSDN문서를 참고하였으나, MSDN 을 그데로 따라 설치하면 많은 난관에 봉착하게 된다. 아래는 그 부분들의 해결책 까지를 포함하고 있다.
- Download
- Spark Cluster 를 이용하여 ScaleR을 돌림에 있어, Linux 버전 Install을 해야 하는지, Hadoop 버전 인스톨을 해야 하는지 좀 햇갈렸는데… Manual 을 잘 보다 보면, for Hadoop 을 설치해야 함을 알 수 있다. 즉 위에서 2번째 버전을 다운받아야 한다.
- 설치 참고 메뉴얼
- Linux 버전과 Hadoop 버전 설치 가이드는 아래 링크에 나와 있다.
- R Server Installation for Linux Systems
- Hadoop installation and configuration for Microsoft R Server
- Spark 위에서 구동하기 위한 Getting Started 문서는 아래 문서를 참고하면 된다.
- https://msdn.microsoft.com/en-us/microsoft-r/scaler-spark-getting-started
- 처음 설치하는 경우라면, scaler spark getting started 를 따라하기 전, Linux 버전이 아닌 Hadoop 버전의 MS R 이 기 설치 되어 있어야 한다.
- MS R on Spark 설치(본 설치에서 사용한 버전은 MS R Server for hadoop 9.0.1 임.)
3.
설치는 install.sh -p 로 -p 옵션을 주고 실행 함.
A.
첫번째 에러 만남.
이후
수행하니 위 에러 없이 정상 Install 되었음.
5.
설치 이후 확인
6. Hadoop 폴더 생성 및 퍼미션
A.
한쪽 노드에서만 수행. Hadoop 은 공유
되어 있으므로.
7.
각 Node에 로컬 공유 폴더 생성
A.
전체 Node 에서 수행.
i.
/usr/lib64/microsoft-r/3.3/lib64/R/library/RevoScaleR/SampleData/AirlineDemoSmallSplit
ii.
But, MSDN의 설치 매뉴얼의 주소와 좀
다른 위치에 있어 주의 요망. 9.0.1 MS R for Hadoop 에서는 위 파일
형태로 Air Polution 셈플 데이터가 존재.
B.
하둡에 업로드할 임시 폴더 생성.
i.
hadoop fs -mkdir
/tmp/msRsamples/
ii.
셈플 파일이 있는 로컬 경로로 이동하여, 해당
셈플 파일을 Hadoop 에 업로드.
iii.
hadoop fs -copyFromLocal *.csv
/tmp/msRsamples/
C.
로컬의 동일 경로에도 해당 파일 복사 생성.
i.
뒤에가서 Hadoop 과 로컬의 비교를 해보기
위함 임.
ii.
mkdir /tmp/msRsamples/
cp /usr/lib64/microsoft-r/3.3/lib64/R/library/RevoScaleR/SampleData/AirlineDemoSmallSplit/*.csv /tmp/msRsamples/
cp /usr/lib64/microsoft-r/3.3/lib64/R/library/RevoScaleR/SampleData/AirlineDemoSmallSplit/*.csv /tmp/msRsamples/
9.
Revo64 구동
A.
cd MRS90Hadoop
B.
Revo64
10. 셈플
코드 수행 준비
11. Hadoop 경로 핸들링
A.
앞에서 생성한 경로 hadoop fs -ls 조회
잘 수행 됨.
12. 셈플
코드 수행(For Local)
A.
input <-
file.path("/tmp/msRsamples/AirlineDemoSmallPart1.csv")
B.
colInfo <- list(DayOfWeek =
list(type = "factor", levels = c("Monday",
"Tuesday", "Wednesday",
"Thursday","Friday", "Saturday",
"Sunday")))
C.
airDS <- RxTextData(file =
input, missingValueString = "M", colInfo = colInfo, fileSystem = RxHdfsFileSystem())
D.
adsSummary <- rxSummary(~ArrDelay+CRSDepTime+DayOfWeek,
data = airDS)
E.
adsSummary
13. 셈플
코드 수행(For Hadoop)
A.
rxSetComputeContext(RxHadoopMR(consoleOutput=TRUE))
위와 같은 에러 발생.
4. 에러 해결
위 내용 중 libhdfs.so 에 문제가 있는 듯 하여 아래처럼 ldd 로 로컬 로딩 분석해 보았음.
4. 에러 해결
위 내용 중 libhdfs.so 에 문제가 있는 듯 하여 아래처럼 ldd 로 로컬 로딩 분석해 보았음.
ldd 로 보면 좀 이해가 가지 않는 부분이 있음. 즉, 모듈이 모두 정상 로딩 된 것으로 보인 다는 점 임.
root 로 su 한 다음
root 권한으로도 수행해 보았음.
위 처럼 이제는 좀전의 에러가 보이지 않음. 대신 Hadoop 에서는 root 의 권한설정이 안되어 있어 이번에는 Hadoop 에서의 에러 메시지가 발생하였음.
다시 밖으로 나가서 root 와 사용자 user 계정 모두 Hadoop 및 local User 에 대하여 공동의 SuperGrop 그룹에 속하도록 퍼미션 권한을 모두 맞추어 주고 재 시도 해 보았음.
앞선 에러 로그의 문제는 해결되었음. 하지만, 이번엔 또 아래 같은 에러 발생.
앞선 문제는 해결되는데… tmp/ 폴더가 또 문제.. (기존에 쓰던 Map/Reduce Job의 사용자와 다른 새로운 사용자로 R 을 병렬 수행하면서 새롭게 권한 문제 발생)
그렇다면 드는 생각. 현재 수행중인 노드는 ldd 로딩이 잘 되는데, 다른 cluster node 는 안되는게 아닐까? 답은 Yes.
최초 local 수행했던 MS R
Master 노드에는 libjvm.so 가 심볼릭 링크 존재함. 그런데, 나머지, 인스톨만 했고,
local 수행을 한번도 한적 없는 모든 노드는 libjvm.so 심볼릭 링크가 저 위치(/usr/lib64/microsoft-r/3.3/hadoop/)에
존재하지 않음 그래서 아래처럼 모든 노드에 수동 심볼링 링크 추가해줌. (이것 때문에 삽질 엄청 했음. 아마도 각 로컬에서 local mode를 한번이라도 수행해주면 최초 한번 자동으로 설정 될 것 같긴 함. 하지만, 수십대 수백대가 존재하는 Yarn Cluster 환경에서는 모든 노드에서 Local 모드 수행을
일일이 해주기 힘듦므로 아래 처럼 심볼릭 링크 수행을 distributed Shell 로 수행하는 것이
유리.)
cd /usr/lib64/microsoft-r/3.3/hadoop
su
ln -s
/data01/java/jdk/jre/lib/amd64/server/libjvm.so
위 경로는 본인 JAVA_HOME의 jdk 위치를 따라야 함. (이를 감지하는 코드가 /usr/lib64/microsoft-r/3.3/Hadoop 경로 안의 getHadoopEnvVars.py
인 것으로 사료 됨.)
위처럼 해주자 모든 문제가 해결되었고, 결과가 아래처럼 Hadoop 버전에서도 동일하게 나왔음.
아래는 Spark 를 통한 수행.(Spark Mode 수행 전 Spark 는 Hadoop 과 연동되어 잘 설정되어 있어야 한다.) Hadoop 을 통한 수행보다 약 4~5배 더 빠름 ^^.
유레카~~~~
5. 결론
우여곡절이 좀 있었지만, 일단, Hadoop Cluster + Spark Cluster 에 MS R 을 전체 노드에 설치하고, Local 수행, on Hadoop 수행, on Spark 수행이 정상적으로 잘 이루어짐을 확인하였다. 대용량 Data Handling 및 병렬 알고리즘 수행 에 대한 위 세가지 Mode 에서의 성능 수치 및 Spark R 과의 deep dive 비교는 다음번에 별도 블로그로 언급해 보도록 하겠다.
당연하겠지만, MS R on Hadoop 보다 MS R on Spark 가 더 수행속도가 빠르다. 그리고, 메모리에 순식간에 로딩되는 작은양의 Sample Data 는 Local 1대 수행이 가장 빠른것도 사실이다. Spark 수행은 그래서 대용량 처리에 있어, 약간 중간계 같은 느낌이다.
속도가 아닌 용량의 측면에서 보자면, local 보다는 spark memory cluster 가, 그리고 spark memory cluster 보다는 hadoop distributed File System cluster 가 훨씬 강력한 것이 사실이기 때문이다.
MS R 은 그 전신인 Revolution R 을 MS가 인수하여, 일부는 Open Community 버전으로 Free 버전으로 오픈되어, 다중 쓰레드, 다중 CPU, disk 기반 iteration 등 기존 Open R의 단점을 많이 보완한 새로운 feature 를 기본 포함하고 있다. 오늘 실험했던 Hadoop 위에서의 병렬 구동, Spark 위에서의 병렬 구동은 MSDN 라이센스가 필요하지만, Azure 위에서 종량제 HDInsight Hadoop + Spark 클러스터를 구동하면, 누구나 몇분만에 클라우드 상에서 유연하게 Node 갯수를 조정해 가며 사용 가능하여, 그다지 먼나라 기술도 아니라 할 수 있다.
모델러가 R 로 넘긴 소스를 BigData scale 로 포팅함에 있어, R 코드를 최대한 재 사용하면서 scale out 을 할 수 있다는 것 자체만으로도, 오늘 실험한 구성은 그 가능성이 무궁무진 하다 하겠다. R의 시각화 기능에 있어서의 막강함은 BigData 개발자들에게 선물같은 기능이 아닐 수 없다.
Spark 는 제트기 같은 민첩함을 제공하지만, 종합운동장 보다 큰 활주로가 있어야 한다. Hadoop 은 듬직하지만, 항공모함 역할 이상을 하긴 힘들었다. Hadoop 위에 Spark 는 항공모함 위에 제트기 처럼, 그 둘의 시너지로 막강한 화력을 제공해주는 것을 우리는 이미 경험한 바 있다. 우리는 가끔 육지에서 조용하게 정교한 작전을 수행하고 돌아오기 위해 Python 이라는 Hummer 고성능 군용 전처후 차량이 필요할 때가 있었다. 스파크보다 빠르지 않아도 된다. 대용량이 좀 힘들어도 상관 없다. 정교한 육지 수색을 할때 제트기 보다는 특공대를 태운 Hummer 차량이 더욱 믿음직한 것 처럼 그 자체로서 역할이 충분히 독보적이었다. 오늘 접한 분산 R 은 그런 측면에서 화력에 비유하자면, Apache 헬기 같은 존재라 할 수 있다. 제트기(Spark) 보다 빠르지 않아도 된다. 할주로가 없는 구석 구석 까지 수색을 하기 위해서 우리는 특공대를 태운 Hummer 차량밖에 대안이 없었으나, 이제는 Apache 헬기를 타고 한번에 더 빠르게 날라갈 수 있으며 그들을 지원사격해줄 수도 있다.
Local Area 에 있어서는, 람보 1인 이면, 모든게 해결 되기도 했었다. 홀로(1대로) 외롭게 싸우던 람보(R)를 Apache 헬기에 태워 여기저기 데리고 다닐 수 있다면...?! 여러곳에 독자적으로 나누어져 있던 람보를 수송헬기에 태워 때(때거지로, 즉, 대용량으로)로 다니게 할 수 있다면...?! 하는 즐거운 상상을 해본다... 람보에 날개 달기(분산 R) 프로젝트는 아직 진행형 이지만, 그 가능성이 심상치만은 않은 이유라 하겠다.
