Store File Tracking
Store File Tracking
이 문서는 HBase의 Store File Tracking 기능을 설명해요. hfile을 어디에 만들고 커밋할 때 어떻게 처리할지 결정을 특정 구현에 위임하는 메커니즘이에요. S3 같은 원자적 rename이 없는 파일 시스템에서 성능 문제를 피하고 싶을 때 특히 유용해요.
출처: 문서
본문
개요
역사적으로 HBase 내부는 먼저 임시 디렉터리에 hfile을 만든 다음, 연산 커밋 시점에 그 파일을 실제 store 디렉터리로 rename하는 방식에 의존했어요. 이것은 임시 파일과 클라이언트 읽기에 데이터를 제공할 준비가 된 확정된 파일을 분리하는 간단하고 편리한 방법이에요. 이 접근 방식은 강한 일관성의 파일 시스템에서 잘 동작하지만, 덜 일관적인 파일 시스템(주로 파일 시스템처럼 사용할 수 있는 Object Store)의 인기가 높아지면서 원자적 rename 연산에 대한 의존이 성능 저하를 유발하기 시작했어요. 특히 Amazon S3 Object Store는 원자적 rename이 없어서 가장 많이 영향을 받은 배포였어요. HBase 커뮤니티는 S3에 대한 연산의 원자성을 보장하기 위해 HBOSS라는 분산 잠금 계층을 구축해 이 문제를 임시로 우회했어요.
Store File Tracking을 사용하면 새 hfile을 어디에 원래 만들지, 커밋 시 어떻게 진행할지에 대한 결정이 특정 Store File Tracking 구현에 위임돼요. 이 구현은 hbase-site.xml의 HBase 서비스 수준에서 또는 TableDescriptor 구성을 통해 Table이나 Column Family 수준에서 설정할 수 있어요.
store file tracking 구현이 hbase_site.xml에 지정되면 이 구성은 테이블 생성 시점에 테이블의 구성으로도 전파돼요. 이는 프로세스 간 위험한 구성 불일치(잠재적으로 데이터 손실로 이어질 수 있음)를 피하기 위한 것이에요.
사용 가능한 구현
Store File Tracking 초기 버전은 세 가지 내장 구현을 제공해요.
- DEFAULT
- FILE
- MIGRATION
DEFAULT
이름 그대로, 명시적 구성이 정의되지 않았을 때 기본으로 사용되는 Store File Tracking 구현이에요. DEFAULT 트래커는 임시 디렉터리와 rename을 사용하는 표준 접근 방식을 구현해요. 이것이 HBase가 store file을 추적하던 모든 이전 (암묵적) 구현 방식이에요.
FILE
store 디렉터리에 바로 새 파일을 만들어 rename 연산의 필요성을 피하는 파일 트래커 구현이에요. 커밋된 hfile 목록을 메모리에 유지하고, 각 store 디렉터리의 메타 파일이 이를 뒷받침해요. 새 hfile이 커밋될 때마다 해당 store의 추적 파일 목록이 업데이트되고, 이 목록 내용으로 새 메타 파일이 쓰여지며, 이전 목록을 담고 있던 이전 메타 파일은 폐기돼요.
MIGRATION
이미 데이터를 포함하고 있어서 특정 로직 아래에서 파일을 추적하고 있는 기존 테이블에서 Store File Tracking 구현 간을 전환할 때 사용하는 특수 구현이에요.
사용법
아직 사용자 데이터가 없는 새 배포의 경우, 첫 hbase 시작 전에 전역 hbase-site.xml 구성의 hbase.store.file-tracker.impl 프로퍼티 값으로 FILE 구현을 설정하면 돼요. 이 프로퍼티를 생략하면 DEFAULT 구현이 설정돼요.
store file tracking 기능을 포함한 HBase 버전으로 업그레이드된 데이터가 있는 클러스터의 경우, Store File Tracking 구현은 MIGRATION 구현으로만 변경할 수 있어요. 그래야 새 트래커가 현재 트래커의 목록을 기반으로 추적 파일 목록을 안전하게 구축할 수 있어요.
MIGRATION 트래커는 전역 구성에 설정하면 안 돼요. 사용하려면 아래의 "Table 또는 Column Family 설정" 섹션을 따르세요.
Table 또는 Column Family 설정
Store File Tracking 구성을 전역으로 설정하는 것이 항상 가능하거나 바람직한 것은 아니에요. 예를 들어 기존 사용자 데이터가 있는 업그레이드된 클러스터의 경우가 그래요.
Store File Tracking은 Table 또는 Column Family 수준 구성으로 설정할 수 있어요. 예를 들어 테이블 생성 시점에 테이블 구성에서 FILE 구현을 지정하려면 다음을 적용해야 해요.
create 'my-table', 'f1', 'f2', {CONFIGURATION => {'hbase.store.file-tracker.impl' => 'FILE'}}
특정 Column Family에 FILE을 정의하려면:
create 'my-table', {NAME=> '1', CONFIGURATION => {'hbase.store.file-tracker.impl' => 'FILE'}}
Table 또는 Column Family에서 트래커 전환
아주 흔한 시나리오는 이 기능을 지원하는 버전으로 업그레이드된 기존 HBase 배포에 Store File Tracking을 설정하는 것이에요. FILE 트래커를 적용하려면 테이블을 DEFAULT 트래커에서 FILE 트래커로 효과적으로 마이그레이션해야 해요. 앞서 설명한 대로, 이 과정은 Table 또는 Column Family 수준에서만 지정할 수 있는 특수 MIGRATION 트래커 구현을 사용해야 해요.
예를 들어 테이블 구성에서 트래커를 DEFAULT에서 FILE로 전환하려면:
alter 'my-table', CONFIGURATION => {'hbase.store.file-tracker.impl' => 'MIGRATION',
'hbase.store.file-tracker.migration.src.impl' => 'DEFAULT',
'hbase.store.file-tracker.migration.dst.impl' => 'FILE'}
컬럼 패밀리 수준 구성에서 비슷한 전환을 적용하려면:
alter 'my-table', {NAME => 'f1', CONFIGURATION => {'hbase.store.file-tracker.impl' => 'MIGRATION',
'hbase.store.file-tracker.migration.src.impl' => 'DEFAULT',
'hbase.store.file-tracker.migration.dst.impl' => 'FILE'}}
모든 테이블 region이 다시 온라인되면 hbase.store.file-tracker.migration.dst.impl 값을 hbase.store.file-tracker.impl로 설정해서 MIGRATION을 비활성화하는 것을 잊지 마세요. 위 예시에서는 다음과 같아요.
alter 'my-table', CONFIGURATION => {'hbase.store.file-tracker.impl' => 'FILE'}
스냅샷 복구 중 트래커 지정
clone_snapshot 명령의 CLONE_SFT 옵션을 사용해 스냅샷을 복구할 때 특정 store file tracking 구현을 지정할 수도 있어요. 이것은 전역 구성의 변경 전에 찍힌 옛 스냅샷이나 다른 store file tracking 설정을 가진 다른 클러스터에서 가져온 스냅샷을 복구할 때 유용해요. 스냅샷은 테이블과 컬럼 패밀리 디스크립터를 보존하므로, 단순 복원은 원래 구성을 다시 로드하고 테이블/컬럼 패밀리를 원하는 트래커 구현으로 변환하려면 위에서 설명한 추가 단계가 필요해요.
clone_snapshot을 사용해 FILE 트래커 구현을 지정하는 예시는 아래와 같아요.
clone_snapshot 'snapshotName', 'namespace:tableName', {CLONE_SFT=>'FILE'}
스냅샷 복구 중 트래커를 지정하는 옵션은 clone_snapshot 명령에만 사용할 수 있어요. restore_snapshot 명령은 이 파라미터를 지원하지 않아요.