1.
OLAP for Big Data
freepsw
2017. 05
1

2.
기존 Hadoop기반 분석의 한계
freepsw 2
대용량의 데이터 조회 성능 (Table scan 비용)
Table Join 성능 (Data shuffling으로 인한 성능저하)
다양한 granularity 기반의 분석 한계 (실행시점의 합계 비용)
Map Reduce job / Spark job (배치 기반의 job 실행)
OLAP영역에서 hadoop기반 query성능 향상에 초점

3.
분산 OLAP
freepsw 3
Event 데이터 기반의 OLAP
Hadoop 기반 OLAP
다양한 차원의 분석 필요
기존 OLAP처럼 쓸수 있을까?
Druid, Kylin, Lens
분산 파일 시스템 (HDFS)
리소스 관리 (YARN)
배치처리 (MapReduce)
분석 (SQL on Hadoop)
NoSQL
NewSQL
수집기술
실시간 처리
운영관리 도구
OLAP

4.
Druid vs kylin vs lens ­ 1 (kor)
freepsw 4
HDFS
Druid
실시간 OLAP 분석
실시간 stream
오래된 데이터는 HDFS로 복제
(Hive query 불가)
Kylin Lens
대용량 OLAP 분석
Cube 생성
HBASE
Cube 조회
Hive Driver
JDBC Driver
ES Driver
여러 관점(성능, 활용, 접근성)별로 특화하여 기능 구현
단일화된 분석 채널 제공
segments

5.
Druid vs kylin vs lens ­ 1 (eng)
freepsw 5
HDFS
Druid
Realtime OLAP
realtime stream
Replicate old data to HDFS
(can’t query using Hive )
Kylin Lens
Massive OLAP analysis
Create Cube
HBASE
Search Cube
Hive Driver
JDBC Driver
ES Driver
Each sw specialized by their perspectives
Provide Unified channel
segments

6.
freepsw 6
성능(속도)
SQL지원
Fault Tolerance
BI 연동
레퍼런스
Druid Kylin Lens
엄청 빠름 빠름 원본 소스에 영향
limited support
(V0.10.0) 지원 X(SQL Like)
모든 Node 별도 설정 별도 설정
X
(limited support)
Tableau 등 JDBC로 연동 가능
Airbnb 등 다수 Ebay 등 다수 -
Druid vs kylin vs lens ­ 2(kor)

7.
freepsw 7
Query speed
SQL support
Fault Tolerance
BI integration
Powered by
Druid Kylin Lens
Very fast fast Depends on
source
limited support
(V0.10.0)
support X (SQL Like)
all Node Need to setup Need to setup
X
(limited support)
O (Tableau …) O
Airbnb,
Alibaba…
Ebay, Yahoo
japan…
-
Druid vs kylin vs lens ­ 2(eng)

8.
Druid
freepsw 8

9.
Druid 특징
freepsw 9

10.
언제 Druid를 적용해야 할까?
freepsw 10
• 빠르게 값을 집계(roll up)하면서 탐색적 분석을 해야 하는 경우
• 데이터가 입력되는 동시에 실시간으로 분석하려고 하는 경우
• 엄청난 대용량 데이터가 있는 경우 (trillions of events, petabytes
of data)
• 항상 가용성을 보장하는 데이터 저장소가 필요한 경우 (hdfs와는 다른가?)

11.
Druid의 구성
freepsw 11
모든 데이터는 3Timestamp, Dimension, measure 필요
Timestamp : 모든 query는 time 축을 기반으로 실행
Dimension : event의 string 속성들 (지역, 부서 등), 위 예시에서는 4개 차원 존재
Metric : 실제 집계할 칼럼. 보통 float와 같은 수치값들이 저장됨

12.
Druid의 핵심기능 (1) ­ roll up
freepsw 12
Druid는 데이터가 수집되는 순간 집계하여 빠른 분석이 가능
이렇게 입력되면서 데이터를 집계하면, 데이터 저장공간이 엄청나게 줄어든다.
동시에 원본의 데이터도 집계시간 단위로 합쳐지게 된다. (즉 raw data는 확인
불가)

13.
freepsw 13
Druid의 핵심기능 (2) ­ Sharding the Data
데이터가 입력되는 순간 time단위로 데이터를 sharding한다.
이렇게 sharding 된 데이터를 segment라고 함.
Druid Query는 segment를 scan한다.

14.
freepsw 14
Druid의 핵심기능 (3) ­ Indexing the Data
분석 query에 최적화된 데이터 구조로 저장하여 속도를 향상시
킨다.
Column 기반 저장구조
Query에 사용되는 column만 유지 가능
Column별로 다른 압축 알고리즘 선택 가능
Segment 단위로 index를 관리

15.
freepsw 15
Druid의 핵심기능 (4) ­ Loading the Data
분석 query에 최적화된 데이터 구조로 저장하여 속도를 향상시
킨다.
Real-time
- 실시간 수집에 최적화 되어 있음.
- Exactly once는 지원하지 않음 (추후 지원)
batch - Exactly once를 지원하는 수집
최신의 데이터는 real time으로 분석하고, 중요한 데이터는 batch로 저장하여 분
석하는 것이 좋음.

16.
Druid의 핵심기능 (5) ­ Querying the Data
freepsw 16
SQL은 지원하지 않으며, 여러 테이블을 join 할 수 없다.
Json over HTTP를 이용한 query
다양한 query library 지원 (http://druid.io/libraries.html)
단일 table query를 지원
- Druid에 적재되기 전에 비정규화를 통해서 join이 필요없도록 전처리 필요

17.
Druid 아키텍처 ­ cluster 구성
freepsw 17
Cluster의 구성요소 및 데이터 흐름
Indexing
service
Indexing
service

18.
Druid 아키텍처 ­ cluster 구성
freepsw 18
Historical Node
- local에 저장된 segment에 대한 query 제공
- Node간 segment에 대해 공유하지 않음 (shared nothing)
Broker Node - Client의 query를 받아서 결과를 제공하는 노드
- 어떤 segment가 정상상태이고, 어디에 있는지 알고 있음.
각 node는 소규모 기능을 가장 잘 할 수 잇도록 구성되었다.
Coordinator Node - Historical node에 있는 segment를 관리
- Segment의 이동/삭제/생성을 historical node에 지시
Indexing service - Query 속도를 높이기 위하여 column format 으로 변환
- Bitmap index 생성 및 데이터 압축 à segment 로 저장
Real-time Processing - 데이터를 수집하고, indexing하여 query서비스를 제공한다.
- 정해진 시간단위로 segment를 생성하여 historical node로 전달한다.

19.
freepsw 19
Druid 아키텍처 ­ Indexing Service
Indexing service는 segment를 생성하거나,
삭제하는 역할
1) Peon : 단위 task를 수행하는 프로세스
2) Middle Manager : peon을 관리하는 프
로세스
3) Overload : middle manager에게 단
위 task의 분배관리
Peon과 middle manager는 반드시 동일한
node에서 실행되어야 함.

20.
freepsw 20
Druid 아키텍처 ­ Segment and storage
1) 데이터 입력시 indexing
처리 (segment 생성)
2) Segment를 Deep
storage에 저장
3) Historical node에 의
해서 segment를 local
disk에 저장
4) Local의 segment를
memory에 로딩
5) Query service 제공

21.
21
Druid 아키텍처 ­ Granularity
https://blog.codecentric.de/en/2016/08/realtime-fast-data-analytics-druid/
Granularity에 따라서 segment 개수 및 데이터 size 결정
Segment
- Segment file의 생성 단위
- Day로 설정한 경우 1개 segment
- Minute인 경우 2개 segment
Query
- 데이터 Roll up 단위
- Minute인 경우 3개 row로 축소
- Disk/memory 사이즈 절약
freepsw

22.
Druid 아키텍처 ­ Metadata Storage
freepsw 22
System에 대한 메타정보를 관리하는 용도 (mysql, postgreSQL)
Derby가 기본 storage이지만, 제품화 단계에서는 mysql or PostgreSQL
Segments Table
- Segment 정보 관리
- Coordinator에 의해
query가능한 segment 정보
관리
Rule Table
- Coordinator가 segment를
어떻게 배치할지에 대한
rule 관리
Task-related Table
- Indexing service의 작업과
정에서 생성되 데이터 저장

23.
Druid 아키텍처 ­Fault Tolerance 방안
23
Historical Node
- 장애 발생시 다른 historical node가 deep storage에 저장된 데이
터를 로딩하여 서비스
Coordinator Node - Hot fail-over가 가능하도록 설정 가능
- 모든 노드가 다운되면, 데이터 변경사항만 기록이 안되고, 서비스는 정상
Broker Node - 병렬로 실행하거나 hot fail-over로 구성 가능
Deep storage - 새로운 데이터가 적재되지 못함. (서비스는 정상 동작)
Real-time Processing
- 동일한 스트림을 병렬로 처리가능
- Check point를 deep storage에 저장하여 복구 가능
- 만약 check point 저장시 문제가 생기면 유실 가능
Node가 다운되더라도 저장된 데이터에 대한 서비스는 정상동작
freepsw

24.
Druid 아키텍처 ­언제 데이터를 메모리에 로딩할까?
freepsw 24
Cache at historical nodes
Cache at broker nodes
Page cache (OS에서 관리)
3가지 level의 memory cache가 존재
- 데이터가 수집되는 즉시 메모이에 올리기 위해서는 약간의 trick이 필요함.
- 입력되는 데이터를 조회하는 dummy sql을 실행하는 방식

25.
Druid 개발에 필요한 것들
freepsw 25

26.
Druid기반의 솔루션은 있을까?
freepsw 26
https://imply.io/

27.
freepsw 27
Imply 기능 구성
Technical architecture

28.
freepsw 28
Imply Pivot 예시

29.
Imply Pivot 예시
freepsw 29

30.
Druid 설치해 보자.
freepsw 30
docker로 생성된 이미지를 이용해 single node로 설치
Ø git clone https://github.com/cimatech/druid-container.git
Ø docker-compose up
Ø docker ps

31.
Druid에서 제공하는 관리화면
freepsw 31

32.
Data를 loading해 보자. (File)
freepsw 32
Loading할 Schema를 생성하고, 데이터를 로딩한다.
Ø curl -O http://static.druid.io/artifacts/releases/druid-0.9.2-bin.tar.gz
Ø tar xzf druid-0.9.2-bin.tar.gz
Ø cd druid-0.9.2
Ø curl -X 'POST' -H 'Content-Type:application/json' -d
@quickstart/wikiticker-index.json localhost:4000/druid/indexer/v1/task

33.
Data를 query하는 방법은.. (1) json
freepsw 33
curl -L -H'Content-Type: application/json' -XPOST --data-binary @quickstart/wikiticker-
top-pages.json http://localhost:8082/druid/v2/?pretty

34.
freepsw 34
Data를 query하는 방법은.. (2) PlyQL
SQL방식과 유사하게 Query할 수 있는 오픈소스
https://github.com/implydata/plyql
http://plywood.imply.io/plyql

35.
freepsw 35
Data를 loading해 보자. (Stream)
Stream 데이터를 수집하는 별도의 sw를 이용하여 입력
curl -XPOST -H'Content-Type: application/json' --data-binary @pageviews.json
http://localhost:8200/v1/post/pageviews
1. 수집서버 구동
2. POST방식으로 데이터 입력

36.
freepsw 36
Apache Kylin

37.
Apache Kylin
freepsw 37
E-bay에서 2014.10 오픈소스화한 Hadoop-SQL기반 OLAP
Druid
와 차이

38.
Kylin의 영역
freepsw 38
OLAP영역에서 hadoop기반 query성능 향상에 초점

39.
39
Kylin 아키텍처
API를 통해 요청받은 job을 Hive로 구동하고, 결과 cube를 hbase에 저장
- Tomcat으로 구성되어 구동이 간편하다
- Cube 생성시 Memory를 많이 사용하게 되는 구조 (JVM GC 옵션을 잘 관리하는 것이 필요)freepsw

40.
Kylin으로 Cube를 만들어 보자
freepsw 40
Web UI를 이용하여 cube를 생성한다.
Project
• Project단위로 여러개의 Model을 관리
• 사용할 Hive Table을 지정해 준다.
Model • Cube에 필요한 모델(스타스키마)을 구성한다.
Cube • Dimension, measure 등을 지정한다.

41.
어떻게 Cube를 생성할까?
freepsw 41
HIVE
Kylin
1) Cube를 생성할 Table 선택
MapReduce
2) Cube의
dimension/measure 지정
HBase
3) Dimension별로 measure 합산
HDFS
(중간파일 임시저장)
4) 최종 cube를 저장 및 조회

42.
Cube 생성 job 모니터링
freepsw 42

43.
자. 그럼 얼마나 빠를까?
freepsw 43
10,000건 데이터를 기준으로 2.5 배 정도 빠른데... 너무 당연한 결과
Kylin (1.76 sec)
Hive (4.56 sec)

44.
자. 그럼 얼마나 빠를까?
freepsw 44
Kylin (0.12 sec)
Hive (103 sec)
10억건 데이터를 기준으로 850 배 정도 빠르다. (Cardinality 3)

45.
자. 그럼 얼마나 빠를까?
freepsw 45
Kylin (0.18 sec)
Hive (125 sec)
10억건 데이터를 기준으로 690 배 정도 빠르다. (Cardinality 2,400)

46.
Kylin 활용시 고려사항
freepsw 46
너무 많은 dimension은 차원의 조합이 지수적으로 증가함
높은 cardinality는 cube의 사이즈를 과도하게 증가시킴
Cube 정보를 최신데이터로 갱신하는 프로세스를 고려해야 함.
Hive 기반으로 cube를 생성해야만 query가 가능한 구조

47.
Kylin을 활용한 솔루션 (Kyligence Analytics Platform)
freepsw 47http://kyligence.io/en/

48.
Kyligence 아키텍처
freepsw 48
Kafka/spark를 통해 streaming 데이터의 cube 생성

49.
Apache Lens
freepsw 49
Unified OLAP on Realtime and Batch Data
(2014 Apache Incubator)

50.
Apache Lens의 등장배경
freepsw 50
동일한 데이터의 용도에 따라 다양한 분석 시스템이 존재하게 됨.
시스템의 복잡도 증가
데이터 일관성 유지 어려움
대량의 데이터 이동(복제)
Data Silo 현상
접근방식 서로 다름
데이터 모델 서로 다름

51.
Apache Lens의 장점
freepsw 51
모든 데이터를 동일한 방식으로 접근하고,
다양한 query별로 cost와 성능관점으로 선택할 수 있는 기능 제공

52.
Hadoop Eco에서 Lens 의 position
freepsw 52
다양한 query Engine들의 상위에서 OLAP을 지원하는 Layer

53.
Apache Lens 적용시 고려사항
freepsw 53
실제 business에 적용된 사례가 거의 없음
Github의 commit 통계도 낮으며, 발전속도가 느림.
실제 프로젝트에 적용하기에는 검증되어야 할 사항이 많아 보임.
2015년 9월에 Apache Top level project로 선정

54.
[back up] olap 용어
freepsw 54

55.
Kylin Cube의 구성
freepsw 55
필요한 dimension별로 cuboid를 생성하여 관리

56.
기존 RDBMS에서 cube생성 방식
freepsw 56
Cube가 없이 rdbms에서 동일한 결과를 내기 위해서는 수많은
aggregation이 필요

57.
Apache kylin
freepsw 57

58.
Apache kylin - Cube Build job flow
freepsw 58

59.
Apache kylin
freepsw 59