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까지 라는 부제를 달아주셨어야 ㅠㅠ
내용이 실제 코드를 봐가며 진행됐던 세션이라 머리로는 이해되지만 가슴으론 이해 못한 슬픈 세션…흑

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. 모바일 광고와 분석을 위한 기술이야기

내가 몇년전부터 모바일 앱을 계속 만들어왔던 사람이라 그런지 전혀 새로운 게 없었던… 상당히 아쉬웠던 세션이었던 것 같다.
모바일 광고 최적화라도 내용을 진행했으면 했는데, 마케터나 기획자 분들은 많이 안계실거라며 스킵해주셨…ㅠㅠ 엉엉
모바일계에 안계시는 분들은 재미있게 들으셨을지도!!

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.

앱 & 서비스 기획자입니다. 잘하고 싶어요.

Sliding Sidebar