### Daum 내부 Hadoop 활용사례

* 발표자 : 윤석찬

* A role of Big Data

* Analytics(Hadoop)

* Realtime(NoSQL)

* Open Source based semi-real time analytics

* New Buzz

* 데이터 분석 산업의 변화

* Bigdata Stack?

* 지금 떠드는 건 한물 갔다.

* 오픈소스로 채우고 있다.

* Hadoo Platform : Today

* 도대체 국내에 빅 데이터가 있기나 하나요?

* 빅 데이터는 상대적이다.

* 데이터를 쌓아온 적이 없다. 

* 긴 시간 축적해놓으면 빅데이터

* Daum Hadoop 사용 사례

* 전사 로그 분석 

* Tiara 시스템

* Daum 서비스 내 발생하는 모든 트래픽을 수집하여 분석 및 리포팅

* Hive

* 하루 70TB 축적

* UCC 문서 스팸 필터링

* 문서 내부 단어 및 사용자 프로필을 기반한 스팸 필터링

* 일평균 600만개 문서

* 사물 검색 데이터 색인

* 이미지에 있는 데이터를 역 색인

* Daum 의 빅데이터 기술전략

* 사내 기술 코디네이션

* 개발자 데이터 접근성 향상

* 때론 컨트롤 타워가 진입 장벽과 아이디어 고갈을 가져온다. 

* Lessons for big data

* 기술 내재화 필요(No vendors)

- 개발자들이 직접 하둡을 활용할 수 있는 환경 필요

- 오픈소스의 적극활용 및 개발 잉여력 제공

* 데이터 분석 및 처리의 역할 파괴(No data scientist!)

- 개발자들이 직접 실시간 분석을 위한 Hive 활용

- 문서, 이미지 등 다양한 형태의 데이터 처리를 위한 토대 마련

* Small data를 활용강화(No big Mistacke!)

- Small Data라도 실시간으로 저렴하게 데이터를 처리 

* Hadoop 장점

* 분산 처리가 장점

* 관리 Host가 많이 든다. 

* 오픈소스는 기술내재화가 중요하다.

### Hadoop 실전 사용 사례 및 운영 노하우

* 발표자 : 김용우, 이선호(Daum)

* 좋은 검색 품질 : 사용자가 짧은 시간 안에 자신이 원하는 값을 얻어가는 것

* 좋은 검색 결과를 만드는 방법

* 검색하는 사용자를 이해하는 것 

- 로그를 기록 -> Big Data

* 데이터 분석을 위한 하둡(Data Analytics Process with Hadoop)

* **모든 데이터는 정제하지 않고 하둡에 입력**

* 분석 필요가 생겼을 때 필터링하여 툴을 이용하여 분석

* Hadoop - features - Tools

* 많이 본글

* Mission

* Target Data

- Half year Search Logs(About 40TB)

* Features

- Query - Collection Relationship

- Query - Document - Session Relationship

* Modeling

* Batch Process

- Hadoop - Feature - Model - Engine

* Search Spam Index

* Mission

* Data

* Task

* Blog Classification

* Mission

* Data

* Task

* What else?

* Topic Analysis With PLSA

* QUery Chain Filtering

* Reprocessing with Hadoop

* Advantage of Hadoop

* Advantage

* Disadvantage

### Hadoop을 사용하면서 겪을 수 있는 문제들에 대한 트러블 슈팅?

* 이선호(sunholee@daumcorp.com)

* 개발자 같아!

* Hadoop 시작하기

* 빅데이터 분석이 의미가 있는가?

* 하루치 로그 대신 30일치 분석하면?

* 유명인이 언급된 모든 문서를 분석하면?

* 문제

- 잘못된 파일 작업 하나 재시도

- 현재 작업 취소

- 다른 작업 떄문에 서버 리소스 부족

- 결과 취합해 다른 작업 수행

* Hadoop 사용자

- 다양한 배경

- 자바 프로그래밍 보다 분석 로직에 초점

* 주요 작업 방법

- Hadoop streaming(파이썬)

- 데이터 집계 :  pig or Hive

* 인프라

- 여분 하드웨어에 실험적으로 도입

* 설치는 쉽다

- 압축 파일 풀고 디렉토리 환경 변수 설정

- 패키지 설치도 가능

* 설정은 어렵다.

- conf/*.xml  너무 많은 설정옵션

- 뭔가 부족한 메뉴얼

- 시행 착오를 거쳐서 안정화

* Hadoop 디자인 - MapReduce

* 사용팁

- 데이터 저장

- 버리지 않고 저장

- 미지의 분석 요구 등장

- 디스크 비용은 감당할 수 있다고 생각

- 데이터 압축

- 빠른 작업 수행을 위해 파일을 쪼개서 압축

- lzo 같은 분할 압축 사용 가능

- 데이터 연동

- ftp로 외부 파일 가져다 분할 압축 저장

- crontab 에 수동 스크립트

- wget .. | zcat ... | hadoop fs ...

- hadoop fs 쉘을 활용하는 스크립트를 잘 짜면 많은 일을 할 수 있음

- Hadoop streaming

- 파이썬 같은 외부 프로그램 실행

- slave는 별도 프로세스를 생성해 표준 입출력으로 데이터만 교환

- Pig or Hive : 과정 명시 vs 결과 명시

- 데이터 정합성

- 데이터가 커서 항상 예외가 발생

- 정형화되어 있지 않은 데이터

- 대책

- 모든 예외 처리를 잘 하거나

- 예외는 버리고, 버려진 데이터 비율 집계 

* 장애상황

* 가장 중요한 자원은 메모리

* 가장 흔한 장애는 디스크 교체

* 가장 위헙한 장애는 네트워크 점유

* 장애 - 메모리 부족

- Slave 메모리 부족

- CPU가 swap 에 묶임 -> 행업, 통제 불가능

- 기본 설정은 hadoop streaming 이 만든 별도 프로세스 메모리까지 통제하지 않음

- 대책

* 장애 - 디스크 교체

- Master 디스크 교체

- 디스크 여러개에 checkpoint 저장 기능 

- Slave 디스크 교체

- hadoop 이 실패한 task 는 다른 서버에서 재시도

* 장애 - 네트워크 점유

- hadoop 클러스터 하나에서 발생한 경우는 없었음

- hadoop 클러스터를 여러 개 만들고, distcp로 대량의 파일을 복사할 떄

- distcp가 병렬로 파일 전송하는 task 생성

- distcp - m 옵션으로 task 개수 제한

### 알고쓰자! NoSQL - Hbase 및 MongoDB 중심

* 발표자 : 유응섭, 최준건

* Group-By Operation

* Secodary Index

*  DualWrite

- Observer를 이용한 구현, 클라이언트는 코드 수정이 필요없음, 부하를 많이 주었을 때 문제 발생해서 보류

* Index Manger

* IDEX_TABLE

* Scan Performance

- 범위가 좁은 검색을 할 때 속도가 높아진다.

- NoSQL의 인덱스를 활용해서 RDBMS처럼 쓰는거야?

* Durability

- 다수 노드 장애시 데이터 복구 불가능

- 다음 HDFS 버전에서 해결될 예정

* MongoDB : Scaling write performance

* 몽고디비!!

* First Impression : Easy

- Easy installation

- Easy data model

* Second thought : not so easy

- No SQL

* Insert throughput on a replica set

* Insert throughput on a second index

- 데이터의 크기가 커질수록 성능저화가 심함

- b+tree 인덱스를 사용

- 균등한 인덱스를 넣을 때는 크게 성능제한 없음

- 균등하지 않은 인덱스를 인서트할 경우에는 성능저하 발생

* 성능저하에 대한 대처

1. partitioning 처리

- 몽고디비는 파티셔닝 지원 안함

- 애플리케이션 수준에서 파티셔닝 해야함

- switch collection every hour

- 레코드 수를 조정?

2. Better HW

- More RAM

- More IOPS

- RAID strinping

- SSD

3. More H/W : sharding

- Automatic partioning across

- 유효한 리소스 메모리자원이 생기면서 성능이 향상됨

- 레이드까지 구성하면 더 높아짐

* Three's no free lunch

- 문제해결을 위한 비용이 든다.

* 몽고디비가 정말 인덱스가 필요하냐?

- 필요한 것에만 사용한다.

* Sharding 을 통해서 입력 성능을 높인다.

- 대용량의 데이터를 입력는 테스트를 어떻게 할꼬?

* Sequential key

- All sharding key to one 

* 문제해결을 위한 시도

* 몽고DB B+tree index 관련한 문제

* 몽고DB에서 sharding 을 통해 입력속도를 높이는 것은 쉽지 않다.

* Lessons learned

* 데이터의 양을 늘려라

* Know the performance impact of secondary index

* 몽고DB

* HBase vs MongoDB

* 인덱스를 사용하지 않을 경우

### 

* 발표자 : 김영한

* 프로젝트 구조와 모순

* 화면 중심 프로젝트

- 화면 중심으로 프로젝트 구조를 구성

- 중복의 상황이 발생한다.

- 프로젝트가 진행된다면

- 같거타 유사한 쿼리가 무수히 나타남

- 회원정보 조회의 경우 11번의 거의 동일한 쿼리 발견

- 수정이 아주 어려움

- 월화수목금금금...

- 화면 중심 프로젝트 구조는 수 많은 중복을 만든다.

* 일반적인 프로젝트

- 데이터와 비즈니스 로직을 중심으로 프로젝트 구조를 구성

- 실전에서 멀티 프로젝트

- 중복 발생

- 멀티 모듈 프로젝트

- 데이터 불일치

- CORE로 통합시 또 다른 문제 발생

- 해결방안

- Row 단위로 전체 조회

- 특별한 경우만 최적화

- 파레토 법칙

- 프로젝트 구조와 모순의 결론

- 엔티티가 쿼리에 의존

- 구멍난 엔티티

- 신뢰할 수 없는 엔티티

- 진정한 의미의 계층 분할이 어려움

* Why ORM

* ORM 을 사용하는 이유

- Projection 문제

- Join 관련 데이터 연결문제

- 엔티티 데이터에 대한 신뢰

- 제대로 된 프로젝트 구조

- CRUD SQL 좀 알아서 해줬으면

- 진정한 객체 지향 개발 가능

- 도메인 주도 개발 가능

* SQL을 사용해야 하는 이유

- 우리가 사용하는 DB는 RDB다

- 통계 데이터

- 아주 복잡한 View

* ORM을 사용하는 이유!

- 컴퓨터가 할 수 있는 일을 더이상 사람이 하지 말자. 나는 SQL Mapper가 아니다.

* JDBC -> iBatis -> ORM

* ORM에 대한 반대

* ORM에 관한 오해

- Object DB 같은 것 아닌가요? 이미 망한 기술로 알고 있는데요?

- 성능이 느리다.

- ORM을 사용하면 SQL을 못쓴다.

- Hibernate 자체도 네이티브 쿼리를 사용할 수 있다.

- SQL을 몰라도 되나요?

- SQL을 잘 아는 사람이 ORM을 해야한다.

- 공부할 내용이 많으면 어쩌지...

- 제대로 된 교육을 했다면 좋았는데

- 모두 iBatis, myBatis만 사용하는데?

- 진실은...

- 우리나라에서만 많이 쓴다.

* ORM을 사용하고 싶은데 어떻게 시작하나요?

- 공부해야 한다.

- 공부해야할 것

- JPA

- Hibernate

- SpringDataJPA

- interface로 repository 자동생성

- Simple queries

- pagination

- Webinding

- Specifications, QueryDSL 지원

- QueryDSL

* ORM 적용시 고민할 2가지 구조

* ORM을 적용하는 방법은 크게 2가지

- Domain Model Everywhere

- Domain 모델을 모든 레이어에서 적극사용하자

- OSIV 사용

- 게터, 세터 사용

- DTO는 중복 악이다.

- 장점

- 개발하기에 빠르고 편리함

- 단점

- 복잡한 View 표현 힘듦

- Domain 모델의 세터 게터 노출, View 로직 추가

- Domain 모델의 순수성이 떨어짐

- XML, JSON, 외부와의 통신 API 위험

- Pure Domain Model

- 도메인을 순수하게 유지

- CQRS

- 장점

- 순수한 도메인 모델

- 단점

- DTO를 만드는 것은 귀찮다. 성가시다. 괴롭다.

- DTO는 또다른 중복이다.

- DTO와 도메인모델의 컨버터를 고민

* 어떻게 해야해!!

- 도메인은 순수해야 한다.

* 우리의 과제

- DDD를 하자

- Pure Domain Model 을 유지하며 실용적으로 개발하는 방법

- DTO를 생성하는 방법, 활용법

* AutoSave : 연관관계에 의한 자동저장이 일어난다고...!? 그럼 왜 우린...Orz...

* SpringDataJpa 소개

### 오전

* 김국현님 진행

* 키노트

* 다음 커뮤니케이션 : 최세훈 대표

* 소통이 안되는 사람들과 이야기

* 커뮤니티와 함께하는 개발자들의 모임

* DevOn 2012에 관한 네가지

- 찾아가는 컨퍼런스

- 참여의 컨퍼런스

- 소통의 컨퍼런스 

- 공유의 컨퍼런스 

* 다음과 함께 즐기세요!!

* 개발자 창업과 아이디어

* 참가자 : 이택경 대표(프라이머), 장병규 대표(블루홀스튜디오), 김길연 대표(엔서미)

* 각 인물들에 대한 이야기를 전할 것

* 대화 

김 : 벤처 정신을 잃지 말라고 별도의 오피스를 제공해준다. 이미지오, 컴퓨터 비전 기술, 음성 인식기술 진행 중. 숨피.

이 : 모든 사람이 창업을 해야하는게 맞을까?

김 : 휴학을 하고 창업을 했었지만, '인생을 걸어야겠다'라는 생각을 하게 되었다. '망하면 뭐하지?'라는 생각을 하지 않고 시작했다. 1년 후 '망하면 뭐하지?' 하고 생각했다. 망하면 다른 창업하거나 취직하면 된다고 생각했지만... '인생을 걸고 한다'라고 생각해라.

장 : 모든 사람이 창업할 필요는 없다. 창업을 하면 자기 자신에게 진지해질수밖에 없다. '스스로에게 질문을 던진다.' 삶에 대해서 진지해진다. 힘들고 척박한 길이니 모든 사람이 함께할 필요는 없다.

이 : 망한다.

장 : 개발자도 기획-경영을 해야한다면, 나는 전문가가 아니니까 열심히 해야해, 전문가가 아니니까 시행착오가 많을테니 열심히 해야해.

이 : 개발자만 있는 팀은 제품을 내놓는다. 기획자가 있는 팀은 외주를 주던가 한다. 기업을 경영해본 것과 경영학을 배운 것은 다르다. 경영학은 배운 것만으로 안된다. 경험해보지 않으면 안되는 학문이다.

창업열풍의 시대. 개발자를 못구해서 난리다. 공급과잉, 양산형 개발자의 과요공급. 지금은 수요와 공급에서 공급이 딸리는 상황이 되었다. 

장 : 개발자의 의미 분리, 첫번째 개발자 : SI 등의 MM(Man month)를 처리하는 구현자 - 수요공급의 표현이 맞음, 두번째 개발자 : 특별한 문제를 해결할 수 있는 해결자 - 창업에 필요한 개발자는 드물다. 인재를 구하는 것은 힘들다.

김 : 알고리즘 구현을 취미로 하는 모임 등에 참여하는 적극적인 개발자가 대접을 받는다.

이 : 능력을 갖춘 개발자가 인정을 받는다. 한국은 학벌사회라서 '개발자'에게도 학력이 중요하다. 스타트업이 투자를 받을 때도 '학벌'에 좌우된다.

장 : 투자를 받는데 '학력'은 관련이 있다. 실제로 그것을 기준으로 하지는 않는다. 상관관계는 없다. 

이 : 본인이 카이스트 출신이라 그러신 거잖아요

장 : 세명이 처음으로 성공했다. 벤처의 평균은 망할 수 있다.

김 : 망해봤다. 환경 중요하다.

이 : 벤처는 '아이디어'가 중요하다. 그런데 기술과 관련된 부분이라면 '전문 분야 경력이나 학력'이 없으면 안된다. B2C, B2B는 다르다. B2B는 영향을 끼친다. B2C는 상관없다. 

'아이디어 창업' : , '기술 창업' : 기술에 너무 얽매이게되는 경향이 생긴다. 

장 : '아이디어 창업' : 모방이 쉬운 경우 , '기술 창업'

이 : 아이디어는 공공재니까 이야기를 해라. 아이디어라는 것을 많은 사람들과 이야기를 나누며 발전시킬 필요가 있다.

장 : 테트리스를 다르게 만들 방법이 없다. 심플하고 디펜스 가능한 아이디어는 많지 않다. 

이 : 린(Lean)하게 가라. 꿈은 크게 가져도 실행할 때는 하나씩 하나씩 해라. Lean start 유행. 고객에 대해서 잘 모르는 상태에서 진행하면 안된다. 검증하면서 한걸음 한걸음 가라. 한번에 막 가면 망한다. 1년 전에 뵈었어야 했는데, 1년전에 만났어도 안들었을거에요.

 후배 창업자들에게 '이렇게 해라' 라고 해줄 말

장 : 추석 때 '창업했다'라고 이야기 하지 마라. '창업'에 대한 사회적인 단적인 예. 들어야 되는 이야기 듣지 않아도 되는 이야기(조언)에 대한 구분을 위한 노력이 필요하다. 

김 : 창업하고 6개월까지가 재미있다. 젊은 나이에 사장하는 느낌. 동네 호프집에 갔더니 다 사장님. 담배를 피거나 운동을 하거나... 책을 많이 읽었다. 직접 창업한 사람들의 책을 읽었다.

이 : 기존 조직에서 창업을 하려고 하는 경우에는 어떻게 해야할까요?

김 : 아이디어를 실현하기 위해 조직구성을 어떻게 할 것인가 고민...

장 : 내부적인 시각만으로는 '이노베이션(혁신)'을 이루기는 없다. 개발자도 참여하고 소통하여 스스로 혁신하고 성장할 필요가 있다. 

이 : 개발자의 경력관리 비전에 대해서. 대학교 갈 때 쉽게 갔다. 대기업조차도 개발자를 구하지 못해서 난리를 치고 있다. 개발자들을 수입할지도 모른다. 

장 : 인도인 개발자, 중국인 개발자를 교육하고 있는데 이 사람들을 교육시키고 있는게 맞을까? 개발은 문화적인 이해가 많지 않아도 대화가 가능하다. '위기는 기회다!' 한국에서만 개발하면 부당한 처우를 받을 수 있다고 생각할 수 있다. 개발자들에게 수많은 기회가 찾아올 것이다. 

김 : 비지니스 쪽에서의 호흡은 느리다. 성취감을 얻을 수 있는 직업이 흔치 않다. 

장 : 개발이란 정신활동이다. 뇌는 인간의 신체장기 중 가장 오래 활동하는 장기다.

이 : 다음 시티홀에 있을 때, 다음 내 직군을 2개 분류하려고 했다. 그루와 같은 개발자, 관리자. 생태계쪽의 인식전환이 필요하다. 정신활동으로 하는 것이기 때문에 벼롤 상관없다. 창업을 하려고 할 때 '개발'을 모르는 사람들과 한다면?

장 : 와아... 정말 어려운 질문. 성공이 쉬운가요? 성공은 어려운 거에요. 그분과 '내'가 했을 때 무엇인가를 만들어낼 수 있다는 생각을 들게 하는 '팀원'이냐? 그 질문이 'Yes'라면 소통이 어려워도 해야한다.

이 : 기획자도 힘들다.

김 : 창업 멤버는 알음알음 아는 사람들과 하고 '소개'를 받아서 하게 된다.

장 : 창업하려고 하는 사람인데 '개발자'가 없다고 하는 기획자들이 많다. 창업하고 싶으면 '개발자'들이 있는 물가로 찾아와라.

이 : 좋은 개발자를 찾는 기획자는 많다. 개발자들에게 기회는 많다.  

* 김지현 이사 키노트 

* 다음이 준비하는 마이피플 API, 다음TV APi

* 다음이 API를 준비하는 이유

- 2006년 10월부터 준비, 당시만해도 개념이 없었다. 

- DNA Lab을 통해서 준비

- [Daum 개발자 네트워크](http://dna.daum.net/)

- 30여개의 API 지원

- API를 열심히 하는 이유 : 생태계에 중요하다.  

- 생태계의 풍족성

- 혁신의 마중물 : third party의 참여, 간접적 기여

* 마이피플 API

- 서비스 플랫폼으로 거듭나고자 API 제공

- Killing time 할 수 있는 마이피플 API Open

- API 데모

- 박병석, 이혜영

- 3가지 OpenAPI

- Client

- bot 관련 : 마이피플 봇 마플 경진대회

- 영어로 번역봇, 일본어로 번역봇, 일어로 번역봇

- 단어장 봇

- 마플듀오

* 다음TV API