apache Hbase

HBase8)는 구글 Bigtable9)의 오픈소스 버전으로 보면 된다. 내부적으로 쓰이는 용어만 다를 뿐 시스템 아키텍처와 데이터 모델, 사용자 인터페이스는 거의 유사하다. Bigtable 특성을 그대로 이어받아 컬럼 기반의 다차원 분산 데이터 스토어로 구성된다. 2007년 아파치 프로젝트로 등록된 이후 2009년부터 활발한 개발됐으며, 현재(2015년 1월 10일)는 0.94.1 정식 버전이 출시돼 서비스에 적용이 가능한 수준까지 발전했다. 위에서 설명한 범주 중 CP를 만족시키며, Bigtable 모델링을 지원하고 마스터-슬레이브 시스템 구조를 따라간다. HBase 홈페이지에서도 말하듯이 HBase는 실시간 랜덤읽기/쓰기 작업이 빅데이터를 대상으로 필요할 때 사용된다. 하둡을 기반 스토리지로 사용하기 때문에 하둡 지식과 운영능력은 필수적이다. 쓰기에 최적화 돼 있어 읽기 성능이 비교적 느리지만 캐시 기술등을 접목했고, 무엇보다 사용자가 HBase의 특성을 잘 이해하고 접근 패턴을 설계하면 읽기 성능을 대폭 개선할 수 있다. HBase의 범주는 데이터베이스이지만 기능적으로 분산 데이터 스토어(data store)에 가깝다. RDBMS처럼 컬럼속성 정의, 세컨더리 인덱스, 트리거, ANSI-92, ANSI-99 SQL 언어와 기능은 지원하지 않는 대신 물류창고처럼 대규모 데이터를 쌓고 응집화하는데 초점을 맞춘다. 선형과 모듈 확장을 지원하기 때문에 서버 한 대를 추가할 때마다 1/n 만큼의 스토리지와 데이터 처리 성능이 향상된다.

다음은 HBase의 주요기능이다.

• 읽기/쓰기 작업의 절대 무결성
• 자동 샤딩
• 자동 RegionServer 장애 처리
• HDFS 스토리지
• MapReduce 지원
• 자바 클라이언트 API 제공
• 쓰리프트/REST API 제공
• 블록 캐시/블룸필터 지원
• 버저닝 지원
• 웹 관리콘솔 제공

물론 장점만 있는 건 아니다. 기능상 트랜젝션이 처리나 관계형 분석에는 적합하지 않다. 자체적으로 세컨더리 인덱스를 지원하지 않는다. MapReduce 같은 배치성 작업에는 스캔 캐시, 필터링 등을 적용해야 제 성능을 낸다.
HDFS 스토리지에 기반을 두었고 MapReduce 인터페이스를 제공하므로 하둡의 필수 지식과 운영 노하우가 필요하다. 일반적으로 시스템을 하둡과 공유하므로 메모리 및 네트워크 같은 시스템 자원이 추가로 필요하다.
물론 HBase 운영시 필요한 zookeeper 노드를 수행할 서버도 필요하다. 활용 예로 대규모 로그성 데이터를 보관하고 랜덤 조회가 필요할 때 사용한다. 페이스북의 메시지 시스템을 예로 들어 보자. 사용자 간 대화 내용을 하나의 레코드 또는 셀(cell)에 보관하고 조회할 때는 해당 키로 랜덤접근하면 된다. 쿼리가 복잡하지 않아 성능에 큰 저하가 없으며, HBase의 무결성 덕분에 사용자들은 항상 최신의 대화 내용만 전달받는다. HBase를 적용하기 전에는 페이스북에서 개발한 Cassandra를 사용했는데 Cassandra의 Eventual Consistency10) 특성 때문에 실제 상대방의 메시지가 늦게 도착하거나 최신 과거 대화 내용이 안 보이는 경우가 종종 발생했다.

HBase 아키텍처

너무 이론적인 이야기로 여러분은 지금까지 HBase 구름을 그리고 있을 것이다. [그림 Ⅱ-2-5]는 여러분의 스케치에 도움을 주고자 HBase의 실체를 표현한 것이다.

[그림 Ⅱ-2-5] HBase 아키텍처

Bottom-up 접근으로 차근차근 풀어가 보자.

HFile

HBase의 키밸류 데이터를 구성하는 가장 기본 단위이며, HDFS의 파일 형태로 저장된다.

[그림 Ⅱ-2-6] HFile

HFile은 HDFS에 저장되는 실질적 파일을 의미하고, StoreFile은 하나의 HFile을 객체화하는 랩퍼 클래스다.

스토어(Store)

하나의 memstore와 다수의 StoreFile로 구성된다. memstore는 스토어의 모든 변경 사항을 메모리에 상주시켜, 읽기/쓰기 과정에 사용되도록 한다.

리전(Region)

Region은 하나 이상의 Store로 구성되며, Region이 오픈될 때마다 컬럼 패밀리별 하나씩의 Store 인스턴스를 생성한다. 리전별 담당하는 키영역이 있으며 startKey와 endKey 정보를 가지고 있다.

HLog

HLog는 리전서버당 하나씩 존재한다. 아키텍처 그림에는 리전당 하나씩 생성되는 것처럼 보이지만, 실제로는 리전서버당 하나씩 생성되고 리전은 해당 HLog를 참조 공유하고 있을 뿐이다. HLog는 HBase의 WAL(write-ahead-log)의 구현체이며, 스토어에 가해지는 모든 변경사항을 기록하면서 로그롤링11)을 수행한다.

[그림 Ⅱ-2-7] HBase WAL

WAL은 MySQL의 바이너리 로그와 비슷한 개념으로 데이터를 수정/추가하기 전에 WAL에 기록한다. WAL 기록에 실패하면 해당 클라이언트 요청도 실패로 처리된다. 리전서버가 네트워크, 전원, 시스템 부하 등의 이유로 다운되면 memstore에 보관하던 데이터 변경 이력은 없어지는데 데이터 손실을 피하기위해 리전서버 복구 시 WAL에 있던 기록을 재수행해 손실된 데이터를 복구한다. HBase의 WAL 기능을 비활성화 시켜 데이터 처리 성능을 높일 수 있지만 권장하지 않는다.

리전서버(RegionServer)

다수의 리전을 호스팅해 사용자의 데이터 읽기/쓰기 요청을 처리한다.

마스터 (HMaster)

리전의 배치와 밸런싱을 담당하며 다운된 리전서버 감지와 메이저-컴팩션12) 같은 클러스터 관리 작업을 수행한다. Jetty 경량 웹 서버를 이용해 HBase 웹 관리 화면도 제공한다. 직접적인 데이터 처리에는 관여하지 않아 마스터가 죽어도 클러스터는 정상 작동한다. 다만 클라이언트가 데이터 요청을 하지 못할 뿐이다. 필요할 경우 active-standby 마스터 이중화도 제공한다.

HBase 데이터 모델

HBase의 데이터 모델은 빅테이블과 매우 유사하다. 컬럼이 모여 로우가 되고, 로우가 모여 테이블이 된다. 컬럼은 컬럼패밀리로 묶인다. 컬럼패밀리 내의 데이터는 같은 HFile에 쓰여져 데이터 압축, 메모리 보관, 컴팩션 등의 주체가 된다.

HBase는 스파스(sparse) & 다차원 스키마로 RDB 형식보다 위의 테이블처럼 한 단계 더 깊게 생각해야 한다. 추가로 컬럼은 버저닝되어 새로운 값이 쓰이더라도 이전 데이터는 timestamp로 조회 가능하다.

[그림 Ⅱ-2-8] HBase 버저닝

컬럼패밀리는 테이블당 30~50개를 넘지 않는 게 좋다. 데이터를 너무 세밀화 해 컬럼패밀리를 기준으로 테이블을 확장하면 데이터 압축률이 낮아지며, 컴팩션 동시 발생 빈도수가 높아지고, 동시 오픈되는 파일 수도 많아져 시스템 문제가 될 수 있다.