HBase Architecture

Apache HBase Architecture 공식문서를 번역한 게시글이다.

 

https://hbase.apache.org/book.html#_architecture

Apache HBase ™ Reference Guide

 

개요

NoSQL이란?

HBase는 NoSQL 데이터베이스의 한 종류이다. “NoSQL”은 일반적으로 RDBMS(기본으로 SQL을 지원)가 아닌 데이터베이스를 의미한다. NoSQL 데이터베이스에는 여러 가지 유형이 존재한다. 예를 들어, BerkeleyDB는 로컬 NoSQL 데이터베이스인 반면, HBase는 분산형 데이터데이스이다. 기술적으로 말하자면, HBase는 “데이터 베이스” 보다는 “데이터 스토어”에 더 가깝다. 왜냐하면 HBase는 입력 열, 보조 인덱스, 트리거 및 고급 쿼리 언어 등과 같이 RDBMS에서 지원하는 많은 기능들이 없기 때문이다.

그러나 HBase는 선형 및 모듈식 확장을 지원한다. HBase 클러스터는 일반 클래스 서버에 호스팅되는 RegionServers를 추가하여 확장한다. 예를 들어, 클러스터가 10개에서 20개의 RegionServers로 확장되는 경우, 스토리지와 처리 용량 측면에서 모두 두 배가 된다. 반면, RDBMS는 확장성이 뛰어나지만, 단일 데이터베이스 서버의 크기까지만 확장할 수 있으며, 최상의 성능을 위해서는 전문 하드웨어 및 스토리지 장치가 필요하다.

HBase의 특징

• 읽기/쓰기가 매우 일관된다. HBase는 “궁극적 일관성” DataStore가 아니다. 따라서 고속 카운터 집계와 같은 작업에 매우 적합하다.
• 자동 샤딩 : HBase 테이블은 regions를 통해 클러스터에 배포되며, 데이터가 증가함에 따라 regions는 자동으로 분할되고 다시 배포된다.
• RegionServer 장애 발생 시 자동으로 대체 작동한다.
• Hadoop/HDFS 통합 : HBase는 HDFS를 분산 파일 시스템으로 지원한다.
• 맵리듀스 : HBase는 MapReduce를 통해 HBase를 소스 및 싱크로 사용하기 위한 대규모 병렬 처리를 지원한다.
• Java Client API : HBase는 프로그램 액세스를 위해 사용하기 쉬운 Java API를 지원한다.
• Thrift/REST API : HBase는 non-Java front-ends를 위해 Thrift와 REST API를 지원한다.
• Block Cache 및 Bloom Filters : HBase는 대용량 쿼리 최적화를 위해 Block Cache 및 Bloom Filters를 지원한다.
• 운영 관리 : HBase는 운영 통찰력 및 JMX 메트릭스를 위한 내장 웹 페이지를 제공한다.

언제 HBase를 사용해야 하나?

HBase는 모든 문제에 적합하지는 않는다.

1. 먼저, 충분한 데이터가 있는지 확인한다. 수억 또는 수십억 개의 행이 있다면 HBase를 사용하는 것이 좋다. 행이 수천만 개에 불과할 경우에는 기존 RDBMS를 사용하는 것이 더 낫다. 왜냐하면 모든 데이터가 단일 노드(또는 2개)에서 처리되고 나머지 클러스터가 휴식 상태일 수 있기 때문이다.
2. 두번째로, RDBMS가 제공하는 모든 추가 기능(e.g. 입력된 열, 보조 인덱스, 트랜잭션, 고급 쿼리 언어 등) 없이도 괜찮은지 확인한다. 예를 들어, RDBMS에 기반하여 구축된 애플리케이션은 단순히 JDBC 드라이버를 변경한다고 HBase로 “포트”될 수 없다. 포트하는게 아니라 완전히 재설계해서 RDBMS에서 HBase로 이동하는것으로 고려한다.
3. 세번째로, 충분한 하드웨어가 있는지 확인한다. HDFS도 5개 미만(기본값인 3인 HDFS 블록 복제 등)의 DataNode와 NameNode를 함께 사용하는 경우에는 적합하지 않는다.

HBase는 노트북에서 상당히 독립적으로 실행될 수 있지만, 개발 환경설정으로만 고려해야 한다.

HBase와 Hadoop/HDFS의 차이점은 무엇일까?

HDFS는 대용량 파일 저장에 적합한 분산 파일 시스템이다. 그러나 문서에는 범용 파일 시스템이 아니고 파일에 따른 개별 레코드 조회를 제공하지 않는다고 명시되어 있다. 반면 HBase는 HDFS를 기반으로 구축되었으며 대용량 테이블에 대한 빠른 레코드 조회(및 업데이트)를 제공한다. 이는 때때로 개념적인 혼란을 일으킬수 있다. HBase는 내부적으로 데이터를 고속 검색을 위해 HDFS에 있는 인덱싱 된 “StoreFiles”에 저장한다. HBase의 목표 달성 방법에 대한 자세한 내용은 데이터 모델 및 이 장의 나머지 부분을 참고한다.

Catalog Tables

카탈로그 테이블인 hbase:meta는 HBase 테이블로 존재하며 HBase 셸의 list 명령에서 필터링되지만 실제로는 다른 테이블과 같다.

hbase:meta

hbase:meta 테이블은 시스템의 모든 region 목록을 보관하며, hbase의 위치는 ZooKeeper에 저장된다.

hbase:meta의 구조는 다음과 같다 :

• Key

Region key of the format ([table], [region start key], [region id])

• Value

info:regioninfo (이 region에 대해 직렬화된 HRegionInfo)

info:server (server : 이 region을 포함하는 RegionServer의 포트)

info:serverstartcode (이 region을 포함하는 RegionServer 프로세스의 시작 시간)

테이블이 분할될 때, info:splitA 와 info:splitB라고 불리는 다른 두 개의 열이 생성될 것이다. 이 열들은 두 개의 자식 지역을 나타낸다. 이러한 열에 대한 값들도 직렬화된 HRegionInfo의 인스턴스이다. 영역이 분할된 이후, 이 행은 삭제된다.

#HRegionInfo

빈 키는 테이블 시작 및 테이블 끝을 나타내는 데 사용된다. 빈 시작 키가 있는 영역은 표의 첫 번째 영역이다. 영역에 시작 키와 끝 키가 모두 비어 있으면 테이블에 있는 유일한 영역이다.

카탈로그 메타 데이터를 프로그래밍 방식으로 처리해야 하는 이벤트에서는 RegionInfo.parseFrom 유틸리티를 참조한다.

시작 순서 지정

먼저, hbase:meta의 위치는 ZooKeeper에서 조회된다. 그 다음, hbase:meta가 서버 및 시작 코드 값으로 업데이트 된다.

Master

HMaster는 마스터 서버의 구현이다. 마스터 서버는 클러스터의 모든 RegionServer 인스턴스를 모니터링하는 역할을 하며, 모든 메타데이터 변경 사항을 위한 인터페이스이다. 분산 클러스터에서 마스터는 일반적으로 NameNode에서 실행된다.

# 공식 매뉴얼 외 참고 그림

시작 동작

다중 마스터 환경에서 실행할 경우 모든 마스터가 클러스터를 실행하기 위해 경쟁한다. 활성 마스터가 ZooKeeper에서 계약을 상실하거나 마스터가 종료될 경우, 나머지 마스터는 마스터 역할을 넘겨받으려고 한다.

런타임 영향

일반적인 분산 목록 질문에 마스터가 작동 중단될 때 HBase 클러스터가 어떻게 되는지 나와 있다.

2.x.y 버전까지

HBase 클라이언트는 RegionServers와 직접 대화하므로 클러스터는 여전히 “안정적인 상태”에서 작동할 수 있다. 또한 카탈로그 표에서 hbase:meta는 HBase 테이블로 존재하며 마스터에 상주하지 않는다. 그러나 마스터는 RegionServer 페일오버 및 완료 영역 분할과 같은 중요한 기능을 제어한다. 따라서 마스터 없이 클러스터를 짧은 시간동안 실행할 수 있지만, 마스터는 가능한 한 빨리 재시작해야 한다.

3.0.0 버전부터

마스터 레지스트리에 언급된 바와 같이, 클라이언트의 기본 연결 레지스트리는 이제 마스터 rpc 끝점을 기반으로 한다. 따라서 이번 릴리즈부터는 마스터 가동 시간에 대한 요구 사항이 더욱 엄격해진다.

• ZooKeeper 앙상블이 필요한 이전과 달리, 연결 설정에는 하나 이상의 활성 마스터 또는 대기 마스터가 필요하다.
• 마스터는 이제 읽기/쓰기 작업의 중요한 경로에 있다. 예를 들어 메타 영역이 다른 영역 서버로 되돌아가는 경우 클라이언트는 새 위치를 가져오려면 마스터가 필요하다. 이전에는 이 정보를 ZooKeeper에서 직접 가져와 수행했다.
• 마스터의 연결 부하가 이전보다 높아진다. 따라서 서버측 구성은 부하에 따라 조정이 필요할 수 있다.

전체적으로 마스터 가동 시간 요구 사항은 클라이언트 운영을 위한 요구사항 보다 더 높다.

인터페이스

HMasterInterface에 노출된 방법은 주로 메타데이터 지향 방식이다 :

• 테이블 (테이블생성, 테이블수정, 테이블삭제, 활성화, 비활성화
• ColumnFamily (컬럼 생성, 컬럼 수정, 컬럼 삭제)
• Region (이동, 할당, 할당해제). 예를 들어 Admin 메서드 disableTable이 호출되면 마스터 서버가 이 테이블을 처리한다.

프로세스

마스터는 몇가지 백그라운드 스레드를 실행한다.

1. 로드밸런서

주기적으로, 그리고 전환 중인 영역이 없을 때 로드 밸런서가 실행되고 클러스터 로드 밸런싱을 위해 영역을 이동한다.

2. CatalogJanitor

주기적으로 hbase:meta 테이블을 확인하고 정리한다.

MasterProcWAL

HMaster는 손상된 서버, 테이블 생성 및 기타 DDL 처리와 같은 관리 작업 및 실행 상태를 Procedure Store에 기록한다. 절차 저장소 WALs은 MasterProcWAL 디렉터리에 저장된다. 마스터 WALs은 RegionServer WALs와 다르다. 마스터 WAL을 유지하면 마스터 장애 발생 시 복원력이 뛰어난 상태 시스템을 실행할 수 있다. 예를 들어, HMaster가 테이블을 생성하는 중에 문제가 발생하여 실패한 경우 다음 활성 HMaster는 이전에 중지한 위치를 차지해서 작업을 완료할 수 있다.

MasterProcWAL의 환경설정

다음은 MasterProcWAL에 영향을 미치는 구성 목록이다. 기본값을 변경할 필요가 없다.

---

hbase.procedure.store.wal.periodic.roll.msec

Description : 새 WAL의 생성 빈도

Default : 1h (3600000 in msec)

---

hbase.procedure.store.wal.roll.threshold

Description : WAL이 롤링되기 전의 임계값 크기이다. WAL이 이 크기 또는 이 기간(마지막 로그 롤 통과 이후)에 도달할 때마다 HMaster는 새 WAL을 생성한다.

Defalut : 32MB (33554432 in byte)

---

hbase.procedure.store.wal.warn.threshold

Description : WAL 수가 이 임계값을 초과하면, 롤링 시 경고 레벨이 있는 HMaster 로그에 다음 메시지가 표시되어야 한다.

procedure WALs count=xx above the warning threshold 64. check running procedures to see if something is stuck.

Default

64

---

hbase.procedure.store.wal.max.retries.before.roll

Description : 슬롯(레코드)을 HDFS와 같은 기본 스토리지에 동기화하는 최대 재시도 횟수. 시도할 때마다 다음 메시지가 HMaster 로그에 나타나야 한다.

unable to sync slots, retry=xx

Defalut

3

---

hbase.procedure.store.wal.sync.failure.roll.max

Description : 위의 3회 검색 후 로그가 롤링되고 재시도 횟수가 0으로 재설정된다. 그러면 새로운 세트가 재시작된다. 이 구성은 동기화 실패 시 로그 롤링의 최대 시도 횟수를 제어한다. 즉, HMaster는 총 9회 동기화까지 실패를 허용한다. 이 값을 초과하면 다음 로그가 HMaster 로그에 표시되어야 한다.

Sync slots after log roll failed, abort.

Defalut

3

RegionServer

HRegionServer는 RegionServer의 구현이다. HRegionServer는 region 제공과 관리를 담당한다. 분산 클러스터에서 RegionServer는 DataNode에서 실행된다.

인터페이스

HRegionRegionInterface에 의해 알려진 방법에는 데이터 지향 방법(data-oriented)과 지역 유지(region-maintenance) 관리 방법이 모두 포함되어 있다.

• Data (get, put, delete, next, etc.)
• Region (splitRegion, compactRegion, etc) 예를 들어, Admin 메서드인 majorCompact가 테이블에서 호출될 때 클아이언트는 실제로 지정된 테이블에 대해 모든 영역을 반복하고 각 영역에 직접 주요 압축을 요청한다.

프로세스

RegionServer는 다양한 백그라운드 스레드를 실행한다.

CompactSplitThread : 분할을 확인하고 minor한 압축을 처리한다.

MajorCompactionChecker : major 압축을 확인한다.

MemStoreFlusher : MemStore에서 StoreFiles로 메모리 내 쓰기를 주기적으로 플러시한다.

LogRoller : RegionServer의 WAL을 주기적으로 확인한다.

코프로세서 (보조 처리기)

코프로세서는 0.92에 추가되었다. 코프로세서에 대한 철저한 블로그 개요가 개시되어있다.

참고 블로그 : https://blogs.apache.org/hbase/entry/coprocessor_introduction

블록 캐시

HBase는 HDFS에서 읽은 데이터를 캐시할 수 있는 두 가지 블록 캐시 구현 기능을 제공한다. 기본 on-heap LruBlockCache 와 (주로)off-heap인 BucketCache가 있다. 이 섹션에서는 각 구현체의 장점과 단점, 적절한 옵션을 선택하는 방법 및 각 구현체에 대한 구성 옵션에 대해 설명한다.

캐시 초이스

LruBlockCache는 original 구현체이며, 자바 힙 내에 있다. BucketCache는 선택 사항이며 블록 캐시 데이터를 off-heap으로 유지하는 데 주로 사용되지만 BucketCache는 파일 백업 캐시가 될 수도 있다. 파일 백업에서는 파일 모드 또는 매핑 모드에서 사용할 수 있다. 또한 영구 메모리 장치에 버킷 캐시가 상주하는 pmem 모드가 있다.

BucketCache를 사용하도록 설정하면 2계층 캐싱 시스템이 활성화된다.

---

---

---

RegionServer 분할 구현

쓰기 요청은 region 서버에서 처리되므로 memstore라고 하는 메모리 내 스토리지 시스템에 누적된다. memstore가 채워지면 memstore의 내용이 추가 저장소 파일로 디스크에 기록된다. 이 이벤트를 메모리 저장소 플러시라고 한다. 저장소 파일이 누적되면 RegionServer는 해당 파일을 더 적은 수의 더 큰 파일로 압축한다. 각 플러시 또는 압축이 완료되면 region 에 저장된 데이터 양이 변경된다. RegionServer는 region 분할 정책을 참조하여 region이 너무 커졌는지 또는 다른 정책별 이유로 분할해야 하는지 여부를 확인한다.

논리적으로, region을 나누는 과정은 간단하다. region을 반으로 나눈 다음, 그 지점에서 region의 데이터를 두 개의 새로운 region으로 분할해야 하는 region의 핵심 공간에서 적절한 지점을 찾는다. 그러나 그 과정의 세부사항은 간단하지 않다. 분할이 발생할 때 새로 생성된 자식 영역은 모든 데이터를 즉시 새 파일로 다시 작성하지 않는다. 대신, 참조 파일이라는 심볼 링크 파일과 유사한 작은 파일을 만들어 분할 지점에 따라 상위 저장소 파일의 위쪽 또는 아래쪽을 가리킨다. 참조 파일은 일반 데이터 파일과 동일하게 사용되지만 레코드의 절반만 고려된다. 상위 영역의 불변 데이터 파일에 대한 참조가 더 이상 없는 경우에만 영역을 분할할 수 있다. 이러한 참조 파일은 압축에 의해 점차 청소되므로 영역이 상위 파일에 대한 참조를 중지하고 분할할 수 있다.

region을 분할하는 것은 RegionServer에 의해 이루어진 로컬의 결정이지만, 분할 프로세스 자체는 많은 행위자들과 조정되어야 한다. RegionServer는 분할 전후에 마스터에게 통지하고 클라이언트가 새로운 자식 region을 검색할 수 있도록 .META. 테이블을 업데이트하며 HDFS에서 디렉토리 구조와 데이터 파일을 재정렬한다. 분할은 다중 작업 프로세스이다. 오류 발생 시 롤백을 사용하도록 설정하려면 RegionServer는 실행 상태에 대한 메모리 내 저널을 유지한다. RegionServer가 분할을 실행하기 위해 취한 단계는 RegionServer Split Process에 설명되어 있다. 각 단계에는 단계 번호로 레이블이 지정된다. RegionServers 또는 Master의 작업은 빨간색으로 표시되고 클라이언트의 작업은 녹색으로 표시된다.

Write Ahead Log (WAL) (로그 선행 기입)

목적

WAL(Write Ahead Log)은 HBase, 파일 기반 스토리지에서 데이터의 모든 변경 사항을 기록한다. 일반적인 작업에서는 데이터 변경 사항이 MemStore에서 StoreFiles로 이동하기 때문에 WAL이 필요하지 않는다. 그러나 MemStore를 플러시하기 전에 RegionServer가 충돌하거나 사용할 수 없게 되면 WAL은 데이터에 대한 변경 내용을 재생할 수 있도록 보장한다. WAL에 쓰기가 실패하면, 데이터를 수정하는 전체 작업이 실패한다.

HBase는 WAL 인터페이스 구현체를 사용한다. 일반적으로 지역 서버당 WAL 인스턴스는 하나만 있다. 예외는 hbase:meta를 전달하는 RegionServer이며, 메타 테이블은 자체 전용 WAL을 가져온다. RegionServer는 Puts 과 Deletes를 WAL에 기록하고 나서 영향을 받는 스토어에 대해 이러한 변화를 기록한다.

WAL은 HDFS 안에 /hbase/WALs/ 디렉토리에 위치하며, region별로 하위 디렉토리가 존재한다.

MultiWAL

지역 서버당 단일 WAL을 사용하는 경우, 지역 서버는 HDFS 파일이 순차적이어야 하므로 WAL에 연속해서 써야 한다. 이로 인해 WAL은 성능 병목 현상을 일으킨다.

HBASE 1.0은 HBASE-5699의 지원 MultiWal을 도입한다. MultiWAL은 RegionServer가 기본 HDFS 인스턴스에서 여러 파이프라인을 사용하여 여러 WAL 스트림을 병렬로 쓸 수 있게 해주며, 이는 쓰기 중에 총 처리량을 증가시킨다. 이 병렬화는 들어오는 편집 내용을 영역별로 분할하여 수행한다. 따라서 현재 구현으로는 처리량을 단일 영역으로 늘리는 데 도움이 되지 않는다.

원래 WAL 구현을 사용하는 RegionServer와 MultiWAL 구현을 사용하는 RegionServer는 각각 WAL 집합 중 하나의 복구를 처리할 수 있으므로, 롤링 재시작을 통해 다운타임 없는 구성 업데이트가 가능하다.

WAL 분할

Region Server는 여러 지역에 서비스를 제공한다. 한 RegionServer의 모든 영역은 동일한 활성 WAL 파일을 공유한다. WAL 파일의 각 편집에는 WAL이 속한 region에 대한 정보가 포함되어 있다. 영역이 열리면 해당 영역에 속하는 WAL 파일의 편집 내용을 재생해야 한다. 따라서 WAL 파일의 편집 내용은 특정 세트를 재생하여 특정 영역의 데이터를 재생성할 수 있도록 영역별로 그룹화해야 한다. WAL 편집을 영역별로 그룹화하는 과정을 로그 분할이라고 한다. 이것은 RegionServer에 장애가 발생할 경우 데이터를 복구하는 데 중요한 프로세스다.

로그 분할은 클러스터 시작 중에 HMaster에 의해 수행되거나 영역 서버가 종료될 때 ServerShutdownHandler에 의해 수행된다. 따라서 데이터가 복원될 때까지 영향을 받는 region을 사용할 수 없다. 지정된 영역을 다시 사용하려면 먼저 모든 WAL 편집 내용을 복구하고 재생해야 한다. 따라서 프로세스가 완료될 때까지 로그 분할의 영향을 받는 region을 사용할 수 없다.

# 공식 매뉴얼 외 참고 그림

• http://www.larsgeorge.com/2010/01/hbase-architecture-101-write-ahead-log.html

Regions

Region은 테이블의 가용성과 분배의 기본 요소로, Column Family당 저장되는것으로 구성된다. 계층 구조는 다음과 같다.

Table                    (HBase table)
    Region               (Regions for the table)
        Store            (Store per ColumnFamily for each Region for the table)
            MemStore     (MemStore for each Store for each Region for the table)
            StoreFile    (StoreFiles for each Store for each Region for the table)
                Block    (Blocks within a StoreFile within a Store for each Region for the table)

 

Region 개수에 대한 고려사항

일반적으로 HBase는 서버당 비교적 큰 용량(5-20Gb)의 region으로 적게(20-200) 설계된다.

일반적으로 여러 가지 이유로 인해 HBase에서 region 수를 작게 유지하려고 한다. 보통 RegionServer당 약 100개의 region이 최상의 결과를 도출했다.

Region-RegionServer 할당

region이 RegionServer에 할당되는 방법을 설명한다.

Startup :

HBase 시작 시 region은 다음과 같이 할당된다.

1. Master는 시작할때 AssignmentManager를 호출한다.
2. AssignmentManager는 hbase:meta에서 기존 region 할당을 확인한다.
3. region 할당이 유효한 경우(즉, RegionServer가 온라인 상태인 경우) 할당은 유지된다.
4. 할당이 잘못된 경우 LoadBalancerFactory가 호출되어 region을 할당한다. 로드밸런서는 region을 RegionServer에 할당한다.
5. hbase:meta는 RegionServer할당(필요한 경우) 및 RegionServer 시작 코드(RegionServer 프로세스의 시작 시간)로 업데이트된다.

Failover :

RegionServer가 실패할 경우

1. RegionServer가 중단되었기 때문에 해당 region을 즉시 사용할 수 없게 된다.
2. Master는 RegionServer가 실패했음을 감지한다.
3. region 할당은 잘못된 것으로 간주되며 Startup 순서와 마찬가지로 다시 할당된다.
4. 이동 중인 쿼리가 다시 시도되고, 손실되지 않는다.
5. 하기 시간 내에 작업이 새 RegionServer로 전환된다.

ZooKeeper session timeout + split time + assignment/replay time

Region 로드 밸런싱

로드 밸런서에 의해 region을 주기적으로 이동시킬 수 있다.

Region 상태 전환

HBase는 각 region의 상태를 유지하면서 hbase:meta의 상태를 유지한다. hbase:meta region의 상태 자체는 ZooKeeper에서 지속된다. 마스터 웹 UI에서 전환 중인 지역의 상태를 볼 수 있다.

Region-RegionServer의 지역성

시간이 지남에 따라 HDFS 블록 복제를 통해 Region-RegionServer 인접성이 달성된다. HDFS 클라이언트는 복제본을 작성할 위치를 선택할 때 기본적으로 다음 작업을 수행한다.

1. 첫 번째 복제본이 로컬 노드에 작성된다.
2. 두 번째 복제본은 다른 랙의 임의 노드에 작성된다.
3. 세 번째 복제본은 두 번째 복제본과 동일한 랙에 작성되지만 임의로 선택하 다르 노드에 작성된다.
4. 이후 복제본은 클러스터의 임의 노드에 작성된다.

따라서 HBase는 플러시 또는 압축 후 최종적으로 영역의 인접성을 달성한다. RegionServer 페일오버 상황에서 RegionServer에는 로컬이 아닌 StoreFiles가 있는 영역이 할당될 수 있다. 하지만 새로운 데이터가 Region에 기록되거나 테이블이 압축되고 StoreFiles가 다시 작성되면 RegionServer의 "local"이 된다.

Region 분할

Region 은 구성된 임계값에 도달하면 분할된다. 아래에서는 주제를 간략하게 설명한다.

분할은 RegionServer에서 도움 없이 실행된다. 즉, 마스터가 참여하지 않는다. RegionServer는 region을 분할하고, 분할된 region을 오프라인으로 표시한 다음 자식 region을 hbase:meta에 추가한다. 그 후 부모 호스팅 RegionServer에서 자식들은 오픈한 다음 Master에 분할을 보고한다.

Store

Store는 MemStore 및 0개 이상의 StoreFiles(HFiles)를 호스팅한다. Store는 지정된 region의 테이블에 대한 column family에 해당한다.

MemStore

MemStore는 Store에 대한 메모리 내 수정을 보유한다. 수정 내용은 셀/키밸류 값이다. 플러시가 요청되면 현재 MemStore가 스냅샷으로 이동되고 지워진다. HBase는 플러시가 플러시 성공했다고 보고할 때까지 새 MemStore 및 백업 스냅샷의 편집 내용을 계속 제공한다. 이때 스냅샷이 삭제된다. 플러시가 발생하면 동일한 영역에 속하는 MemStore가 모두 플러시된다.

MemStore Flush

MemStore 플러시는 아래 나열된 모든 조건에서 트리거될 수 있다. 최소 플러시 단위는 개별 MemStore 레벨이 아닌 region영역당이다.

1. MemStore가 hbase.hregion.memstore.flush.size에서 지정한 크기에 도달하면 해당 영역에 속하는 모든 MemStore가 디스크로 플러시된다.
2. 전체 MemStore 사용량이 hbase.regionserver.global.memstore.upperLimit에서 지정한 값에 도달하면 다양한 영역의 MemStore가 디스크로 플러시되어 RegionServer의 전체 MemStore 사용량을 줄인다.플러시 순서는 region의 MemStore 사용 내림차순을 기반으로 한다. 전체 MemStore 사용량이 hbase.regionserver.global.memstore.lowerLimit 또는 약간 아래로 떨어질 때까지 region은 MemStore를 플러시한다.
3. 지정된 RegionServer의 WAL에서 WAL 로그 항목 수가 hbase.regionserver.max.logs에 지정된 값에 도달하면, 다양한 region의 MemStore가 디스크로 플러시되어 WAL의 로그 수를 줄인다.플러시 순서는 시간을 기준으로 한다.가장 오래된 MemStore가 있는 영역은 WAL 카운트가 hbase.regionserver.max.logs 아래로 떨어질 때까지 먼저 플러시됩니다.

Scans

• 클라이언트가 테이블에 대해 검색을 발행하면 HBase는 영역당 하나씩 RegionScanner 개체를 생성하여 검색 요청을 처리한다.
• RegionScanner 개체에는 StoreScanner 개체 목록이 column family당 하나씩 포함되어 있다.
• 각 StoreScanner 개체에는 해당 열 패밀리의 각 StoreFile 및 HFile에 해당하는 StoreFileScanner 개체 목록과 MemStore에 대한 KeyValueScanner 개체 목록이 추가로 포함된다.
• 두 목록은 하나로 병합되며, 목록 끝에 있는 MemStore의 검색 개체와 함께 오름차순으로 정렬된다.
• StoreFileScanner 개체가 구성되면 현재 memstore인 MultiVersionConcurrencyControl 읽기 지점과 연결된다.

StoreFile(HFile)

StoreFiles는 데이터가 저장된 곳이다.

HFile Tool

텍스트화된 버전의 HFile 내용을 보려면 hbase 파일 도구를 이용할 수 있다.

$ ${HBASE_HOME}/bin/hbase hfile

Blocks

StoreFiles는 블록으로 구성된다. 블록 크기는 ColumnFamily로 구성된다. 압축은 StoreFiles의 블록 레벨에서 발생한다.

KeyValue

KeyValue 클래스는 HBase에서 데이터 스토리지의 심장이다. KeyValue는 바이트 배열을 래핑하고 전달된 배열에 오프셋과 길이를 가져와서 내용을 KeyValue로 해석할 위치를 지정한다.

바이트 배열 내의 키 값 형식은 다음과 같다.

• keylength
• valuelength
• key
• value

키는 추가로 다음과 같이 분해된다.

• rowlength
• row (i.e., the rowkey)
• columnfamilylength
• columnfamily
• columnqualifier
• timestamp
• keytype (e.g., Put, Delete, DeleteColumn, DeleteFamily)

KeyValue 인스턴스는 블록 간에 분할되지 않는다. 예를 들어, 8MB 키 값이 있는 경우 블록 크기가 64KB인 경우에도 이 키 값을 일관된 블록으로 읽는다.