Menu

스트레스를 받으면 기획자는 글을 씁니다.

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.

적게 일하고 많이 버는 법을 늘 고민합니다. 일이 되게 하는 것에 간혹 목숨을 겁니다. 지금은 우아한형제들과 함께 일하고 있어요.

Post Navigation

Deview 2013 – Day 1

Deview 2013 – 현장분위기 사진들(…?)