Ingestion spec 레퍼런스

모든 수집 방법은 ingestion task를 사용해서 데이터를 Druid에 로드해요. 스트리밍 수집은 시간에 걸쳐 태스크 집합을 실행하고 감독하는 지속적인 supervisor를 사용하고, 네이티브 배치는 일회성 태스크를 사용합니다. SQL 기반 수집을 제외하고는 ingestion spec으로 수집을 구성합니다.

Ingestion spec은 세 가지 주요 컴포넌트로 구성돼요.

dataSchema — datasource 이름, 기본 타임스탬프, dimension, metric, 그리고 (필요하면) transform과 filter를 구성
ioConfig — Druid가 소스 시스템에 어떻게 연결하고 데이터를 어떻게 파싱할지 알려 줌. 자세한 내용은 각 수집 방법의 문서를 참고
tuningConfig — 각 수집 방법에 특화된 다양한 튜닝 파라미터 제어

태스크 타입 index_parallel(네이티브 배치)의 ingestion spec 예시:

{  "type": "index_parallel",  "spec": {    "dataSchema": {      "dataSource": "wikipedia",      "timestampSpec": {        "column": "timestamp",        "format": "auto"      },      "dimensionsSpec": {        "dimensions": [          "page",          "language",          { "type": "long", "name": "userId" }        ]      },      "metricsSpec": [        { "type": "count", "name": "count" },        { "type": "doubleSum", "name": "bytes_added_sum", "fieldName": "bytes_added" },        { "type": "doubleSum", "name": "bytes_deleted_sum", "fieldName": "bytes_deleted" }      ],      "granularitySpec": {        "segmentGranularity": "day",        "queryGranularity": "none",        "intervals": [          "2013-08-31/2013-09-01"        ]      }    },    "ioConfig": {      "type": "index_parallel",      "inputSource": {        "type": "local",        "baseDir": "examples/indexing/",        "filter": "wikipedia_data.json"      },      "inputFormat": {        "type": "json",        "flattenSpec": {          "useFieldDiscovery": true,          "fields": [            { "type": "path", "name": "userId", "expr": "$.user.id" }          ]        }      }    },    "tuningConfig": {      "type": "index_parallel"    }  }}

이 섹션들이 지원하는 구체적 옵션은 선택한 수집 방법에 따라 달라져요. 더 많은 예시는 각 수집 방법의 문서를 참고하세요.

ingestion spec을 작성하지 않고도 Druid 웹 콘솔의 "Load data" 기능으로 시각적으로 데이터를 로드할 수 있습니다. Druid의 시각적 데이터 로더는 Kafka, Kinesis, 네이티브 배치 모드를 지원해요.

출처: 문서

본문

dataSchema

dataSchema는 다음 컴포넌트를 담는 컨테이너예요.

datasource 이름
기본 타임스탬프
dimensions
metrics
transforms와 filters (필요한 경우)

dataSchema 예시:

"dataSchema": {  "dataSource": "wikipedia",  "timestampSpec": {    "column": "timestamp",    "format": "auto"  },  "dimensionsSpec": {    "dimensions": [      "page",      "language",      { "type": "long", "name": "userId" }    ]  },  "metricsSpec": [    { "type": "count", "name": "count" },    { "type": "doubleSum", "name": "bytes_added_sum", "fieldName": "bytes_added" },    { "type": "doubleSum", "name": "bytes_deleted_sum", "fieldName": "bytes_deleted" }  ],  "granularitySpec": {    "segmentGranularity": "day",    "queryGranularity": "none",    "intervals": [      "2013-08-31/2013-09-01"    ]  }}

dataSource

dataSource는 dataSchema → dataSource에 위치하며, 데이터가 기록될 datasource의 이름입니다. dataSource 예시:

"dataSource": "my-first-datasource"

timestampSpec

timestampSpec은 dataSchema → timestampSpec에 위치하며 기본 타임스탬프를 구성하는 역할을 해요. timestampSpec 예시:

"timestampSpec": {  "column": "timestamp",  "format": "auto"}

정보

개념적으로 입력 데이터 레코드를 읽은 뒤 Druid는 ingestion spec 컴포넌트를 특정 순서로 적용해요: 먼저 flattenSpec(있으면), 그다음 timestampSpec, 그다음 transformSpec, 마지막으로 dimensionsSpec과 metricsSpec. ingestion spec을 작성할 때 이 순서를 기억하세요.

timestampSpec은 다음 컴포넌트를 가질 수 있어요.

| Field | Description | Default | | column | 기본 타임스탬프를 읽을 입력 행 필드. 이 입력 필드의 이름과 무관하게 기본 타임스탬프는 항상 Druid datasource에서 __time이라는 이름의 컬럼으로 저장됨 | timestamp | | format | 타임스탬프 형식. 옵션: - iso: 'T' 구분자가 있는 ISO8601, 예: "2000-01-01T01:02:03.456" - posix: epoch 이후 초 - millis: epoch 이후 밀리초 - micro: epoch 이후 마이크로초 - nano: epoch 이후 나노초 - auto: ISO('T' 또는 공백 구분자) 또는 millis 형식을 자동 감지 - 아무 Joda DateTimeFormat 문자열 | auto | | missingValue | null 또는 누락된 타임스탬프 column을 가진 입력 레코드에 사용할 타임스탬프. format에 다른 것을 지정했더라도 ISO8601 형식(예: "2000-01-01T01:02:03.456")이어야 함. Druid는 기본 타임스탬프를 요구하므로, 이 설정은 레코드별 타임스탬프가 전혀 없는 데이터셋을 수집할 때 유용 | none |

Druid가 transform을 적용하기 전에 timestampSpec을 파싱하므로 표현식에서 타임스탬프를 __time으로 사용할 수 있어요. 표현식의 name을 __time으로 설정해서 타임스탬프 값을 대체할 수도 있습니다.

__time을 밀리초 타임스탬프(1970년 1월 1일 자정 UTC 이후의 밀리초 수)로 취급하세요.

dimensionsSpec

dimensionsSpec은 dataSchema → dimensionsSpec에 위치하며 dimension을 구성하는 역할을 해요.

dimension을 직접 지정하거나, Druid가 데이터의 스키마 전체 또는 일부를 추론하도록 하는 스키마 자동 발견(schema auto-discovery)을 활용할 수 있습니다. 즉 dimension과 그 타입을 명시적으로 지정하지 않아도 됩니다.

스키마 자동 발견을 사용하려면 useSchemaDiscovery를 true로 설정하세요. 또는 문자열 기반 schemaless 수집(발견된 모든 dimension을 문자열로 취급)을 사용할 수 있는데, 이를 위해 useSchemaDiscovery를 false(기본값)로 두고 dimensions 목록을 비우거나 includeAllDimensions 속성을 true로 설정합니다.

다음 dimensionsSpec 예시는 명시적으로 정의된 dimension과 함께 스키마 자동 발견("useSchemaDiscovery": true)을 사용해서 Druid가 데이터의 일부 스키마를 추론하게 합니다.

"dimensionsSpec" : {  "dimensions": [    "page",    "language",    { "type": "long", "name": "userId" }  ],  "dimensionExclusions" : [],  "spatialDimensions" : [],  "useSchemaDiscovery": true}

정보

dimensionsSpec은 다음 컴포넌트를 가질 수 있어요.

| Field | Description | Default | | dimensions | dimension 이름 또는 객체의 목록. dimensions와 dimensionExclusions 둘 다에 같은 컬럼을 포함할 수 없음. dimensions와 spatialDimensions가 둘 다 null 또는 빈 배열이면 Druid는 dimensionExclusions에 나타나지 않는 timestamp·metric 이외의 모든 컬럼을 String 타입 dimension 컬럼으로 취급. 자세한 내용은 inclusions and exclusions 참고. 모범 사례로 가장 자주 필터링되는 dimension을 dimension 목록의 앞쪽에 두세요. 이 경우 같은 dimension으로 partitioning하는 것도 고려해 보는 게 좋음. | [] | | dimensionExclusions | 수집에서 제외할 dimension 이름. 여기서는 이름만 지원하고 객체는 지원하지 않음. 이 목록은 dimensions와 spatialDimensions 목록이 둘 다 null 또는 빈 배열일 때만 사용되고, 그 외에는 무시됨. 자세한 내용은 아래 inclusions and exclusions 참고 | [] | | spatialDimensions | spatial dimensions의 배열. | [] | | includeAllDimensions | 이 필드는 발견한 dimension을 문자열로 수집하는 문자열 기반 스키마 발견에만 적용됨. 데이터의 타입을 추론하는 스키마 자동 발견과는 다름. includeAllDimensions를 true로 설정하면 dimensions 필드의 명시적 dimension과 수집 태스크가 입력 데이터에서 발견한 다른 dimension을 모두 수집할 수 있음. 이 경우 명시적 dimension이 지정한 순서대로 먼저 나타나고, 동적으로 발견된 dimension이 뒤에 옴. 이 플래그는 특히 flattenSpec을 사용한 자동 스키마 발견에서 유용. 설정하지 않고 dimensions 필드가 비어 있지 않으면 Druid는 명시적 dimension만 수집. 설정하지 않고 dimensions 필드가 비어 있으면 발견된 모든 dimension이 수집됨 | false | | useSchemaDiscovery | Druid가 스키마 자동 발견을 사용해서 데이터의 일부 또는 모든 dimension·타입을 발견하도록 구성. 균일한 타입이 아닌 dimension은 Druid가 JSON으로 수집함. 네이티브 배치 또는 스트리밍 수집에 사용할 수 있음 | false | | forceSegmentSortByTime | true(기본값)로 설정하면 수집 작업이 만든 세그먼트가 {__time, dimensions[0], dimensions[1], ...}로 정렬됨. false로 설정하면 수집 작업이 만든 세그먼트가 {dimensions[0], dimensions[1], ...}로 정렬됨. 이 파라미터를 false로 설정할 때 __time을 정렬 순서에 포함하려면 dimensions 목록에 long 타입의 __time이라는 dimension을 명시적으로 포함해야 함. false로 설정하는 것은 실험적 기능이며 자세한 내용은 Sorting 참고 | true |

Dimension 객체

dimensions 목록의 각 dimension은 이름 또는 객체일 수 있어요. 이름을 제공하는 것은 주어진 이름의 string 타입 dimension 객체를 제공하는 것과 동일합니다(예: "page"는 {"name": "page", "type": "string"}과 동일).

Dimension 객체는 다음 컴포넌트를 가질 수 있어요.

| Field | Description | Default | | type | auto, string, long, float, double, json 중 하나. auto 타입의 경우 Druid가 dimension에 가장 적절한 타입을 결정해서 STRING, ARRAY, LONG, ARRAY, DOUBLE, ARRAY, COMPLEX 컬럼 중 하나를 할당하며, 모두 공통 'nested' 형식을 공유. Druid가 스키마 자동 발견으로 스키마를 추론할 때 타입은 auto임 | string | | name | dimension의 이름. 입력 레코드에서 읽을 필드 이름이자 생성된 세그먼트에 저장되는 컬럼 이름. 수집 중 컬럼 이름을 바꾸고 싶다면 transformSpec을 사용할 수 있음에 유의 | none (필수) | | createBitmapIndex | string 타입 dimension에 대해, 생성된 세그먼트의 컬럼에 bitmap 인덱스가 생성될지 여부. bitmap 인덱스를 만들면 저장 공간이 더 필요하지만 특정 종류의 필터링(특히 동등·접두사 필터링)이 빨라짐. string 타입 dimension에서만 지원 | true | | multiValueHandling | string 타입 dimension에 대해 multi-value 필드의 처리 타입을 지정. 가능한 값은 array(문자열 배열을 그대로 수집), sorted_array(수집 중 문자열 배열 정렬), sorted_set(수집 중 문자열 배열 정렬 및 중복 제거). string 외 타입에서는 이 파라미터가 무시됨 | sorted_array | | maxStringLength | string 타입 dimension에 대해 값당 저장할 최대 문자 수. 더 긴 값은 수집 중 절단됨. multi-value 문자열 dimension에는 적용되지 않음. 전역 druid.indexing.formats.maxStringLength 속성을 덮어씀. 값은 >= 0이어야 함 | null (절단 없음) |

Inclusions and exclusions

Druid는 dimensionsSpec을 normal 또는 schemaless 두 가지 방식으로 해석합니다.

dimensions 또는 spatialDimensions 중 하나가 비어 있지 않으면 normal 해석이 발생해요. 이 경우 두 목록의 조합이 수집할 dimension 집합으로 취급되고, dimensionExclusions 목록은 무시됩니다.

정보

다음 schemaless 설명은 Druid가 발견한 dimension을 문자열로 취급하는 문자열 기반 schemaless를 가리켜요. 우리는 Druid가 dimension의 타입을 추론하는 스키마 자동 발견을 권장합니다. 자세한 내용은 dimensionsSpec 참고.

dimensions와 spatialDimensions가 둘 다 비어 있거나 null이면 schemaless 해석이 발생합니다. 이 경우 dimension 집합은 다음과 같은 방식으로 결정됩니다.

먼저 inputFormat에 의해 결정된 입력 레코드의 모든 최상위(root-level) 필드 집합에서 시작. "Root-level"은 데이터 구조의 최상위에 있는 모든 필드를 포함하지만, map이나 list 안에 중첩된 필드는 포함하지 않음. 이것들을 추출하려면 flattenSpec을 사용해야 함. CSV나 구분 텍스트 같은 비중첩 데이터 형식의 모든 필드는 최상위로 간주
flattenSpec을 사용 중이라면 최상위 필드 집합은 flattenSpec이 생성한 모든 필드를 포함. useFieldDiscovery 파라미터가 원래 최상위 필드를 유지할지 버릴지 결정
dimensionExclusions에 나열된 모든 필드는 제외
timestampSpec의 column으로 나열된 필드는 제외
metricsSpec의 애그리게이터 입력으로 사용되는 모든 필드는 제외
metricsSpec의 애그리게이터와 같은 이름을 가진 모든 필드는 제외
다른 모든 필드는 기본 설정으로 string 타입 dimension으로 수집

추가로, 문자열 기반 schemaless 수집에 포함하고 싶은 빈 컬럼이 있다면 storeEmptyColumns 컨텍스트 파라미터를 포함해서 true로 설정해야 합니다.

정보

참고: transformSpec이 생성한 필드는 현재 schemaless dimension 해석의 후보로 간주되지 않습니다.

metricsSpec

metricsSpec은 dataSchema → metricsSpec에 위치하며 수집 시점에 적용할 애그리게이터 목록이에요. 이것은 수집-시점 집계를 구성하는 방법이므로 롤업이 활성화됐을 때 가장 유용합니다.

metricsSpec 예시:

"metricsSpec": [  { "type": "count", "name": "count" },  { "type": "doubleSum", "name": "bytes_added_sum", "fieldName": "bytes_added" },  { "type": "doubleSum", "name": "bytes_deleted_sum", "fieldName": "bytes_deleted" }]

정보

일반적으로 롤업이 비활성화되면 metricsSpec을 비워 두어야 해요(롤업이 없으면 Druid는 수집-시점 집계를 하지 않으므로 수집-시점 애그리게이터를 포함할 이유가 거의 없음). 다만 어떤 경우에는 metric을 정의하는 것이 여전히 의미 있을 수 있는데, 예를 들어 근사 집계의 일부를 미리 계산하는 방법으로 복잡한(complex) 컬럼을 만들고 싶다면 metricsSpec에서 metric을 정의하는 것만으로 가능합니다.

granularitySpec

dataSchema → granularitySpec에 위치한 granularitySpec은 다음을 지정해요.

segmentGranularity — datasource를 시간 청크로 파티셔닝
queryGranularity — 타임스탬프를 선택적으로 절단
intervals — 배치 수집을 위해 만들 세그먼트의 시간 청크 정의
rollup — 수집-시점 롤업 활성화 여부

rollup을 제외하고 이 작업들은 모두 기본 타임스탬프에 기반합니다. segmentGranualarity와 queryGranularity를 지정할 때는 [Query granularities]의 형식을 사용하세요.

granularitySpec 예시:

"granularitySpec": {  "segmentGranularity": "day",  "queryGranularity": "none",  "intervals": [    "2013-08-31/2013-09-01"  ],  "rollup": true}

granularitySpec은 다음 컴포넌트를 가질 수 있어요.

| Field | Description | Default | | type | uniform | uniform | | segmentGranularity | 이 datasource의 시간 청킹 granularity. 시간 청크당 여러 세그먼트를 만들 수 있음. 예를 들어 day로 설정하면 같은 날의 이벤트는 같은 시간 청크에 들어가고, 다른 구성·입력 크기에 따라 선택적으로 여러 세그먼트로 더 파티셔닝될 수 있음. 여기에는 어떤 granularity든 제공할 수 있음. 같은 시간 청크의 모든 세그먼트는 같은 세그먼트 granularity를 가져야 함에 유의. 데이터 파티셔닝에는 WEEK granularity를 피하세요. 주가 월·연과 깔끔하게 정렬되지 않아 더 거친 granularity로 파티셔닝을 바꾸기가 어렵기 때문. 대신 더 유연한 DAY나 MONTH 같은 다른 파티셔닝 옵션을 선택하세요. | day | | queryGranularity | 각 세그먼트 안 타임스탬프 저장의 해상도. segmentGranularity보다 같거나 더 세밀해야 함. 이 granularity가 합리적인 결과를 얻으며 쿼리할 수 있는 가장 세밀한 단위가 되지만, 이 granularity보다 거친 것으로는 여전히 쿼리할 수 있음에 유의. 예: minute 값은 레코드가 분 단위로 저장되고 분의 배수(분, 5분, 시간 단위 등)로 합리적으로 쿼리될 수 있음을 의미. 여기에는 어떤 granularity든 제공할 수 있음. none을 사용하면 타임스탬프를 절단 없이 그대로 저장. queryGranularity가 none으로 설정돼도 rollup이 설정되어 있으면 적용됨에 유의 | none | | rollup | 수집-시점 rollup 사용 여부. queryGranularity가 none으로 설정돼도 롤업이 여전히 유효함에 유의. 데이터가 정확히 같은 타임스탬프를 가지면 롤업됨 | true | | intervals | 세그먼트의 시간 청크를 정의하는 interval 목록. interval 값을 ISO8601 형식으로 지정. 예: ["2021-12-06T21:27:10+00:00/2021-12-07T00:00:00+00:00"]. 시간을 생략하면 기본값은 "00:00:00". Druid는 목록을 분할하고 segmentGranularity에 따라 목록 값을 반올림. null이거나 제공되지 않으면 배치 수집 태스크는 일반적으로 입력 데이터에서 찾은 타임스탬프에 기반해 어떤 시간 청크를 출력할지 결정. 지정되면 배치 수집 태스크가 파티션 결정 단계를 건너뛸 수 있어 수집이 더 빨라질 수 있음. 배치 수집 태스크는 잠금을 하나씩 대신 한 번에 모두 요청할 수도 있음. 배치 수집 태스크는 지정된 interval 밖의 타임스탬프를 가진 모든 레코드를 버림. 어떤 형태의 스트리밍 수집에서도 무시됨 | null |

transformSpec

transformSpec은 dataSchema → transformSpec에 위치하며 수집 중 레코드를 변환·필터링하는 역할을 해요. 선택 사항입니다. transformSpec 예시:

"transformSpec": {  "transforms": [    { "type": "expression", "name": "countryUpper", "expression": "upper(country)" }  ],  "filter": {    "type": "selector",    "dimension": "country",    "value": "San Serriffe"  }}

정보

Transforms

transforms 목록을 사용하면 입력 데이터 위에서 평가할 표현식 집합을 지정할 수 있어요. 각 transform은 dimensionsSpec, metricsSpec 등에서 참조할 수 있는 "name"을 가집니다.

transform이 입력 행의 필드와 같은 이름을 가지면 원래 필드를 가립니다(shadow). 필드를 가리는 transform은 자신이 가리는 필드를 여전히 참조할 수 있어요. 이것을 사용해서 필드를 "제자리에서(in-place)" 변환할 수 있습니다.

Transforms에는 몇 가지 제한이 있어요. 실제 입력 행에 있는 필드만 참조할 수 있고, 특히 다른 transform은 참조할 수 없습니다. 또 필드를 제거할 수 없고 추가만 가능합니다. 다만 필드를 모두 null로 가진 다른 필드로 가릴 수 있는데, 이는 필드를 제거하는 것과 비슷하게 동작합니다.

Druid는 현재 한 종류의 내장 transform인 expression transform을 포함합니다. 구문은 다음과 같아요.

{  "type": "expression",  "name": "<output name>",  "expression": "<expr>"}

expression은 Druid 쿼리 표현식입니다.

정보

Filter

filter는 수집 중 입력 행을 조건부로 필터링합니다. filter를 통과한 행만 수집됩니다. Druid의 표준 쿼리 필터를 어떤 것이든 사용할 수 있어요. transformSpec 안에서는 transforms가 filter보다 먼저 적용되므로 filter가 transform을 참조할 수 있음에 유의하세요.

Projections

Projections는 Druid가 세그먼트의 dimension·metric 부분 집합에 대해 계산하는 수집/컴팩션 시점 집계예요. 세그먼트 안에 저장됩니다. 사전 집계된 데이터는 쿼리를 실행할 때 쿼리 엔진이 처리해야 하는 행 수를 줄여 줍니다. 이는 projection과 일치하는 쿼리 형태에 대해 쿼리를 빠르게 할 수 있어요.

새 데이터 소스의 projection은 수집 중 projectionsSpec 블록에서 정의하세요. 기존 데이터 소스에 projection을 추가하려면 이후에 만들어 추가하세요.

정보

정의한 projections는 datasource의 dimension이 됩니다. datasource에서 projection을 제거하려면 그 projection을 제거한 채로 데이터를 다시 수집해야 해요. 또는 쿼리 컨텍스트 파라미터를 사용해서 특정 쿼리에 대해 projection을 사용하지 않게 할 수 있습니다.

"projectionsSpec": {  "projections": [    {      "name": "daily_channel_summary",      "dimensions": [        "channel"        ],      "granularity": "DAY",      "metrics": [        {           "type": "longSum",           "name": "total_added",           "fieldName": "added"           },        { "type": "longSum",         "name": "total_deleted",         "fieldName": "deleted"         },        { "type": "longSum",         "name": "total_delta",         "fieldName": "delta"         },        {           "type": "cardinality",           "name": "distinct_users",           "fieldName": "user"           }      ]    }  ]}

ioConfig

ioConfig는 Apache Kafka, Amazon S3, 마운트된 파일시스템, 또는 다른 지원되는 소스 시스템 같은 소스 시스템에서 데이터를 어떻게 읽을지에 영향을 줍니다. inputFormat 속성은 모든 수집 방법에 적용됩니다. ioConfig의 나머지는 각 개별 수집 방법에 특화됩니다. JSON 데이터를 읽는 ioConfig 예시:

"ioConfig": {    "type": "<ingestion-method-specific type code>",    "inputFormat": {      "type": "json"    },    ...}

자세한 내용은 각 수집 방법이 제공하는 문서를 참고하세요.

tuningConfig

튜닝 속성은 인제션 spec의 최상위에 가는 tuningConfig 객체에 지정합니다. 일부 속성은 모든 수집 방법에 적용되지만, 대부분은 각 개별 수집 방법에 특화됩니다.

다음 표는 수집 방법들 사이에 공유되는 공통 튜닝 속성을 나열합니다.

| Field | Description | Default | | type | 각 수집 방법은 자신만의 튜닝 타입 코드를 가짐. 수집 방법과 일치하는 타입 코드를 지정해야 함. 공통 옵션은 index, kafka, kinesis | | | maxRowsInMemory | 디스크로 persist 하기 전에 메모리에 저장할 최대 레코드 수. 이는 롤업-후(post-rollup) 행 수이므로 입력 레코드 수와 같지 않을 수 있음에 유의. maxRowsInMemory 또는 maxBytesInMemory 중 어느 것이든 먼저 도달하면(먼저 일어나는 쪽) 수집된 레코드가 디스크에 persist 됨 | 1000000 | | maxBytesInMemory | persist 전에 JVM 힙에 저장할 레코드의 최대 총 크기(바이트). 메모리 사용의 대략적 추정치에 기반. maxRowsInMemory 또는 maxBytesInMemory 중 어느 것이든 먼저 도달하면 수집된 레코드가 디스크에 persist 됨. maxBytesInMemory는 중간 persist에서 만들어진 아티팩트의 힙 사용도 포함. 즉 매 persist 후 다음 persist까지 사용 가능한 maxBytesInMemory 양이 줄어듦. 모든 중간 persisted 아티팩트의 바이트 합이 maxBytesInMemory를 초과하면 태스크는 실패. maxBytesInMemory를 -1로 설정하면 이 검사가 비활성화돼 Druid가 메모리 사용을 제어하는 데 전적으로 maxRowsInMemory에 의존함. 0으로 설정하면 기본값(현재 JVM 힙 크기의 1/6)이 사용됨. 메모리 사용 추정치는 과대 추정하도록 설계됐고, 스케치를 포함한 복잡한 수집-시점 애그리게이터를 사용할 때 특히 높을 수 있음. 이것으로 인해 indexing 워크로드가 디스크에 너무 자주 persist 된다면 maxBytesInMemory를 -1로 설정하고 maxRowsInMemory에 의존할 수 있음 | 최대 JVM 힙 크기의 1/6 | | skipBytesInMemoryOverheadCheck | maxBytesInMemory 계산은 수집 중 생성되는 오버헤드 객체와 각 중간 persist를 고려함. 이것을 true로 설정하면 이 오버헤드 객체들의 바이트를 maxBytesInMemory 검사에서 제외할 수 있음 | false | | indexSpec | 인덱싱 시점에 사용할 세그먼트 저장 형식 옵션 정의 | 자세한 내용은 indexSpec 참고 | | indexSpecForIntermediatePersists | 인덱싱 시점에 중간 persisted 임시 세그먼트에 사용할 세그먼트 저장 형식 옵션 정의 | 자세한 내용은 indexSpec 참고 | | Other properties | 각 수집 방법은 자신만의 추가 튜닝 속성 목록을 가짐. 전체 목록은 각 방법의 문서를 참고: Kafka indexing service, Kinesis indexing service, Native batch | |

다음 예시는 공유 공통 속성들을 모두 기본값으로 설정하는 tuningConfig 객체입니다.

"tuningConfig": {  "type": "<ingestion-method-specific type code>",  "maxRowsInMemory": 1000000,  "maxBytesInMemory": <one-sixth of JVM memory>,  "indexSpec": {    "bitmap": { "type": "roaring" },    "dimensionCompression": "lz4",    "metricCompression": "lz4",    "longEncoding": "longs"  },  <other ingestion-method-specific properties>}

indexSpec

indexSpec 객체는 다음 속성을 포함할 수 있어요. 쿼리 컨텍스트에서 indexSpec을 정의하는 방법은 SQL-based ingestion reference를 참고하세요.

| Field | Description | Default | | bitmap | bitmap 인덱스의 압축 형식. type이 roaring 또는 concise로 설정된 JSON 객체여야 함 | {"type": "roaring"} | | dimensionCompression | dimension 컬럼의 압축 형식. lz4, lzf, zstd, uncompressed 중 하나 | lz4 | | stringDictionaryEncoding | STRING 및 COMPLEX 컬럼이 사용하는 문자열 값 사전의 인코딩 형식. front coding을 활성화하려면 stringDictionaryEncoding.type을 frontCoded로 설정. 선택적으로 bucketSize와 formatVersion 속성을 지정할 수 있음. 자세한 내용은 Front coding 참고 | {"type":"utf8"} | | metricCompression | 기본 타입(primitive type) metric 컬럼의 압축 형식. 옵션은 lz4, lzf, zstd, uncompressed, 또는 none(uncompressed보다 더 효율적이지만 이전 버전의 Druid에서는 지원되지 않음) | lz4 | | longEncoding | long 타입 컬럼의 인코딩 형식. dimension이든 metric이든 무관하게 적용. 옵션은 auto 또는 longs. auto는 컬럼 카디널리티에 따라 offset 또는 lookup table로 값을 인코딩하고 가변 크기로 저장. longs는 각 값을 8바이트로 그대로 저장 | longs | | complexMetricCompression | complex 타입 metric 컬럼의 압축 형식. 옵션은 lz4, lzf, zstd, uncompressed. uncompressed 이외의 옵션은 31보다 이전의 Druid 버전과 호환되지 않으며, 특수 컬럼 형식이 없는 complex metric에만 적용됨 | uncompressed | | jsonCompression | 중첩 컬럼 원시 데이터에 사용할 압축 형식. 옵션은 lz4, lzf, zstd, uncompressed | lz4 |

Front coding

Druid는 더 나은 압축을 위해 STRING 컬럼을 사전 인코딩으로 저장해요. 각 문자열 값은 사전순으로 정렬된 사전에 추가되고 실제 컬럼은 사전 항목에 대한 포인터만 저장합니다. Front coding은 최소한의 성능 영향으로 Druid의 STRING·COMPLEX 컬럼을 더 압축할 수 있게 해 주는 선택적 증분 인코딩 전략이에요. Front-coded 사전은 공통 접두사를 공유하는 값들을 최적화해서 중복 데이터 저장을 피하고 저장 공간을 줄이며 성능을 높일 수 있습니다. 예를 들어 웹사이트 방문을 추적한다면 대부분의 URL이 https://domain.xyz/로 시작하는데, front coding은 이 패턴을 활용해 그러한 데이터셋을 저장할 때 더 최적의 압축을 실현할 수 있어요.

Front coding은 모든 종류의 수집에서 사용할 수 있습니다.

Front coding 활성화

클러스터에 front coding을 활성화하기 전에 front-coded dictionaries용 Migration guide를 검토하세요. 25.0.0 이전의 Druid 버전과의 호환성에 관한 중요한 정보가 들어 있습니다.

Front coding을 활성화하려면 ingestion spec의 tuningConfig 객체에서 indexSpec.stringDictionaryEncoding.type을 frontCoded로 설정하세요.

다음 선택적 속성을 지정할 수 있습니다.

bucketSize: 델타 인코딩을 수행하기 위해 버킷에 넣을 값 수. 이 속성을 설정하면 indexing task가 지정된 버킷 크기의 압축 사전으로 세그먼트를 쓰도록 지시합니다. 128 이하의 2의 거듭제곱으로 설정할 수 있어요. bucketSize 기본값은 4.
formatVersion: 사용할 front coding 버전 지정. 옵션은 0과 1(Druid 버전 26.0.0 이상에서 지원). formatVersion 기본값은 1.

예를 들어:

"tuningConfig": {  "indexSpec": {    "stringDictionaryEncoding": {      "type":"frontCoded",      "bucketSize": 4,      "formatVersion": 1    }  }}

더 알아보기 (Learn more)

네이티브 배치 수집 — index_parallel 태스크와 배치 수집
Kafka 수집 가이드 — 스트리밍 수집 spec
스키마 설계 문서 — 데이터 모델링 팁