2) Apache HBase® Architecture
HBase의 전체적인 구성요소들이 뭐가 있는지 아키텍처를 살펴보고
세부적으로 가이드문서를 통해 알아보도록 하겠습니다
1. HBase 아키텍처 (HBase Architecture)
설계 개념 (Design Idea)
HBase는 분산 데이터베이스(Distributed Database)이며,
클러스터 관리를 위해 ZooKeeper를 사용하고, HDFS를 기본 스토리지로 활용함.
HBase 주요 구성 요소
HMaster
- Zookeeper에 의해 리더(Leader)로 선출됨
- 클러스터 관리 및 메타데이터 관리 역할 수행
HRegionServer (다수의 서버가 존재)
- 데이터의 실제 저장 및 읽기/쓰기 요청 처리
- 각 RegionServer는 여러 개의 Region을 관리
아래 그림에서는 HBase의 기본적인 구조를 나타냅니다.
(HMaster와 여러 HRegionServer, 그리고 HDFS와의 관계)
HBase에서의 HRegionServer 개념
- HRegionServer는 클러스터 내에서 하나의 노드(Node)에 해당한다.
- 각 HRegionServer는 여러 개의 HRegion을 관리하며,
- 하나의 HRegion은 특정 테이블의 일부 데이터를 저장하는 단위이다.
HBase에서 HRegion의 역할
- 하나의 테이블은 매우 많은 HRegion을 필요로 할 수 있으며,
- 각 HRegion에 저장된 데이터는 무작위로 분산되지 않는다.
HRegion 관리는 RowKey 범위를 기준으로 진행됨
- HBase는 각 HRegion마다 특정 RowKey 범위를 정의
- 해당 범위 내의 데이터를 특정 HRegion에 할당
- 이렇게 하면 데이터가 여러 노드에 분산되어 부하가 균등하게 분배됨
즉, 분산 시스템의 장점을 최대한 활용 가능
HBase의 자동 부하 조절 기능
HBase는 HRegion의 위치를 자동으로 조정함.
만약 특정 HRegionServer에 과부하(Oversload)가 발생하면?
- 해당 서버에 있는 HRegion이 다른, 상대적으로 여유 있는 노드로 이동
- 이를 통해 클러스터 자원을 최적화하고 부하를 분산함
즉, HBase는 자동 부하 균형 기능을 통해 노드 간의 자원 활용도를 극대화함!
HBase 기본 아키텍처 (Basic Architecture)
HBase는 HMaster와 HRegionServer로 구성되며, 마스터-슬레이브(Master-Slave) 아키텍처를 따름.
HBase의 데이터 저장 구조
HBase는 논리적인 테이블을 여러 개의 데이터 블록(HRegion)으로 나눠서 저장함.
각 HRegion은 HRegionServer에 배치되며, 데이터를 실제로 저장하고 관리하는 역할을 수행함.
HMaster의 역할
HMaster는 클러스터 내 모든 HRegionServer를 관리하는 역할
하지만 자신은 데이터를 직접 저장하지 않음!
대신 데이터와 HRegionServer 간의 매핑 정보(메타데이터)를 저장
즉, HMaster는 “관리자 역할”을 하며, 데이터는 HRegionServer에 분산 저장됨.
Zookeeper의 역할
클러스터 내 모든 노드를 조정 및 관리
HBase 운영 중 발생할 수 있는 여러 가지 문제를 처리
HMaster가 죽었을 경우 새로운 HMaster를 선출하는 역할 수행 (Failover 지원)
즉, HBase는 분산된 여러 HRegionServer에 데이터를 저장하고, HMaster와 Zookeeper가 이를 관리하는 구조!
HBase 주요 구성요소 및 동작방식
Client(클라이언트)
HBase의 RPC(Remote Procedure Call) 메커니즘을 사용해 HMaster 및 HRegionServer와 통신
요청을 보내고 결과를 받는 역할
관리 작업 → HMaster와 RPC 수행
데이터 읽기/쓰기 작업 → HRegionServer와 RPC 수행
ZooKeeper (주키퍼)
클러스터의 모든 노드 상태 정보를 등록 및 관리
HMaster가 각 HRegionServer의 상태를 실시간으로 감지할 수 있도록 지원
HMaster의 싱글 포인트 장애(Single Point of Failure, SPOF) 방지
- 여러 개의 HMaster가 실행될 수 있으며, Zookeeper의 선출(Election) 메커니즘을 통해 항상 하나의 HMaster만 활성화됨
즉, HBase 클러스터의 안정성을 보장하는 핵심 요소
HMaster
클러스터 내 모든 HRegionServer를 관리하는 역할
HRegionServer에 어떤 HRegion을 할당해야 하는지 지시
각 HRegionServer의 상태를 모니터링하고, 장애 발생 시 조치 수행
HRegionServer가 새로운 노드로 등록되면, 데이터를 할당하기 위해 대기 상태로 둠
HRegionServer가 다운되면, 해당 서버가 관리하던 모든 HRegion을 “할당되지 않음(unallocated)” 상태로 표시하고,
다른 HRegionServer에 재할당
HBase는 다중 HMaster 실행이 가능하며, ZooKeeper를 통해 하나의 HMaster만 활성화되도록 보장
즉, HMaster가 죽어도 클러스터가 계속 동작할 수 있음 → 고가용성(HA) 보장
HRegion (데이터 저장 단위)
HBase 테이블이 커지면, 테이블을 여러 개의 HRegion으로 자동 분할
각 HRegion은 테이블의 일부 데이터(특정 범위의 RowKey)를 저장함
사용자 입장에서 HBase의 테이블은 하나의 데이터 집합처럼 보이지만, 실제로는 여러 개의 HRegion으로 나뉘어 저장됨
각 HRegion은 테이블 이름 + 시작/끝 RowKey 범위로 구분됨
즉, 하나의 HRegion은 테이블의 연속된 데이터 조각을 저장
전체 테이블 데이터는 여러 개의 HRegion에 분산 저장됨
HRegionServer
HBase의 모든 데이터는 기본적으로 HDFS에 저장됨
사용자는 HRegionServer를 통해 데이터를 읽고 씀 (HRegionServer가 I/O 요청을 처리)
일반적으로 하나의 클러스터 노드에는 하나의 HRegionServer가 실행됨
각 HRegion은 하나의 HRegionServer에 의해 관리됨 (즉, 특정 HRegion을 동시에 여러 HRegionServer가 관리할 수 없음)
HDFS와 연동하여 데이터를 저장하고, 요청이 들어오면 데이터를 읽거나 씀
즉, HRegionServer는 HBase에서 데이터를 관리하고 처리하는 핵심 모듈
HRegionServer 내부 구조
HRegionServer는 여러 개의 HRegion 객체를 관리
각 HRegion은 테이블의 연속된 데이터 조각을 저장
HRegion 내부에는 여러 개의 HStore가 존재
각 HStore는 특정 컬럼 패밀리(Column Family)의 데이터를 저장
즉, 컬럼 패밀리별로 별도의 저장 공간이 존재하며, 동일한 I/O 특성을 가진 컬럼을 하나의 컬럼 패밀리로 묶는 것이 성능 최적화에 유리함
HStore (HBase의 저장 핵심)
HBase의 저장 엔진으로, MemStore와 StoreFile로 구성됨
MemStore:
- 메모리 캐시(Buffer) 역할
- 사용자가 데이터를 쓰면 먼저 MemStore에 저장됨
- MemStore가 가득 차면(버퍼가 넘치면) StoreFile로 플러시(Flush)됨
StoreFile:
- HDFS에 저장되는 파일 형태 (HFile 형식으로 저장)
- 일정 개수 이상의 StoreFile이 생성되면 Compaction(병합) 수행
Compaction (병합 연산):
- 여러 개의 StoreFile을 하나로 합치는 작업
- 데이터의 중복을 제거하고, 삭제된 데이터를 정리하여 최적화
Split (분할 연산):
- StoreFile이 일정 크기 이상으로 커지면 HRegion을 두 개로 나눔
- 기존 HRegion을 오프라인 상태로 두고, 두 개의 서브 HRegion을 생성하여 HRegionServer에 배치
- 이를 통해 데이터가 자동으로 여러 노드에 분산되도록 유도
HLog (Write-Ahead Log, WAL)
- 각 HRegionServer는 하나의 HLog 객체를 가짐
- HLog는 Write-Ahead Log(WAL, 사전 기록 로그)를 구현한 클래스
- 사용자가 데이터를 MemStore에 쓰면, 동일한 내용을 HLog에도 기록 (장애 복구용)
- 주기적으로 HLog 파일을 롤링 및 삭제 (StoreFile에 영구 저장된 데이터는 HLog에서 삭제됨)
- 장애 발생 시 HLog를 이용하여 데이터 복구 가능
- HMaster는 Zookeeper를 통해 HRegionServer의 비정상 종료를 감지하면,
해당 HRegionServer의 HLog 파일을 분석하여 복구를 수행
즉, HLog는 데이터 영속성을 보장하고 장애 발생 시 데이터 복구를 담당
Root와 Meta 테이블의 역할 (HBase Metadata 관리)
HBase의 모든 HRegion 메타데이터는 .META. 테이블에 저장됨.
HRegion의 개수가 증가하면, .META. 테이블의 데이터도 증가하며, 여러 개의 HRegion으로 분할(Split)됨.
HBase에서 HRegion을 찾는 과정
HBase는 계층적인 방식으로 HRegion의 위치를 관리함.
1. .META. 테이블
- HBase의 모든 HRegion의 메타데이터를 저장하는 테이블
- 어떤 RowKey 범위가 어느 HRegionServer에 위치하는지 기록
- .META. 테이블의 크기가 커지면 여러 개의 HRegion으로 나뉘어 저장됨
2. -ROOT- 테이블
- .META. 테이블이 여러 개의 HRegion으로 분할되면,
→ 어느 HRegion에 어떤 .META. 데이터가 있는지 기록하는 테이블
즉, .META. 테이블의 위치를 찾기 위한 테이블
3. ZooKeeper
- -ROOT- 테이블의 위치를 기록함.
- 모든 클라이언트는 데이터를 조회하기 전에 ZooKeeper에 먼저 접근하여 -ROOT- 테이블의 위치를 가져옴.
HBase의 -ROOT- 테이블과 .META. 테이블의 동작 방식
-ROOT- 테이블은 절대 분할(Split)되지 않음.
오직 하나의 HRegion만 존재, 따라서 어떤 HRegion이든 “최대 3번의 조회(Jump)로 위치 확인 가능”
.META. 테이블의 모든 HRegion 정보는 메모리에 캐싱되어 있어 조회 속도를 향상시킴
클라이언트의 데이터 조회 과정
클라이언트는 데이터를 조회할 때, 기존에 캐싱된 위치 정보를 활용
1) 클라이언트는 캐싱된 데이터 위치를 먼저 확인 (cnt 1)
- 만약 캐시에 존재하면 바로 데이터에 접근 (cnt 2)
- 하지만 클라이언트 캐시는 자동으로 만료되지 않음 (Cache does not actively fail)
2) 캐시 정보로 데이터에 접근할 수 없을 경우
- .META. 테이블이 위치한 RegionServer에 요청하여 데이터의 정확한 위치를 확인 (cnt 3)
- 그래도 실패하면, .META. 테이블이 어디 있는지 -ROOT- 테이블에 문의 (cnt 4)
3) 이전 단계에서도 데이터 위치를 찾지 못하면?
- ZooKeeper가 최종적으로 해당 HRegion의 위치를 다시 찾음 (cnt 5)
- 최종적으로 클라이언트가 새롭게 찾은 HRegion으로 데이터 요청(cnt 6)
즉, 클라이언트의 캐시가 완전히 무효화되었을 경우, 올바른 HRegion을 찾기까지 “최대 6번의 요청”이 필요함. 🚀
2. HBase 데이터 모델 (HBase Data Model)
HBase는 Google의 BigTable과 유사한 분산 데이터베이스
HDFS 위에서 동작하는 희소성(Sparse) 기반 장기 저장소
다차원(Multi-Dimensional) 및 정렬된(Sorted) 매핑 테이블 구조
HBase 테이블 구조
HBase 테이블의 인덱스는 다음 세 가지 요소로 구성됨:
1) Row Key (행 키, Row Keyword) → 데이터의 기본 키 역할
2) Column Key (컬럼 키, Column Keyword) → Column Family + Column Qualifier
3) Timestamp (타임스탬프) → 버전 관리
HBase 데이터는 문자열(String)로 저장되며, 특정 데이터 타입이 없음!
즉, 모든 데이터는 바이트 배열(Byte Array)로 저장됨 → 타입 제한이 없어 유연성이 높음
HBase 데이터 모델 개념 정리
HBase에서 테이블은 거대한 매핑(Mapping) 구조와 같음
특정 데이터를 찾는 방법
- RowKey로 조회
- RowKey + Timestamp로 조회
- RowKey + Column (Column Family: Column Qualifier) 조합으로 조회
HBase는 희소(Sparse) 데이터 저장 방식 → 일부 컬럼이 비어 있어도 무관
HBase 테이블 구조 예시
예제 테이블: com.cnn.www 웹사이트 데이터 저장
RowKey: "com.cnn.www" (이 행의 유일한 식별자)
각 데이터 수정 시 타임스탬프(Timestamp) 기록됨
테이블에는 4개의 컬럼 존재:
- contents: HTML
- anchor: cnnsi.com
- anchor: my.look.ca
- mime: type
각 컬럼은 특정 컬럼 패밀리(Column Family)에 속함
RowKey의 역할과 특징
RowKey는 테이블에서 데이터 행을 식별하는 유일한 키
HBase에서 행(Row) 조회 방식은 3가지뿐
1) RowKey를 통한 직접 조회
2) RowKey 범위를 지정한 Range 조회
3) 전체 테이블 스캔(Full Table Scan)
RowKey는 문자열(String) 형태 (최대 64KB 크기)
RowKey는 “사전 순(Lexicographical Order)“으로 저장됨
자주 함께 읽히는 행들은 RowKey 설계를 신중하게 해야 효율적으로 저장 가능
3. HBase read and write process
HBase의 읽기/쓰기 프로세스 (HRegionServer 데이터 저장 구조)
아래 그림은 HRegionServer의 데이터 저장 관계를 나타냄.
HBase는 MemStore와 StoreFile을 사용하여 테이블의 변경 사항을 저장
데이터가 업데이트될 때, 먼저 HLog(Write-Ahead Log, WAL)와 MemStore에 기록됨
MemStore에 저장된 데이터는 자동으로 정렬(Sorted)됨
HBase의 데이터 저장 및 관리 프로세스
MemStore가 일정 임계치(Threshold)에 도달하면:
- 새로운 MemStore가 생성됨
- 기존 MemStore는 Flush 큐(Queue)에 추가됨
- 별도의 쓰레드(Thread)가 MemStore 데이터를 Disk로 플러시(Flush)하여 StoreFile로 변환
동시에 시스템은 Zookeeper에 CheckPoint를 기록
- 이 CheckPoint는 이 시점 이전의 데이터 변경 사항이 디스크에 영구 저장되었음을 의미
- 시스템 장애 발생 시, CheckPoint 이전의 데이터는 안전하게 저장됨
- 하지만 CheckPoint 이후의 MemStore 데이터는 손실될 가능성이 있음
이런 경우 HLog(Write-Ahead Log, WAL)를 사용하여 데이터 복구
- CheckPoint 이후의 변경 사항을 HLog에서 읽어와 복구 수행
StoreFile(스토어파일) 관리
StoreFile은 읽기 전용(Read-Only)이며, 생성 후 수정할 수 없음
따라서 HBase의 데이터 갱신(Update)은 “추가(Append)” 방식으로 이루어짐
StoreFile이 일정 임계치를 초과하면 병합(Merge) 작업 수행
- 동일한 키(Key)의 여러 변경 사항을 하나로 합쳐 더 큰 StoreFile을 생성
StoreFile 크기가 너무 커지면? → Split(분할) 수행
- 기존 StoreFile을 두 개의 StoreFile로 나누어 관리
즉, HBase는 MemStore → StoreFile(Flush) → Merge → Split 과정을 거쳐 데이터를 효율적으로 관리!
Write operation flow
Step 1: 클라이언트가 HRegionServer로 데이터 쓰기 요청 전송
클라이언트는 ZooKeeper를 통해 HRegionServer를 찾고, 해당 HRegion에 데이터를 쓰기 요청을 보냄.
Step 2: 데이터가 HRegion의 MemStore에 저장됨
HRegion의 MemStore에 데이터가 저장되며, MemStore가 미리 설정된 임계치(Threshold)에 도달할 때까지 유지됨.
Step 3: MemStore의 데이터가 StoreFile로 Flush됨
MemStore가 가득 차면, 그 내용을 StoreFile로 변환하여 HDFS에 저장.
Step 4: StoreFile 개수가 증가하면 Compact(병합) 연산 수행
StoreFile 개수가 일정 임계치를 초과하면 Compact Merge 작업이 트리거됨.
여러 개의 StoreFile을 하나로 합치면서 버전 병합 및 삭제된 데이터 정리 작업 수행.
Step 5: StoreFile 크기가 점점 커짐 (지속적인 Compact 과정 진행)
Compact 연산이 반복되면서 StoreFile 크기가 점점 커짐.
Step 6: StoreFile이 너무 커지면 HRegion을 Split(분할)함
단일 StoreFile 크기가 특정 임계치를 넘어서면 Split 연산이 발생.
기존 HRegion이 두 개의 새로운 HRegion으로 분할됨.
부모 HRegion은 비활성화(Offline)되며, 새로운 두 개의 HRegion은 HMaster에 의해 적절한 HRegionServer로 재배치.
이를 통해 기존 HRegion의 부하가 분산됨.
Read Operation Flow
Step 1: 클라이언트가 ZooKeeper에서 -ROOT- 테이블 정보를 조회
클라이언트는 ZooKeeper에 접속하여 -ROOT- 테이블의 위치를 확인.
이를 통해 .META. 테이블의 위치를 조회함.
Step 2: .META. 테이블을 조회하여 타겟 데이터의 HRegion 정보 확인
.META. 테이블을 검색하여 클라이언트가 원하는 데이터를 포함하는 HRegion의 위치를 찾음.
그 HRegion을 관리하는 HRegionServer의 주소를 확인함.
Step 3: HRegionServer에서 데이터 조회
찾은 HRegionServer에 데이터 요청을 보내고, 해당 데이터를 조회함.
Step 4: HRegionServer의 메모리 구조에서 데이터 검색
HRegionServer의 메모리는 MemStore와 BlockCache 두 부분으로 나뉨.
먼저 MemStore에서 데이터가 있는지 확인 (최신 데이터가 있을 수 있음).
다음으로 BlockCache에서 캐싱된 데이터를 확인.
캐시에 없는 경우, StoreFile에서 데이터를 직접 조회.
읽은 데이터를 BlockCache에 저장하여 다음 검색 시 성능을 향상.
즉, HBase의 읽기 프로세스는 “캐시 → 디스크 순서”로 최적화되어 있어 성능을 높임!
4. HBase usage scenarios
HBase vs RDBMS: HBase가 필요한 이유
HBase는 반구조적(Semi-structured) 또는 비구조적(Unstructured) 데이터를 처리하는 데 강점이 있음.
RDBMS는 데이터 구조가 고정되어 있어 확장이 어렵지만, HBase는 유연한 데이터 모델을 지원.
1. 반구조적 / 비구조적 데이터 처리
- RDBMS는 데이터 필드(Columns)가 고정적이므로, 새로운 필드를 추가하려면 DB 테이블을 변경해야 함.
→ 변경 시 다운타임(운영 중단)이 발생할 수 있음.
- 반면, HBase는 동적으로 컬럼을 추가할 수 있어 비즈니스가 성장함에 따라 유연하게 확장 가능.
2. 희소성 데이터 저장 (Sparse Data Storage)
- RDBMS에서는 모든 컬럼이 고정되어 있어, 값이 없는 컬럼도 저장됨.
→ 빈 컬럼(Null 값)도 공간을 차지하여 저장 효율이 떨어짐.
- 반면, HBase는 비어있는 컬럼을 저장하지 않음.
→ 공간 절약 + 읽기 성능 개선 효과
3. 다중 버전 데이터 관리 (Multi-Version Data Management)
- HBase는 RowKey + Column 조합으로 데이터를 찾을 때, 여러 버전의 값을 가질 수 있음.
→ 즉, 타임스탬프(Timestamp)를 이용하여 변경 이력을 저장 가능.
- 과거 데이터를 유지하면서 변경 기록을 관리해야 하는 경우 매우 유용!
4. 대량 데이터 처리 문제 (Big Data Scaling)
- RDBMS는 데이터가 많아질수록 성능 한계에 부딪힘.
- 일반적으로 마스터-슬레이브(Master-Slave) 방식으로 읽기-쓰기 분리
- 마스터가 쓰기 담당, 슬레이브가 읽기 담당
- 하지만 데이터가 폭증하면 마스터가 감당할 수 없게 됨.
- 이때 DB 샤딩(Sharding, 테이블 분할) 작업이 필요함.
- 샤딩 과정에서 JOIN 불가능 → 중간 계층(Middleware) 필요
- 데이터 증가 → 테이블 커짐 → 조회 성능 저하 → 또 테이블 분할 필요
- 운영이 복잡해지고 유지보수 어려움
HBase는 이런 문제를 단순화함!
- 노드(Node) 추가만 하면 HBase가 자동으로 데이터를 분산 저장.
- 수평 확장(Horizontal Scaling)으로 성능 유지 가능.
- Hadoop과 통합되어 HDFS 기반의 데이터 안정성 보장 + MapReduce로 빠른 데이터 분석 가능!
| 문제 | RDBMS의 한계 | HBase 해결책 |
| 데이터 확장성 | 테이블 변경 시 다운타임 발생 | 컬럼 동적 추가 가능 |
| 희소 데이터 저장 | 빈 컬럼도 저장되어 공간 낭비 | 빈 컬럼은 저장하지 않음 → 효율적 |
| 변경 이력 관리 | 개별 테이블을 따로 만들어야 함 | RowKey + Timestamp로 버전 관리 |
| 대량 데이터 처리 | 샤딩 필요, JOIN 불가, 성능 저하 | 노드 추가만 하면 자동 확장! |
| 분산 시스템 지원 | 수직 확장(Scale-up) 한계 | HDFS + MapReduce 기반으로 수평 확장(Scale-out) 가능 |
즉, HBase는 대량의 비정형 데이터를 저장하고 확장하는 데 최적화된 NoSQL 데이터베이스!
5. HBase Map Reduce
HBase의 테이블과 리전(Region) 관계
HBase에서 “테이블(Table)과 리전(Region)의 관계”는 HDFS의 “파일(File)과 블록(Block)의 관계”와 유사함.
즉, HBase 테이블은 여러 개의 HRegion으로 나뉘어 저장되며, HDFS의 파일이 여러 블록으로 나뉘는 방식과 비슷함.
HBase와 MapReduce 연동
HBase는 MapReduce와 연동할 수 있는 API(TableInputFormat, TableOutputFormat)를 제공함.
이를 통해 HBase 테이블을 Hadoop MapReduce의 입력(Input)과 출력(Output)으로 직접 사용할 수 있음.
즉, 개발자가 HBase 데이터를 MapReduce로 처리할 때, HBase 내부 시스템의 세부적인 처리를 신경 쓰지 않아도 됨.
참고 : 링크