딥러닝의 대부이신 제프리 힌튼 교수님은, 머신러닝의 수십년간 암흑기가 극복될 수 있었던 계기로 3대 난재가 풀렸기 때문이라고 언급하신 바 있다. 바로 아래와 같다.
- 알고리즘적 혁신 ( Deep Neural Net 이 가능해진, Relu, DropOut, 발견 등등..)
- 하드웨어 혁신 ( GPU 를 이용한 컴퓨팅 파워 Scale Up )
- 소프트웨어 혁신 ( BigData Cluster 를 이용한 분산 컴퓨팅 파워 Scale Out )
이 중 1은 우리가 너무나 많이 알고 있고, 곁에서 접하고 있고, 심지어 사랑하고 있는 분야이다.
2는 약간 비싸지만, 회사에서 안사주면, 자비를 털어서라도 집 Desktop에 2개 정도 꼳아주고, 그 날개 돋힌 파워를 충분히 느껴 볼 수 있는 분야이다.
하지만, 3은 좀 말이 다르다. 힌튼 교수님이 말씀 하셨지만, Lab 에서든 기업에서든, 섣불리(아직까지는) 시도되지 못하는 경향이 있고, 관련된 자료도 많지 않다. 무엇보다도, Popular 한 오픈 Data 를 통해 논문에서 통용되는 수십만 혹은 수백만건의 데이타는 그다지 Big 하지 않기 때문에, 1+2 만 가지고도 꾸엮 꾸엮 실험하고 돌려보고, 논문을 완성해갈 수도 있는 수준일 수 있다. 때문에, 구글, MS 등 몇몇 회사등을 제외하고는 수십층 짜리 Very Very Deep 류의 모델을 밑바닥부터 적합한 Neural Networks 구조를 발견하고, 이를 초기값부터 시작하여 새롭게 학습시키는 등의 작업은 일반 소규모 Lab 등에서는 하기가 매우 힘들고, 그러다 보니, 그에 대한 학계의 연구가 보편화 되어 있지는 않는 듯 보인다.
그래서인지 3의 접근은 일부 공룡 기업들에 의하여 자체 구축 혹은 오픈소스화 되어 일부 만이 오픈된 상태이다.
기업의 Production Deep Learning 프로젝트의 경우, 우선 보유 Data 의 크기가 논문에서 사용되는 Data 의 크기보다 수십배 ~ 수백배인 경우가 많다.(아닌경우도 많지만...) 그리고, 복수의 모델을 함께 쓰거나 좀더 Fine Tuning 을 위해, Online Learning , Transfer Learning 보다는 초기부터의 Learning 을 시도하는 경우가 훨씬 많다.(특히, 한글 Deep Learning Text NLP 등은 기 학습되어 있는 Pre training Set 도 존재하지 않는다.)
오늘은 그런 부분 즉, Deep Learning 을 Big Data Scale Data 를 가지고 수십대 수백대의 GPU 클러스터를 가지고서 병렬 Training 을 하기 위한 BigData Platform + deep Learning Platform 구성에 대하여 이야기 해보고자 한다.
[1] GPU 만으로 하는 Deep Learning Approach의 한계
가장 Popular 한 Deep Learning 프레임워크 중 하나인 Tensorflow 는 사실, 이미 멀티 GPU 를 지원하고, 멀티 노드도 지원하며, 아직 미흡하지만, 자체 Serving Layer 도 가지고 있다. 하지만, Tensorflow 가 지원하는 수준의 분산 컴퓨팅, 분산 GPU 는 마치, 분산 데이타 컴퓨팅을 Map/Reduce 로 하는 경우와 유사하게 너무 Low Level 접근을 필요로 하는 경우가 많다. 하나의 Simple 한 Neural Network 모델이 Data Parallel 이 되거나 Compute Parallel 이 되는것 특히, 그것이 High Level 로 저절로 되는 것은 아직 그 어떤 Deep Learning 프레임워크도 완벽하게 지원하고 있지는 않는 영역이다.
Caffe나 Tensorflow , Torch, CNTK 등의 deep learning 프레임워크는 그 자체만으로 은총알은 아니다. High Level Scale Up 된 장비 한두대로 논문에서 다루는 크기의 데이타를 처리하는데에는 문제가 되지 않으나, 실무 데이타, 특히 클릭 스트림을 RNN이나 LSTM 분석하는 정도의 시나리오만 되도, 데이타의 크기나 GPU 머신의 Memory 문제로 금방 문제가 드러나기 십상이다.
다중 사용자에게 Deep Learning Serving(Service Request 대응) 을 하는 도중에, Model traing 갱신이 일어나고, 실시간 업데이트가 되면서, 무중지로 Model 배포되는 시나리오는 또 다른 고급 기술을 요구하기도 한다.
GPU 만으로 하는 Single Scale Up, Deep Learning Approach의 한계를 정리해 보자면 아래정도 일 것이다.
- Hyper Parameter Tunning 노가다
- Training 속도 한계있음
- 멀티 GPU 코딩의 거시기함.
- GPU의 협소한 메모리로 인한 ResourceExhaustedError.
- 강제된 작은 Batch Size
- RealTime Inference, 다수 동접자 Serving Layer, 모델의 무중지 Rolling Upgrade
- BigData Scale Data 들을 접근 하기 위한 Data Pipe lining
- 모델 태우기 전, Python 레벨 데이타 전처리와 후처리의 한세월...
[2] Open Source 진영 BigData Scale Distributed Deep Learning Approach
하지만, 오픈소스 진영에서는 그러한 것들을 주로 hadoop + Spark (PySpark) 를 통해 해결 시도 하고 있고, 어느정도 Production 레벨까지 활용 가능한 수준의 결과물들이 나오고 있다. 즉, 서두에서 언급했던 3(BigData 혁신)의 시도가 되고 있는 것이다.
BigDL, elaphas , caffeOnSpark 등 그런류의 몇가지 오픈소스를 실제 Production Level Deep Learning 배치 시나리오를 이용 Training 해보고 테스트 해보았는데, 아래 소개하는 TensorflowOnSpakr (made by Yahoo) 오픈소스는 그중 가장 가능성이 보이는 Approach 중 하나라 할 수 있을 것이다. (참고로, Yahoo 는 TensorflowOnSpark 을 만들기 전 CaffeOnSpark을 먼저 만들었고 테스트 하였다.)
아래는 Inception-v3 모델을 spark 멀티 노드위에서 worker 노드 갯수를 달리해가면 분산 Training 한 속도 비교 이다.
위처럼 1대에서 48시간을 돌려도 정확도가 0.73 % 정도인게, 8대에서는 7시간만에 도달되고 이후로, 85%가 넘는 정확도에 훨씬 빠른 시간에 도달 되는 것을 확인 할 수 있다.
[3] TensorflowOnSpark 설치 및 세팅 사용방법
아래는 그런 Producion Level 에서 BigData 분산 Traing 과 RealTime Traing 부분에 강한 강점을 가지고 있는 시스템 구성으로 Tensorflow + Spark + Hadoop 구성을 설정 하고 세팅 한 후, 간단하게 사용하는 방법이다. ( Hadoop 과 Spark 는 Yarn Cluster 모드로 이미 설정이 기 완료 되어 있다고 가정하고, 그 이후의 세팅 방법만 언급 하였다.)
- Python3 관련 설정 및 설치
- 우선 SSL 관련
- yum install openssl openssl-devel -y
- Anaconda 설치
- https://repo.continuum.io/archive/ 위치에서 Linux 버전 최신 설치 파일 Download
- 각 노드에 모두 복사
- chmod 755 Anaconda3-4.4.0-Linux-x86_64.sh
- sudo ./Anaconda3-4.4.0-Linux-x86_64.sh
- 설치 완료 시 화면
- 설치 완료 화면
- bin 경로에 심볼릭 링크 연결 (Source 경로는 각자의 경로를 따를 것!)
- sudo ln -s /home/moneymall/anaconda3/bin/python3 /bin/python3
- 기존 python 을 un link
- sudo unlink /bin/python
- 새로 설치한 python3 로 다시 link
- sudo ln -s /bin/python3 /bin/python
- pip 도 설정
- sudo ln -s /home/moneymall/anaconda3/bin/pip /bin/pip
- Anaconda 설치에 관하여.
- Tensorflow 등의 기본이 되는 Python Dev 환경을 설치하는 여러가지 방법이 있지만, 내가 선호하는 방법은 우선 anaconda 를 깔아주는 것이다. 공간차지 등등 부수적인 단점이 있긴 하지만, 여러가지 추가적인 기능들이나 필수 모듈들이 동시에 깔려서 편하고, 이후 anaconda 가 제공하는 여러가지 관리 도구들을 이용하여 다양한 장점을 꽤할 수 있다.
- Root 로 설치시 실제 사용하는 계정으로 수행하는데 불편함이 많음.
- 실제 사용하는 계정으로 설치하는 것이 더 편함.
- Tensorflow 및 TensroflowOnSpark 설치
- pip install tensorflow
- CPU 모드일때는 그냥 간단히 저렇게 해줘도 됨.
- virtual env 등에 설정할 수도 있고, conda create 한 다음 설정할 수도 있으나, spark 와 연동을 위해서는 바깥에서 전역적으로 저렇게 설치하는 것이 좋음.
- 설치 완료 화면
- pip install tensorflowonspark
- 설치 무지 빨리 끝남.
- 설치 완료 화면
- 참고로 위 설치 방법은 Simple 설치 방법을 공유하기 위한 목적의 설치 Guide 이므로, RDMA 를 사용하는 Advanced 설정 방법은 아님.
- RDMA 사용 시 훨씬 성능을 극대화 할 수 있음.
- Spark및 Hadoop 에서 Tensorflow 의 Records 를 직접 읽고 쓰기위 한 Jar 라이브러리 설치
- 아래 주소에 Spark 용 해당 Open Source 가 있음.
- https://github.com/tensorflow/ecosystem/tree/master/spark/spark-tensorflow-connector
- git clone 후 spark 디렉토리로 이동.
- git clone https://github.com/tensorflow/ecosystem.git
- sbt build
- build.sbt 파일이 존재하는 위치까지 이동.
- sbt clean assembly
- 위 빌드 명령어 입력 하면 아래처럼 sbt 빌드 완료 되고, target 디렉토리 하위에 jar 파일 생성 됨.
- Jar 파일 위치
- 아래는 Spark 이 아닌 Hadoop 용 InputFormat/OutputFormat 모듈 for Tensorflow Records Direct Read/Write
- https://github.com/tensorflow/ecosystem/tree/master/hadoop
- 위 git clone 소스에서 Hadoop 경로로 간다.
- $TF_SRC_ROOT 는 Tensorflow 소스 루트.
- protoc 가 설치되어 있지 않다면, https://developers.google.com/protocol-buffers/ 에서 3.3.0 버전 설치 필요 함.
- git clone https://github.com/google/protobuf.git
- cd protobuf
- ./autogen.sh
- ./configure
- make # 무지오래걸림.
- make check # 더 오래걸림. 커피 먹으러 갔다 오길 추천.
- make check 완료시 화면
- sudo make install # 금방 끝남.
- sudo ldconfig
- 완료 후 확인
- protoc 명령어를 수행하면 저런 화면이 떠야 함.
- protobuf java 버전도 설치 필요
- 소스 위치는 앞에서 다운받았던 protobuf 소스에서 java 경로 밑에 있음.
- mvn test (maven 이 기 설치 되어 있어야 함.)
- 완료시 이런 모양.
- mvn install
- protoc --proto_path=$TF_SRC_ROOT --java_out=src/main/java/ $TF_SRC_ROOT/tensorflow/core/example/{example,feature}.proto
- $TF_SRC_ROOT 는 tensorflow 소스가 미리 받아져 있어야 하고 해당 경로로 set 되어 있어야 함. (.bashrc 등에...)
- tensorflow 소스는 https://github.com/tensorflow/tensorflow.git 이곳에 있음.
- mvn clean package
- 처음 default pom.xml 로 수행시 아래같은 에러 잔뜩 남.
- Cannot find symbol 이라는 문구들이 error 로그에 보이는 걸로 봐서...이건 version 오류로 추정됨.
- pom.xml 을 열어서 보면... version 이 1.6 으로 되어 있음. 이걸 1.8로 수정(내 환경에서의 Java 는 1.8 이었으므로...)
- Java 버전 1.8로 수정했음.
- protobuf 버전도 3.3.1 에서 내가 설치했던 버전인 3.4.0 으로 수정해 주었음.
- jar 생성
- 위 pom.xml 수정 후 빌드 성공하면 jar 생성됨.
- 빌드 성공시의 화면
- jar 파일은 target 디렉토리 아래 존재
- 해당 jar 를 HDFS 에 업로드
- hadoop fs -put tensorflow-hadoop-1.0-SNAPSHOT.jar /user/moneymall/
- Parallel MNIST 돌려보기
- 우선 데이타 준비
mkdir ${HOME}/mnist pushd ${HOME}/mnist >/dev/null curl -O "http://yann.lecun.com/exdb/mnist/train-images-idx3-ubyte.gz" curl -O "http://yann.lecun.com/exdb/mnist/train-labels-idx1-ubyte.gz" curl -O "http://yann.lecun.com/exdb/mnist/t10k-images-idx3-ubyte.gz" curl -O "http://yann.lecun.com/exdb/mnist/t10k-labels-idx1-ubyte.gz" zip -r mnist.zip * popd >/dev/null- 위 mnist.zip 파일은 local 에 존재 시키고, spark-submit 할때 인자로 넘길 예정이다.
- Pyspark 를 이용한 Data 병렬 전처리 후 CSV 포맷으로 저장
- Pyspark 를 이용해서 MNIST 데이타를 traing 셑과 test 셑으로 나누는 부분을 병렬로 수행 해보자.
- 여기에 사용되는 example 코드는 tensroflowOnSpark github 에 존재하는 코드이다.
- https://github.com/yahoo/TensorFlowOnSpark/blob/master/examples/mnist/mnist_data_setup.py
- 위 코드를 사용하였다.
- pySpark 로 data 전처리를 병렬로 수행하고 CSV 결과는 Hadoop 에 쓸 예정이다.
- 수행 Script 는 아래와 같다.
${SPARK_HOME}/bin/spark-submit \ --master yarn \ --deploy-mode cluster \ --queue ${QUEUE} \ --num-executors 13 \ --executor-memory 22G \ --archives ./mnist/mnist/mnist.zip#mnist \ ./mnist/mnist_data_setup.py \ --output mnist/csv \ --format csv
- 위는 official manual 문서와 다소 다르다. 처음 수행을 하면 에러가 나는데, spark yarn cluster 를 이용하였으므로, hadoop job 모니터링 페이지를 통해 에러 로그를 확인 할 수 있다.
- 즉, mnist 다운로드한 파일의 경로 참조를 정확히 해주지 못해서 에러가 발생하고 있음을 알수있다.
- 경로를 수행한 python 파일과의 상대경로로 정확히 지정하고 나면, 에러가 나지 않고, pyspark yarn cluster 모드로 잘 동작이 된다.
- 또 official manual 과 내가 수행한 스크립트의 다른 부분은 아래 옵션을 나는 삭제 했다는 점이다.
- --archives hdfs:///user/${USER}/Python
- 우리는 앞서 모든 노드에 동일하게 Python 환경을 이미 세팅해 주었고, Path 에도 포함시켜 줬다. 때문에, 굳이 Python을 배포를 통하여 공유되게 하지 않아도 에러없이 수행이 가능하다.
- 최종적인 결과 메시지는 아래와 같다.
- hadoop 에 CSV 파일이 잘 Write 되었는지도 확인해 보자.
- 하이라이트 한 부분 처럼 Hadoop 에 mnist 데이타에 대한 전처리 후 결과 output 이 train 과 test 데이타로 나뉘어 잘 적재 된 것을 확인 할 수 있다.
- 이는 앞으로 대용량 데이타에 대한 Python 전처리를 병렬로 수행할 수 있음을 확인 한 부분이다.
- Pyspark 를 이용한 Data 병렬 전처리 후 Tensroflow Records 포맷으로 저장
- CSV 로 파일을 저장하지 않고, Tenssorflow Records 포맷으로 바로 저장할 수도 있다.
- 우리는 이를 하기 위해 윗부분 설치 시점에, 4.2.8 에서 protobuf 까지 설치해가며, tensorflow ecosystem github 의 소스를 내려 받아 maven 빌드 후 tensorflow-hadoop-1.0-SNAPSHOT.jar 파일을 생성한 바 있다.
- 해당 jar 를 pyspark submit 시 인자로 넘겨주고 해당 jar 라이브러리를 이용 아래 내용을 수행 할 예정이다.
- 수행 스크립트는 아래와 같다.
${SPARK_HOME}/bin/spark-submit \ --master yarn \ --deploy-mode cluster \ --queue ${QUEUE} \ --num-executors 13 \ --executor-memory 22G \ --archives ./mnist/mnist/mnist.zip#mnist \ --jars hdfs:///user/moneymall/tensorflow-hadoop-1.0-SNAPSHOT.jar \ ./mnist/mnist_data_setup.py \ --output mnist/tfr \ --format tfr
- 앞서 CSV 로 HDFS에 저장해보았던 예제의 수행 스크립트 내용과 매우 유사하지만 대표적으로 --jars 옵션을 사용한것이 큰 차이점이다.
- 그리고, 소스 내부에서 format 인자로 로직이 분기하므로 --format 값으로tfr 을 넘겨 주었으며, output 경로 또한 csv 가 아닌 tfr 로 변경해 주었다.
- hadoop 에 tensorflow 포맷 records 가 잘 저장되었는지 살펴보자.
- 스크립트를 수행해주자 위처럼 tfr 폴더가 생성 되었다.
- tfr 디렉토리의 상세내용을 살펴보면 아래와 같다.
- 역시 test 와 train 으로 구분되었으며, spark job 이 생성하는 파일 명명 규칙으로 파일이 생성 되었다. (파일 내용은 TFRecords 포맷이다.)
- MNIST 모델 돌려보기
- 위 전처리 및 아래 Tensorlfow 병렬 모델 수행에서의 수행 스크립트는 Dev Zone 에서 테스트 된 관계로 GPU 관련 옵션이 빠져 있다. GPU 모드 병렬 수행을 위해서는 아래 옵션들이 추가되어야 한다.
--queue GPU--conf spark.executorEnv.LD_LIBRARY_PATH=$LIB_CUDA:$LIB_JVM:$LIB_HDFS \ --driver-library-path=$LIB_CUDA \#infiniband 에서의 성능 향상을 위해서는 아래 옵션도 추가하는 경우 # 큰 성능 향상을 가져올 수 있다. (설치시에도 옵션 설정 필요) --rdma
- Training (using feed-dict)
- feed-dict 을 이용한 Traing 용 수행 스크립트는 아래와 같다.
# 재 수행시에는 아래 주석을 풀어주어야 한다. Overwrite error 방지. # hadoop fs -rm -r mnist_model ${SPARK_HOME}/bin/spark-submit \ --master yarn \ --deploy-mode cluster \ --queue ${QUEUE} \ --num-executors 13 \ --executor-memory 22G \ --py-files ./mnist/spark/mnist_dist.py \ --conf spark.dynamicAllocation.enabled=false \ --conf spark.yarn.maxAppAttempts=1 \ --conf spark.executorEnv.LD_LIBRARY_PATH=$LIB_JVM:$LIB_HDFS \ ./mnist/spark/mnist_spark.py \ --images mnist/csv/train/images \ --labels mnist/csv/train/labels \ --mode train \ --model mnist_model # to use infiniband, add --rdma아래는 위 병렬 Training 이 수행되는 동안의 Yarn Batch Job 모니터링 페이지의 모습이다. 일반 Spark Yarn Cluster Job 과 동일한 모양이다.
- 최중 수행 뒤 결과 메시지는 아래와 같다.
- inference (using feed-dict)
- training 이 끝났으므로, inference 즉, 모델의 학습 결과를 확인 해 보자.
- 수행 스크립트는 아래와 같다.
# hadoop fs -rm -r mnist_model ${SPARK_HOME}/bin/spark-submit \ --master yarn \ --deploy-mode cluster \ --queue ${QUEUE} \ --num-executors 13 \ --executor-memory 22G \ --py-files ./mnist/spark/mnist_dist.py \ --conf spark.dynamicAllocation.enabled=false \ --conf spark.yarn.maxAppAttempts=1 \ --conf spark.executorEnv.LD_LIBRARY_PATH=$LIB_JVM:$LIB_HDFS \ ./mnist/spark/mnist_spark.py \ --images mnist/csv/train/images \ --labels mnist/csv/train/labels \ --mode inference \ --model mnist_model \ --output predictions # to use infiniband, add --rdma
- mode 부분과 output 부분만 차이가 있다.
- 주의할 점은 앞에서 mnist_model 을 training 과정에서 이미 수행하였다면, 상단 hadoop 명령어로 mnist_model 을 지우고 수행해야 한다는 점이다. (hadoop 에서의 경로는 적절히 수정 할 것)
- 결과는 아래와 같다.
- 최종 결과는 output 으로 지정해준 predictions 안에 존재한다.
- 아래 명령어로 내용을 살펴보자.
- hadoop dfs -cat predictions/part-00000
- 결과는 아래와 같다.
- training (using queueRunners)
- feed-dict 대신 I/O 병목에 더 강점이 있는 queueRunners 모드를 사용해 보자. 여기서는 TFRecords 를 이용하여 좀더 Tensorflow Low Level training 을 할 예정이다.
- 수행 스크립트는 아래와 같다.
# hadoop fs -rm -r mnist_model ${SPARK_HOME}/bin/spark-submit \ --master yarn \ --deploy-mode cluster \ --queue ${QUEUE} \ --num-executors 13 \ --executor-memory 22G \ --py-files ./mnist/spark/mnist_dist.py \ --conf spark.dynamicAllocation.enabled=false \ --conf spark.yarn.maxAppAttempts=1 \ --conf spark.executorEnv.LD_LIBRARY_PATH=$LIB_JVM:$LIB_HDFS \ --jars hdfs:///user/moneymall/tensorflow-hadoop-1.0-SNAPSHOT.jar \ ./mnist/spark/mnist_spark.py \ --images mnist/tfr/train \ --format tfr \ --mode train \ --model mnist_model # to use infiniband, add --rdma
- CSV 대신 tfr 즉, TensorFlow Records 를 직접 사용할 예정이다.
- 기존 hadoop model output 을 제거한 후 수행하자.
- 여기서 주의할 점은 2017년 8월 기준 official manual 에 --jars 옵션이 빠져 있어 에러가 난다는 점이다. 위처럼 jars 옵션으로 앞서 만들었던 tensorflow-hadoop-1.0-SNAPSHOT.jar 파일을 포함해 주어야 위 스크립트가 정상 동작 한다.
- 최종 결과는 아래와 같다.
[결론]
우선, PySpark 와 Tensorflow 를 섞어 쓸 수 있는게 매우 편하다. Python 전처리 수시간 걸리던게 PySpark 로 수분안에 끝나는 묘미를 맛보면, 이전으로 돌아가기가 쉽지 않다.
익숙한 Jupyter Notebook 이나 Zepellin Notebook 환경 모두 tensorflowOnSpark 연동이 가능한 것도 장점이다.
익숙한 Jupyter Notebook 이나 Zepellin Notebook 환경 모두 tensorflowOnSpark 연동이 가능한 것도 장점이다.
그리고, 대부분의 기존 Tensorflow 모델을 10줄 미만으로 수정하여, 병렬화 가능하다는 장점이 돋보인다. Spark 클러스터는 Yarn Cluster Mode 만을 지원하고 있다. 그리고, CPU 병렬 뿐만 아니라 GPU 병렬도 지원한다.
또한, Spark Streaming Mode 도 지원한다. 즉, 앞에 Kafka Cluster Queue 등을 놓으면, site 전체의 Click Stream 등 초 Heavy 트래픽에 대한 input 을 염두하며, 실시간 realtime inference가 되는 사이트 실시간 개인화 모델등을 만든다고 할때, 그러한 연산에 있어서의 Spark-streaming Layer 의 강점을 Deep Learning 모델에도 적용가능하리라 여겨진다.
설치는 Official Document 가 그런데로 상세히 나와 있는 편이지만, Legacy 가 최신 버전일때는 약간의 에러들이 발견되었고, 그래서 위처럼 설치 과정이 좀 길어졌다, 그 경우 소스 레벨 debub 및 log 를 확인해가며 설치를 해야 마무리가 되었던 부분은 약간 아쉬웠다. 즉, 너무 최신 Legacy 버전이 아닌 Official 버전을 사용하여 설치하면 좀더 쉽게 설치가 가능 할 것이다. 그리고, github 에 답변이나 issue 해결 commit 이 거의 매일 올라오고 갱신되는 편이라, 믿음이 간다. elaphs 는 설치해서 테스트 하다가 포기한게, issue 에 대한 대응이 너무 느렸다.
BigDL 역시 SparkML 과 유사한 패턴으로 딥러닝을 할 수가 있어, general 한 모델을 만들때는 더 편할 수 도 있다. 그리고, 자사의 BigData Cluster 가 아직 GPU 는 없고, intel cpu 기반이라고 하다면, BigDL 이 tensorflowOnSpark 보다 좀더 성능이 잘 나올 수 있다.
하지만, 다양한 고급 모델을 지원하지 못한다는 단점이 분명히 존재한다.
BigData + Deep Learning 콜라보레이션 아키텍처에 대한 고민은 거의 반년 이상 했던거 같다. 여러가지를 실험해 보았고, 결론은 BigDL 과 TensorflowOnSpark 두개로 거의 확정하였다. 둘은 장단점이 극명하여, 어느 하나로 치우칠 필요 없이, 선택적으로 사용하려고 한다.
좀더 실무레벨에서 많은 경험을 한 후 다시 한번 포스팅 해볼 기회가 생겼으면 하는 주제였다.
