Deview 2013 - Day 2
Deview 2013 Day 2.
데뷰 두번째 날. 어제와는 달리 오늘의 세션 트랙의 대부분은 ‘빅데이터’ 이슈.
선행기술이라는 트랙이 있긴 했으나, 내용은 빅데이터 ㅋ
빅데이터가 ‘음, 엄청많은 데이터로 의미있는 데이터를 얹는거잖아’ 이상의 개념이 없던 초초뉴비의 기록이니…
차마 올리기가 애매한 점이 많다 ㅠㅠ 들여쓰기 잘못해놔서 내용 엉킨게 있을지도 …
물론 발표자료와 동영상을 보는게 가장 좋지만, 올라오기 전까지 자료를 좀 더 찾아 올려봐야겠다.
그리고 필기(라고 쓰고 불꽃타이핑이라고 읽는다)의 압박으로 내용을 통채로 날려먹기도 했지만, 꼭지는 아마 살아있을 듯?;;
ps. 에고. 정리하는 것도 일이야
Session1. Deep-learning : Machine Learning with Deep Neural Network
에.. 그러니까 구글음성검색을 사례로 드셨는데, 구글/네이버음성검색이 낯선 나에겐 그냥 ‘Siri’ -_-;
Deep learning 구조
- input layer(음성신호) – (weight) – hidden layer(계산) – out layer(언어별 확률값)
- 히든레이어가 많아서 딥러닝이라고 부른다
- 너무 많은 레이어를 쌓으면 효율이 떨어진다. 6~7개 레이어만.
새로운 알고리즘
- DNN-Back propagation : 90년대 개발된 방법. 2000년대 부활(원인 : 새로운 알고리즘. (오버티피 극복한) + 빅데이터 + GPU의 발전)
- Pre-training : Restricted Boitzmann Machine (RBM)
- hidden node들 끼리, visible node를 끼리는 independent : 서로 미치는 영향이 동일함
- HInton의 제안 : 프리트레이닝 방법을 제안. 현재의 딥러닝.
- CD-1만으로도 충분하다 : learn & freeze. 그리고 hidden1을 다시 input으로 두고, hidden2와 프리즈.
- Drop-out
- Pegularizer의 일종. Randomness를 추가함
- Hidden node를 모두 훈련시키지 않고, Random하게 Dop out. 뉴럴 네트웍을 랜덤하게 학습(60%정도)시켜 그것들이 merge되며 하나의 네트웍을 구성.
- 단점 : 학습커버로의 수렴이 느리다. 랜덤해서 시키기 때문에 학습이 될 떄도 있고, 안될때도 있다.
Deep learning tip
- Dropout is better than RBM : 오버라이닝을 막을 프리트레이닝 목적이라면 굳이 RBM은 필요없음
- inputData에 noisy한 Real Data가 많다면 굳이 RBM도 Drop-out도 쓰지 않아도 됨. 노이지 데이터가 없다면 만들어서라도 넣어줘야 학습이 잘된다.
- 계속 같은 Learning Rate를 써야 하나요? iteration이 진행 될 수록 learning rate를 감소.
- 남은 어려운 점 : DNN을 훈련시키기 위해 결정되어져야 할 파라미터 중에, Learing Rate(낮게 잡아서 학습정도에 따라 점점 높여갈것)
Session2. 멀티쓰레드 프로그래밍이 왜이리 힘드나요
컴파일러와 하드웨어에서 lock-free까지 라는 부제를 달아주셨어야 ㅠㅠ
내용이 실제 코드를 봐가며 진행됐던 세션이라 머리로는 이해되지만 가슴으론 이해 못한 슬픈 세션…흑
[slideshare id=12746882&doc=ndc12-2-120430113657-phpapp01]
Session4. 하둡 및 하둡 에코 시스템을 이용한 뎅터 플랫폼 아키텍처 적용 사례
엔터프라이즈의 빅데이터
- 현재 엔터프라이즈 IT환경은 빅데이터 적용하기 어려운 환경
- 기획 및 관리 중심, 실행은 아웃소싱(bad)
- 자회사가 관리 및 실행(bad)
- 주요 운영/개발은 직접 수행, 일부 외주(good) : 빅데이터 적용이 수월
- 대부분 직접수행(good) : 엔터프라이즈가 없는 조직이 많다.
- 빅데이터 프로젝트 성공요소
- 분석 결과 가치 > 분석 비용 : 비용을 낮춰버리면 가치가 애매모호 해도 해볼만 하다.
- 무엇을 분석할 것인가에 대하나 고민
- 지속적인 분석 결과 개선 활동(튜닝)
- IT부서가 아닌 실제 데이터 사용부서가 주도
- !잘작성된 프로젝트 계획서 : 실패할 수 있다.
- 실행할 수 있는 기술력
- 프로젝트 진행
- 시스템 기획(대충~) > 데이터 수집 > 데이터 가지고 놀기 > 가치 발굴 > 시스템에 반영 : 조직 스스로가 애자일 방식으로 접근
- 결론
- 기존의 데이터 분석과 현재의 빅데이터의 가장 큰 차이는 데이터 크기/종류/속도가 아닌 기업 스스로 데이터를 적극적으로 이용해서 제품 개발, 서비스 기능, 마케팅 등에 차별화되고 경쟁 우위에 있는 무기를 가지는 것.
- 임원수준에선 어렵. 직책이 변경되서. 오너가 하는게 좋음
사례연구
1) 이커머스(GSshop) 적용사례
- 요구사항 : 아마존 쇼핑몰! + 구글 analystic
- 현실은?
- 가장 기본적인 로그 조차도 일 단위 분석
- 비지니스에 중요한 데이터는 로그도 없음
- 일부 로그는 외부 업체로 전달
- 전체 시스템 아키텍처
- 실시간 분석 시스템 구성 예
- (참고 – http://highlyscalable.wordpress.com/2013/08/20/in-stream-big-data-processing/)
- 임시 저장소인 큐 장애시 방안은?
- 분석 중 일부 분석 서버 장애 시 임시 분석 결과는 어떻게?
- 분석 결과 저장소의 성능은?
- 분석 결과 서비스 제공시 충분한 기능 제공? : noSQL은 인덱스가 없어서 분산입력은 쉬우나, 인덱스가 없어서 빼기가 힘들다
- 실시간 분석의 어려움
- 중복, 유실, 성능 모두를 만족시키기 어려움 : 이중화된 큐와 체크 포인팅 기능이 핵심, 체크 포인팅을 자주 하면 성능 저하, 가끔 하면 데이터 유실이 높아짐
- 성능 : 대량의 데이터, 분석의 복잡성(다양한 메타 데이터와 연계 등) : 접속지역, 성별, 등등…
- 운영관리 : 무정지로 운영 되어야함, 프로그램 배포(->이중서버이용, 배포시 우회하는 방식으로 함.)
- 분석결과 저장 : 저장 주기, 체크 포인트, 저장소 성능, 기능
- 시간관리 : 분산된 환경의 시간 동기화, time window 동기화, data time vs. system time(-> 데이터타임 : 분석기 입장에서는 과거데이터도 올 수 있다.)
- 분석로직 구현
- 플랫폼들의 조함 : Flume, storm, kafka 등. 각각은 HA등에 대한 기능 제공, but 근데 조합시 불협화음
- 결론
- 실시간 분석은 대세지만, 많은 난관이 존재 : 고객의 요구(정합성, 안정성 모두 만족 등), 메타정보(조인)처리 성능, 운영의 어려움(항상 데이터가 흘러다님)
- 분석 대상 데이터의 속성, 분석 로직 등에 따라 적절한 플랫폼 선택 : 플랫폼은 기본만 제공, 많은 것을 그 위에 만들어야 함, 적절한 플랫폼이 없으면 만드는 것도 방법
2) 보안분석플랫폼 사례
3) 바이오 인포메틱스 사례
4) 온라인 컨텐츠 서비스 사례
(주. 사례연구는 너무 자세히 설명해주셔서…ㅠㅠ 노트는 다했지만 요약이 어렵다; 자세한건 발표자료를 통해..쿨럭;)
Session5. 모바일 광고와 분석을 위한 기술이야기
내가 몇년전부터 모바일 앱을 계속 만들어왔던 사람이라 그런지 전혀 새로운 게 없었던… 상당히 아쉬웠던 세션이었던 것 같다.
모바일 광고 최적화라도 내용을 진행했으면 했는데, 마케터나 기획자 분들은 많이 안계실거라며 스킵해주셨…ㅠㅠ 엉엉
모바일계에 안계시는 분들은 재미있게 들으셨을지도!!
[slideshare id=27191511&doc=mobileadanalyticstechnology-131014225010-phpapp01]
Session6. AWS에서 추천 구현하기
SK Planet의 사내벤처, PlanetX의 RecoPick팀! 스타트업환경에서 구축가능한 AWS를 활용하고 있는 내용이 주 발표내용이어서, AWS 서비스 비용에 대해 감을 잠을 수 있었던 시간. 발표가 재미있어서 빼먹은 내용이 많다(…)
수집/변환/계산/결과제공
1) 수집
- 로그 포맷? 서버 연동? 방화벽오픈? 추가개발필요 —> 스크립트 개발.
- <스크립트 방식 > 페이지 로딩 완료. 스크립트에 따라 로그 전송. 쿠키기반으로 UID생성. 아이템 추출.
- 장점 – 간편하다, 서버 부하 감소
- 단점 – 일부 데이터 손실 가능
- 브라우저들 -> 콜렉터(ELB+node.js …)
- collector는 nodejs로 구현. redis로 불의의 사고를 대비하자
- auto scaling으로 비용 절감
- 11번가 + 티몬+한겨례+판도라 = m1.small 6대로 커버
- 데이터의 임시 저장소 : Amazon RDS 사용 – 설정, 튜닝, 이중화 몰라도 된다. multi-az deplop
2) 변환
- user to item 추천
- minhash based filtering : 비슷한 사용자들을 미리 걸러낸다
- Matrix factorization
- item to item 추천 : Mahout
3) 추천계산
- 행동가중치, 시간가중치를 준다.
- KSM ㅋㅋKeyword semantics model
4) 추천결과 제공
- json으로 저장. 결과에 대한 hash 생성(recohash)
- Redis
Tips
- 사용한 인스턴스 : c1.medium / map :4 / reduce :1
- Amazon S3 + Amazon EMR < Hadoop on EC2
- AWS – 자체클러스터를 운영하는 경우 :: 퍼블릭 ip로 주고받으면 과금!!!!!! 내부 ip로만 주고받아야.
-
CDH
- hadoop만 설치할거라면 아파치 버전도 쓸만함
- Hbase, oozie 등을 함꼐 쓰면? CDH쓰는게 편함. 모니터링도 되고. 대수 제한도 없어짐.(manager4.6에 버그있어서 4.7버전 이용)
-
HDFS로 Data를 저장하는 경우
- 기존 : 디렉토리로 파일 관리하기 귀찮음 —> 맵 태스크 파편화를 막기위한 파일 merge 필요, 오래된 파일 삭제, 로그 포맷이 변경되면?
- HDFS 쓰면, : 파일머지 따위 ㅋ, TTL을 이용해서 자동 삭제, NoSQL
- 멀티스캔
- 추가사항 : setCacheBlocks(true) -> 시퀀스로 불러오는 경우가 많을땐 false로 지정.
- 모니터링 및 알람
- 장비 모니터링 및 알람 시스템 없고 , 만들려면 어렵다.
- AWS Cloudwatch
Session7. 링크드인의 Big Data Recommendation Products : 어제의 데이터를 통해 내일을 예측한다.
결론부터!
- 예측 알고리즘
: 어제의 데이터를 분석하여 내일의 사용자의 행동을 예측하는 머신러닝 알고리즘 - 예측 인프라
: 하둡, 키밸류스토어, 각종 오픈 소스 프로덕트를 활용한 링크드인의 빅데이터 에코시스템
추천프로덕트
- 종류 : 친구추천, 어떤 스킬을 승인?, 새 직장에 관심이 있을것인지? 어떤 뉴스?
- 특징1. 빅데이터 에코시스템
roof(하둡 클러스터 > 키밸류 스토어 > 반영 > 유저 인터렉션 데이터) - 특징2. Encapsulation
- 특징3. 온라인 vs 오프라인
온라인 | 오프라인 | |
---|---|---|
장점 | 사용자에게 최신의 정보를 제공 가능 | 더빠른 개발과 iteration, scale 쉬움, failure toleration |
단점 | 더 긴 개발시간, scale 어려움, failure handling에 더 신경써야함 | 최신의 정보를 제공할 수 없음 |
슈퍼바이저 머신러닝
- supervised 머신러닝
- 과거의 데이터를 통해 모델을 train
- train된 모델을 사용해 실제 예측
- 바이너리 classification
- 결과가 1 or 0으로 나오는 supervised 머신 러닝 문제
- 머신러닝 기반의 추천
- 과거 : 주어진 상황하에서 유저의 행동을 관찰
- 현재 : 데이터를 바탕으로 모델을 훈련 시킬 수 있음. 주어진 과거 데이터의 오류를 최소화 하는 모델을 만듬
- 미래 : 만들어진 모델을 통해 미래의 유저 반응을 예측
빅데이터 추천 프로덕트 만들기
1) intuition
2) feature select / extraction
3) model building
- 샘플링 후 R 등의 통계 패키지를 이용한 모델 러닝. 기능 숫자가 적고, 빠른 iteration이 필요한 경우
- ADMM framework
- feature의 숫자가 많을 수록, 모델 러닝 자체를 분산 시스템 하에서 실행하고 싶은 경우
- 여러 다른 머신에서 각자 러닝 후 각각의 결과를 합산
- 합산된 결과를 바탕으로 다시 iterate
4) Data Generation : 빌드 된 모델을 바탕으로 실제 추천 데이터를 만들어 내는 과정.
- Azkaban: Linkedin’s open source project
5) Serving Data
- Voldemort : Linkedin의 key value storage.