데이터 롤업

데이터 롤업 (Data rollup)

Druid는 수집 시점에 데이터를 롤업해서 디스크에 저장할 원본 데이터 양을 줄일 수 있어요. 롤업(rollup)은 일종의 요약 또는 사전 집계(pre-aggregation)예요. 데이터를 롤업하면 저장 데이터 크기를 크게 줄이고, 행 수를 때로는 수 자릿수(order of magnitude)까지 줄일 수 있지요. 그 대가로 개별 이벤트를 쿼리하는 능력은 잃어요. 효율과 정밀함 사이의 트레이드오프를 이해하고 결정하는 게 중요합니다.

출처: Apache Druid 공식 문서 — Data rollup

본문

수집 시점에 롤업은 granularitySpec의 rollup 설정으로 제어해요. 롤업은 기본적으로 활성화됩니다. 즉 Druid는 queryGranularity 기반 절단 이후 dimension 값과 timestamp 값이 같은 행들을 한 행으로 합쳐요.

롤업을 끄면 Druid는 어떤 사전 집계도 없이 각 행을 그대로 로드해요. 이 모드는 롤업 기능이 없는 데이터베이스와 비슷하지요. 각 레코드를 요약 없이 그대로 저장하고 싶으면 rollup을 false로 설정하세요.

다음 두 조건을 모두 만족하면 테이블 datasource를 만들 때 롤업을 쓰는 게 좋아요.

  • 최적의 성능을 원하거나 저장 공간 제약이 엄격한 경우
  • 고기수성 dimension의 원시 값이 필요 없는 경우

반대로 다음 중 하나라도 해당하면 롤업을 끄세요.

  • 개별 행에 대한 결과가 필요한 경우
  • 어떤 컬럼에든 GROUP BY나 WHERE 쿼리를 실행해야 하는 경우

유스케이스별로 요구가 충돌하면, 테이블마다 다른 롤업 설정을 가진 여러 테이블을 만들 수도 있어요.

롤업 비율 극대화 (Maximizing rollup ratio)

datasource의 롤업 비율을 측정하려면 Druid의 행 수(COUNT)와 수집된 이벤트 수를 비교해 보세요. 예를 들어 정수 타입 metric이 가리키는 행 수 COUNT를 보는 Druid SQL 쿼리를 실행해 볼게요. 여기서 "num_rows"는 수집 시점에 만들어진 count-타입 metric이에요.

SELECT SUM("num_rows") / (COUNT(*) * 1.0) FROM datasource

결과가 높을수록 롤업에서 얻는 이점이 커요. 롤업 활성화 상태에서 카운팅이 어떻게 동작하는지 자세히 보려면 수집된 이벤트 수 세기를 참고하세요.

롤업을 극대화하는 팁이에요.

  • dimension을 더 적게, 더 낮은 기수성으로 설계하면 롤업 비율이 좋아져요.
  • sketch를 사용해 고기수성 dimension 저장을 피하세요 — 이들은 롤업 비율을 떨어뜨려요.
  • 수집 시점에 queryGranularity를 조정해 Druid에서 여러 행이 같은 timestamp를 가질 가능성을 높여 보세요. 예를 들어 1분(PT1M) 대신 5분 쿼리 granularity(PT5M)를 쓰는 거예요.
  • 같은 데이터를 Druid datasource 두 개 이상에 로드할 수도 있어요. 예:
    • 롤업이 꺼져 있거나 최소 롤업 비율로 켜져 있는 "full" datasource를 만들고,
    • dimension이 더 적고 롤업 비율이 더 높은 두 번째 "abbreviated" datasource를 만들어요. 쿼리가 "abbreviated" 집합의 dimension만 관련되면 두 번째 datasource를 써서 쿼리 시간을 줄여요. 흔히 이 방법은 저장 공간을 조금만 더 쓰는데, abbreviated datasource가 훨씬 작아지는 경향이 있기 때문이에요.
  • 완벽한 롤업을 보장하지 않는 best-effort 롤업 수집 설정을 쓴다면 다음 중 하나를 시도해 보세요.
    • 보장된 perfect rollup 옵션으로 전환하거나,
    • 초기 수집 후 백그라운드에서 데이터를 Reindex 하거나 compact 해요.

Perfect rollup vs best-effort rollup

수집 방식에 따라 Druid는 다음 롤업 옵션을 제공해요.

  • 보장된 perfect rollup: Druid가 수집 시점에 입력 데이터를 완벽하게 집계해요.
  • Best-effort rollup: Druid가 입력 데이터를 완벽하게 집계하지 못할 수 있어요. 따라서 여러 세그먼트에 같은 timestamp·dimension 값을 가진 행이 남을 수 있지요.

일반적으로 best-effort 롤업을 제공하는 수집 방식은 다음 이유 중 하나로 그렇게 해요.

  • 수집 방식을 perfect rollup에 필요한 셔플링 단계 없이 병렬화한 경우
  • 수집 방식이 증분 발행(incremental publishing) 을 쓰는 경우 — 즉 시간 청크의 모든 데이터를 받기 전에 세그먼트를 확정·발행해요.

이 두 경우 모두 이론적으로 롤업될 수 있는 레코드가 서로 다른 세그먼트에 담길 수 있어요. 모든 스트리밍 수집 방식은 이 모드로 실행됩니다.

Perfect rollup을 보장하는 수집 방식은 데이터 수집 전에 인터벌과 파티셔닝을 정하는 추가 전처리 단계를 사용해요. 이 전처리 단계는 입력 데이터셋 전체를 스캔하지요. 시간은 늘지만 perfect rollup에 필요한 정보를 얻을 수 있어요.

다음 표는 각 방식이 롤업을 어떻게 처리하는지 보여줘요.

방식 동작 방식
Native batch index_parallel와 index 타입은 설정에 따라 perfect 또는 best-effort일 수 있어요.
SQL 기반 배치 항상 perfect.
Kafka indexing service 항상 best-effort.
Kinesis indexing service 항상 best-effort.

더 알아보기