Daum 분산 스토리지의 증가
100,000
50GB
25GB
10,000
1GB
1,000
100MB
100
2004 2006 2012
분산 파일 시스템: 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)
미지원 디렉토리 구조 지원함
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)
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
Hadoop 기반 광고 로그 분석
광고 로그 및 통계 처리, 매체 토픽 분류 및 과거 로그 데
이터를 기반으로 광고 집행 타켓팅 분석
• input: 과거 집행(노출, 클릭) 로그 데이터 ( 필요에 따라 일,
주, 월 단위 로그 사용)
• output 광고에 대한 사용자별 노출 내역 통계 처리
기존 분석 프로세스
– 데이터 복사 ▶ 파싱 ▶ 필터링 ▶분석
– Raw data ▶ SAS파일 : 약 10시간 (데이터 복사시간 제외)
– Query count : 약 6시간 (1일 데이터)
Hadoop을 이용한 분석 프로세스
– 데이터 ▶ 분석
– 1일 데이터 처리 : 1.5시간
분석 속도 증가
Hadoop 도입 전
Hadoop 도입 후
시간당 분석 일 로그 분석
기존 방식에 비해 10~25%의 시간에 처리 가능
실시간으로 10분 단위 분석 가능
Hive: SQL을 통한 쉬운 분석
selelct keyword, count(distinct adid)
from ad_log
where dt='20120101' and hr='10' and mi= ‘10'
group by serviceId, mi
실시간 비즈니스 분석
모바일 광고 타게팅 로그 분석 (10분 주기)
– Input: 광고ID, 사용자프로필, 노출/클릭
– Output: 광고ID, 프로필별 인덱스
– 실행시간: 1분 이내
모바일 광고 리포팅 (10분, 1시간, 1일 주기)
– Input: Ad@m 로그
– Output: 통계 데이터
– 실행시간: 4~5분, 2분 30초, 80분
모바일 매체 토픽 분석 (1시간 주기)
– 매체별 광고의 클릭율 분석
– PC/모바일 광고 카테고리 분류
– 실행시간: 1분 이내
광고 카테고리 분석 (1~3시간 주기)
– 광고주나 랜딩 페이지에 따른 카테고리 분류
– PC: 3시간, 모바일:1시간 주기
– 실행시간: 10분 이내
쇼핑 상품정보 (title) 클러스터링
– 상품id-상품title-상품category 형태의 base 데이터
생성이 필수
Hadoop 도입 효과
– 주기적 (일별) 데이터 추가 작업 필요
– 2억 row 이상의 상품정보 테이블 join 필요
– DB 작업이나 기타 다른 방식으로 일괄 처리시 큰 비용
부담임
클릭 쿼리별 연관 분석
– 클릭쿼리와 카테고리간의 연관분석
– 쇼핑상품 클릭로그와 카테고리 정보를 결합(join)
Hadoop 도입 효과
– 대규모 데이터간의 결합(join) 및 집계
(Aggregation) 작업 부담
– 1년치 이상의 쇼핑클릭로그와 상품정보와의 결합 및
연관분석
• 로직 변경으로 기존의 데이터에 대해서 재계산이 필요한 상황
• 계절성을 고려하여 최소 1년 이상의 분석결과가 필요
(3) 다음 Top 토픽 분석
Top 화면에 제공할 콘텐츠의 토픽 분석
Hadoop 기반의 머신러닝 도구인
mahout 이용
Hadoop의 장단점
장점 : 빠르고 저렴하게 데이터 분석 가능
– 데이터를 바라 보는 관점의 차이 (저렴한 처리 비용)
– 샘플링이 필요 없음 (대용량 처리 가능)
– 운영 비용이 적음 (인프라 운영이 관리 가능)
– 분석도구나 프로그래밍 언어에 독립적임
– 다양한 지원 도구 (오픈소스 지원)
단점: 프로그래밍 방식의 변화 및 내재화 비용
– 설정 및 운영상의 내재화 작업이 필요
– 개념의 변화가 필요 (Map/Reduce 사고 전환)
– Hadoop은 계속 개선 중인 프로젝트임 (벤더 배포판 사용)
– 아직 구현되지 않은 부분이 많음(호환성이 낮은 편)
– 장애에 대한 대비 필요(메모리 및 네트웍 관련)
AD Search Listing
다음 통합 검색 쿼리: 6천만/일
외부 매체 포함 유입 쿼리 1.4억
Read Query: 2B/Day
Total Query: 2.5B/Day
From RDB to NoSQL
검색용DB
데이터 증가에 따른 한계점
– Oracle에서 불가능하다! MySQL에서 메모리 엔진 기반으로 운영
– “검색어- 광고목록”은 단순한 시스템
카산드라 선정 이유
– 검색 엔진의 데이터 구조와 유사
– 기타 NoSQL의 일반적 장점을 그대로 채용 가능
카산드라의 장점
– 메모리가 우선이며 Read/Write 뿐 (업데이트가 없음)
– 단순한 Read Query에 대해 빠르게 응답 가능
– 주요 튜닝 지점
• 단순한 구조로 스키마 설계를 잘 해야 함
• 빠른 I/O 성능을 갖는 디스크 변경 및 RAID 설정 변경
• TCP 네트워크 조절 필요
• JVM 설정 튜닝도 필요
최근 Hbase의 사용 현황
– Hadoop을 사용하는 경우, 대부분 로그 저장소로 사용 중
– 2012년 상반기 부터는 안정성이 강화되고 있음
(2) 마이아고라
마이아고라는?
– 토론, 청원, 즐보드 등 아고라의
모든 글을 모아서 제공
– 총 데이터 6천만건 (2012.1)
문제점
– 짧은 시간에 너무 많은 데이터가
추가 되고 있음
해결 방법
– 데이터 입력 시간이 훨씬 짧은
NoSQL 솔루션 도입
Select Insert Update Delete
MySQL 355sec 250sec 317sec 310sec
MongoDB 294sec 60sec 153sec 123sec
<1백만건 MySQL과 MongoDB 데이터 처리 실험 결과>
MongoDB의 장점
– 문서 기반의 콘텐츠 데이터 저장에 유리
– 개발자 친화적인 (RDB) 기반 SQL을 그대로 사용할 수 있음
– MySQL과 비슷한 데이터 백업 및 복구 구조
– Replication: 안전성과 높은 가용성
– Auto-sharding : 분산확장(scale-out) 기능
주요 튜닝 사항
– 장애 시 쉽지 않은 데이터 복구
– 데이터가 없어지더라도 크게 상관(?) 없는 데이터에 활용
– 활용 함수에 따라 성능에 차이가 날 수 있음
• count() vs. cursor.size()
• update() vs. update($set)
Daum의 빅데이터 기술 전략
사내 기술 코디네이션
– 각 개발자가 Hadoop을 다양하게 활용할 아이디어 개발 및 실험
실행
– Hadoop을 테스트 해 볼 수 있는 클라우드 플랫폼 제공
– 실 서비스 투입 시 기존 운영팀으로 부터 노하우 전수
• 사내 세미나 및 교육 프로그램 운영
• Hadoop Expert를 중심으로 필요 시 노하우 제공
개발자 데이터 접근성 향상
– 데이터 분석가가 아닌 개발자가 직접 데이터에 접근 가능
– 기획자와 비즈니스에서 바로 의사 결정 가능
콘트롤 타워 보다는 분석 지원 및 인프라 운영 조직!
– 기술 진입 장벽을 낮추고 다양한 분석 아이디어 지원
사내 개발자를 위한 Hadoop Farm
오픈 소스 CloudStack과 Hadoop 클러스터를 통한 유연한 분석용
온디멘드 작업 서비스 프로토타입 및 제공
- 가상 머신 활용 Hadoop 클러스터 생성
- 일정 관리 및 자동 할당 및 반납
- 초보자 및 전문가로 나누어 마법사 제공
- 다양한 샘플 작업 제시를 통한 작업 인지
Lessons for Big Data
기술 내재화가 중요 (No Vendors!)
– 개발자들이 직접 Hadoop을 활용할 수 있는 환경 필요
– 오픈 소스의 적극 활용 및 개발 잉여력 제공
데이터 분석 및 처리의 역할 파괴 (No Data Scientist!)
– 개발자들이 직접 실시간 분석을 위한 Hive 활용
– 문서, 이미지 등 다양한 형태의 데이터 처리를 위한 토대 마련
Small Data를 활용 강화 (No Big Mistakes!)
– Small Data라도 실시간으로 저렴하게 데이터를 처리하고,
– 처리된 데이터를 더 빠르고 쉽게 분석하도록 하여,
– 이를 비즈니스 의사결정에 바로 이용하는 것
– 이것이 바로 BigData 기술을 바른 활용임!