HBase 기반
검색 데이터 저장소
박범신
Naver / Naver Search

CONTENTS
1. 배경/현황
2. 데이터 특성
3. Time range scan & Real-time processing
4. Multi contents & Filtered scan
5. 데이터 정합성
6. 그 외 저장소 구성 요소

1.
배경 / 현황

과거에는
웹 수집 문서
서비스 문서
Data Science
모델링
생산자
검색서비스
Data Science
모델링
데이터 정제
소비자

현재는
데이터 저장/유통 서비
스
웹 수집 문서
서비스 문서
Data Science
모델링
생산자
검색서비스
Data Science
모델링
데이터 정제
소비자
CUVE
Catalog
Storage
API/ToolAPI/Tool

다수의 생산자
웹 수집 문서
서비스 문서
Data Science
모델링
생산자
검색서비스
Data Science
모델링
데이터 정제
소비자
CUVE
Catalog
Storage
API/ToolAPI/Tool
수집/서비스 문서만 해도 수십개가 넘음
뉴스
카페
지식인
이미지
지역
라이브
음악
리뷰
블로그
동영상
사전
뉴스

웹 수집 문서
서비스 문서
Data Science
모델링
생산자
검색서비스
Data Science
모델링
데이터 정제
소비자
CUVE
Catalog
Storage
API/ToolAPI/Tool
다양한 데이터
각 서비스 별 관련 데이터도 수십개,
각 데이터 별 담당자도 제각각
포스트
카테고리
댓글
좋아요
로그..
로그...
사전
사전...
검색 보조
검색 보조
다수의 담당자
검색 서비스에
모두 필요
블로그

생산자 Interface
웹 수집 문서
서비스 문서
Data Science
모델링
생산자
검색서비스
Data Science
모델링
데이터 정제
소비자
CUVE
Catalog
Storage
API/ToolAPI/Tool

생산자 Interface
웹 수집 문서
서비스 문서
Data Science
모델링
생산자
검색서비스
Data Science
모델링
데이터 정제
소비자
CUVE
Catalog
Storage
API/ToolAPI/Tool
• Batch
• Create
• Update
• Delete
• Stream
• Create
• Update
• Delete

소비자 Interface
웹 수집 문서
서비스 문서
Data Science
모델링
생산자
검색서비스
Data Science
모델링
데이터 정제
소비자
CUVE
Catalog
Storage
API/ToolAPI/Tool

소비자 Interface
웹 수집 문서
서비스 문서
Data Science
모델링
생산자
검색서비스
Data Science
모델링
데이터 정제
소비자
CUVE
Catalog
Storage
API/ToolAPI/Tool
• 이종 데이터를 동일 인터페이스로
제공
• 다양한 읽기 방식 제공
• Stream read
• Time range scan
• Random read

Data catalog
데이터 활용을 돕는 Catalog
웹 수집 문서
서비스 문서
Data Science
모델링
생산자
검색서비스
Data Science
모델링
데이터 정제
소비자
CUVE
Catalog
Storage
API/ToolAPI/Tool

Data catalog
웹 수집 문서
서비스 문서
Data Science
모델링
생산자
검색서비스
Data Science
모델링
데이터 정제
소비자
CUVE
Catalog
Storage
API/ToolAPI/Tool• 데이터 종류 검색
• 데이터 meta 정보
• 생산 / 소비 담당자 정
보
• 권한 부여
• 티켓발급

현황
5백여 종의 데이
터
out : 300 억 건 / dayin : 20억 건 / day
수천억 건의 문
서
수 Peta byte
웹 수집 문서
서비스 문서
Data Science
모델링
생산자
검색서비스
Data Science
모델링
데이터 정제
소비자
CUVE
Catalog
Storage
API/ToolAPI/Tool

2.
데이터 특성

데이터 특성
- 가변 : 컨텐츠 데이터 생성/수정/삭제 발생
- 불변 : 로그 데이터 생성만 발생
불변/가변 따른 분류
- 웹 수집 : 웹에서 수집된 문서
- 서비스 : 네이버 카페, 블로그, 지식인 ..
- 제휴 : 트위터
- 정제 : 원본 데이터를 가공한 데이터
생성 또는 관리 주체에 따른 분류

데이터 특성
• 생성 패턴
- 하루에 한번 전체 데이터 생성
- 실시간으로 생성/수정/삭제 전달 가능 (또는 짧은 시간의 DB select를
통해서)
• 소비패턴
- 하루에 한번씩 전체 데이터
- 단위 시간당 ( 10분에 한번 10분 구간)
- 실시간으로 생성/수정/삭제 event 발생 시 마다 전달
사용 패턴에 따른 분류
Text/Multi Media

데이터 특성
Stream
CUVE
Catalog
Storage
API/Tool Q
Time Range
Random
본 발표는 실시간 생성/수정/삭제 되어 HBase에 write되고
time range/real-time read 되는 가변 데이터에 집중하기로 함

3.
Time range scan &
Real-time Processing

RegionServer 2
RegionServer 3
RegionServer 1
HBase table, region
Region A
Region B
Region C
Region D
0xFFFF
Table doc
row key
A 0x0001
A 0xFFFF
B 0x0001
B 0xFFFF
C 0x0001
C 0xFFFF
D 0x0001
D
doc, Region A
doc, Region D
doc, Region B
doc, Region C
any, Region ..
key, Region 다
key, Region 가
key, Region 라
key, Region 나
Table key
0x0001
0xFFFF
Region 가
가
가
0x0001
0xFFFF
Region 나
나
나
0x0001
0xFFFF
Region 다
다
다
0x0001
0xFFFF
Region 라
라
라

HBase client operation
A 0x0001
A 0xFFFF
Region A
B 0x0001
B 0xFFFF
Region B
C 0x0001
C 0xFFFF
Region C
D 0x0001
D 0xFFFF
Region D
SortedMap<byte[], Colums> ?
• put/get/delete 등을 지원
• scan
시작 지점과 종료 지점을 지정하여 일
부만 읽어낼 수 있음
(미 지정시 전체 region)
D 0x2000
startRow (A) stopRow(B)
startRow (D0x0001) stopRow(D0x2000)

Schema design
요소 내용
URL http://www.abc.com/bab/asdf
meta 문서의 속성들
content 원본 HTML을 쓰기 편하게 파싱한
XML
raw 원본 HTML
웹 수집기가 수집한 문서 저장
- 몇 백억 건 규모 밖에.. (더 늘어난다)
- 수십 종류 의 카테고리가 있다
Time range 덤프(scan) 지원
- 전체, 한달, 하루, 한 시간 (내 맘대로)
URL로 개별 문서에 대한 접근 지원
- 저장된 문서 확인
- URL 리스트로 해당하는 문서 덤프 필
요
요구 사항

Schema design - table, row key
table row key 설계
ID(16)MessageType(1)
web table
URL은 unique 한 속성이므로 ID로 사용가능
URL은 고정크기가 아니므로 MD5 hash를 통해서 크기를 고정
문서, 이미지 구별 용도 MessageType (1byte)
row key
Unique Key : URL
ID : URL MD5 Hash

Schema design - table, row key
문제 - 과도한 disk I/O
하루치 생성/수정 분만 읽으려 해도
전체 문서 수 백억 건의 I/O 가 발생
서버에서 filtering 하면
network 비용은 감소하지만
disk I/O 비용은 여전
HBase table에는 DBMS 와 같은 보조 index 가 없음
수백억
몇천만건
full scan
web

Schema design - table, row key
해결 방안
ID(16)MessageType(1)
web table
cache table을 추가해서 2벌을 저장
짧은 기간 데이터는 cache table에서 읽음
TTL 등을 두어서 cache 기간이 만료된 데이터는 지워지도록
row key
ID(16)MessageType(1)
web cache table
row key

Schema design - table, row key
문제 : 운영 비용
cache table에 유지기간이 카테고리마다 다르므로
카테고리를 추가할 때마다 테이블을 2개씩 생성해야 함
web
all table
cache table
twitter
all table
cache table
youtube
all table
cache table
blog
all table
cache table

Schema design - table, row key
Group(2) Time(8) ID(16)MessageType(1)
doc table
카테고리마다 cache table row 유지 기간이 각각 다르므로 문제가 발생
-> row key에 Group (2bye) 추가해서 여러 테이블을 하나의 테이블로
-> row key에 Time (8byte) 추가해서 time range scan을 대응
해결 방안
row key

Schema design - table, row key
문제 : Hot Spot
row key에 timestamp 와 같은 순차적으로 증가하는 값이 있는 경우에 발
생
여러 Region 들이 존재해도
하나의 Region 으로 write 요청이 몰림
Region 1
Ex) Group, MessageType이 같은 1억 건의
문서를 짧은 시간에 쓰게 되면
row key 의 시작 byte의 일정 부분이 같
음
web
group
doc
messageType
…
id
id …web doc 0x11111…
Region n
id …web doc 0x12345678…
1억
id …web doc 0x12345678…
id …web doc 0x11111…
0x12345678 …
time

Schema design - table, row key
특정 region에 몰리는 것이 문제이므로 몰리지 않고 퍼지도록 row key
앞에 Hash 값을 넣기로 함
Hash는 2000 으로 ID 통해서 모듈러 연산으로 생성 -> Salt(2 byte)
region을 미리 split 하여 테이블 생성 초기 (2000개)부터 만들자
해결 방안
Group(1) Time(8) ID(16)MessageType(1)
doc table
Salt(2)
row key

Schema design - table, row key
문제 : 개별 문서 읽기
random access 용 index 가 필요
HBase table 보조 인덱스 기능이 없으므로..
random access 용 index table을 하나 더 생성
key table
ID(16) G(2) M(1)
column timestamp
해결 방안
ID는 MD5 Hash 의해서 생성하므로 특정 region으로 몰리는 문제가 없
음
unique key로 문서의 random access 가 되지 않
음
row key를 구성하는 timestamp를 몰라서..

Schema design - table, row key
최종
key table
S(2) G (2) M(1) T(8) ID(16)
doc table
ID(16) G(2) M(1)
• Create - doc put, key put
• Update - doc put, key put(time update), doc delete
• Delete - doc put, key put(time update), doc delete
doc table에 문서 저장, key table은 개별문서 접근용 index

Write (create/update/delete)
Region n
n 00 0 xxxx ID
n 00 0 xxxx ID
Region 1
1 00 0 xxxx ID
1 00 0 xxxx ID
Region 0
00 0ID
00 0ID
Region n
00 0ID
00 0ID
client
doc table은 salt, key table은 ID에 의해 여러 region에 퍼지면서 쓰여 짐
doc table key table

Time-based sequential read
Region 1 Region n
00 0 00001 ID
1E 1 xxxx ID
00 1 xxxx ID
n 00 0 192618 ID
region 1 ~ region n 까지 모든 region을 scan
- 문서 시간 00001 ~ 192618 (파란색 범위)
- 문서 전체 (녹색 범위)
doc table
n
n
n
00 0 00001 ID
1E 1 xxxx ID
00 1 xxxx ID
1 00 0 192618 ID
1
1
1

Random read
key table
S(2) G (2) M(1) T(8) ID(16)
doc table
ID(16) G(2) M(1) column
timestamp
S(2) G(2) M(1) T(8) ID(16)
client
1. URL을 ID(MD5 hash) 변환 후에 key table timestamp 읽기
2. doc table row key를 생성
- salt는 ID로 구함
- timestamp는 key table로 부터
3. doc table 문서 읽기
1
2
3

Schema design - column family
읽기 패턴을 고려한 column family 구성
요소 내용
URL http://www.dic.com/bab/asdf
meta 문서의 속성들
content 원본 HTML을 쓰기 편하게 파싱한
XML
raw 원본 HTML
URL 등 저장소 메타 데이터 필요
(저장소 통계, 저장소 배치작업 등에
사용)
content 가 데이터 가공에 주로 사용
(사용빈도 높음)
원본 html은 파서 변경 등으로 재처
리가 필요할 때 읽음 (사용빈도 낮음)

Schema design - column family
Column Family Qualifier 설명
sysMeta
docId URL MD5
group group (web, blog, twitter)
messageType doc, image …
uniqueKey URL
modifyTime 저장소 문서 수정시간
isDeleted 삭제 여부
updateTime 원본의 갱신 시간
digest 원본 Content digest
meta meta 문서 속성
content content Html 파싱한 XML 형태
extensions rawHtml 원본
4개의 column family로 구성
HBase에서 같은 column family로
구성된 컬럼은 같은 HFile로
HDFS 저장됨
sysMeta HFile
meta HFile
content HFile
extensions
HFile
`

저장 주체
HBase에 누가 write를 할 것인가?
사용자에게 HBase write API를 전달하여 사용자 프로세스가 직접?
사용자로부터 Queue 등을 통해 전달 받고 시스템에서 write (사용자 간접)?

저장 주체
Queue
공통 처리 문서 이력데이터 저장
HBase
사용자
• 문서에서 공통 처리를 필요로 하는 부분이 존재
- Reversed domain, 이미지에서 정보 추출
• 데이터 관리 측면에서도 문서 처리 이력이 필요
• 사용자는 Queue 통해서 문서를 전달 Queue로 부터 가져와 처리 후 저장
저장소 내부 프로세스가 저장을 수
행
Kafka

시간 순서 보장
Kafka
uniqueKey : u1
status : S3
updateTime : t3
uniqueKey : u1
status : S2
updateTime : t2
uniqueKey : u1
status : S1
updateTime : t1
uniqueKey : u1
status : S1
updateTime : t1
uniqueKey : u1
status : S2
updateTime : t2
uniqueKey : u1
status : S3
updateTime : t3
DocumentWriteBolt
Final status
uniqueKey : u1
status : S1
문제 처리량 증가를 위해서 Kafka topic에 여러 파티션을 두고
병렬 처리시 문서의 시간 순 상태를 보장하기 어려움
Queue
1
2
3
1
2
3
DocumentWriteBolt
DocumentWriteBolt

시간 순서 보장
해결 문서를 쓰기 전에 문서를 읽어서 시간 비교 후 처리

문서 쓰기 경쟁
문제 n개의 Storm Bolt Executor 간에 동일 문서에 대해 쓰기 경쟁이 발
생 DocumentWriteBolt A DocumentWriteBolt B
읽기 d1
처리 d1
읽기 d1
처리 d1
쓰기 d1쓰기 d1
document D1
t1 t2
t3t4

문서 쓰기 경쟁
해결
- 경쟁이 발생하는 경우는 같은 문서를 처리할 때 발생함
- 읽기->처리(순서보장)-> 쓰기 3단계 operation이 atomic 하지 않
음
- row lock 등을 고려해 볼 수 있으나 성능 저하 및 복잡도 증
가
- Storm bolt 연결 방식 중 field grouping으로
같은 문서는 같은 Bolt에서 처리되도록 하여 경쟁을 회피

분산처리 플랫폼 지원 - Streaming
Spout
Storm topology Spout
Storm topology
Spout
Storm topology
Storm cluster
Queue
Kafka
트위터 문서 처리 등과 같은 실시간 데이터를 필요
- HBase 짧은 주기로 scan 해서는 요구 사항을 맞추기 어려움
문서의 create/update/delete event를 실시간으로 전달하기 위해
streaming queue를 도입

분산처리 플랫폼 지원 - Batch
CuveInputFormat extends InputFormat<MD5Hash, CuveDocumentWritable>
Region 1
Region 1Region
100
RegionServer n
Region 1
Region 1Region
320
RegionServer 1
RecordReader
mapper RecordReader
mapper
RecordReader
mapper
HBase cluster
Hadoop
cluster

cuve-trans
시스템 구성도
cuve-reader
Cluster
Zookeeper
cuve-storage
cuve-sender
Cluster
cuve-stream

4.
Multi contents &
Filtered Scan

Multi contents
요소 내용
URL http://www.abc.com/bab/asdf
meta 수집 문서의 속성들
content 수집 원본 HTML을 쓰기 편하게 파
싱한 XML
raw 원본 HTML
- 제휴에 의한 웹 수집 문서 인입이 발생
해서 추가적으로 컨텐츠를 저장하고
싶음
- 웹 수집 문서에 본문의 프로세싱 해서
얻은 정보를 미리 저장하고 싶음
- 결국..
다른 생산 주체가 생산한 데이터가 같
이
요구 사항
meta 제휴 문서의 속성들
content 제휴 문서를 편하게 구성한 XML

Multi contents
rawhtmlExtension
Content
Meta
sysMeta
group
messageType
modifyTime
isDeleted
meta
contentInfo
sysMeta
group
messageType
modifyTime
isDeleted
문서는 여러 개의 content를 가질 수 있도록 확장
crawlContentInfo
crawlContentRaw
meta
data
syndiContentInfo
anyContentInfo
meta
data
meta
data
meta
data
content는 meta + data로 구성

Filtered scan
웹 문서에서 meta 속성 중 documentType = D1 인 문서만 read 원함
SQL에서 where 절 비슷하게..
HBase scan은 다양한 filtering 기능을 가지고 있고 column 값에 의한
필터링 기능인 SingleColumnValueFilter 가 있음
그러나 content meta를 하나의 문자열 덩어리로 저장되어 filtering 기능을
사용하기 비 효율적임
요구 사항

전송 프로토콜 변경
문서 전송 프로토콜 변경
Queue로 문서 전송 시 사용되는 프로토
콜변경
Multi Content 지원하도록 변경
특히 meta는 기존 문자열 덩어리
형태에서 Map 형태로 변경
document thrift
meta(map)
data
content
meta(map)
data
content
meta (map)
data
content
sysMeta

Column family 구성
document를 HBase에 어떻게 저장할 것인가?
document
meta
data
content
meta
data
content
meta
data
content
sysMeta
HBase
Table
Scan시 column filter 기능을 위해서
meta 데이터는 꼭 개별 컬럼으로 나
뉘어저장 되어야 함

Column family 구성
content 당 하나의 column family
document
meta
data
content
meta
data
content
meta
data
content
sysMeta sysMeta
content1
content2
content3
contentN

문제 : content 당 하나의 column family
- column family 가 많아지면 HBase write 성능이 떨어짐
- flush , compaction 이 Region 단위로 발생하기 때문에
region 이 flush 될 때 한꺼번에 여러 column family가 flush 됨
- 데이터가 적게 들어오는 small column family에 의한 작은 HFile이 많아짐
- 최신 버전의 HBase에서는 유연성을 위해서 flush 정책이 다양해 졌지만
- column family 수가 많으면 관리하기 어려움
Column family 구성

Column family 구성
column family 4개만 구성하여 content를 담을 수 있는 slot 처
럼
- meta 끼리 모아서 meta column family
- data는 content1~3에
document
meta
data
content
meta
data
content
meta
data
content
sysMeta
meta
content1
content2
content3

Column family 구성
meta content1 content2 content3
sysMeta.cuve.group
sysMeta.cuve.messageType
sysMeta.cuve.uniqueKey
sysMeta.cuve.modifyTime
crawlContentInfo.meta.docType
crawlContentInfo.meta.classId
syndiContentInfo.data.binary
crawlContentRaw.data.binarycrawlContentInfo.data.binary
syndiContentInfo.meta.docType
syndiContentInfo.meta.classId
crawlHttpHeader.data.binay
해결
column family
column
하나의 문서에 여러 content를 저
장
meta 컬럼을 통한 scan filtering 가
능

5.
데이터 정합성

HTable mutateRow(RowMutations rm) method 사용
- 단일 row에 대해서는 atomic 한 put/delete operation을 보장
- 단일 row의 여러 컬럼에 대해서 atomic put /delete 등이 필요하므로 사
용
HTable mutateRow method Bug (HBase 0.96만 해당)
- https://issues.apache.org/jira/browse/HBASE-10803
- 일반 put/delete 등의 메소드에서는 정상적으로 동작
- mutateRow 메소드로 write 결과가 제대로 반영되지 않음 (data loss)
문제 : key table에만 있거나, doc table에만 있는 문서 존재
Data loss

HTable
Data loss
mutateRow
HRegion
HBase client
RegionServer
원인 : RegionServer 보낸 Exception을 상위 method로 Throw를 하지 않음
HBase client operation 실패 시 retry를 하지 못함
HRegion
HRegion
HRegion
HRegion
HRegion
해결 : HBase client API 수정
RegionSever로 부터 전달 받은 exception throw

delete 실패로 남아 있음
데이터 중복
modifyTime
T2
문제 : 삭제되지 않은 row 존재
ex) 문서 update 시
1. doc table put (신규 row)
2. key table put (타임 갱신)
3. doc table delete (이전 row 삭제)
1, 2 단계 성공, 3 단계 delete 실패
Salt G M T1 ID
update가 실패되어 재시도를 해도 이전 row를 알 수
없음
중복된 row 가 계속 존재
doc table key table
Salt G M T2 ID
ID G M
T1

데이터 중복
ID G M
modifyTime
T2
원인 : atomic 하지 않은 연산으로 doc/key table 간 불일치 발
생
1. doc table put (신규 row)
2. key table put (타임 갱신)
3. doc table delete (이전 row 삭제)
HBase는 multi table 간 트랜잭션이 지원되지 않음
doc table key table
1~3 오퍼레이션이 atomic 하지 않
음
Salt G M T1 ID
Salt G M T2 ID

데이터 중복
1. 보조 인덱스 생성 솔루션을 고려
2. Multi Table 간 트랜잭션 지원 솔루션을 고려
1, 2에 대한 다수의 오픈소스 솔루션들이 존재
(팀 내부에서 개발된 솔루션도 있음, 타 시스템에 적용되어 이미 사용)
해결 방안

데이터 중복 - 트랜잭션 지원
HBase 0.94에서 기본골격 완성
- https://issues.apache.org/jira/browse/HBASE-5229
- MultiTable은 아니지만 Multi Row에 대해서 트랜잭션을 지원
- HRegion processRowsWithLocks method
(주석이 잘되어 있어서 트랜잭션 구현 관련 설명은 생략)
Client API 인 HTable 의 method로 열어 놓지는 않고
- Coprocessor endpoint를 이용한 사용자 정의 RPC 호출하도록 구현됨
- MultiRowMutationEndpoint client 호출 코드도 포함되어 있음
- 동일 Region에 존재하는 row들에 대해서만 가능

데이터 중복
doc table : region A
key table : region B
one table : region a
S(2) G(2) M(1) T(8) ID(16)
ID(16) G(2) M(1)
TYPE(1)S(2) G(2) M(1) T(8) ID(16)
ID(16) G(2) M(1)TYPE(1)S(2)
해결 : doc/key table 하나로 합침
salt를 이용해서 동일 region에 배치
multi row transaction 이용
Row Key에 TYPE(1byte)에 의해서 row key 용도를 구별

트랜잭션 적용 효과
- index 용 row들과 데이터 불일치 해소
- 여러 row에 대한 put/delete 등의 operation을 한번의 RPC 요청으
로 처리하므로 throughput 향상
- 보조 index row를 추가할 여지 상승

요구 사항
사용자 : 웹 수집문서 중에서 ‘http://www.abc.com/’
로 시작하는 문서만 dump 받고 싶어요
cuve : scan에서 filter를 걸어서 사용하세요
사용자 : 일단 오래 걸리고, timeout 이 자주 발생해요
cuve : 네... timeout 시간을 늘려서 받으셔야 되요
수백억
몇 백만건
full scan
web
보조 index row 추가

보조 index row 추가
해결 방안 이전에는 불일치 문제로 index Table 추가가 부담되었
으나
같은 Region에 배치되면 트랜잭션이 가능하므로
Unique key에 대한 타입 정보를 추가one table : region a
TYPE(1)S(2) G(2) M(1) T(8) ID(16)
ID(16) G(2) M(1)TYPE(1)S(2)
unique key (n byte)G(2) M(1)TYPE(1)S(2)

6.
그 외 저장소 구성 요소

DB 데이터 Pulling
BIOarticle
tag map
thum
bnail
video
Blog DB
BIOarticle
tag map
thum
bnail
video
Blog DB
BIOarticle
tag map
thum
bnail
video
Blog DB
BIOarticle
tag map
thum
bnail
video
Blog DB
BIOarticle
tag map
thum
bnail
video
Blog DB
N 개로 sharding
- DB 데이터를 HBase에 저장하는 요
청
- 메인 테이블과 1:n 관계의 위성 테
이블
- N 개의 DB로 sharding 되어 있음

DB 데이터 Pulling - Streaming
FetchThread
FetchRunnable
DBFetchSpout
PlanetFetcher
SatelliteFetchernextTuple()
Ack() Fail()
FetchTread
CustomBolt RecordSendBolt
CuveDocumentRecord
Sale
Thumbnail
Map Movie
article
ContentCleanBolt
Record
Record
zookeeper
Kafka
Fetch time 저장용
Queue

DB 데이터 Pulling - Batch
ProbeInputFormat extends InputFormat<Text, RecordWritable>
Blog DB
Blog DB
Blog DB
DBRecordReader
mapper
hadoop cluster
Queue
Kafka
RecordSend
ContentClean

데이터 처리 모니터링
- 단위 시간당(day/hour/minute) 얼마만큼의 문서들이
생성/수정/삭제 되는가?
- 전체 문서는 몇 건 인가? (그룹별, 메세지별 건 수, 디스크 사용량)
- 개별 문서가 언제 생성/수정/삭제 되었는가? (문서 처리 이력)
- Kafka, HBase에 저장된 문서를 볼 수 있어야 함

사용자 관리 및 제어
- 대량으로 전송하고 있는 사용자는 누구인가?
- 대량으로 소비하고 있는 사용자는 누구인가?
- 데이터 접근 제어

Thank you