DevOn 2012 - 오후 메모

### 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 소개