[211] HBase 기반 검색 데이터 저장소 (공개용)
•
16 gefällt mir•8,665 views
HBase 기반 검색 데이터 저장소 (공개용)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie [211] HBase 기반 검색 데이터 저장소 (공개용)
Ähnlich wie [211] HBase 기반 검색 데이터 저장소 (공개용) (20)
Mehr von NAVER D2
Mehr von NAVER D2 (20)
[211] HBase 기반 검색 데이터 저장소 (공개용)
- 1. HBase 기반 검색 데이터 저장소 박범신 Naver / Naver Search
- 2. CONTENTS 1. 배경/현황 2. 데이터 특성 3. Time range scan & Real-time processing 4. Multi contents & Filtered scan 5. 데이터 정합성 6. 그 외 저장소 구성 요소
- 3. 1. 배경 / 현황
- 4. 과거에는 웹 수집 문서 서비스 문서 Data Science 모델링 생산자 검색서비스 Data Science 모델링 데이터 정제 소비자
- 5. 현재는 데이터 저장/유통 서비 스 웹 수집 문서 서비스 문서 Data Science 모델링 생산자 검색서비스 Data Science 모델링 데이터 정제 소비자 CUVE Catalog Storage API/ToolAPI/Tool
- 6. 다수의 생산자 웹 수집 문서 서비스 문서 Data Science 모델링 생산자 검색서비스 Data Science 모델링 데이터 정제 소비자 CUVE Catalog Storage API/ToolAPI/Tool 수집/서비스 문서만 해도 수십개가 넘음 뉴스 카페 지식인 이미지 지역 라이브 음악 리뷰 블로그 동영상 사전 뉴스
- 7. 웹 수집 문서 서비스 문서 Data Science 모델링 생산자 검색서비스 Data Science 모델링 데이터 정제 소비자 CUVE Catalog Storage API/ToolAPI/Tool 다양한 데이터 각 서비스 별 관련 데이터도 수십개, 각 데이터 별 담당자도 제각각 포스트 카테고리 댓글 좋아요 로그.. 로그... 사전 사전... 검색 보조 검색 보조 다수의 담당자 검색 서비스에 모두 필요 블로그
- 8. 생산자 Interface 웹 수집 문서 서비스 문서 Data Science 모델링 생산자 검색서비스 Data Science 모델링 데이터 정제 소비자 CUVE Catalog Storage API/ToolAPI/Tool
- 9. 생산자 Interface 웹 수집 문서 서비스 문서 Data Science 모델링 생산자 검색서비스 Data Science 모델링 데이터 정제 소비자 CUVE Catalog Storage API/ToolAPI/Tool • Batch • Create • Update • Delete • Stream • Create • Update • Delete
- 10. 소비자 Interface 웹 수집 문서 서비스 문서 Data Science 모델링 생산자 검색서비스 Data Science 모델링 데이터 정제 소비자 CUVE Catalog Storage API/ToolAPI/Tool
- 11. 소비자 Interface 웹 수집 문서 서비스 문서 Data Science 모델링 생산자 검색서비스 Data Science 모델링 데이터 정제 소비자 CUVE Catalog Storage API/ToolAPI/Tool • 이종 데이터를 동일 인터페이스로 제공 • 다양한 읽기 방식 제공 • Stream read • Time range scan • Random read
- 12. Data catalog 데이터 활용을 돕는 Catalog 웹 수집 문서 서비스 문서 Data Science 모델링 생산자 검색서비스 Data Science 모델링 데이터 정제 소비자 CUVE Catalog Storage API/ToolAPI/Tool
- 13. Data catalog 웹 수집 문서 서비스 문서 Data Science 모델링 생산자 검색서비스 Data Science 모델링 데이터 정제 소비자 CUVE Catalog Storage API/ToolAPI/Tool• 데이터 종류 검색 • 데이터 meta 정보 • 생산 / 소비 담당자 정 보 • 권한 부여 • 티켓발급
- 14. 현황 5백여 종의 데이 터 out : 300 억 건 / dayin : 20억 건 / day 수천억 건의 문 서 수 Peta byte 웹 수집 문서 서비스 문서 Data Science 모델링 생산자 검색서비스 Data Science 모델링 데이터 정제 소비자 CUVE Catalog Storage API/ToolAPI/Tool
- 15. 2. 데이터 특성
- 16. 데이터 특성 - 가변 : 컨텐츠 데이터 생성/수정/삭제 발생 - 불변 : 로그 데이터 생성만 발생 불변/가변 따른 분류 - 웹 수집 : 웹에서 수집된 문서 - 서비스 : 네이버 카페, 블로그, 지식인 .. - 제휴 : 트위터 - 정제 : 원본 데이터를 가공한 데이터 생성 또는 관리 주체에 따른 분류
- 17. 데이터 특성 • 생성 패턴 - 하루에 한번 전체 데이터 생성 - 실시간으로 생성/수정/삭제 전달 가능 (또는 짧은 시간의 DB select를 통해서) • 소비패턴 - 하루에 한번씩 전체 데이터 - 단위 시간당 ( 10분에 한번 10분 구간) - 실시간으로 생성/수정/삭제 event 발생 시 마다 전달 사용 패턴에 따른 분류 Text/Multi Media
- 18. 데이터 특성 Stream CUVE Catalog Storage API/Tool Q Time Range Random 본 발표는 실시간 생성/수정/삭제 되어 HBase에 write되고 time range/real-time read 되는 가변 데이터에 집중하기로 함
- 19. 3. Time range scan & Real-time Processing
- 20. 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 라 라 라
- 21. 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)
- 22. Schema design 요소 내용 URL http://www.abc.com/bab/asdf meta 문서의 속성들 content 원본 HTML을 쓰기 편하게 파싱한 XML raw 원본 HTML 웹 수집기가 수집한 문서 저장 - 몇 백억 건 규모 밖에.. (더 늘어난다) - 수십 종류 의 카테고리가 있다 Time range 덤프(scan) 지원 - 전체, 한달, 하루, 한 시간 (내 맘대로) URL로 개별 문서에 대한 접근 지원 - 저장된 문서 확인 - URL 리스트로 해당하는 문서 덤프 필 요 요구 사항
- 23. 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
- 24. Schema design - table, row key 문제 - 과도한 disk I/O 하루치 생성/수정 분만 읽으려 해도 전체 문서 수 백억 건의 I/O 가 발생 서버에서 filtering 하면 network 비용은 감소하지만 disk I/O 비용은 여전 HBase table에는 DBMS 와 같은 보조 index 가 없음 수백억 몇천만건 full scan web
- 25. 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
- 26. 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
- 27. 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
- 28. 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
- 29. 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
- 30. 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를 몰라서..
- 31. 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
- 32. 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
- 33. 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
- 34. 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
- 35. Schema design - column family 읽기 패턴을 고려한 column family 구성 요소 내용 URL http://www.dic.com/bab/asdf meta 문서의 속성들 content 원본 HTML을 쓰기 편하게 파싱한 XML raw 원본 HTML URL 등 저장소 메타 데이터 필요 (저장소 통계, 저장소 배치작업 등에 사용) content 가 데이터 가공에 주로 사용 (사용빈도 높음) 원본 html은 파서 변경 등으로 재처 리가 필요할 때 읽음 (사용빈도 낮음)
- 36. 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 `
- 37. 저장 주체 HBase에 누가 write를 할 것인가? 사용자에게 HBase write API를 전달하여 사용자 프로세스가 직접? 사용자로부터 Queue 등을 통해 전달 받고 시스템에서 write (사용자 간접)?
- 38. 저장 주체 Queue 공통 처리 문서 이력데이터 저장 HBase 사용자 • 문서에서 공통 처리를 필요로 하는 부분이 존재 - Reversed domain, 이미지에서 정보 추출 • 데이터 관리 측면에서도 문서 처리 이력이 필요 • 사용자는 Queue 통해서 문서를 전달 Queue로 부터 가져와 처리 후 저장 저장소 내부 프로세스가 저장을 수 행 Kafka
- 39. 시간 순서 보장 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
- 40. 시간 순서 보장 해결 문서를 쓰기 전에 문서를 읽어서 시간 비교 후 처리
- 41. 문서 쓰기 경쟁 문제 n개의 Storm Bolt Executor 간에 동일 문서에 대해 쓰기 경쟁이 발 생 DocumentWriteBolt A DocumentWriteBolt B 읽기 d1 처리 d1 읽기 d1 처리 d1 쓰기 d1쓰기 d1 document D1 t1 t2 t3t4
- 42. 문서 쓰기 경쟁 해결 - 경쟁이 발생하는 경우는 같은 문서를 처리할 때 발생함 - 읽기->처리(순서보장)-> 쓰기 3단계 operation이 atomic 하지 않 음 - row lock 등을 고려해 볼 수 있으나 성능 저하 및 복잡도 증 가 - Storm bolt 연결 방식 중 field grouping으로 같은 문서는 같은 Bolt에서 처리되도록 하여 경쟁을 회피
- 43. 분산처리 플랫폼 지원 - Streaming Spout Storm topology Spout Storm topology Spout Storm topology Storm cluster Queue Kafka 트위터 문서 처리 등과 같은 실시간 데이터를 필요 - HBase 짧은 주기로 scan 해서는 요구 사항을 맞추기 어려움 문서의 create/update/delete event를 실시간으로 전달하기 위해 streaming queue를 도입
- 44. 분산처리 플랫폼 지원 - 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
- 46. 4. Multi contents & Filtered Scan
- 47. Multi contents 요소 내용 URL http://www.abc.com/bab/asdf meta 수집 문서의 속성들 content 수집 원본 HTML을 쓰기 편하게 파 싱한 XML raw 원본 HTML - 제휴에 의한 웹 수집 문서 인입이 발생 해서 추가적으로 컨텐츠를 저장하고 싶음 - 웹 수집 문서에 본문의 프로세싱 해서 얻은 정보를 미리 저장하고 싶음 - 결국.. 다른 생산 주체가 생산한 데이터가 같 이 요구 사항 meta 제휴 문서의 속성들 content 제휴 문서를 편하게 구성한 XML
- 48. 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로 구성
- 49. Filtered scan 웹 문서에서 meta 속성 중 documentType = D1 인 문서만 read 원함 SQL에서 where 절 비슷하게.. HBase scan은 다양한 filtering 기능을 가지고 있고 column 값에 의한 필터링 기능인 SingleColumnValueFilter 가 있음 그러나 content meta를 하나의 문자열 덩어리로 저장되어 filtering 기능을 사용하기 비 효율적임 요구 사항
- 50. 전송 프로토콜 변경 문서 전송 프로토콜 변경 Queue로 문서 전송 시 사용되는 프로토 콜변경 Multi Content 지원하도록 변경 특히 meta는 기존 문자열 덩어리 형태에서 Map 형태로 변경 document thrift meta(map) data content meta(map) data content meta (map) data content sysMeta
- 51. Column family 구성 document를 HBase에 어떻게 저장할 것인가? document meta data content meta data content meta data content sysMeta HBase Table Scan시 column filter 기능을 위해서 meta 데이터는 꼭 개별 컬럼으로 나 뉘어저장 되어야 함
- 52. Column family 구성 content 당 하나의 column family document meta data content meta data content meta data content sysMeta sysMeta content1 content2 content3 contentN
- 53. 문제 : 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 구성
- 54. 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
- 55. 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 가 능
- 56. 5. 데이터 정합성
- 57. 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
- 58. 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
- 59. 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
- 60. 데이터 중복 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
- 61. 데이터 중복 1. 보조 인덱스 생성 솔루션을 고려 2. Multi Table 간 트랜잭션 지원 솔루션을 고려 1, 2에 대한 다수의 오픈소스 솔루션들이 존재 (팀 내부에서 개발된 솔루션도 있음, 타 시스템에 적용되어 이미 사용) 해결 방안
- 62. 데이터 중복 - 트랜잭션 지원 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들에 대해서만 가능
- 63. 데이터 중복 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 용도를 구별
- 64. 트랜잭션 적용 효과 - index 용 row들과 데이터 불일치 해소 - 여러 row에 대한 put/delete 등의 operation을 한번의 RPC 요청으 로 처리하므로 throughput 향상 - 보조 index row를 추가할 여지 상승
- 65. 요구 사항 사용자 : 웹 수집문서 중에서 ‘http://www.abc.com/’ 로 시작하는 문서만 dump 받고 싶어요 cuve : scan에서 filter를 걸어서 사용하세요 사용자 : 일단 오래 걸리고, timeout 이 자주 발생해요 cuve : 네... timeout 시간을 늘려서 받으셔야 되요 수백억 몇 백만건 full scan web 보조 index row 추가
- 66. 보조 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)
- 67. 6. 그 외 저장소 구성 요소
- 68. 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 되어 있음
- 69. 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
- 70. DB 데이터 Pulling - Batch ProbeInputFormat extends InputFormat<Text, RecordWritable> Blog DB Blog DB Blog DB DBRecordReader mapper hadoop cluster Queue Kafka RecordSend ContentClean
- 71. 데이터 처리 모니터링 - 단위 시간당(day/hour/minute) 얼마만큼의 문서들이 생성/수정/삭제 되는가? - 전체 문서는 몇 건 인가? (그룹별, 메세지별 건 수, 디스크 사용량) - 개별 문서가 언제 생성/수정/삭제 되었는가? (문서 처리 이력) - Kafka, HBase에 저장된 문서를 볼 수 있어야 함
- 72. 사용자 관리 및 제어 - 대량으로 전송하고 있는 사용자는 누구인가? - 대량으로 소비하고 있는 사용자는 누구인가? - 데이터 접근 제어
- 73. Thank you
Hinweis der Redaktion
- 안녕하세요 네이버 서치에서 “검색 데이터 저장소” 개발/운영을 담당하고 있는 박범신 입니다 말씀드릴 내용은 검색에서 사용하는 데이터 저장소 개발에 관련된 내용입니다 요즘 점차 검색 말고 다른 용도로도 사용되고 있습니다 검색 부서는 예전부터 여러 데이터가 많이 사용되고 있어서 데이터 저장소를 개발하는 것이 타 부서에 비해 자연스러웠던 거 같습니다
- 목차는 다음과 같습니다
- 배경/ 현황을 보겠습니다
- 과거에는 데이터를 생산하는 사람과 데이터를 소비하는 사람들간에 직접 거래가 이루어지는 인간미 넘치는 아름다운 세상이었습니다 인간미 넘치는 아름다운 세상에서 데이터를 사용할 때는 아름아름 물어서 사용합니다 생산하는 데이터가 많아지고 소비하는 사람들이 많아지게 되면 아름아름하는 방식은 비용이 더 커지게 되죠
- 그래서 인간미를 뺀 좀 더 체계화되고 기계화된 세상을 만들기 위해서 CUVE 라는 이름의 검색 데이터 저장소를 개발하였습니다 CUVE는 데이터 저장 및 유통을 담당합니다
- 그럼 도데체 데이터가 얼마나 많길래? 란 생각이 드실 수 있는데요 웹수집 문서, 서비스 문서 등의 카테고리만 해도 수십개이고
- 블로그 데이터 하나만 보더라도 여러 종류의 데이터가 사용되는 것을 아실 수 있습니다.
- 생산자가 생산한 데이터를 API /Tool 제공합니다.
- Batch 형태 Stream 형태로 생성/수정/삭제를 제공합니다.
- 소비자는 다양한 데이터를 동일한 인터페이스로 제공받을 수 있습니다 실시간 read, 시간 기반으로 언제부터 언제까지의 데이터, 개별 데이터 read, 등의 인터페이스를 제공합니다.
- 저장된 데이터의 일람을 볼 수 있는 데이터 카탈로그를 갖추고 있습니다.
- 데이터 카탈로그를 통해서 데이터 종류를 볼 수 있고 데이터의 생김새를 알 수 있습니다 누가 생산했고 누가 소비하는지도 알 수 있으며 티켓 발급에 의한 접근제어 및 생산/소비량을 알 수 있습니다
- 현황은 이렇습니다 하루에 약 20억의 데이터가 들어오고 약 300억의 데이터를 읽어갑니다 수 페타 바이트의 규모이고 수천억건의 문서가 저장되어 있으며 5백여종의 데이터가 있습니다.
- 데이터 특성 데이터를 하나 하나 봐가면서 구분한 특징들은 아니고요 하기도 어렵죠.. 저희 저장소 운영 편의에 의한 데이터 분류입니다
- 불변 가변 데이터가 있습니다 가변 데이터는 생성/수정/삭제가 발생하는 데이터.. 불변 한번 생성되면 변하지 않는 분별 데이터가 있습니다 대표적인게 로그 데이터 생성/또는 관리 주체에 따른 분류 수집 데이터 내부 DB 데이터 제휴에 의한 데이터 이런 데이터를 가공한 정제 데이터 등이 있습니다
- 사용 패턴에 따른 분류입니다 생성 패턴 하루에 한번 전체 데이터를 생성하는 case 실시간으로 개별 문서가 건건이 생성/수정/삭제 등을 전달하는 데이터 소비 패턴은 하루에 한번 전체 데이터가 필요한 경우 단위시간당으로 읽어가는 경우 실시간으로 생성/수정/삭제 event 발생시마다 전달 받고 싶은 경우 등이 있습니다 텍스트 또는 멀티 미디어 데이터가 있습니다 현재는 텍스트와 이미지 데이터만 취급하고 있습니다.
- 본 발표에서는 실시간으로 생성/수정/삭제 되어 HBase에 저장되고 전체 타임 레인지 또는 실시간 read 되는 가변 컨텐츠 데이터에 집중해서 설명하겠습니다. 로그 같은 불변 데이터는 추후 기회가 있겠죠..
- 시간 범위 scan 리얼 타임 프로세싱 read 지원
- 설명 편의상 테이블의 로우키만 표현했습니다 로우키 byte로 구성되며 사전순으로 소팅되어 있습니다 엔터> 로우키는 Region 이라는 단위로 파티셔닝되며 엔터> 리전서버 데몬에 배치됩니다 엔터> 마찬가지로 key table 도 배치가 됩니다 리전은 리전서버에 고정되지 않습니다 실제 리전의 데이터들은 Hfile 형태로 HDFS 저장됩니다 리전서버가 장비장애 등으로 내려가면 리전은 다른 리전서버로 이동되어 계속 서비스 됩니다
- 처음 hbase 테이블을 봤을 때 바이트를 key 로 갖고 컬럼들이 밸류인 자바 sortedMap 인페이스와 비슷한 느낌을 받았습니다 자바 Map interface 와 비슷하게 put, get, delete 등을 지원합니다 특이하게 scan operation 이 존재하는데요 scan 은 startRow, stopRow 메소드로 특정 영역을 지정해서 특정 영역을 읽어낼 수 있음 startRow 와 stopRow 가 이럴 때는 녹색범위의 row 들이 대상이 됩니다 startRow 와 stopRow 가 이럴 때는 파란색범위의 row 들이 대상이 됩니다 이런 특성 때문에 row key를 어떻게 설계하느냐 중요합니다
- 웹 수집 문서가 있습니다 수집문서 구성을 보면 URL 있고 Meta 데이터, Content 가 있고 원본 HTML 이 있습니다 이러한 웹 수집 문서를 저장해야 된다는 것으로 부터 저장소 개발이 처음 시작되었습니다 수백억건 규모이고 더 늘어날 수 있으며 수십종류 카데고리로 있다고 했습니다 소비 패턴은 타임레인지 덤프 당연히 URL 로 개별 문서에 대한 접근을 지원해야죠
- 지금도 hbase 잘 아는 것은 아니지만 시작할 때 무지했습니다 까짓거 대~충 저장해주면 되지 하고 테이블 설계에 들어갑니다 웹 데이터니까 웹 테이블이라고 정하고 row key 를 잡아야죠 URL 을 MD5 Hash 로 ID 앞으로 용어들이 나온느데요 uniqueKey 는 URL ID 는 URL MD5 해쉬한 것으로 이해주시면 됩니다
- 로우키 그리 잡아서 저장하면 될 줄 알았는데 문제가 발생하죠 하루치 몇천만이 필요한데 전체 수백억건의 full scan 이 읽어납니다 느리죠.. 서버에서 filterting 하면 … 여전히 느리죠 못쓰죠.. full scan 하면 웬지 모르게 이 말이 생각나죠 index 를 타야지.. 그런데 HBase 테이블에는 DBMS 와 같은 보조 인덱스가 없습니다
- 그럼 모 웹 전체 말고 최대 읽어가는 주기는 얼마래? 한달? cache 테이블 한달짜리에 다가 한벌 더 저장하면되지 cache 테이블은 한달지난거 는 지워지게 하면되지 머 라고 생각했습니다 그래서 web cache table 을 하나 더 두면 된다고 생각했죠
- 카테고리별로 짧은 주기 읽기 범위가 달라서 cache 테이블 유지 기간이 다릅니다 이렇게 하면 웹, 블로그, 유투브 트위터, 카테고리를 추가할 때마다 테이블 2개씩 생성해야 됩니다 운영비용이 많이 들죠 좀 과장되게 얘기하면 개발끼 충만한 뉴비들이 와서 허걱하고 퇴사합니다
- 카테고리마다 cache 테이블을 유지것은 짧은 주기 읽기 디펜던트한 요소입니다 Time이 로우키에 들어가지 않으면 해결되지 않을 것 같아서 Time을 로우키에 추가하기로 합니다 이렇게 되면 cache 테이블을 유지할 필요가 없고 카테고리는 group 으로 해서 로우키에 추가하면 여러 테이블을 하나로 만들수 있습니다 그래서 doc table 을 만들었습니다 정리하면 group 2byte, messageType 1byte time 8byte id 16byte scan 할 때 web 에, 이미지 또는 문서 전체 읽겠다 하면 앞에 3byte 만 start, stop 로우 메소드에 지정하면 되죠.. web 에 문서 언제 부터 언제까지 읽겠다고 하면 Time 바이트 까지 지정하면 됩니다.
- row key 에 timestamp 같이 순차적으로 증가하는 값이 있는 경우 Hot spot 문제가 발생합니다 로우키 시작 byte 일정부분이 같게 되고 그렇게 되면 하나의 region 으로 write 가 몰리게 됩니다 리전이 많음에도 불구하고 write에 관여되는 리전은 적게 됩니다 write 성능이 떨어지죠 예를 들어 그림처럼 web 에 doc 을 짧은 기간에 1억간 쓰면 Region n 으로 몰리게 됩니다
- 몰리면 퍼트려야죠… 그래서 ID 를 통해서 모듈러스 연산한 Hash 2 byte 를 두기로 했습니다 몰리는 것을 방지하기 위해서 row 키 앞에 임의의 값을 두는 그런 것을 salt 라고 부른다고 합니다 그리고 테이블 생성초기 부터 여러 리전서버로 write 요청이 들어가도록 region 을 pre split 해서 2000개 두기로 했습니다
- URL 로 개별문서 읽기가 되지 않은 문제가 있습니다 로우키를 timestamp 를 몰라서.. 개별문서 읽기용 index 가 필요한데요 HBase 에는 말씀드렸다시피 table 에 서브 기능으로 보조 인덱스가 없으므로 개별문서 읽기용 index table 을 하나 더 두었습니다 로우키에 ID 를 먼저 배치해서 Hot spot 문제는 없습니다
- 최종적으로 2개의 테이블을 만들어습니다 doc 테이블에는 문서가 저장되어 있고 key 테이블은 개별 문서 접근용 index 테이블입니다 create 할 때는 doc put , key put update 할 때는 doc put, key put doc 에 이전row delete delete 는 사용자에게 전달해야 하므로 바로 삭제 하지 않고 삭제 플래그를 바꾸므로 업데이트와 마찬가지입니다
- 정리해보면 write 는 doc 은 salt, key 는 id 에 의해서 퍼지면서 쓰여집니다
- 타임 기반 순차 읽기는 소비자 측면에서 언제부터 언제까지 시간동안 생성/수정/삭제 된 문서만 읽기입니다 region1 ~ region n 까지 모든 리전을 읽어냅니다 대용량 분산 병렬처리에 용이합니다.
- 개별문서 읽기는 두 번 읽어야 하기에 비효율적인 면이 발생하지만 소비자 측면에서 순차 읽기에 비해 상대적으로 덜 발생합니다 먼저 key 테이블 읽고 doc table 로우키를 조합한 후에 doc 테이블을 읽어서 문서를 가져갑니다.
- 이제 컬럼 패밀리 얘기입니다 문서를 구성하는 요소 중에서 저장소에 필요한 system meta 데이터, unique key, 수정시간 등은 데이터 읽기가 제일 빈번합니다 content 는 데이터 가공에 주로 사용되므로 소비자 입장에서 꼭 필요하여 사용빈도가 높습니다 원본 HTML 은 파서 변경등올 채처리가 필요할 때만 읽게 되므로 사용빈도가 낮습니다
- 보시는 것처럼 4개의 컬럼 패밀리로 나뉘었는데요 HBASe 에서는 같은 컬럼 패밀리는 같은 Hfile 로 저장됩니다 그래서 모든 컬럼을 하나의 컬럼 패밀리로 저장하게 되면 하나의 HFile 로 저장되는데요 예를 들어서 저장소 배치작업을 위해서 전체 문서를 읽어야 한다고 했을 때 system meta 만 필요한데 하나의 hfile 로 되어 있으면 사용자 meta 데이터, content, 로우 html 등의 컬럼에 대해서 디스크 읽기가 들어가면 비효율적이게 되죠 그리고 로우 html 은 크기도 상대적으로 큽니다. 컬럼 패밀리를 나누게 되면 필요하지 않은 컬럼에 디스크 읽기가 발생하지 않기 때문에 효율적이게 됩니다.
- 그럼 이제 누가 hbase 에 write 할 것인가의 문제입니다
- HBase에 직접 넣고 빼는 API 및 Tool을 제공하여 처리 하려고 했으나 공통으로 처리해야 하는 부분들이 있었고 문서 처리 이력을 기록하는 것도 저장소가 가져야 할 기본 사항이 인 것을 고려하여 사용자 입력을 Q를 통해서 받기로 했습니다 Q는 Kafka 를 채용 했구요 kafka storm 조합을 많이 사용하여서 공통 처리는 storm 토폴로지로 하였습니다
- 처리량 증가를 위해서 .. 같은 u1 문서가 T1, T2, T3 로 업데이트 빨간색색 순서의 1, 2, 3 으로 Q로 전달 u1 문서의 최종상태는 S3 가 되어야 된다 storm 볼트에 의해서 쓰여질 때는 파란색 1, 2, 3 순으로 저장되어 상태가 S1 으로 맞지 않게 됩니다
- 문서를 쓰기 전에 읽어서 시간 선후관계를 따져서 저장 그림과 같이 순서를 따져보야 하는데요 여기서 이걸 따져볼 필요는 없겠죠.
- 문서를 읽고 시간 순서를 따지고나서 HBase 쓰기 순으로 작업이 되는데요 볼트 A, B 가 동시에 읽고 동시에 쓰는 경쟁상태가 발생합니다 문서의 상태를 보장할 수 없습니다
- HBAse 저장후에 카프카에도 저장 스톰말고도 spark 스트림으로 사용되고 있습니다
- hadoop 에서 데이터 접근하기 위한 InputFormat 인터페이스를 구현해놨습니다 spark 도 inputFormat 을 이용하기 때문에 스팍 rrd 생성도 편리하게 됩니다
- 앞단 Q 뒷단 Q … 결과적으로 괜찮은 구성 HBase 장애 또는 문서 처리 이상시에 Kafka offset을 돌려서 재처리, 운영 유연성 확보
- abc.com 에서 제휴가 발생 제휴문서 같이 저장 또는 웹 수집문서에서 본문 프로세싱된 부가정보 미리 저장 결국..
- 기존에는 하나의 메타와 컨텐츠 데이터를 가지고 있음 엔터> 여러 개의 컨텐를 가지도록.. syndiContent 가 제휴된 컨텐츠 anyContent는 부가적으로 생성한 컨텐츠
- 문서 전송 프로토콜을 변경
- 이제 확장된 도큐먼트를 어떻게 저장할까?
- content 당 하나의 컬럼 패밀리 구성 생각해 볼 수 있음
- 하나의 로우에 저장된 컬럼 구성들입니다 여기까지 30분..
- 다 읽고 처음에는 method 버그 모름 이럴 경우에 보통 우리 비즈니스 로직 점검 시간을 많이 들임 Hbase client 쪽 문제 인 것을 테스트를 통해서 알았으나 0.96 은 0.96.2 버전을 일찍 유지보수 끝내고 0.98 이 스테이블이 됨 10803 이슈 버그 패치는 안됨 우리가 해결할 수 밖에 없었음
- 버그 원인은 싱겁게도 client에서 exception 들 throw 하지 않음
- 삭제 되지 않은 row 때문에 문서 중복 저장 문제 발생 처음에 이런 상태에서 문서 업데이트가 발생 엔터>
- 1~3 에 연산이 atomic 하지 않아서 발생합니다 엔터> 그러나 multi table 트랜잭션이 지원되지 않습니다
- 성능에 이슈가 있거나 디스크 공간을 더 많이 사용하는 방식들.. 장비를 더 투입해야 함 성능저하 없는 방식으로 하고 싶었음
- 앞서 말씀드린 버그 트레이스중 알게된 내용 관련 내용을 찾아보니 이미 문서들이 존재했습니다 hbase 0.94 부터 멀티 테이블 아님 멀티 로우 트랜잭션을 지원 싱글로우 트랜잭션이던 멀티로우 트랜잭션이던 HRegion에 같은 메소드 호출 프로세스 로우 위드 락 메소드에 주석이 잘되어 있어서 설명 생략 client API 인… 동일 region에 존재하는 row 들에 대해서만 트랙잭션이 가능하므로 앞에 소개한 방식들보다 범용성은 떨어지지만 우리 상황에는 맞음
- 멀티 로우 트랜잭션이 동일 리전내에서만 가능하므로 …
- 보조 인덱스 로우 여지 상승에 힘입어 보조 인덱스 추가.. abc.com 문서 읽기