MS R(구 Revolution R) on Spark - 설치 및 가능성 엿보기(feat. SparkR)

BigData Scale Data 분석 및 활용 업무를 하다보면, 도구나 사용 언어, 사용 기술 등에 있어 여러가지 선택의 기로에 서게 되는 경우가 종종 있다.

물론 혹자는 특정 언어나 특정 기술로 많은 것을 처리하는 것을 선호하기도 하지만(전문성 증대, 기술의 장인정신 측면에서 이 방식의 유리한 점이 존재한다.), 혹자는(나를 포함) 다양한 언어나 기술을 섞어 쓰면서, 처한 상황(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에서 자주 접하는 시나리오는 아래와 같다.

1. 순수 모델러들이 R이나 SAS 로 최적화된 알고리즘을 찾아낸다.
2. 셈플 데이타 혹은 전수로 데이타를 돌려보고, 각종 파라미터나 로직을 거의 완성한다.
3. But, 모델이 도는데 3박 4일 이상이 걸리거나, 전수 데이타로 돌리는 것 자체가 불가능하다.
4. BigData 팀으로 Co-Work 요청이 들어온다. 즉, R 모델을 다른 기술을 이용하여 포팅하는 협의가 시작된다.
5. SparkML 으로 우선 포팅 가능성을 타진한다.
6. 초대용량의 경우 수십~수백대의 Spark Cluster 위의 SparkML 로도 답이 안나오는 경우가 많은데 이때는 1차로 Mahout 의 구버전으로 Hadoop Map/Reduce  경유 수행이 가능한지 검토한다.
7. SparkML 이나 Mahout 으로 구현이 쉽지 않은 복잡한 복합 모델의 경우는 제삼의 기술을 검토한다. Weka, PredictionIO, H2O 등등... 하지만 이 프레임워크들은 좀 난잡해서 별로 선호하진 않는다. 오히려 아래 방식을 좀더 먼저 검토한다.
8. Spark, Mahout 계열에 없거나, Method 가 빈약한 경우 Python을 뒤져본다. SparkML 은 기본 메소드는 있는데, 고급 옵션들이 아예 구현이 안되어 있는 경우가 많다. 예를 들어 Spark ML의 Word2Vec 에는 기본 Method 외에 다양한 고급 활용 메소드들이 거의 존재하지 않아 일일이 구현을 해주어야 하고, FPGrowth 등은 Lift 값 관련 Method가 없어 이를 구할때, 개발자가 수식을 일일이 구현 해줘야 가능하다. 반면에 R이나 Python 들은 논문에 언급된 대부분의 기법들은 거의 구현이 되어 있는 경우가 많다. 이 시점에 R을 보지 않고, Python 을 보는 이유는, SAS 가 그러하듯이 Python 은 메모리에 올려놓고 계산하지 않고, 머신 1대가 오래 걸리더라도 꾸역 꾸역 계산을 하긴 해내기 때문이다.(뒤에 이 부분에 있어서의 R의 역습을 언급하겠다.) 머신 1대가 담기 힘든 용량이면 Hadoop 같은 공유 저장소에 올려 놓고 loop 를 돌리면, 어쨋든 무한 루프를 돌면서도 뻗지 않고 돌아는 간다.
9. 8의 기술이 죽지는 않지만, 1대라 너무 너무 오래걸릴때는 GPU 카드를 꺼내 든다. 모든 알고리즘이 GPU 버전이 존재하는 것은 아니지만, 조금 뒤져보면 github 에 다양한 공유 구현체 들이 가끔 큰 희망을 줄때가 많다. C로 최적화된 Gensim 등의 Python 라이브러리는 굳이 GPU까지 동원하지 않더라도, 1대에서 돌려도 Spark 5~7 대의 성능과 맞먹는 경우가 종종 있다. 어쨋든 Python 에는 Spark 에 없는 무수히 많은 알고리즘 중 상당수가 이미 구현된 경우가 왕왕 있다. 그리고 대부분의 알고리즘들이 지원하는 고급 기법들이나 옵션들이 더 풍성하게 구현되어 있다.
10. Python 이 너무 느릴때도 있다. 병렬 수행이 목마를때도 있다. 이 경우 PySpark 로의 Hybrid 사용 가능성을 타진한다.
11. PySpark 로도 답이 없는 경우는 TensorFlow 카드를 꺼내 든다. Word2Vec 도 그렇지만, TensorFlow 에는 Deep Learning 류의 거의 대부분과, 상당수의 Machine Learning  알고리즘들이 기본 지원되거나, github 구현체가 이미 존재하는 경우가 왕왕 있다. (deeplearning4j 나 theano, caffe, cntk 등 다른 대안도 존재한다.)
12. 이도 없을 때는 제일 마지막 방법으로 구글링 후 해당 알고리즘의 구현체, 그게 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 을 그데로 따라 설치하면 많은 난관에 봉착하게 된다. 아래는 그 부분들의 해결책 까지를 포함하고 있다.

1. Download

1. Spark Cluster 를 이용하여 ScaleR을 돌림에 있어, Linux 버전 Install을 해야 하는지, Hadoop 버전 인스톨을 해야 하는지 좀 햇갈렸는데… Manual 을 잘 보다 보면, for Hadoop 을 설치해야 함을 알 수 있다. 즉 위에서 2번째 버전을 다운받아야 한다.
2. 설치 참고 메뉴얼
1. Linux 버전과 Hadoop 버전 설치 가이드는 아래 링크에 나와 있다.
1. R Server Installation for Linux Systems
1. https://msdn.microsoft.com/en-us/microsoft-r/rserver-install-linux-server
2. Hadoop installation and configuration for Microsoft R Server
1. https://msdn.microsoft.com/en-us/microsoft-r/rserver-install-hadoop
2. Spark 위에서 구동하기 위한 Getting Started 문서는 아래 문서를 참고하면 된다.
1. https://msdn.microsoft.com/en-us/microsoft-r/scaler-spark-getting-started
2. 처음 설치하는 경우라면, scaler spark getting started 를 따라하기 전, Linux 버전이 아닌 Hadoop 버전의 MS R 이 기 설치 되어 있어야 한다.
3. MS R on Spark 설치(본 설치에서 사용한 버전은  MS R Server for hadoop 9.0.1 임.)

  1.   MS R on Hadoop Package 다운로드 후 압축 풀기

 2.     Root 권한으로 install 스크립트 수행해야 함.

  3.     설치는 install.sh -p 로 -p 옵션을 주고 실행 함.

A.      첫번째 에러 만남.

에러 log 에서 크게 단서를 찾을 수는 없었지만, MS R for Hadoop 인 관계로, Hadoop 관련 설치 설정 과정 중의 에러라고 여겨져, 설치하는 계정에 Hadoop Path 추가.

이후 수행하니 위 에러 없이 정상 Install 되었음.

  4.     모든 Hadoop 노드에 다 설치. (설치 과정은 위와 동일. dsh, pdsh, PyDSH, fabric등으로 이를 병렬 수행 할 수도 있기는 함.)

  5.     설치 이후 확인

  6. Hadoop 폴더 생성 및 퍼미션

A.     한쪽 노드에서만 수행. Hadoop 은 공유 되어 있으므로.

  7.     각 Node에 로컬 공유 폴더 생성

A.     전체 Node 에서 수행.

  8.     아래 경로의 파일을 Hadoop 에 업로드 하여, Test Code 수행 준비.

     A.     아래 경로는 설치 하고 나면, 자동 생성.

                         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/

  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 로 로컬 로딩 분석해 보았음.

ldd 로 보면 좀 이해가 가지 않는 부분이 있음. 즉, 모듈이 모두 정상 로딩 된 것으로 보인 다는 점 임.

root 로 su 한 다음 root 권한으로도 수행해 보았음.

위 처럼 이제는 좀전의 에러가 보이지 않음. 대신 Hadoop 에서는 root 의 권한설정이 안되어 있어 이번에는 Hadoop 에서의 에러 메시지가 발생하였음.

다시 밖으로 나가서 root 와 사용자 user 계정 모두 Hadoop 및 local User 에 대하여 공동의 SuperGrop 그룹에 속하도록 퍼미션 권한을 모두 맞추어 주고 재 시도 해 보았음.

앞선 에러 로그의 문제는 해결되었음. 하지만, 이번엔 또 아래 같은 에러 발생.

앞선 문제는 해결되는데… tmp/ 폴더가 또 문제.. (기존에 쓰던 Map/Reduce Job의 사용자와 다른 새로운 사용자로 R 을 병렬 수행하면서 새롭게 권한 문제 발생) 

hadoop fs -chmod -R 1777 /tmp 로 tmp 폴더 권한 문제 해결. 하지만 여전히 libjvm.so 를 인식하지 못하는 문제가 계속되고 있음. 다시 ldd 를 해보아도 로딩 잘 되고 있고...

그렇다면 드는 생각. 현재 수행중인 노드는 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) 프로젝트는 아직 진행형 이지만, 그 가능성이 심상치만은 않은 이유라 하겠다.


    

Python Anaconda & GPU - 세팅 및 성능 비교

요즘 Python 의 행보가 매우 무섭다. 

특히 Machine Learning 쪽에서 다양한 오픈 모듈이 나오면서 힘을 받기 시작했고,  Deep Learning 쪽에서는 TensorFlow 등의 걸출한 프레임워크가 그 행보에 힘을 더해 준 느낌이다. 최근 화두가 된,  microservice 또한 Python 계열에 장점이 많은 분야 중 하나이다. 

그리고, Python Data Platform 에선 끝판왕 같은 느낌. 바로 Anaconda.(이 안에 여러가지 것들이 짬뽕되어 있는데, Anaconda는 그것들을 잘 패키징 해놓았다.)

Anaconda 는 GPU 를 지원하고 있는데.... 해서, 최근에 확보된 GPU 장비들에 Anaconda GPU 설치 세팅 후 간단하게 CPU 대비 Anaconda +  GPU 세팅 버전의 성능 비교를 해보았다. 설치 세팅 방법과 성능 비교 내용은 다음과 같다.

1. 아나콘다 Accelerate 모듈 업데이트
1. conda update conda

2. conda install accelerate

3. conda install numbapro

2. NVIDIA 드라이버 다운로드
1. 아래처럼 NVIDIA 홈페이지에서 전용 driver 다운로드.
2. 먼저 Tesla ... 이름에서 부터 존재감이..ㅋㅋ

3. 다음은 Quadro ... 드라이버. 존재감이 살짝 떨어짐 TT

4. 드라이버를 각각 서버에 업로드

5. 위처럼 기존에 있던 Nouveau 때문에 에러 남. Nouveau 를 disable 시켜야 함.

6. 친절하게도 disable script 도 만들어 준다.

7. 기타, 지금까지의 로그는 저 위치에 기록되어 있는 듯... 친절하기도 해라...

8. 위 수행하고 나면 Tesla 장비는 정상 수행되나, Quadro 장비는 nouveau 가 계속 떠 있어서 충돌 남.
9. 메뉴얼에 하라는거 다해도 계속 좀비처럼 살아남...
1. 에이... 강제로 모듈 제거.
2. rmmod nouveau
3. 다시 설치... OK 설치 됨.
10. 설치 후 메시지

3. CUDA 툴킷으로 GPU Check
1. 먼저 Tesla M40 장비

2. 정상 설정 되었음.
3. 다음은 Quadro K4200 장비

4. 야도 정상 설정 되었음.
4. CPU 와 GPU 성능 비교를 위해 사용된 코드
1. CPU  버전 성능 체크를 위해 사용한 코드

2. GPU 버전 성능 체크를 위해 사용한 코드

5. Python Code 로 두 장비에서 CPU vs GPU 성능 비교.
1. Tesla 장비
1. CPU 버전 코드 3번 수행 결과

2. GPU 버전 코드 3번 수행 결과

2. Quadro 장비
1.  CPU 버전 코드 3번 수행 결과

2. GPU 버전 코드 3번 수행 결과

3. 성능 비교상 기존에 보유하고 있던 1500만원 상당의 Legacy X86 표준 장비와도 성능 비교 해 봄.
1. GPU는 Support 하지 않으므로 CPU 만 수행하였음.

6. 종합 결과 (일단, 가격 요소를 제외하고, 성능 부분만 정리하였음.  ps.  Legacy 장비대비 GPU 2개씩 꼳힌 장비들이 약 3배 비쌈.)
   

이상.

위처럼 GPU 가 CPU 에 비하여 월등한 컴퓨팅 파워들 보여주고 있다. 

ps. 물론 실제 Production 환경에서 저정도 차이가 나거나 하지는 않는데, 모든 연산위 위에서 실험한 GPU 지원 백터 연산만 있는 것은 아니기 때문이다.

최신 IT 트랜드(Language on Data Platform 측면)의 "왕좌의 게임"

Data 를 다루는 언어들, 기술들이 최근 하루가 다르게 발전하고, 또 변화하고 있습니다. 특정 기술들은 이쪽 라인에 붙어 있다가, 저 쪽 라인에 붙는가 하면, 잘나가다가 어느새 훅 사라져버리기도 하죠. 주인공들이 픽픽 죽어나가는 것이, 마치 미드 "왕좌의 게임"을 보는 듯 합니다.

어느 한 기술을 고수하다 보면(국지전에 너무 매진하다 보면), 자칫 커다랗게 밀려오는 큰 흐름을 놓치고, 그 흐름을 따라가는데 힘이 겨워 질 수도 있을 것입니다.(곧 다가올 겨울에 대한 대비를 간과하게 될 지도 모릅니다.)

그런 측면에서, 얼마전 사내 BigData 기술 전파를 위한 공지 메일에서 경각심 부각 용으로 작성했던, "최신 IT 트랜드(Language on Data Platform 측면)의 왕좌의 게임 비유"를 블로그에 옮겨 보았습니다.

언어	주요 지원 프레임워크	왕좌의 게임	비고
Java	Spring, Netty, MapReduce		Korea 국민 언어 Java. 저도 빅데이타하면서 3~4년전에는 Java 로 Spring Data 위에서 MapReduce 쓰다가 흰 머리가 많이 났었습니다.조금 더 그 좋지 않았던 경험이 반복되었다면, 신생 언어를 만들어 낼뻔 한 순간, 트위터 애들이 먼저 그짓을 마무리 해주었었죠. 잠시나마 cascading 위에서 clojure 랭귀지를 다루거나, Riak 언어를 기웃거리던 계기를 Java가 제공하기도 했었습니다. 그렇게 개발자들에게 무관심하던 Java 는 왕좌의 게임의 라니스터 가문입니다. 천하를 통일했던 옛 명성이 있지만, 요즘은 왠지 좀 불안불안 합니다. 최근 1.8 이 나오면서, 서세이가 다시 녹색 물폭탄을 터트리고, 존재감을 드러내긴 했습니다만… C# 처럼 상위 프레임워크 지향 Legacy 호환성이 있는 것이 아니므로, 여러 Enterprise 기업들은 1.8을 구경하기조차 쉽지 않습니다.
Scala	Play 2, Spark Zeppelin Notebook		Play2 가 살짝 다시 각광을 받고 있기도 하지만, Scala.js 가 여기저기 조금씩 보이기도 하지만, 그 무엇보다 Scala 의 성장은 Spark 의 성장과 땔래야 땔 수가 없습니다. Scala 는 비록 한때 아무런 존재감이 없었으나, Spark 의 Dragon 급 존재감에 힘입어, 현재 막강 화력을 자랑하고 있습니다. Spark는 이미 BigData Eco 시스템의 춘추전국 국지전에서 Map/Reduce 나 Cascading, Pig 등을 제치고, 국지전 승리를 거둔바 있습니다. Spark 의 요즘 기세는 하늘을 나는 용과도 흡사합니다.
R	SparkR, RevolutionR(MS R Server)		R 은 사실 매우 똑똑합니다. 세상의 모든 알고리즘이 다 있는 것 같습니만, 그런데 너무 작습니다. Small Data 밖에 다루지 못하는 것이, 마치 티리온 라니스터 같습니다. 라니스터에서 독립되어 최근 Python에도 밀리는 형국이지만, Spark 가 손을 벌려 SparkR 병렬성을 지원하고 있고, 최근 MS 가 Revolution R 을 인수하고 커뮤니티를 지원하면서, 다시금 조금씩 병렬 R의 시대가 열릴 것 만 같습니다. 여전히 피는 다르지만, 아직 Spark 진영에 붙어 있는 것도 안전해 보이네요.  시즌6에서 용(Spark)과 친근함을 보여주기도 했었죠.
Python	DJango, Flask, 기타 등등.. Jupyter Notebook		Java 의 라니스터 가문만큼이나 오래된, 그러나 항상 변방의 2인자였던, Python은 마치 스타크 가문 같습니다. 더구나, 2010년 전후로는 거의 맛이 갈 정도로 존재감이 하락했던 적이 있습니다. 느려 터지기도 했었구요. 이제 몇 명 남지도 않았어요. 하지만, 그래서 소수의 몇몇은 여전히 매우 Agile 하죠. 더구나 시즌 6 마지막에 북부 연합은 스타크를 위한 대동단결의 결의를 보여 주었습니다. 이는 마치 Python의 개발자 생태계를 보는 듯 합니다. 요즘은 개발자들이 직접 만들어 서로 공개, 공유 하고, 패키지를 주고 받는 pip 모듈 생태계가, 집단지성의 힘으로 재 조명되어, Java 나 C# 의 공룡 프레임워크의 그것을 위협하고 있습니다. Spring 이나 .NET Framework 같은 공룡 가문은 없지만, 수많은 100만 지방 호족의 힘을 합치면, 라니스터를 쉽게 위협하고도 남습니다.
	TensoFlow (Deep Learning Framework By Google), SyntaxNet On TensorFlow ( for NLU, NLP By Google) Anaconda ( for Machine Learning & Deep Learning )		Google 이 만들어내는 TensorFlow , SyntaxNet 같은 프레임워크는 GPU도 지원되고, 병렬 분산 컴퓨팅도 지원하며, 엔진 코어가 C/C++ 이라 무지 빠르기 까지 합니다. 그리고, 개발자들은 Python 으로 코딩합니다. Google 이라는 한개 회사가 붙었을 뿐인데도.. 그 존재감은 “존 스노우” 급 입니다. 우리의 알파고도 Lua 언어의 Torch 에서 python 의 TensorFlow 로 갈아 탄바 있습니다. Python 입장에서는 존 스노우 처럼 죽다 살아난 말도 안 되는 존재감의 우군입니다. Python Anaconda 는 아직은 약하지만, 뒤에 큰 활약이 예감되는 브랜이나 아리아 스타크 같습니다. 아직은 혼자(병렬처리 안됨) 놀지만, GPU 를 달아주면, 그 퍼포먼스가 장난이 아닙니다.

Word2Vec Vector Algebra Comparison - Python(Gensim) VS Scala(Spark)

요즘 각종 내외부 Text 데이타들이, 새롭게 재 조명 되며, 다양한 형태로 분석 활용 되고 있다. 대표적인 예가 Text Classification , Sentiment Analysis ,  Opinion Mining 등 일것이다. (이 용어들 또한 많이 겹치는 의미들 이다.) 이러한 기법들을 이용하면, 고객센터나 이메일로 접수되는 내용들을 자동분류 하고, 실시간 Dash Board 화 하여, 문제가 되는 부분을 빠르게 파악 하고 대처할 수 있다. 또한, SNS나 게시판, 댓글등을 분석하여, 평판분석을 할 수 있고, 문제 상황을 좀더 빨리 인지하여 대응 할 수 있으며, 경쟁사의 평판과도 비교해 볼 수도 있다. 좀더 적극적으로는 Chat봇 이나 토픽 검색, 추천 고도화 등으로 확장되어 활용되는 사례도 많이 보이고 있다.

오늘 정리해본 내용은 그러한 Text 처리에 있어, 전처리 Word Embedding 기법 중 간단하면서도 뛰어난 효율을 보이는 Word2Vec 에 대한 내용이다. 

1. Word2Vec 알고리즘에 대하여?
1. 정의는 Learning4j 에서의 정의를 인용하였다.
1. "데이터의 양이 충분하면 Word2vec은 단어의 의미를 꽤 정확하게 파악합니다. 그리고 이를 이용하면 단어의 뜻 뿐만 아니라 여러 단어의 관계를 알아냅니다. 예를 들어 단어의 관계를 이용해 ‘남자’:’소년’ = ‘여자’:x 같은 관계식을 주면 x=’소녀’라는 답을 구할 수 있습니다. 단어 뿐만 아니라 더 큰 단위의 텍스트인 문장이나 문서를 분류하는데에도 Word2vec을 사용합니다. 예를 들어 문서를 군집화한 뒤에 결과를 이용하면 검색 엔진에서 문서의 분야별 검색(과학, 법률, 경제 등)이나 문장의 감정 분석, 추천 시스템을 만들 수 있습니다."
2. Word2Vec 은 텍스트를 처리하는 인공 신경망이며, 두 개의 층으로 구성되어 있다. 심층 신경망은 아니지만, 심층 신경망의 전처리 단계로 많이 쓰인다. 

1. 인공 신경망 작동 방식은 크게 위 2가지로 나뉜다.
3. Word2Vec 알고리즘에 대하여 좀더 자세한 내용을 알고싶어 하는 분들은 이 글을 참고하면 될것 같다.
1. 자연어 기계학습의 혁명적 진화! (나프다에 기재된 글)
2. http://www.moreagile.net/2014/11/word2vec.html 

오늘 내가 정리하는 내용은 Word2Vec 을 실제 구현하는 2가지 큰 방법( Python vs Scala )에 대하여 비교 분석한 내용이다.

1. 구현방법 1
1. Python 계열로 구현해 보기.
1. Gensim 으로 구현하면, Word2Vec 구현하기가 너무 쉽다.
2. 게다가 다음과 같은 장점이 있다.
1. Python 계열은 우선 설치도 간단하다.
1. Anaconda 를 설치하자. 이거 하나로 모든게 해결된다.
2. https://docs.continuum.io/anaconda/install
2. Word2Vec 에서 생각해볼 수 있는 거의 모든 내용이, 매우 쉽게 사용가능한, 잘 정리된 메소드로, 거의 다 만들어져 있다.
3. 사용예, 셈플도 매우 많다.
4. 한글의 경우 좀 쓸만한 형태소 분석기들은 죄다, R이나 Python 계열이다. 때문에, 자연어 처리에 있어, Python으로의 선택은 이런 모듈들과 궁합이 좋아, 우선 가장 안전한 접근 일 수 있다.
1. 특히, Konlp 나  Konlpy 가 좋다.
5. 요즘 Python 은 GPU 를 쓰기도 좋고, CPython  등으로 인하여 속도도 매우 빠르다.
3. 물론 다음과 같은 단점도 있다.
1. 초 대용량으로 가는 경우 답이 없다.
2. 기본적으로 아직 까지는 Single  머신으로 돌리는 것이 Default 이다. 물론 병렬로 돌리기 위한 몇몇 마이너한 방법들이 있으나, 아직 까지 그 길은 최적화 되어 있지 못하다.
4. 기본적인 코드들은 인터넷에 널려 있다.
1. 참고로 너무 쉽고, 매우 짧다.
2. 살짝 드려다 보자면...

5. 학습을 위해 준비한 데이타.
1. 나무위키 데이타, 위키피디아 데이타, 그리고 모사의 블로그 크롤링 데이타 등이 사용되었다.
2. 데이타를 조사제거하고, 의미없이 너무 긴단어 제거하고, 몇몇 전처리를 해 줘야 하는데, 이 역시 Konlpy 등을 이용하면, 어렵지 않게 전처리 가능하다. (물론 Data가 매우 매우 클 때는 Python 으로는 매우 오래 걸리는 작업이긴 하지만..)
6. 대표적인 Vector Algebra 인 King:Man = Queen:Woman 예제를 돌려 보자. 
1. 참고로 이 예제는 한글에서는 잘 맞지 않다. 그 이유는 왕 이라는 단어가, 한글에서는 동음 이의어가 존재하기 때문이다. (왕서방, 왕짜장, 왕 좋다. 킹 왕짱 등등 때문에 그렇다.)
7. 그래서 중국:북경 = 대한민국:서울 의 Algebra로 실험을 해 보았다.
   중국 - 북경 = X - 서울 요렇게 표기하는 것도 가능할것이다.답은 대한민국이 나와야 한다. X 를 구하기 위해 위 식을 아래처럼 다시 바꾸어 보았다.
   X = 중국 - 북경 + 서울
2. Algebra 수식 부분 수행코드는 아래와 같다.

1. 코드는 허무하게시리 간단하다.
2. 위 결과에서처럼 대한민국과 한국이 1, 2등 이다. 놀랍지 아니한가??? 나는 처음 이 결과 봤을때 깜짝 놀랐었는데...
2. 구현방법2
1. Scala On Spark 로 구현해 보기.
1. Spark 로 구현해 보자. Spark ML 안에 Word2Vec 이 있으니, 망설일 필요가 없다.
2. Spark 는 Mesos Cluster 로 구동하였고, 모든 데이타는 Hadoop 내 공유 저장소에 존재한다.
3. 하지만, 막상 구현을 해보니, 일단 학습하고, 저장하고, 로드하는 Spark 가 제공하는 Example 외에, 실무에서 활용할 만한 Sample 이 너무 너무 없다.게다가, 메뉴얼이 매우 빈약하다.

1. 여튼 코드는 간단하다. Sample을 찾긴 힘들지만...
4. Algebra 예제는 2시간을 Goggling 해도 제대로 수행된는 Code를 찾기가 힘들다. 몇몇 Code가 stackoverflow 사이트 등에 메뉴얼 Base, 답변 글 형태로 Code가 존재하긴 하는데 작동하지 않는다. (아래에서 좀더 상세 설명)
5. API Document 를 보고 Algebra 구현을 시도해 보았다.
1. 1차 시도
1. 메뉴얼만 보면, 위처럼 하면 되야만 한다. 
2. 하지만 위처럼 하면, model.getVectors() 쪽에서 인자가 없다고 에러가 난다. 분명 API Doc 에는 getVectors() 가 인자 없는 메소드 인데 말이다.
3. () 를 하지 말고 그냥 가져오면 되긴 한다. 
1. val w2v_map = model.getVectors   # 메뉴얼상의 getVectors() 메소드는 존재하진 않는다.
2. 소스를 까보면 getVectors 가 Map[String, Array[Float]] 형태의 자료 구조이다. 즉, 뒤에서 다시 언급하겠지만, 그냥 Map 이라고 생각하고 getVectors(key:String) 으로 변수를 끄집어 낼수는 있지만, getVectors()(key:String)는 에러가 난다.
3. 위에서 getVectors()를 getVectors 로 고치면 위 에러는 해결 되지만, 사칙연산이 안되는 새로운 에러가 발생한다. 이는 뒤에서 다시 언급...
2. 2차 시도.
1. 메뉴얼을 보면 이렇게 해도 되야 될거 같은데, 일단, 에러...
2. Vectors 를 사칙연산 가능하게 breeze Vector로 형변환 해주면 되긴 한다. 맨 뒤에서 다시 언급...
3. IDE 로 가 보았다. (개인적으로 서버에서 Scala 코딩은 zepplin 이나 sbt 로 바로 코딩 하고 확인 하는걸 선호 하는데... 이런 경우는 IDE에서의 확인이 필요하다.)
1. 확인 결과 getVectors 는 메소드가 아니었다. 공식 API Document 에는 getter method 처럼 되어 있음에도 말이다...
4. Github 의 소스 코드를 직접 확인해 보니 아래와 같다.

1. getVectors 의 형이 요런식이다. 확실히 메소드가 아니다.TT
5. 3차시도
1. getVectors 자체에 args(N)을 인자로 주고, vector algebra 연산을 해보았다.
2. 역시나.... algebra 연산에서 에러가 난다. Python 이 아니니까...
3. linear Algebra 를 위한 breeze Vector 로 형변환을 하고 시도하였다. 성공!

1. findSynonmys 안에 넣을때는 다시 dense 로 형변환이 필요하다. Python 이 얼마나 편한지... 비교 되는 부분이다. 
6. Algebra 를 수행한 결과는 아래와 같다. Python 의 경우와 Data Set 이 살짝 달라서 결과도 약간 다르다.(시점 차이로..) 여튼 요런식으로 결과가 나온다.

최종 결론은 다음과 같다.

1. Word2Vec 을 구현하기 위해
1. Gensim + Python
1. 구현을 하기 위한 가장 손쉽고 빠른 접근 방법이다.
2. 왠만한 모든 가공 처리가 일사천리로 진행 가능하다..막히는 부분이 거의 없다.
3. 데이타 전처리 부 또한 걸출한 Open 모듈들이 매우 많다.
4. 단, 데이타 크기가 수십기가가 넘어가면, 단일머신에서는 고사양이 아닌 경우 급격히 느려 진다.
5. GPU 를 사용하여 한번 더 성능을 점프 업 할 수 있으나, 이 역시 한계가 있다.
6. 최고사양의 GPU 머신이라 할지라도 수백기가가 넘는 텍스트는 불가능 한 것으로 보여진다. (각종 변태 같은 다른 방법은 고려하지 않음.)
2. Spark + Scala (or Python) : (실험에 사용한 환경은 Spark + Mesos + Hadoop)
1. Spark 의 MLlib 를 이용하는 것이므로, Scala 가 아닌 Python 으로도 가능하다. 
2. Python on Spark 인 경우 형태소 분리 등 전처리는 Python 의 모듈을 그대로 활용 할 수 있으며, Python 형태소 분리 등의 전처리를 Gensim 과 달리 병렬 처리 구현 하기 수훨해 진다.
3. 단일 머신에서 돌릴때, Gensim 에 비하여 매우 느리다. 일단, Spark 는 분산처리를 위한 소잡는 칼이기 때문일 것으로 위안을 삼아 본다.
4. gensim 고사양 1대 vs Spark 고사양 5대를 비교 했는데, 극한의 Spark 튜닝을 하기 전에는 기본 비교 시 gensim 이 좀 더 빨랐다.
5. 하지만 여러가지 튜닝을 해주니, 중사양 Spark 20대가 고사양 Gensim 1대보다 5배 정도 빠른 결과를 내 주었다. (이 부분은 별도로 Posting 을 해보겠다. 속도를 끌어 올리는데 매우 많은 실험과 극한의 config 설정 튜닝이 필요하였다.)
6. 무엇보다, Gensim 고성능 서버 1대에서 절대 돌지 않는 양 (수백 GB 이상)의 데이타가 Spark Dev 클러스터 중사양 20대에서는 그런데로의 속도로 도는 것이 가능하였다. ( 이 부분도 별도로 Posting 해 보도록 하겠다. 각종 Memory 관련 이슈가 등장하는데, 이 부분을 해결하는것 또 한 매우 많은 실험과 극한의 설정 튜닝이 필요하였다. 속도도 속도 지만, 대 용량을 Spark ML 로 돌릴때에는 Memory 의 제약으로 인하여 각종 Trick 이 필요한데. 이 부분의 작업은 매우 지난한 작업 이었다.)
7. 수 ~ 수십 TB 단위의 데이타로의 실험을 해보진 않았는데, 돌지 않을지도 모른다는 생각이 든다, 실험결과 Spark Submit  수행시 주는 옵션인 Driver Memory가 학습할 Text 데이타의 크기에 비례하여 많이 필요하였기 때문이다.  
3. 결론
1. 작은 양의 데이타는 Gensim + Python Win!
2. 중간 이상 크기의 데이타는 어쩔 수 없이 Spark!
3. 그 이상 크기의 데이타는, 곧 훨씬 더 큰 데이타와 훨씬 고사양의 훨씬 많은 Spark 노드에서 다시 한번 테스트 해볼 예정이지만, 위 2-7의 가설이 맞다면, 어쩔 수 없이... deeplearning4j! (물론 deeplearning4j 도 내부에서 Spark를 이용하고는 있지만..)
4. 어느정도 이상의 데이타는 도메인을 나누어 학습을 시켜도 될 듯 싶다.
1. 어느정도 이상의 데이타는 표본이 전수를 대표하는 성격을 가질 것이기 때문이다. 굳이 이세상의 모든 데이타를 하나의 model 로 합쳐서 학습할 필요가 없다는 생각이 든다.
2. 백과 사전 몇개를 학습하여, 일반어 간의 거리를 관리하는 모델을 하나 만들어 놓고, 이후부터는 특정 도메인 별로 데이타를 수집하여 별개로 학습해도 될 것 같다.
1. 예를 들어, 네이버 요리 카테고리 블로그를 따로 쭉 학습해서 요리 단어에 대한 학습을 하고 나면, 요리 박사가 될 수 있다.
2. 상품명을 가지고 크롤링 하여 쭉 학습을 하고 나면 또 상품 박사가 될 수 있다.
3. 결국은 중간 Classification 분류 대표명이 중요하다. 중분류 대표명이 있다면, 세상의 모든 단어에 해당하는 백과사전 Model 과 특정 분야에 특화된 Domain 사전 간에 중분류 대표 단어를 매개로 거리 Mapping 을 통하여, 다양한 조합 쿼리가 가능하기 때문이다. (단, 방향성 연산은 이 시나리오가 통하지 않는다. 복수 모델을 조합할때는 similarity 연산만 유용하다.)
4. 백과사전 Model 로 부터 다양한 형태의 자연어 대화 질문을 Classification 대표 질문으로 분류해주고, Classfication 대표 질문으로 부터 해당 Class 에 맞는 Domain 특화 model 에 질의 하여 정확한 전문 용어를 끄집어 내는 것이 가능 할 것이기 때문이다.