HBase 소개

Contents

HBase(Hadoop database)는 하둡 기반의 분산 데이터베이스로 빅데이터를 저장하기 위해서 사용한다. NoSQL로 분류되는데, 많은 NoSQL 솔류션들이 그렇듯이 스키마 변경없이 자유롭게 데이터를 저장 할 수 있다. HDFS위에서 작동하기 때문에, HDFS의 데이터의 가용성과 확장성을 그대로 이용 할 수 있다. 데이터베이스 CAP 이론에서 HBASE는 CP 타입(Consistency & Partition tolerance) 시스템으로 구글의 BigData모델과 유사한 기능을 제공한다.

HBase는 BigTable 논문의 설명을 그대로 구현하고 있다. 즉 컬럼 단위의 데이터 저장, 압축, 메모리 작업 Bloom 필터등을 제공한다. HBase는 Hadoop에서 실행되는 MapReduce의 입력/출력을 사용 할 수 있다. 기본적으로 Java API를 통해서 접근 할 수 있지만 REST, Avro 혹은 Thrift 게이터웨이를 통한 접근도 가능하다.

HBase는 SQL 데이터베이스를 대체하는 솔류션이 아니지만 Apache Phoenix와 같은 소프트웨어를 이용해서 SQL 레이어를 올릴 수 있다. SQL 레이어를 올리면 JDBC 드라이버 등을 사용해서 다양한 분석 작업을 (익숙한 방법으로)쉽게 처리 할 수 있다.

HBase의 기본 단위는 컬럼이고 이 컬럼들이 모여서 컬럼 패밀리(Column Family)를 구성하고, 이 컬럼 패밀리가 모여서 테이블을 구성한다. 테이블에 들어가는 각 row는 rowkey를 가지고 식별 할 수 있다. 아래 그림을 보자.

1. 이 테이블은 Customer와 Sales 두 개의 컬럼 패밀리를 가지고 있다.
2. Customer 컬럼 패밀리는 Name과 City 두 개의 컬럼을 가지고 있다.
3. Sales 컬럼 패밀리는 Product와 Amount 두 개의 컬럼을 가지고 있다.
4. Row는 Row Key, Customer CF, Sales CF로 구성된다.

여기에서 컬럼 패밀리는 단순히 컬럼의 그룹이라는 것을 알 수 있다. 그런데 왜 HBase는 컬럼 패밀리라는 걸 가지고 있을까? 이유를 알기 위해서는 HBase의 데이터베이스 특징을 살펴볼 필요가 있다.

HBase는 distirbuted, Sparse, Column-Oriented, versioned, Non-relational의 특징을 가지고 있다.

위 그림은 HBase의 특징을 잘 보여준다.

1. Sparse 는 밀도가 희박한이라는 뜻을 가진다. HBase는 sparse matrix(희소행렬)방식으로 데이터를 저장 할 수 있다. 예컨데 굳이 모든 필드에 값을 채울 필요가 없다는 얘기다.
2. Column Oriented : RDBMS는 row 단위로 데이터를 저장한다. 하지만 HBase는 Sparse하기 때문에, 컬럼 단위로 데이터를 읽고 쓸 수 있다.
3. Distributed. 테이블은 수백만개의 Row와 컬럼들로 구성된다. 이들 컬럼들은 쉽게 분산 할 수 있다.
4. versioned. 위 테이블은 Customer ID를 Row key로 사용하고 있다. 당연하지만 고객은 하나 이상의 물건을 구매할 수 있기 때문에 하나의 row key에 여러 개의 row를 저장 할 수 있다. 이 경우 Timestamp가 버전이 되며, 질의를 할 경우 가장 최근 timestamp의 row를 읽어 온다.
5. Non-relational. 관계형 데이터베이스의 ACID 속성을 따르지 않는다.

아래 그림은 HBase의 확장성 모델을 묘사하고 있다.

Region은 HBase에서 수평확장(Scale-in/out)의 기본단위다. Region은 함께 저장되는 테이블 데이터의 부분집합이다. 처음에는 테이블은 오직 한개의 Region에만 있다. 만약 Region에 많은 row 들이 추가되서 그 크기가 너무 커지면, 중간키를 이용해서 Region을 반으로 나눠서 저장한다.

각 테이블의 데이터는 HregionServer가 관리하며, 전체 클러스터는 HMaster관리한다.

HMASTER는 아래와 같은 일들을 한다.

• 리전 서버들을 조정한다.
  • 리전의 시작을 관리한다. 로드 밸런싱을 위해서 리전을 재 할당하거나 복구하는 등의 일을 한다.
  • 클러스터에 있는 모든 리전 서버들을 (주키퍼를 이용해서)모니터링 한다.
• 관리 기능
  • 테이블의 생성, 삭제, 업데이트

테이블이 region으로 나눠지면, key를 관리하기 위한 장치가 필요할 것이다. Key와 Region의 맵핑정보는 META라는 이름의 시스템테이블에 저장된다. 따라서 클라이언트는 Master와 통신하지 않고 Region server와 통신하는 것으로 읽기/쓰기 작업을 할 수 있다.

HBase는 주키퍼를 이용해서 클러스터를 구성하는 서버들의 상태를 관리한다. 주키퍼는 서비스들이 살아 있는지 그리고 사용 가능한지를 모니터링하며, 실패할 경우 이를 알린다. 또한 클러스터간의 정보공유를 위한 저장소의 역할을 한다. 주키퍼 자체 가용성을 위해서 3대 혹은 5대로 구성한다.

활성화된 리전서버와 HMaster는 주키퍼에 연결이 된다. 주키퍼는 하트비트를 통해서 이들 노드의 상태를 관리한다.

각 리전 서버는 ephemeral 노드로 등록이 된다. 따라서 리전서버에 문제가 생기면, 이 노드는 클러스터에서 즉시 제외된다. HMaster역시 ephemeral node로 등록이 된다. HMaster가 실패는 전체 클러스터의 실패로 이어질 수 있으므로, 두 대 이상의 노드가 Master/Slave 방식으로 구성된다. 하나의 HMaster 노드만 활성화 되는데, 이 역시 주키퍼가 책임진다.

HBase는 META 테이블이라고 부르는 HBase Catalog 테이블을 유지한다. 여기에는 클러스터에 포함된 리전의 위치정보들을 저장하고 있따. 이 테이블은 주키퍼가 관리한다.

1. 클라이언트는 주키퍼의 META 테이블을 서비스하는 리전 서버의 호스트 정보를 읽어온다.
2. 클라이언트는 리전 서버에 .META 테이블을 질의해서 접근하려는 row 키를 가지고 있는 리전 서버 정보를 가져온다. 클라이언트는 META 테이블의 정보를 캐시한다.
3. 해당 리전 서버로 부터 row를 읽는다.

HBase META 테이블은 아래와 같은 구조를 가지고 있다.

• .META 테이블은 클러스터에 있는 모든 리전 정보를 저장하고 있다.
• .META 테이블은 b tree 다.
• .META 테이블은 Key와 Value로 구성된다.
  • KEY : 리전의 ID와 테이블, Start key를 가지고 있다.
  • Values : 리전 서버

아래 그림은 META 테이블의 구조를 묘사하고 있다.

리전 서버는 HDFS 데이터 노드위에서 실행된다. 아래의 컴포넌트들로 구성된다.

• WAL : Write Ahead Log파일로 분산 파일 시스템에 기록된다. 데이터는 영구 저장장치(하드디스크)에 저장되기전에 WAL에 먼저 저장이 된다. 데이터 저장 실패를 복구하기 위해서 사용된다.
• BlockCache : 읽기 캐시다. 자주 접근하는 데이터는 메모리에 저장해서 읽기 성능을 높인다.
• MemStore : 쓰기 캐시다. 아직 디스크에 기록되지 않은 데이터들이 저장된다. 데이터는 디스크에 쓰기전에 정렬된다. 각 리전의 컬럼 패밀리당 하나의 MemStore가 있다.
• 데이터들은 Key & Values 형태로 Hfiles로 저장된다.

클라이언트에서 데이터와 함께 Put 요청을 전송하면, 이 데이터는 WAL에 기록된다. WAL은 로그파일 시스템으로 입력된 데이터는 맨 마지막에 추가된다. 서버에 어떤 문제가 생길 경우 데이터를 복구하기 위해서 사용한다.

WAL에 쌓인 데이터는 MemStore로 복사된다. 이때 비로서 클라이언트에 acknowledgement가 리턴된다.

MemStore는 Key/Value 데이터를 정렬해서 저장하고, 이 데이터를 그대로 HFile에 저장한다. 하나의 컬럼패밀리당 하나의 MemStore가 존재한다.

MemStore에 충분한 데이터가 쌓이면, 정렬된 전체 집합을 HDFS에 새로운 HFile을 만들어서 저장한다. MemStore가 컬럼패밀리단위로 연산을 하기 때문에 HFile역시 각 컬럼패밀리당 HFile을 생성한다.

컬럼패밀리가 늘어나면 HFile이 늘어나는 구조 때문에, HBase는 컬럼패밀리에 제한을 두고 있다. 하나의 컬럼패밀리당 하나의 MemStore가 있고, MemStore이 꽉차면 모든 내용을 flush 한다. 또한 마지막으로 기록된 시퀀스 번호를 저장해서 지금까지 저장한 내용을 추적할 수 있게 한다. 가장 높은 시퀀스 번호는 각 HFile에 메타필드로 저장되어서, 어느 시점에서 저장이 끝났는지를 알려준다.

데이터는 Key/Value 형식으로 HFile에 저장된다. MemSotre는 데이터가 충분히차면 새로운 HDFS에 새로운 HFile을 만들어서 저장한다. 랜덤엑세스를 최소화하는 구조로 이 과정은 매우 빠르게 이루어진다.

HBase는 데이터를 효율적으로 찾기 위해서 multi-layerd index를 사용한다. Multi-layerd index는 B+tree와 비슷하다.

• Key/Value는 increasing order 로 저장된다.
• 색인은 64KB 크기의 블록을 가리킨다.
• 각 블럭은 자체적으로 leaf-index를 가지고 있다.
• 각 블럭의 마지막 키는 중간색인(intermediate index) 된다.
• 루트 인덱스는 중간색인 가리킨다.

HFile 색인은 Hfile이 열릴때 읽어서 메모리에 올린다. 따라서, 처음 한번 디스크를 읽는 것으로 조회작업을 실행 할 수 있다.

데이터를 입력하다 보면 여러 개의 작은 HFile들이 만들어진다. 파일들이 많아지면 성능이 떨어질 수 있는데, HBase는 자동으로 여러 개의 HFile들을 좀 더 큰 몇 개의 HFiles로 다시만드는 식으로 HFile의 개수를 관리한다. Minor compaction은 여러 개의 HFile들을 하나의 큰 HFile로 통합한다. HFile에 저장된 데이터는 정렬되 있으므로 merge sort를 이용해서 빠르게 합병할 수 있다.

Major compaction은 리전에 있는 모든 HFiles들을 모아서 컬럼당 하나의 HFile로 만든다. 이 과정에서 필요없는 셀, 시간이 초과된 셀등을 제거해서 전반적인 읽기 성능을 높인다. 대량의 파일들에 대한 읽기/쓰기 작업이 일어나기 때문에 디스크 I/O와 트래픽 증가가 발생할 수 있다.

Major compaction은 자동으로 실행하도록 예약 할 수 있다. 급작스러운 I/O의 증가가 서비스에 미치는 영향을 최소화하기 위해서 주말이나 야간으로 스케줄링 할 수 있다.

기본적으로 하나의 테이블은 하나의 리전에 저장된다. 리전이 너무커지면, Hbase는 이 리전을 두 개의 child 리전으로 나눈다. 리전을 나누어야 할 경우 이 정보를 HMaster에 보고하고, HMaster는 로드를 조정하기 위해서 새 리전을 다른 서버로 이동하기 위한 작업을 수행한다. 이때 데이터를 즉시 이동

Region split가 발생한다고 해서, 다른 서버로 테이블이 이동하는 것은 아니다. 이때는 다만 리전 서버만 다른 노드에 두는 방식으로 리전 서버의 로드만 분산한다. HFile의 물리적인 이동은 다음번 compaction에서 이루어진다.

모든 데이터 읽기와 쓰기는 프라이머리 노드를 통해서 이루어진다. HDFS는 WAL과 HFile 블럭을 복재한다. 이때 HFile 블럭의 복재는 자동으로 이루어진다. HBase는 HDFS를 기반으로 하고 있기 때문에, 안전하게 데이터를 저장 할 수 있다. 데이터를 HDFS에 쓰면, 하나의 사본이 로컬에 기록되고 다음 2차 노드에 복제되고 3차 사본이 3차 노드에 기록된다.

리전서버가 실패하면, 실패를 감지하고 복구하기 전까지는 해당 리전을 사용 할 수 없어야 한다. 주키퍼는 리전 서버에 주기적으로 허트비트(Heat beats)메시지에 대한 응답을 확인한다. 만약 리전 서버가 허트비트 요청에 대한 응답을 하지 않은 경우 노드가 실패했다고 판단한다. 동시에 HMaster는 리전서버가 실패했다는 통지를 받게된다.

리전서버 실패를 감지한 HMaster는 충돌한 리전을 작동중인 다른 리전서버에 할당 한다. 이제 Memstore에서 디스크로 flus되지 않은 데이터는 복제된 WAL 데이터를 이용해서 복구한다. HMaster는 복제된 WAL 데이터를 별도의 파일로 분할하고, 이 파일을 새로 할당한 리전서버의 데이터노드에 저장한다. 이제 각 리전서버는 데이터노드에 저장된 WAL 파일로 부터 WAL을 재생해서 Memstore를 재 구성 한다.

아래의 장점을 가진다.

• 강력한 consistency 모델을 지원한다. 모든 리더는 같은 값을 읽는다.
• Auto Scale
  • 데이터가 너무 커지면 리전이 분리된다.
  • HDFS의 복제 기능을 이용해서 자동으로 진행된다.
• 강력한 복구 기능 : WAL을 이용해서 자체복구한다.(저널링 파일 시스템과 유사한 매커니즘이다.)
• Hadoop과 통합 : MapReduce와 자연스럽게 통합된다.

아래의 단점을 가지고 있다.

• 비지니스 연속성과 신뢰성
  • WAL은 느리다.
  • 복구과정이 느리다.

	RDBMS	HBase
데이터 레이아웃	Row oriented	Column oriented
Transactions	Multi-row ACID	Single row or adjacent row groups only
Query Language	SQL	NON(API Access)
Indexes	임의의 열(자유롭다)	Single row index only
Max data size	Terabytes	Petabytes
R/W throughput limits	1000s of operations per second	Millions of operations per second

• Transforming HBase into a Relational Database
• How scaling really works in apache hbase
• In depth look HBase architecture