Druid 정리(1)

주요기능 
· 컬럼너 저장 포멧 
· 확장형 분산 시스템 
· 대용량 병렬 처리 
· 실시간 또는 일괄 처리 
· 자기 치유, 자기 균형 조정 
· 내결함성 아키텍처 
· 빠른 필터링을위한 인덱스 
· 근사치 알고리즘 
· ingest time에 자동 집계 


드루이드를 쓰면 좋을 때 
· 데이터 적재를 많이 하지만 업데이트가 적을 때 
· 대부분의 쿼리가 집계(group by), 검색, 스캔인 경우 
· 응답속도를 100ms 이하로 잡고 싶은 경우  
· 둘 이상의 테이블이 있는 경우 쿼리는 큰 테이블을 조회하고  작은 테이블을 lookup 함 
· 높은 카디널리티 데이터(URLs, user Ids)를 가지고 빠르게 카운팅, 랭킹을 구해야 하는 경우 
· kafka, HDFS, s3등과 같은 저장소에서 데이터를 로드하고 싶은 경우 


드루이드를 쓰면 좋지 않을 때 
· PK를 사용하여 빠르게 존재하는 레코드를 업데이트 하는 경우 (업데이트는 백그라운드 배치로 수행) 
· 쿼리 대기 시간이 중요하지 않은 오프라인 보고 시스템을 구축할 때 
· 하나의 큰 테이블이 다른 큰 테이블을 조인할 때 


아키텍쳐 

Historical node(람다 아키텍쳐에서 배치 뷰) 
  · 딥 스토리지로 부터 세그먼트를 다운 받아 처리하고 이 세그먼트에 대한 쿼리에 응답한다.

MiddleManager node 
  · 새로운 데이터를 외부 데이터 소스로 부터 받아 클러스터에 배포한다.

Broker node 
  · 외부 클라이언트에서 쿼리 요청을 받고 이 쿼리를 Historical와 MiddleManager에 전달한다. 
  · User는 Historical, MiddleManager에 직접 쿼리하기 보단 Broker에 쿼리하는게 좋다.

Coordinator node 
  · Historical 노드를 감시하고 세그먼트가 Historica 노드에 균형을 잘 유지하도록 한다.

Overlord node 
  · Ingestion Task를 MiddleManager에 할당하고 세그먼트 배포를 조정한다.

Router node (optional) 
  · Broker, Overlord, Coordinator 앞에서 API Gateway 역할한다. 
  · 각각의 노드 API에 직접 접근해도 된다. 

Datasource와 Chunk 

Datasource 
· RDMBS에서 테이블과 유사한 개념

· 기본적으로 시간으로 파티션 된다.(다른 속성으로도 가능)

· 각 시간 범위는 "chunk"라고 불려진다. 
  · 만약 데이터 소스가 하루 기준으로 파티션 되어 있으면 chunk는 하루

· 몇 개의 세그먼트, 최대 수십만 개, 심지어 수백만 개의 세그먼트로 구성 될 수 있다

· 각 세그먼트는 MiddleManager에서 생성되기 시작하며 그 시점에서 변경 가능하고 커밋되지 않는다.

· 세그먼트 작성 프로세스에는 소형 데이터 파일을 생성하고 빠른 쿼리를 지원하도록 설계된 다음 단계가 포함된다. 
  · 컬럼 형식으로 변환 
  · 비트 맵 인덱스로 인덱싱하기 
  · 다양한 알고리즘을 사용한 압축 
  · 문자열 열에 대한 ID 저장소 최소화로 사전 인코딩 
  · 비트 맵 인덱스의 비트 맵 압축 
  · 모든 열에 대한 유형 인식 압축 

정기적으로 세그먼트는 커밋되고 배포된다. 이 시점에 deep storage에 쓰여지고 불변상태가 되며 MiddleManager에서 Historical process로 이동한다. 세그먼트에 대한 정보(스키마, 사이즈, 딥스토리지 위치)는 metadata store에도 쓰여진다. -> 코디네이터 노드가 데이터를 파악하기 위함 

Chunk 
· 청크 안에 데이터는 여러 개의 세그먼트로 파티션 된다. 
· 세그먼트는 수백만 행의 데이터를 포함하는 하나의 파일이다. 

쿼리 프로세싱 
· Broker에서 해당 세그먼트와 관련된 데이터가 있는 세그먼트를 식별한다

· 세그먼트 목록은 시간에 따라 항상 제거되며 데이터 소스가 분할되는 방식에 따라 다른 속성에 의해 제거 될 수도 있다.

· 브로커는 어떤 Historicals 및 MiddleManagers가 해당 세그먼트를 제공하고 있는지 식별하고 각 프로세스에 다시 작성된 하위 쿼리를 보낸다. 

· Historical / MiddleManager 프로세스는 쿼리를 처리하고 처리하여 결과를 반환한다.

· Broker는 결과를 받고 이를 합쳐 요청자에 반환한다. 

드루이드는 쿼리 성능을 극대화하기 위한 3가지 기술을 사용한다. 
· 각 쿼리에 대해 액세스 할 세그먼트를 식별한다. 
· 각 세그먼트 내에서 인덱스를 사용하여 액세스해야하는 행을 식별한다. 
· 각 세그먼트 내에서 특정 검색어와 관련된 특정 행 및 열만 읽는다. 

External Dependencies

Deep storage 
· 세그먼트를 영구적으로 저장하기 위한 영역 
· HDFS, S3, Local등..

Metadata storage 
· 세그먼트 가용성 정보 및 작업 정보와 같은 다양한 시스템 메타 데이터를 보유한다.

Zookeeper 
· 현재 클러스터 상태를 관리하기 위해 주키퍼를 사용한다. 
  · 코디네이터 리더 선출 
  · Historical 및 Realtime에서 세그먼트를 "publishing"한다. 
  · Coorinator와 Historical간에 세그먼트 load / drop 
  · Overlord 리더 선출 
  · 인덱싱 서비스 작업 관리