5. Daum 분산 스토리지의 증가
100,000
50GB
25GB
10,000
1GB
1,000
100MB
100
2004 2006 2012
6. 분산 파일 시스템: Tenth vs. HDFS
Tenth는 한메일, 카페 첨부 파일 등 대용량 파일을 저렴하게 저장하
기 위한 분산 파일 시스템으로 2005년 부터 개발
저장 파일 개수 700억개, 20페타 바이트 (2011)
– 2006년 라이코스메일, 카페 도입
– 2007년 한메일 기가 용량 도입
– 2009년 동영상 업로드팜 도입
– 2010년 다음 클라우드 도입
Tenth 비교 HDFS
2005 개발 시작 2006
C++ 구현 언어 Java
첨부 파일을 저장하기 위해 하 이용 목적 분산 시스템에서 파일 저장
나의 스토리지 처럼 이용 가능 용도로 활용
다중 (MySQL이용) 네임 노드 싱글
1~4MB (fixed chunks) 파일 형태 64MB (fixed blocks)
미지원 디렉토리 구조 지원함
7. Daum 소셜 데이터의 증가
월 검색 쿼리수
1,017,410,000
월 검색 UV
19,473,803
월 Top 페이지 PV
2,074,688,580
월 Top 페이지 UV
23,121,882
월 Daum.net PV
13,745,663,643
KoreanClick 통계(2012.3)
12. Daum’s Bigdata Use-cases
• Log Analysis
– Log Analysis for Daum services
– Targeting Ads by click-through logs • Services (MongoDB/Cassandra)
– Search Ranking by user behaviors - MyAgora
- Search Ad sysem
– User recommendation for Café service analysis - Index of recent visiting Daum Café
– Data process for search ranking algorithm - Internal Cache Farm(Redis)
– Analysis of gaming log analysis - Internal Git Repo (Redis)
• Data Storage (Hbase)
• Data Analysis - Search engine index
– Shopping data analysis - Server monitoring data
– Topic analysis and recommendation - User login data
– Spam filtering for user-generated contents
– Reverse-index for image search
– Search query normalization in NLP
– Data mining for search query, related query,
classification of documents
• Research
– SemSearch: large-scale semantic web search
– VisualRank: Similarity for Image search
21. Hadoop 기반 광고 로그 분석
광고 로그 및 통계 처리, 매체 토픽 분류 및 과거 로그 데
이터를 기반으로 광고 집행 타켓팅 분석
• input: 과거 집행(노출, 클릭) 로그 데이터 ( 필요에 따라 일,
주, 월 단위 로그 사용)
• output 광고에 대한 사용자별 노출 내역 통계 처리
22. 기존 분석 프로세스
– 데이터 복사 ▶ 파싱 ▶ 필터링 ▶분석
– Raw data ▶ SAS파일 : 약 10시간 (데이터 복사시간 제외)
– Query count : 약 6시간 (1일 데이터)
Hadoop을 이용한 분석 프로세스
– 데이터 ▶ 분석
– 1일 데이터 처리 : 1.5시간
23. 분석 속도 증가
Hadoop 도입 전
Hadoop 도입 후
시간당 분석 일 로그 분석
기존 방식에 비해 10~25%의 시간에 처리 가능
실시간으로 10분 단위 분석 가능
24. Hive: SQL을 통한 쉬운 분석
selelct keyword, count(distinct adid)
from ad_log
where dt='20120101' and hr='10' and mi= ‘10'
group by serviceId, mi
25. 실시간 비즈니스 분석
모바일 광고 타게팅 로그 분석 (10분 주기)
– Input: 광고ID, 사용자프로필, 노출/클릭
– Output: 광고ID, 프로필별 인덱스
– 실행시간: 1분 이내
모바일 광고 리포팅 (10분, 1시간, 1일 주기)
– Input: Ad@m 로그
– Output: 통계 데이터
– 실행시간: 4~5분, 2분 30초, 80분
26. 모바일 매체 토픽 분석 (1시간 주기)
– 매체별 광고의 클릭율 분석
– PC/모바일 광고 카테고리 분류
– 실행시간: 1분 이내
광고 카테고리 분석 (1~3시간 주기)
– 광고주나 랜딩 페이지에 따른 카테고리 분류
– PC: 3시간, 모바일:1시간 주기
– 실행시간: 10분 이내
29. 쇼핑 상품정보 (title) 클러스터링
– 상품id-상품title-상품category 형태의 base 데이터
생성이 필수
Hadoop 도입 효과
– 주기적 (일별) 데이터 추가 작업 필요
– 2억 row 이상의 상품정보 테이블 join 필요
– DB 작업이나 기타 다른 방식으로 일괄 처리시 큰 비용
부담임
30. 클릭 쿼리별 연관 분석
– 클릭쿼리와 카테고리간의 연관분석
– 쇼핑상품 클릭로그와 카테고리 정보를 결합(join)
Hadoop 도입 효과
– 대규모 데이터간의 결합(join) 및 집계
(Aggregation) 작업 부담
– 1년치 이상의 쇼핑클릭로그와 상품정보와의 결합 및
연관분석
• 로직 변경으로 기존의 데이터에 대해서 재계산이 필요한 상황
• 계절성을 고려하여 최소 1년 이상의 분석결과가 필요
31. (3) 다음 Top 토픽 분석
Top 화면에 제공할 콘텐츠의 토픽 분석
Hadoop 기반의 머신러닝 도구인
mahout 이용
32.
33.
34. Hadoop의 장단점
장점 : 빠르고 저렴하게 데이터 분석 가능
– 데이터를 바라 보는 관점의 차이 (저렴한 처리 비용)
– 샘플링이 필요 없음 (대용량 처리 가능)
– 운영 비용이 적음 (인프라 운영이 관리 가능)
– 분석도구나 프로그래밍 언어에 독립적임
– 다양한 지원 도구 (오픈소스 지원)
단점: 프로그래밍 방식의 변화 및 내재화 비용
– 설정 및 운영상의 내재화 작업이 필요
– 개념의 변화가 필요 (Map/Reduce 사고 전환)
– Hadoop은 계속 개선 중인 프로젝트임 (벤더 배포판 사용)
– 아직 구현되지 않은 부분이 많음(호환성이 낮은 편)
– 장애에 대한 대비 필요(메모리 및 네트웍 관련)
37. AD Search Listing
다음 통합 검색 쿼리: 6천만/일
외부 매체 포함 유입 쿼리 1.4억
Read Query: 2B/Day
Total Query: 2.5B/Day
38. From RDB to NoSQL
검색용DB
데이터 증가에 따른 한계점
– Oracle에서 불가능하다! MySQL에서 메모리 엔진 기반으로 운영
– “검색어- 광고목록”은 단순한 시스템
카산드라 선정 이유
– 검색 엔진의 데이터 구조와 유사
– 기타 NoSQL의 일반적 장점을 그대로 채용 가능
39. 카산드라의 장점
– 메모리가 우선이며 Read/Write 뿐 (업데이트가 없음)
– 단순한 Read Query에 대해 빠르게 응답 가능
– 주요 튜닝 지점
• 단순한 구조로 스키마 설계를 잘 해야 함
• 빠른 I/O 성능을 갖는 디스크 변경 및 RAID 설정 변경
• TCP 네트워크 조절 필요
• JVM 설정 튜닝도 필요
최근 Hbase의 사용 현황
– Hadoop을 사용하는 경우, 대부분 로그 저장소로 사용 중
– 2012년 상반기 부터는 안정성이 강화되고 있음
40. (2) 마이아고라
마이아고라는?
– 토론, 청원, 즐보드 등 아고라의
모든 글을 모아서 제공
– 총 데이터 6천만건 (2012.1)
문제점
– 짧은 시간에 너무 많은 데이터가
추가 되고 있음
해결 방법
– 데이터 입력 시간이 훨씬 짧은
NoSQL 솔루션 도입
Select Insert Update Delete
MySQL 355sec 250sec 317sec 310sec
MongoDB 294sec 60sec 153sec 123sec
<1백만건 MySQL과 MongoDB 데이터 처리 실험 결과>
41. MongoDB의 장점
– 문서 기반의 콘텐츠 데이터 저장에 유리
– 개발자 친화적인 (RDB) 기반 SQL을 그대로 사용할 수 있음
– MySQL과 비슷한 데이터 백업 및 복구 구조
– Replication: 안전성과 높은 가용성
– Auto-sharding : 분산확장(scale-out) 기능
주요 튜닝 사항
– 장애 시 쉽지 않은 데이터 복구
– 데이터가 없어지더라도 크게 상관(?) 없는 데이터에 활용
– 활용 함수에 따라 성능에 차이가 날 수 있음
• count() vs. cursor.size()
• update() vs. update($set)
42. Daum의 빅데이터 기술 전략
사내 기술 코디네이션
– 각 개발자가 Hadoop을 다양하게 활용할 아이디어 개발 및 실험
실행
– Hadoop을 테스트 해 볼 수 있는 클라우드 플랫폼 제공
– 실 서비스 투입 시 기존 운영팀으로 부터 노하우 전수
• 사내 세미나 및 교육 프로그램 운영
• Hadoop Expert를 중심으로 필요 시 노하우 제공
개발자 데이터 접근성 향상
– 데이터 분석가가 아닌 개발자가 직접 데이터에 접근 가능
– 기획자와 비즈니스에서 바로 의사 결정 가능
콘트롤 타워 보다는 분석 지원 및 인프라 운영 조직!
– 기술 진입 장벽을 낮추고 다양한 분석 아이디어 지원
43. 사내 개발자를 위한 Hadoop Farm
오픈 소스 CloudStack과 Hadoop 클러스터를 통한 유연한 분석용
온디멘드 작업 서비스 프로토타입 및 제공
- 가상 머신 활용 Hadoop 클러스터 생성
- 일정 관리 및 자동 할당 및 반납
- 초보자 및 전문가로 나누어 마법사 제공
- 다양한 샘플 작업 제시를 통한 작업 인지
44. Lessons for Big Data
기술 내재화가 중요 (No Vendors!)
– 개발자들이 직접 Hadoop을 활용할 수 있는 환경 필요
– 오픈 소스의 적극 활용 및 개발 잉여력 제공
데이터 분석 및 처리의 역할 파괴 (No Data Scientist!)
– 개발자들이 직접 실시간 분석을 위한 Hive 활용
– 문서, 이미지 등 다양한 형태의 데이터 처리를 위한 토대 마련
Small Data를 활용 강화 (No Big Mistakes!)
– Small Data라도 실시간으로 저렴하게 데이터를 처리하고,
– 처리된 데이터를 더 빠르고 쉽게 분석하도록 하여,
– 이를 비즈니스 의사결정에 바로 이용하는 것
– 이것이 바로 BigData 기술을 바른 활용임!