동시 append와 replace

동시 append와 replace (Concurrent append and replace)

동시 append와 replace는 datasource의 특정 interval에 새 데이터가 append되는 동안, 그 interval의 기존 데이터를 안전하게 replace할 수 있게 해 주는 기능이에요. 이 기능의 가장 흔한 활용 사례 중 하나는, 어떤 interval에 대한 컴팩션(compaction)이 이미 진행 중일 때 그 interval에 새 데이터(예: 스트리밍 수집으로)를 append하는 상황입니다. 이 시간 동안 수집되는 데이터는 Druid가 dynamic 파티셔닝으로 나눠요. 이후 실행되는 컴팩션은 컴팩션 config에서 지정한 granularity로 데이터를 파티셔닝합니다.

동시 append와 replace를 구성하려면 컨텍스트 플래그 useConcurrentLocks를 사용하세요. 그러면 Druid가 append 또는 replace 중 올바른 잠금 타입을 자동으로 정해 줍니다. 잠금 타입을 수동으로 설정할 수도 있지만 권장하지는 않아요.

출처: 문서

본문

컴팩션 config를 동시 잠금으로 업데이트하기

컴팩션이 실행되는 동안 datasource에 데이터를 append하려면, 컴팩션 설정을 업데이트해서 그 datasource에 대해 동시 append와 replace를 활성화해야 해요.

Druid 웹 콘솔에서 컴팩션 config 업데이트

datasource의 Compaction config에서 Use concurrent locks를 활성화하세요. UI에서 컴팩션 config에 접근하는 방법은 Enable automatic compaction with the web console을 참고해 주세요.

REST API로 컴팩션 config 업데이트

다른 자동 컴팩션 설정과 마찬가지로 API를 통해 taskContext를 추가하세요.

curl --location --request POST 'http://localhost:8081/druid/coordinator/v1/config/compaction' \--header 'Content-Type: application/json' \--data-raw '{    "dataSource": "YOUR_DATASOURCE",    "taskContext": {        "useConcurrentLocks": true    }}'

수집 작업에서 동시 잠금 사용하기

수집 작업도 동시 잠금을 허용하도록 구성해야 해요. API나 UI에서 다른 수집 작업 파라미터와 마찬가지로 컨텍스트 파라미터를 제공할 수 있습니다.

Druid 웹 콘솔에서 동시 잠금 사용

클래식 배치(JSON 기반) 수집과 스트리밍 수집의 Load data 마법사에서, Publish 단계의 다음 설정을 활성화하세요: Use concurrent locks.

REST API에서 동시 잠금 사용

API를 사용한다면 supervisor 또는 수집 스펙에 다음 JSON 스니펫을 추가하세요.

"context": {   "useConcurrentLocks": true}

모든 수집·컴팩션 작업에 동시 잠금을 쓰도록 Overlord 속성 업데이트

클러스터에 datasource가 여러 개라면 데이터 소스마다 컴팩션 config와 수집 작업을 업데이트하는 건 번거로울 수 있어요. 대신 Overlord 서비스의 runtime.properties에 다음 설정을 넣으면 모든 수집·컴팩션 작업에 걸쳐 동시 잠금을 사용할 수 있습니다.

druid.indexer.task.default.context={"useConcurrentLocks":true}

태스크 잠금 타입 (Task lock types)

useConcurrentLocks 컨텍스트 파라미터를 사용해서 Druid가 태스크 잠금 타입을 자동으로 정하게 하는 것을 권장해요. 그런데 어떤 이유로 태스크 잠금 타입을 명시적으로 수동 설정해야 한다면, 이 섹션에서 자세한 내용을 읽어 보세요.

잠금 타입에 대한 더 많은 내용은 여기를 클릭하세요.

Druid는 태스크 잠금을 사용해서 충돌하는 작업이 동시에 발생하지 않도록 보장해요. 태스크 잠금 타입은 APPEND와 REPLACE 두 가지가 있습니다. 사용할 잠금 타입은 무엇을 하려는지에 따라 정해져요.

태스크 잠금 타입을 수동으로 설정할 때 다음을 유의하세요.

  • append 태스크의 세그먼트 granularity는 replace 태스크의 세그먼트 granularity보다 같거나 더 세밀해야 합니다.
  • APPEND 잠금을 가진 태스크가 REPLACE 잠금을 가진 태스크보다 더 거친(coarser) 세그먼트 granularity를 사용하면 동시 append와 replace가 실패해요. 예를 들어 APPEND 태스크가 YEAR granularity를 쓰고 REPLACE 태스크가 MONTH granularity를 쓴다면 동시 append와 replace를 사용하면 안 됩니다.
  • 주어진 datasource interval에 대해 REPLACE 잠금을 보유할 수 있는 태스크는 단 하나뿐이에요.
  • 여러 태스크가 주어진 datasource interval에 대해 APPEND 잠금을 보유하고 동시에 그 interval에 데이터를 append할 수 있습니다.

수집 작업에 태스크 잠금 타입 추가하기

수집 작업의 태스크 잠금 타입은 다음과 같이 구성합니다.

  • 스트리밍 작업의 경우 taskLockType 컨텍스트 파라미터가 supervisor 스펙에 들어가고, 잠금 타입은 항상 APPEND예요.
  • 클래식 JSON 기반 배치 수집의 경우 taskLockType 컨텍스트 파라미터가 수집 스펙에 들어가고, 잠금 타입은 APPEND 또는 REPLACE 둘 다 가능합니다.

컨텍스트 파라미터는 수집 작업의 다른 파라미터와 마찬가지로 API를 통해, 또는 UI를 통해 제공할 수 있어요.

Druid 콘솔로 태스크 잠금 추가

클래식 배치(JSON 기반) 수집과 스트리밍 수집의 Load data 마법사에서, Publish 단계 동안 수집의 태스크 잠금 타입을 구성할 수 있습니다.

  • Append to existing를 True로 설정하면 Allow concurrent append tasks (experimental)를 True로 설정할 수 있어요.
  • Append to existing를 False로 설정하면 Allow concurrent replace tasks (experimental)를 True로 설정할 수 있습니다.
API로 태스크 잠금 타입 추가

API를 사용한다면 supervisor 또는 수집 스펙에 다음 JSON 스니펫을 추가하세요.

"context": {   "taskLockType": LOCK_TYPE}   

LOCK_TYPE은 무엇을 하려는지에 따라 달라져요. 다음 중 하나라도 해당한다면 taskLockType을 APPEND로 설정하세요.

  • append to existing이 true로 설정된 dynamic 파티셔닝
  • 수집 작업이 스트리밍 수집 작업인 경우

같은 datasource를 대상으로 append하는 수집 작업이 여러 개 있고 그것들을 동시에 실행하려면, 다음 컨텍스트 파라미터도 포함해야 해요.

"useSharedLock": "true"

참고로 taskLockType은 useSharedLock보다 우선합니다. REPLACE 태스크 잠금에서는 useSharedLock을 사용하지 마세요.

데이터를 replace한다면 taskLockType을 REPLACE로 설정하세요. 예를 들어 다음 파티셔닝 타입 중 하나를 사용한다면 REPLACE를 쓰세요.

  • hash 파티셔닝
  • range 파티셔닝
  • append to existing이 false로 설정된 dynamic 파티셔닝

알려진 제한 (Known limitations)

다음 중 하나라도 해당하면 datasource에서 동시 append와 replace를 사용하지 마세요.

  • datasource에 어떤 interval에서 혼합된 granularity의 데이터가 있는 경우. 예를 들어 어느 interval에 DAY와 WEEK granularity 데이터가 둘 다 있으면, 동시 append와 replace를 사용할 때 데이터 손실이나 중복이 발생할 수 있어요.
  • datasource에 데이터를 더 세밀한 청크로 컴팩트하는 컴팩션 config가 있는 경우. 예를 들어 MONTH 데이터를 수집하고 DAY granularity로 컴팩트하도록 구성된 datasource는 데이터 손실이나 중복을 겪을 수 있습니다.

더 알아보기 (Learn more)