This slide was presented at Elasticsearch Seoul meetup

1. Web Analytics at Scale
with Elasticsearch @
naver.com – Part 1
허정수 / 네이버
jason.heo.sde@gmail.com

2. Agenda
• Introduction
• 콘텐츠소비통계
• Part I - Architecture
• Initial Architecture -> Problems & Solutions -> Proven Architecture
• Data Pipelines
• Part II - Lessons Learned
• 성능 개선 Tip
• 운영 Tip

3. Agenda
• Introduction
• 콘텐츠소비통계
• Part I - Architecture
• Initial Architecture -> Problems & Solutions -> Proven Architecture
• Data Pipelines
• Part II - Lessons Learned
• 성능 개선 Tip
• 운영 Tip
오늘은 여기까지만 발표합니다

4. 콘텐츠소비통계
회사 내부 직원용이 아닌,
네이버 사용자를 위한 서비스
네이버 블로그
(2016.06. 서비스 시작)
공통통계플랫폼
(2016.01. 개발 시작)
네이버 사용자
YYY 서비스
(2017.07. 서비스 예정)
다양한 네이버의 서비스들
OOO 서비스
(2016.09. 서비스 시작)
…
…

5. Goal
High
Throughput
Low
Latency

6. <블로그 프론트엔드>
<블로그 통계 메뉴>

7. https://www.slideshare.net/deview/215-67608986

8. Agenda
• Introduction
• Part I - Architecture
• Initial Architecture -> Problems & Solutions -> Proven Architecture
• Data Pipelines
• Part II - Lessons Learned

9. Lambda Architecture
source: http://lambda-architecture.net

10. Lambda Architecture
Pros: Can serve real-time analytics
Cons: Complex, needs different platforms for batch & speed layer
source: http://lambda-architecture.net

11. Initial Architecture
Elasticsearch
• Has Low Latency
• Has High Throughput
• Supports Aggregation Query
Elasticsearch 하나로 Batch Layer와 Speed Layer를 모두 구현해보자!

12. Initial Architecture
KafkaLogstash Storm Hot Boxes
(Raw Data)
Warm Boxes
(pre-aggregated Data)
MapReduce
(Nightly Batch Job)
Single Large ES Cluster (60 nodes)
Node.js
End User

13. Pros of Initial Architecture
Simple
Architecture
Reduced
Platforms
Simple
Data Pipelines

14. Problems
Worked fine with
small data sets
and a small cluster
Problems arose
after large data sets
were gathered
Only 1 month left until open
Today, share the stories
• how we built a proven architecture with Elasticsearch.
• how we solved the issues

15. Problems
• es-hadoop
• es-hadoop MR supports max 31 http-enabled nodes
• ES is not good for the Data Source for pre-aggregation
• MapReduce
• cumbersome
• intermediate data size is big
• slow
• Storm
• Could be difficult to achieve exactly-once

16. es-hadoop MR supports max 31 http-enabled nodes
PowerSet(Set<E> set) {
// any number higher than this triggers a size bigger than Integer.MAX_VALUE
Assert.isTrue(set.size() < 32, "Too many elements to create a power set " + set.size());
input = new LinkedHashMap<E, Integer>(set.size());
int i = set.size();
for (E e : set) {
input.put(e, Integer.valueOf(i--));
}
}
https://github.com/elastic/elasticsearch-hadoop/blob/2.3/mr/src/main/java/org/elasticsearch/hadoop/rest/ShardSorter.java#L194
Solution1: Operate with less than 31 http-enabled nodes
Cons: The architecture gets more complex
Solution 2: Do not use MapReduce with es-hadoop
Problem: Which platform is appropriate?

17. ES is not good for Data Source for Aggregation
Full scan with es-hadoop is slow.
• Fast Random Access is not important for pre-aggregation
• Fast full scan is required for pre-aggregation
958초 vs 1.8초
ES Hadoop Parquet
- 80 shards
- 80 parquet files
- 80 workers
sqlContext.read.format("org.elasticsearch.spark.sql").
load("index_name").registerTempTable("logs")
sqlContext.sql("SELECT COUNT(*) FROM logs").show
sqlContext.read.parquet("path/to/parquet").registerTempTable("logs")
sqlContext.sql("SELECT COUNT(*) FROM logs").show
4.2억건 단순 COUNT

18. ES is not good for Data Source for Aggregation
ES node
ES Data File
ES
file readYarn Node
Worker
HTTP Transport
Layer
ES
Coordinator
Node
Data node
Parquet
Worker
file read
<read using es-hadoop> <read using parquet>
json
encode/
decode

19. ES is not good for Data Source for Aggregation
ES Index size is big (compared to Parquet)
200GB vs 32GB
ES index size Parquet
Needs more disk space to save data
Needs more disk reads to pre-aggregate

20. Problems – MapReduce & Storm
• MapReduce
• coding is cumbersome or time-consuming
• slow
• Intermediate data size is big
• 20TB is needed for intermediate data to aggregate monthly data
• 8 times bigger than Spark
• Storm
• Had a hard time achieving exactly-once
• Solution
• used SparkSQL & Spark Streaming instead of MapReduce and Storm

21. SparkSQL is easy, intuitive, and fast to aggregate
sqlContext.read.parquet("...").registerTempTable("logs")
sqlContext.sql("
SELECT c, u, g, a, COUNT(*) AS pv
FROM logs
GROUP BY c, u, g, a
").saveToEs("index_name/doc_type")
<snippet of mapper code> <SparkSQL>

22. Proven Architecture
Kafka 1
(Raw Log)
Kafka 2
(Refined Log)Transform
Realtime
ESLoader
Parquet
Loader
Scoreboard
Loader
Logstash
nginx
access log
Realtime
ES Cluster
Batch
ES Cluster
Parquet
Files
nBase-ARC
(Redis Cluster)
SparkSQL
Node.jsEnd Users
SparkSQL
Impala
업무
요청
&
내부
지표Zeppelin

23. Data Pipelines - Ingestion
Kafka 1
(Raw Log)
Logstash
nginx
access log Exactly-Once is important
• id field is generated in nginx access log
• Logstash options (described in Part II)
• File Input
• Kafka Output

24. Data Pipelines – Spark Streaming 1 - Transform
Kafka 1
(Raw Log)
Transform Kafka 2
(Refined Log)
Transform is a Spark Streaming Job
• Cleansing
• Session Management
• 기타 비지니스 로직들…

25. Data Pipelines – Spark Streaming 2 - Loaders
Realtime
ESLoader
Parquet
Loader
Scoreboard
Loader
Realtime
ES Cluster
Parquet
File
nBase-ARC
(Redis Cluster)
Kafka 2
(Refined logs)
3 Spark Streaming Jobs which loads refined logs to
1. Realtime Elasticsearch
- serves today's metrics
2. nBase-ARC
- act as cache for ES
3. Parquet
- input of pre-aggregation

26. Data Pipelines – Serving Realtime Requests
Realtime
ES Cluster
nBase-ARC
(Redis Cluster)
Node.jsEnd Users

27. Data Pipelines – Serving Realtime Requests
<블로그 프론트엔드>
<블로그 통계메뉴 – 오늘 지표>

28. Data Pipelines – SparkSQL – Batch Job
Batch
ES Cluster
Parquet
File
SparkSQL
Pre-aggregation
• Job reads parquet files
• Load the result to Batch ES Cluster

29. Data Pipelines – Serving pre-aggregated Data
Batch
ES Cluster
Node.jsEnd Users
블로그 조회수 화면
<블로그 통계 메뉴>

30. Data Pipelines – 업무 요청 & 내부 지표
서비스 운영자
예) 최근 한달
조회수 높은 순
블로거 목록 요청

31. Data Pipelines – 업무 요청 & 내부 지표
Parquet
Files
SparkSQL
Impala
Zeppelin
서비스 운영자
예) 최근 한달
조회수 높은 순
블로거 목록 요청

32. Data Pipelines – 업무 요청 & 내부 지표
Parquet
Files
SparkSQL
Impala
Zeppelin
서비스 운영자
예) 최근 한달
조회수 높은 순
블로거 목록 요청
장점
• 서비스 중인 ES에 부하가 없다
• 원본 Data를 오래 보관할 수 있다
• pre-aggregation되지 않은 다양한 지료를 추출할 수 있다

33. Agenda
• Introduction
• Part I - Architecture
• Part II - Lessons Learned
• 성능 개선 Tip
• 운영 Tip

34. Agenda
• Introduction
• Part I - Architecture
• Part II - Lessons Learned
• 성능 개선 Tip
• 운영 Tip
다음 시간에…

35. Versions
1. Elasticsearch 2.3 & es-hadoop 2.3
2. Logstash 2.1
3. Spark 1.6
4. JDK 1.8 for ES, 1.7 for Spark
5. CDH 5.8
6. Storm 0.10
7. CentOS 7.2
8. Kafka 0.9
9. nBase-ARC 1.3

36. Part I 요약
• Elasticsearch 정말 좋습니다
• Low Latency, High Throughput
• 쉬운 클러스터 운영, 안정성
• Logstash, Kibana, Marvel, …
• 빠른 입수 속도
• 다양한 질의, Aggregation 함수
• 하지만…

37. Part I 요약
• Elasticsearch 정말 좋습니다
• Low Latency, High Throughput
• 쉬운 클러스터 운영, 안정성
• Logstash, Kibana, Marvel, …
• 빠른 입수 속도
• 다양한 Aggregation 함수
• 하지만…
• No Silver Bullet https://www.projectsmart.co.uk/project-methodologies-not-a-silver-bullet.php

38. Part I 재미있게 들으셨나요?
네이버 별거 아니라 생각들고,
이것보다 더 잘 만들 자신있으신 분께서는!

39. We will be hiring
jason.heo.sde+hire.me@gmail.com
이력서 (자유양식)
2017.06 현재 오픈된 포지션은 없습니다
(메일 주신 분은 개인정보 제공에 동의한 것으로 간주합니다)

40. Q&A

41. 사전 질문
• 질문1) "최적화 하신 방법들"
• 8월 meetup에서 설명드리겠습니다
• 최초 응답 시간 40% 줄이기
• Index size 줄이는 Tip 2가지
• execution_hint 설정에 따른 응답 속도
• throughput 늘린 사례 (특정 조건 한)
• Heap 사용량 Tuning
• 기타 다양한 운영 Tip들

42. 사전 질문
• 질문2)"대용량 데이터 통계 시스템을 구축하면서 데이터가 많아짐에
따라 겪으셨던 시행착오가 궁금합니다"
• 초기 아키텍처에서 현재 아키텍처로 변한 부분에서 설명됨
• 웹의 특성상 Cardinality가 높다
• pre-aggregation의 효과가 크지 않음
• 예) 똑같이 하루 1억 PV더라도, unique 문서가 10만개인 상황과 1,000만개인 상황은
완전 다름
• 예) Referrer, 유입 키워드, 방문자 수
• 아직 풀지 못한 문제
• Heap 사용량 증가 현상
• 다차원 분석
• pre-aggregation vs on-demand