네이버 로그를 지탱하는 힘
(DataStore 로그 저장소) #
로그 저장 이야기
기존 문제
- 생산자와 소비자의 강한 결합
- 유실 없는 로그 저장
- At-least-once Delivery
- 데이터 중복 발생 가능
- 고유 식별자를 바탕으로 RowKey 생성
- 같은 로그는 하나의 고유한 식별자가 할당되어야
- How?
- Hash값
- 시퀀스 값 발급
- UUID (범용 고유 식별자)
- 원하는 기간
- 필요한 필드만
- 돌일한 인터페이스
- 보안 정보 처리
- 보안 정보 분리 저장
- 주기적 삭제
- 데이터 접근 제어
- 데이터를 읽는 패턴과 포맷이 비슷하면 같은 Column Family로 묶는 것이 효율적
- 저장 공간을 용도별로 나눈다
Data Catalog
- 사용자 역할 관리
- 데이터 필드 정보 및 포맷 관리
- 티켓
- RGM과 티켓 정보만 알면 로그 사용 가능
로그 활용의 문제점
- 번거로운 프로세스
- 원하는 시점에 분석 힘듬 (수동적)
- 부정확한 지표 (폐쇄적)
- 중복된 추출 로직
- 반복적인 추출 로직
- 서비스에 대한 이해 부족
=> DataStore
비 개발 작군에게는 사용성의 한계
=> SQL 인터페이스
특정 기간을 기준으로 하면 빠름
컬럼을 해시 기준으로 지정된 버킷 개수의 파일로 분리해 저장
- partition 날짜 기준 지정 = 디렉토리
- bucket 검색어 기준 분류 = 파일
bucket
- 특정 검색어가 집중되면
- 해당 검색어 bucket 파일 사이저가 커짐
- 해당 bucket의 생성 시간이 오래 걸림
- shuffle 단계에서 메모리 에러
- 위의 문제를 해결하기 위해 메모리를 늘려줄 필요
External Table
- 안전
- HDFS가 아니여도 Table화 가능
- 데이터 소스 변경 용이