메타데이터 저장소

메타데이터 저장소 (Metadata storage)

Apache Druid는 메타데이터 저장을 위해 외부 의존성에 의존해요. Druid는 시스템에 대한 다양한 메타데이터를 보관하기 위해 metadata store를 사용하지만, 실제 데이터를 저장하지는 않아요.

출처: 문서

본문

Apache Druid는 메타데이터 저장을 위해 외부 의존성에 의존해요.

Druid는 시스템에 대한 다양한 메타데이터를 보관하기 위해 metadata store를 사용하지만, 실제 데이터를 저장하지는 않아요.

metadata store는 Druid 클러스터가 동작하는 데 필수적인 모든 메타데이터를 보관해요.

metadata store는 다음을 포함해요:

  • Segment 레코드
  • Rule 레코드
  • Configuration 레코드
  • Task 관련 테이블
  • Audit 레코드

Derby는 Druid의 기본 metadata store지만 프로덕션에는 적합하지 않아요.

MySQL과 PostgreSQL이 프로덕션에 더 적합한 metadata store예요.

기본 구성 설정은 Metadata storage configuration을 참고하세요.

info

잃어버린 메타데이터를 복원할 방법이 없으므로 고가용성 환경을 설정하는 것을 권장해요.

사용 가능한 metadata store

Druid는 메타데이터 저장을 위해 Derby, MySQL, PostgreSQL을 지원해요. metadata store는 ACID를 준수해야 한다는 점에 유의하세요. ACID를 준수하지 않으면 task가 간헐적으로 실패하는 등의 문제가 발생할 수 있어요.

큰 메타데이터 테이블에 스키마 변경이 필요한 업그레이드와 관련된 문제를 피하려면, instant ADD COLUMN 의미론을 지원하는 metadata store 버전을 고려하세요. 버전에 대한 지침은 데이터베이스별 문서를 참고하세요.

MySQL

mysql-metadata-storage extension 문서를 참고하세요.

PostgreSQL

postgresql-metadata-storage을 참고하세요.

Derby

info

프로덕션 클러스터에서는 Derby 대신 MySQL이나 PostgreSQL을 사용하는 것을 고려하세요.

Druid 구성에 다음 속성을 설정해 Derby로 metadata storage를 구성하세요.

druid.metadata.storage.type=derby
druid.metadata.storage.connector.connectURI=jdbc:derby://localhost:1527//opt/var/druid_state/derby;create=true

커스텀 DBCP 속성 추가

metadata store에 연결하기 위한 데이터베이스 연결 풀(DBCP)을 커스터마이즈하는 커스텀 속성을 추가할 수 있어요.

이 속성들을 druid.metadata.storage.connector.dbcp. 접두사로 정의하세요.

예를 들어:

druid.metadata.storage.connector.dbcp.maxConnLifetimeMillis=1200000
druid.metadata.storage.connector.dbcp.defaultQueryTimeout=30000

일부 속성은 druid.metadata.storage.connector.dbcp.로 설정할 수 없고 반드시 druid.metadata.storage.connector. 접두사로 설정해야 해요:

  • username
  • password
  • connectURI
  • validationQuery
  • testOnBorrow

구성 가능한 전체 속성 목록은 BasicDataSource Configuration을 참고하세요.

Metadata storage 테이블

이 섹션에서는 metadata storage의 다양한 테이블을 설명해요.

Segments 테이블

이는 druid.metadata.storage.tables.segments 속성이 결정해요.

이 테이블은 시스템에서 이용 가능해야 하는 segment에 대한 메타데이터를 저장해요. (이 segment 집합을 문서와 프로젝트 전반에서 "used segments"라고 불러요.) Coordinator가 이 테이블을 폴링해서 시스템에서 쿼리 가능해야 하는 segment 집합을 결정해요. 이 테이블에는 두 개의 주요 기능 컬럼이 있고, 나머지 컬럼은 indexing 목적이에요.

used 컬럼의 값 1은 segment가 클러스터에 "used"(즉 로드되어 요청에 이용 가능해야) 되어야 한다는 뜻이에요. 값 0은 segment를 클러스터에 로드하지 않아야 한다는 뜻이에요. 메타데이터를 실제로 제거하지 않고 클러스터에서 segment를 내리는 수단으로 이렇게 해요(문제가 되면 롤백이 더 간단해짐). used 컬럼에는 used_status_last_updated라는 대응 컬럼이 있어 segment의 used 상태가 마지막으로 업데이트된 시간을 나타내요. Coordinator는 이 정보를 사용해(자동 segment kill이 활성화된 경우) segment가 삭제 후보인지 결정할 수 있어요.

payload 컬럼은 segment의 모든 메타데이터를 가진 JSON blob을 저장해요.

payload 컬럼의 일부 데이터는 segments 테이블의 다른 컬럼 데이터를 의도적으로 중복해요.

예를 들어 payload 컬럼은 다음 형태를 취할 수 있어요:

{
	"dataSource":"wikipedia",
	"interval":"2012-05-23T00:00:00.000Z/2012-05-24T00:00:00.000Z",
	"version":"2012-05-24T00:10:00.046Z",
	"loadSpec":{
		"type":"s3_zip",
		"bucket":"bucket_for_segment",
		"key":"path/to/segment/on/s3"
	},
	"dimensions":"comma-delimited-list-of-dimension-names",
	"metrics":"comma-delimited-list-of-metric-names",
	"shardSpec":{"type":"none"},
	"binaryVersion":9,
	"size":size_of_segment,
	"identifier":"wikipedia_2012-05-23T00:00:00.000Z_2012-05-24T00:00:00.000Z_2012-05-23T10:00:00.046Z"
}

Rule 테이블

rule 테이블은 segment가 위치해야 할 곳에 대한 다양한 규칙을 저장해요. 이 규칙은 Coordinator가 클러스터에 대한 segment (재)할당 결정을 내릴 때 사용돼요.

Config 테이블

config 테이블은 런타임 구성 객체를 저장해요. 아직 많지 않고 이 메커니즘을 계속 유지할지 확실하지 않지만, 런타임에 클러스터 전체에서 일부 구성 파라미터를 변경하는 방법의 시작이에요.

Task 관련 테이블

Task 관련 테이블은 Overlord와 Middle Manager가 task를 관리할 때 생성하고 사용해요.

Audit 테이블

audit 테이블은 Coordinator가 수행한 rule 변경 같은 구성 변경과 기타 구성 변경의 감사 이력을 저장해요.

Metadata storage 접근

다음 프로세스만 metadata storage에 접근해요:

  • Indexing service 프로세스(있는 경우)
  • Realtime 프로세스(있는 경우)
  • Coordinator 프로세스

따라서 metadata storage에 접근하도록 이 머신에만 권한을 부여하면 돼요(예: AWS security groups).

더 알아보기 (Learn more)