View
6.568
Download
3
Category
Preview:
Citation preview
증분 처리 플랫폼Cana 개발기
김영준NAVER 검색솔루션개발랩
contents
Cana 소개 / 증분 처리 개요HBaseSI + HBase Coprocessor 기반 구현Omid + Storm Topology 기반 구현Cana Tx + Cana Reactor트랜잭션 성능 / 적용 사례 / 남은 과제 / 유사 솔루션
Cana 소개 /증분 처리 개요
Cana 소개
HBase와 Storm 기반의 증분 처리 플랫폼
검색 증분화 프로젝트 BREW의 하위 프로젝트로 2012년에 시작
문서 정제 증분 처리용 플랫폼을 만드는 것이 목표
수집 정제 색인 서빙
Cana BREW4
A B Sum
R1 10 20 30
R2 7 12 19
R3 … … …
… … … …
… … … …
Total - - 500
증분 처리 개요
(R1, A) = 30
다시 계산해야 할 부분
5
증분 처리 개요
다시 계산할 필요가 없는것도 모두 계산해야 함
배치처리– 긴 반영 시간, 비효율적6
재처리 대상
A B Sum
R1 10 20 30
R2 7 12 19
R3 … … …
… … … …
… … … …
Total - - 500
증분 처리 개요
A B Sum
R1 10 20 30
R2 7 12 19
R3 … … …
… … … …
… … … …
Total - - 500
(R1,A)←30
7
Sum = A + B
Total =∑Sum
(R1,Sum)←50
(Total,Sum)←520
증분처리– 짧은 반영 시간, 효율적
증분 처리 개요
A B Sum
R1 10 20 30
R2 7 12 19
R3 … … …
… … … …
… … … …
Total - - 500
8
Transaction
TransactionTransaction
Event Notification
증분 처리 개요
대용량 갱신 연산 트랜잭션
RDBMS X O O
Hadoop O X X
NoSQL O O Single-Row
데이터저장소후보
Multi-Row 트랜잭션9
증분 처리 개요
무결성 동시성
Serializable Read Uncommitted
트랜잭션의 Isolation Level
10
Snapshot Isolation
높은 무결성을 보장하면서 동시성도 우수한 Isolation LevelTimestamp Oracle과 Multi-Version Data Store 필요
Write(A, 1)
Read(A) == 1, Write(A, 2)
Read(A) == 1, Write(A, 3)
Read(A) == 2
t
Start TS
Write-Write Conflict
11
Commit TS
HBase
대표적인 NoSQL로 Single-Row 트랜잭션만 지원
사내에서 데이터 저장용으로 많이 사용
Snapshot Isolation 구현에 필요한 Multi-Version 기능 제공
12
Cana 프로젝트의 ‘구체적인’ 목표
HBase 위에 Snapshot Isolation 트랜잭션구현
+Event Notification 기능 구현
13
HBaseSI + HBase Coprocessor기반 구현
15
HBaseSI논문기반Coprocessor기반
OmidStorm Topology 기반
Cana TxCana Reactor
Early 2012
Mid 2012
Mid 2013
HBaseSI
HBase 위에 Snapshot Isolation 트랜잭션을 구현한 논문(link)여기에 기반하여 트랜잭션 라이브러리를 구현
Client
Counter Tables(Timestamp Oracle)
DataTable
incrementColumnValue()
commitwrite
CommitRequestQueue
CommitQueue
Committed
16
HBase Coprocessor
HBase 프로세스 내에서 원하는 동작을 실행하는 기능(HBase 0.92에 추가됨)
<Region>put()
<RegionObserver>
postPut()prePut()
17
RegionObserver Coprocessor 구현
기본동작1. put()이 실행되었다는 Event를 postPut()으로 감지
2. 감지된 Event는 RegionObserver 내의 큐에 넣음
3. RegionObserver 내의 스레드에서 큐의 Event를하나씩 꺼내어 관련 트랜잭션 로직 실행
4. 트랜잭션 로직에서 put()이 실행되면 위 과정이 반복
18
RegionObserver Coprocessor 구현
Storage
Sum=A+B
RegionObserver
Total=∑Sum
Region Server
(R1, A) = 30(R1, A) 변경
(R1, Sum) = 50
postPut()App
19
RegionObserver Coprocessor 구현
Storage
Sum=A+B
Total=∑Sum
Region Server
RegionObserver
(R1, Sum) 변경
(Total, Sum) = 520
postPut()
20
특정테이블에요청이집중되어 트랜잭션 성능이 떨어짐21
CommitRequestQueue
Client
Counter Tables(Timestamp Oracle)
CommitQueue
Committed
Client
Client
Hot Spot
HBaseSI 구현의 문제점
Coprocessor 구현의 문제점
어플리케이션의문제가 Region Server에바로영향을미침
CoprocessorApplication
Region Server
CoprocessorApplication
Region ServerBug,
Memory Leak
22
Coprocessor 구현의 문제점
어플리케이션배포가불편
hbase> disable ‘document’hbase> alter ‘document’ … ‘coprocessor’=>‘…’hbase> enable ‘document’Coprocessor
Application
HBaseTable
deploy OtherApp
23
Omid +Storm Topology기반 구현
25
HBaseSI논문기반Coprocessor기반
OmidStorm Topology 기반
Cana TxCana Reactor
Early 2012
Mid 2012
Mid 2013
Omid
Yahoo!에서 개발한 오픈소스(link, 논문)
HBase 위에 Snapshot Isolation 트랜잭션을 구현
Optimistically transaction Management In Data-stores(낙관적 – 트랜잭션이 쓴 데이터는 Commit 전에 저장소에 기록됨)
HBaseSI를 대체할 트랜잭션 엔진으로 선택
26
Omid를 선택한 이유
바로 사용 가능한 코드
Omid를 사용하여 작성한 논문이 공개되어 있었음
HBaseSI 구현에 비해 높은 성능
적어도 Event Notification 기능을 재개발하는 동안은Omid에 의존할 수 있을 것이라 판단
27
Omid
DataTable
write
Servertransactionoperations
Timestamp Oracle
TransactionInformation
Client
서버/클라이언트모델28
Omid - Write
Client
TS Val
1 X
① begin
③ Putwith TS = 1
Column A
Client
TS Val
1 X
1
④ commit(1, [‘A’])
Column A
1
Server Server
⑤ success
1 1→2
②
29
Omid - Read
Client
TS Val
6 Z
3 Y
1 X
③ Getwith TS <= 7
Column A
Client
TS Val
6 Z
3 Y
1 X
7
Column A
7
Server Server
④ commit query / responseinSnapshot(7, 6) ? => NoinSnapshot(7, 3) ? => NoinSnapshot(7, 1) ? => Yes A = X
① begin
②
7 7
30
Omid - Commit 실패 시
Client
TS Val
1 X
① commit
③ Deletewith TS = 1
Column A
Client
TS Val
1
④ cleanup
Column A
1
Server Server
② failure ⑤ ok
1 1
31
Omid - 단일 서버의 한계 극복
Server
Timestamp Oracle
TransactionInformation
BookKeeperWAL
Client 서버 장애 대비
서버로의 요청 횟수↓최대 크기를 제한(오래된 트랜잭션을 강제 abort)
32
Storm
오픈소스실시간연산프레임워크Coprocessor를 대체할 수단으로 선택
33
Storm을 선택한 이유
Event Notification을통한실행모델과유사한컨셉- Storm은 Tuple을 전달함으로써 작업을 처리함
Event Notification 처리에필요한기본적인기능을제공- Scalable- Fault-tolerance- Guaranteeing message processing
어플리케이션배포가간편함
34
Storm Topology 기반 구현
Event의생성과전달방식Event는어플리케이션에서직접생성하여전달(자유도↑)
데이터를 저장소에 기록하지 않고 Event에 포함시켜 전달 가능데이터 write와 무관한 Event도 사용 가능
최초의 Event는 Kestrel 큐에넣음예) 문서 수집/변경 Event
파생 Event는스트림을통해바로관련로직에전달(큐사용 X)
35
Storm Topology 기반 구현
트랜잭션을분산처리할수있도록함
Storm의 분산 처리 기능을 그대로 활용
트랜잭션 객체가 Tuple의 형태로 하위 스트림에 전달됨
‘Sub Topology’ 단위로 트랜잭션이 실행되도록 함
36
Storm Topology 기반 구현
Sum=A+B
Total=∑Sum
Storage
Kestrel
Topology
Sub Topology
Sub Topology
(R1, A) = 30
(R1, A) 변경
App (R1, Sum) 변경
(Total, Sum) = 520
(R1, Sum) = 50
37
Storm Topology 기반 구현
Sub Topology는로직및트랜잭션의단위
Begin Tx Commit Tx
Tx Read/Write(App Logic)
Sub Topology
Spout or
Sub Topology
Tx
Tx
Tx
Tx
Tx
Tx
Tx
Tx
38
Omid의 문제점
기본적인 트랜잭션 기능에서 버그가 종종 발견됨
미완성된 기능 존재
프로젝트가 정체되어 있었음
39
Storm Topology 기반 구현의 문제점
로직이여러 Bolt로분산되어개발/유지보수가어려움
40
A =?
A←10A←20
Storm Topology 기반 구현의 문제점
Event와로직의연결이번거롭고 Topology가커지는문제
41
Sub Topology
Sub Topology
Sub Topology
Storm Topology 기반 구현의 문제점
데이터포함 Event가큐안에서오래대기하면데이터불일치발생
A=20 A=10
A=20
Event의 데이터와저장소의 데이터가불일치
최신 Event가 처리되면되지만 앞 작업은 헛수고
42
Cell Value
A 10 20
… …
Cell Value
A 20
… …
Cana Tx +Cana Reactor
44
HBaseSI논문기반Coprocessor기반
OmidStorm Topology 기반
Cana TxCana Reactor
Early 2012
Mid 2012
Mid 2013
Cana Tx
Omid에서 사용하는 개념만 빌려 새로 개발한 트랜잭션 엔진
Omid의 버그 수정
Omid에서 미완성된 기능 완성- 서버 이중화- Garbage Collection
45
Cana Tx 서버 이중화
Server1
BookKeeper
WAL
ZooKeeperClient Server2
Server3
Active: Server1
46
Curator
Curator
Curator
Curator를사용하여 Active-Standby 방식으로구현
Cana Tx 서버 이중화
Curator를사용하여 Active-Standby 방식으로구현47
BookKeeperZooKeeperClient
Active: Server3WAL
Server1
Server2
Server3
Curator
Curator
Curator
Cana Tx Garbage Collection
필요성–죽은클라이언트에의해남겨진데이터제거
Ta
Tb
Tc
Cana Tx Client Cana Tx Server
Ta Tb Tc
HBase
48
Cana Tx Garbage Collection
Ta
Tb
TcTa Tb Tc
49
필요성–죽은클라이언트에의해남겨진데이터제거
Cana Tx Client Cana Tx ServerHBase
Cana Tx Garbage Collection
필요성 - Commit된데이터중더이상접근되지않는것이발생
TS Val
3
1
TS Val
10
8
3
1
TS Val
21
15
10
8
3
1Committed
Data
Column A Column A Column A
t
50
Cana Tx Garbage Collection
HBase의데이터정리하기–기본아이디어
1. Abort된 데이터는 언제 제거해도 무방2. Commit된 데이터는 읽힐 가능성이 없는 것만 제거해야 함
1) Commit된 데이터를 지워도 되는 기준 타임스탬프를 찾고, 2) 그 이하 구간에서 Abort된 데이터는 모두 제거하고,3) Commit된 데이터는 칼럼 마다
타임스탬프가 최신인 것 하나씩만 남겨두면 됨
51
Cana Tx Garbage Collection
TS Val
23 …
20 …
15 …
10 …
6 …
3 …
1 …
Column A
기준 타임스탬프 = 20Committed = [3, 15]
Aborted = [1, 6, 10, 20]
Cana TxServer
TS Val
23 …
15 …
Column A
Compaction
Tx Snapshot
Coprocessor를써서 Compaction 도중데이터를정리하도록구현52
Cana Reactor
Event와로직연결의유연성을높이기위해 Pub-Sub 모델을사용
Event는변경이발생한영역정보만전달하여최신성문제해결- 더불어 Event는 데이터 변경만을 나타내도록 자유도를 제한
모든 Event는 Topology에연결된큐를거쳐전달
트랜잭션은단일 Bolt 내에서만실행되도록제한- 분산 처리의 이점보다는 로직 개발 편의성이 중요하다고 판단
53
Publish-Subscribe 모델
A observes (T1, F1, Q1)
B observes (T2, F2, Q2)
ZooKeeper
Logic A
Logic B
54
Cell Value
A 10 20
… …
Cell Value
A 20
… …
Event 처리 시점에데이터를 저장소에서읽어옴(최신성 보장)
중복 처리를 하지 않기위한 방법은 필요함(예: 어플리케이션에서
diff 체크)
A A
A
55
Event는 변경이 발생한 영역 정보만 전달
모든 Event는 큐를 거쳐 전달
56
트랜잭션은 단일 Bolt 내에서만 실행
Sub Topology Bolt
57
Cana Reactor
Sum=A+B
Storage
Topology
Total=∑Sum
App
Topology
(R1, A) = 30
(R1, A) 변경
(R1, Sum) 변경
(Total, Sum) = 520
(R1, Sum) = 50
58
Cana Reactor
일반적인 Storm 사용방식과는다름- 로직을 단일 Bolt 내에서 실행- 파생 Event를 스트림이 아니라 큐를 통해 전달
그러나 Storm을그대로사용- 그 동안 Storm을 사용해 와서 익숙함- Storm이 제공하는 기능을 활용하기 위해
59
HBase 테이블 큐
큐가 아니나 Storm Spout에서 쓰는 용어에 맞춰 큐라고 부름
Message Collapsing 기능을 사용하기 위해 개발함
Kestrel 프로젝트가 정체되어 이를 대체할 큐 필요
60
HBase 테이블 큐
Message Collapsing
61
C1 C2 C3
R1
R2
R3
HBase 테이블 큐
T1 + C1 T1 + C2
salted(R1) + R1 N1
salted(R2) + R2 N2
...
테이블 큐
62
T1 테이블N1
N2
C1 C2 C3
R1
R2
R3
HBase 테이블 큐
T1 + C1 T1 + C2
salted(R1) + R1 N1 N3
salted(R2) + R2 N2
...
N3
scan
N3
N2
테이블 큐
63
T1 테이블
트랜잭션 성능 /적용 사례 / 남은 과제 /유사 솔루션
Cana Tx 트랜잭션의 성능 특성
65
트랜잭션 연산 비용 = HBase 연산 비용 + 트랜잭션 오버헤드
트랜잭션 오버헤드: 트랜잭션 시작, Commit Query, Commit
트랜잭션 오버헤드는 HBase와 무관
Commit 비용은 Write-Set이 클수록 증가(Conflict 체크 비용 증가)
Write-Set 크기에 따른 트랜잭션 성능
66
0
1
2
3
4
5
6
7
0 10000 20000 30000 40000 50000 60000
Latency(m
s)
TPS
1
16
32
64
128
# of Columns
적용 사례
2015년 상반기 NAVER 지식인 검색 서비스에 BREW 적용
적용 후 검색 문서 갱신에 소요되는 시간 감소
점차 다른 검색 서비스로 확대 적용 예정
67
남은 과제
Cana TxSQL on HBase 적용(예: Apache Phoenix)HBase 외의 저장소에 적용
Cana ReactorStorm 대체 플랫폼 고려
68
Google Percolator와의 비교
Google Percolator
2010년 논문을 통해 공개됨(link)
증분 인덱싱 시스템 Caffeine에서 사용
Bigtable에 Snapshot Isolation 트랜잭션 제공
Observer Framework를 사용한 Event Notification 기능 제공
69
Google Percolator와의 비교
트랜잭션구현방식비교
Cana Tx Percolator
Timestamp Oracle 서버로 구현 서버로 구현
데이터기록시점 Write 할 때 Commit 할 때
트랜잭션정보저장소
서버의 메모리 +클라이언트의 캐시
메타 칼럼
Commit 서버에서 처리Lock을 사용하여
클라이언트에서 처리
70
Google Percolator와의 비교
Event Notification 구현방식비교
공통점- 테이블에 Event를 저장하고 테이블을 스캔하여 Event를 추출- Message Collapsing 기능 제공
차이점- Cana Reactor: Event 저장 전용 테이블 사용- Percolator: 데이터 테이블의 메타 칼럼에 Event를 저장
71
Omid2
최근 새로운 Omid 코드가 GitHub에 올라옴
기본적인 트랜잭션 처리 방식은 기존과 동일
Commit 관련 정보를 HBase 테이블과 메타 칼럼에 저장
WAL을 더 이상 사용하지 않음
72
유사 오픈 소스 솔루션
HBase 기반 트랜잭션 솔루션- Haeinsa: Percolator 방식과 유사. DEVIEW 2013- Tephra: Omid 방식과 유사- Themis: Percolator 논문에 기반한 구현
Tigon- Storm과 유사- HBase 테이블을 사용하여 큐를 구현- Tephra를 사용하여 트랜잭션 사용 가능
73
Q&A
Thank You
Recommended