HBase의 특징

개인적으로 어떤것이든 도입 필요성에 대해서 경영진을 설득할 때 그것에 대한 특징이 잘 설명된다고 생각한다. 그렇다면 다음에 진행할 프로젝트에서 HBase를 사용해야 한다고 경영진을 설득하는 방법에 대해서 알아보도록 하자.



다음 프로젝트에서 HBase를 사용하고 싶다면 다음과 같이 경영진을 설득할 수 있다.

Hadoop과 강한 연관성을 가지고 있다!

HBase에서 분산 환경을 구축하기 위해서는 HDFS위에서 실행되어야 한다. 어찌보면 제한사항으로 느껴질 수도 있지만 이미 Hadoop을 사용하고 있는 환경에서는 오히려 그것이 큰 장점이 될 수 있다. 설득의 포인트는 "기존의 Hadoop 시스템을 활용해서 NoSQL Database까지 운영할 수 있다"로 하면 된다.

기존 시스템을 활용할 수 있다는 것은 매우 강한 설득력을 가질 수 있다. 구체적인 목적을 가지고 Hadoop 시스템을 필요한 규모만큼만 운영하는 경우라면 "꼭 Hadoop을 활용할 필요가 있느냐?"는 질문을 받을 수 있다. 하지만 다행히 Hadoop 시스템을 구체적인 목적을 가지고 운영하는 경우는 많지 않다.

만약 Hadoop 시스템을 운영하고 있지 않은 경우라도 공략은 어렵지 않다. Hadoop 시스템을 도입하자고 경영진을 설득하는 것은 HBase에 비하면 너무나 쉽기 때문이다.

* 공략 키워드 : Big Data, Hadoop

Big Data 처리가 가능하고 MapReduce도 가능하다!

HBase는 Hadoop의 ecosystem으로 분류된다. 요즘같이 Big Data = Hadoop이라는 관계에 대해서 의문을 갖는 사람들이 많지 않다는 것을 이용하면 된다. 사실 Big Data + 대용량 데이터 처리는 HBase뿐만 아니라 다른 NoSQL Database들도 가능하다. 물론 기존에 많이 사용하던 RDBMS도 Sharding 등을 통해서 충분히 대용량 처리를 할 수 있다.



HBase는 대용량 데이터의 읽기, 쓰기 뿐만 아니라 MapReduce를 통한 처리도 가능하다. 이것을 교묘히 이용하면 성공할 수 있는 확률이 높아지게 된다. 공략의 방식은 다음과 같다.

  1. Big Data = Hadoop라는 관계를 강조한다.
  2. Hadoop의 MapReduce를 통해서 Big Data 처리를 한다는 것을 슬쩍이라도 얘기해야 한다. 이때 Hadoop이란 것을 강조해야 한다.
  3. HBase는 Hadoop의 ecosystem이라고 한다.
  4. 간단한 몇가지 정보를 흘려둔 후 경영진이 Big Data = Hadoop = HBase라는 공식을 머리속에 그려낼 수 있도록 시간을 준다.

데이터에 대한 MapReduce를 지원하는 Database가 HBase뿐만은 아니다. HBase와 비교되는 Cassandra도 MapReduce가 가능하다. 하지만 Hadoop의 ecosystem으로 분류되는 HBase에서 Hadoop의 MapReduce를 처리한다고 하면 다른 NoSQL Database보다 더 잘 할 수 있을 것 같은 기분이 든다.

* 공략 키워드 : HBase는 Hadoop의 ecosystem!

CAP이론에서 CP 모델을 가진다.

HBase는 데이터의 Consistency를 보장한다. 다시 말하면 HBase에 쓰기를 한 후 바로 다른 노드에서 읽기를 한 경우 가장 최근에 쓰여진 데이터를 읽는다는 것이 보장된다.



CAP이론을 들먹이면서 자주 비교되는 것이 Cassandra이다. HBase를 경영진에게 설득해야 하는 입장에서 Cassandra는 눈에 가시같은 존재이다. 만약 경영진이 Cassandra에 대해서 언급한다면 좀 치사한 방법이기는 하지만 Cassandra를 깎아내려서 HBase의 존재를 부각시키는 방법이 가장 좋다.

Cassandra는 CAP 이론에서 AP의 모델을 가진다. 극단적으로 말하면 Cassandra는 데이터의 Consistency를 보장하지 못한다. 그렇기 때문에 데이터의 Consistency가 필요한 경우라면 HBase를 사용하는 것이 더 유리하다고 주장한다.

데이터를 다루는 대부분의 경우에는 Consistency는 매우 중요한 속성 중 하나이다. 만약 Cassandra가 Consistency가 약하다는 말을 들으면 경영진도 쉽게 포기하게 될 것이다. 그렇기 때문에 HBase를 사용해야 한다고 경영진을 설득할 때에는 무조건 Consistency를 강조해야 한다. 

만약 경영진이 Cassandra에 대해서 좀 더 자세하게 물어보는 경우 대충 얼버무리면 된다. 만약 Cassandra가 읽기, 쓰기에 대해서 각각 Consistency Level을 설정하는 것이 가능하고 Consistency Level중 ALL은 클러스터 내의 모든 노드에 row를 저장한다는 것까지 경영진이 알게되면 문제가 복잡해지게 되니 조심해야 한다. 만약 경영진이 미리 Cassandra에 대해서 조사한 후 Consistency Level = ALL에 대해서 얘기하면 그럴 경우 하나의 노드가 반응하지 않을 경우 읽기/쓰기가 실패하게 되는 단점이 있다고 얘기해주면 된다.

그리고 Google의 BigTable도 CP 모델을 가진다고 얘기하면 HBase가 더 좋아보일 수도 있다.

* 공략 키워드 : Consistency 보장.

Automatic Failover를 제공한다.

HBase에서 데이터를 관리해주는 역할을 하는 것은 Region Server이다. 이 Region Server가 죽게되면 해당 Region Server의 역할을 다른 Region Server들로 재분배하여 처리할 수 있도록 한다. Failover기능은 다른 NoSQL들도 많이 가지고 있고 요즘에는 서비스를 운영하는데 필수이면서 당연한 기능으로 생각되기 때문에 Failover기능을 가지고 설득을 한다고 해서 큰 효과를 볼 수는 없다.

하지만 얼마나 잘 포장하느냐에 따라서 HBase데이터는 HDFS에 저장되고 Region Server는 데이터 관리만을 해주기 때문에 Region Server의 Automatic Failover 기능과 HDFS의 Replication에 의해서 데이터가 2중으로 보호되는것만 같은 착각을 하도록 할 수 있다. 하지만 사실은 HBase는 HBase의 시스템 뿐만 아니라 HDFS의 시스템 문제에도 영향을 받을 수 있기 때문에 너무 과대포장했다가 오히려 나중에 낭패를 볼 수도 있으니 주의해야 한다.

* 공략 키워드 : Region Server의 Automatic Failover를 제공.

테이블을 자동으로 Sharding할 수 있다.

데이터가 많아지면 테이블 관리도 신경써지게 된다. HBase는 테이블을 자동으로 Sharding하기 때문에 하나의 테이블에 많은 데이터가 들어가도 문제 없이 처리할 수 있다. 설득을 할 때 주요 공략 포인트는 다음과 같다.

  1. 서비스를 운영하면 점점 많은 데이터가 쌓이게 된다. (데이터 관리에 대한 불안감을 조성)
  2. MySQL등은 데이터가 많이 쌓이면 속도도 느려지고 테이블 관리도 어렵다. (단, 엔지니어 출신 경영진한테는 조심해야 한다. 그런 경영진은 RDBMS도 적절한 인덱스 관리와 Sharding을 하면 된다는 것을 알고있을 수 있다.)
  3. HBase는 자동으로 테이블의 데이터 크기를 관리할 수 있다. (꼭 HBase라고 해야 한다. 그래야 다른 NoSQL에 대해서 찾아보지 않는다. 경영진이 다른 NoSQL도 Sharding이 가능한지에 대해서 찾아보면 설득할 때 불리해질 수 있다.)
  4. Sharding이라는 단어는 가급적이면 사용하는 것이 좋다. 만약 경영진이 Sharding의 뜻을 물어보면 "데이터 분산 처리"라고 애매하게 답해줘야 한다.
그럴 일은 없지만 혹시라도 경영진이 어떤 방식으로 자동 Sharding을 하느냐에 대해서 물어본다면 절대 방심해서는 안된다. 자동 Sharding 방식에 대해서 물어보는 경우는 경영진이 어느정도 분산 관련 지식이 있다는 것을 의미한다. HBase는 rowkey 순서에 따른 Sharding을 하기 때문에 효율적인 분산을 위해서는 rowkey 디자인이 매우 중요하다는 사실은 경영진이 모르도록 하는 것이 더 좋을 수도 있다. 나중을 위한 보험 정도로 생각하면 된다.

* 공략 키워드 : 자동 Sharding, rowkey 순서에 따른 Sharding

자바 API를 사용해서 쉽게 개발이 가능하다. Thrift, Avro, Restful API도 제공한다.

자바 API는 다른 NoSQL들도 많이 제공하기 때문에 그쪽에 무게를 둬서 설득하면 안된다. Thrift에 무게를 두는 것이 설득을 더 쉽게 만들 수 있다. 다른 NoSQL들도 Thrift를 제공하지만 다음과 같이 설득해볼 수 있다.

  1. Thrift는 페이스북에서 개발해서 사용하고 있는 통신방식이라고 설명한다. 페이스북이라는 단어를 사용하면 경영진은 알 수 없는 신뢰감을 얻게된다.
  2. Thrift는 현재 Apache 프로젝트에 등록되어있다고 한다.
  3. HBase도 Apache 프로젝트라고 한다.
  4. 둘 다 Apache 프로젝트이기 때문에 둘 간에는 뭔가 더 특별한 것이 있을꺼라고 경영진이 착각할 시간을 준다.
주의할 점은 Cassandra도 Apache 프로젝트라는 얘기는 절대 해서는 안된다. 

* 공략 키워드 : 사용하기 쉬운 자바 API, Thrift, Avro, Restful API 제공


참고자료








Posted by 알 수 없는 사용자
,

HBase에 대해서 간단히 알아보자!


HBase?

HBase에 대해서는 무엇보다도 HBase 홈페이지(http://hbase.apache.org)가 가장 정확하게 설명하고 있을 것 같다.

Apache HBase™ is the Hadoop database, a distributed, scalable, big data store.
(
Apache HBase™는 분산되고 확장 가능하면서 큰 데이터를 저장하기 위한 Hadoop Database이다.)

HBase 홈페이지에는 다음과 같은 좀 더 상세한 설명도 있다.

Apache HBase is an open-source, distributed, versioned, column-oriented store modeled after Google's Bigtable.
(Apache HBase는 구글의 Bigtable 모델을 따르는 오픈소스 분산되고 버전화 되어있는 컬럼 기반의 저장소이다.)

그렇다면 HBase를 이해하기 위해서는 구글의 BigTable에서 시작해야 할 것 같다.

구글의 Bigtable에 대해서 설명한 논문(http://research.google.com/archive/bigtable.html)에서 Data Model에 대한 설명을 보면 다음과 같다.

A Bigtable is a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp.

Bigtable Data Model의 특징은 sparse, distributed, persistent multidimensional sorted map 이라고 할 수 있다. 

그렇다면 각 특징에 대해서 간단히 알아보면 다음과 같다.

sparse

sparse라는 영어 단어는 "밀도가 희박한"이라는 뜻을 가지고 있다. 뜻도 어려울 뿐만 아니라 발음할때도 r 발음에 주의해야 한다! 스파~ㄹ스라고 해야 하지만 영국식 발음은 스파스 해도 무난하다고 한다. (거꾸로 읽어도 스파스가 된다!)
아무튼.. 밀도가 희박하다는 특징이라고 하면 잘 떠오르지 않는다. 만약 "밀도가 희박하다"는 단어만으로 설명하려 하면 다음과 같은 사태가 발생할 수 있다.

개똥이 : 구글의 Bigtable의 특징은 sparse하다는 거야!
소똥이 : sparse가 무슨 뜻인데?
개똥이 : 밀도가 희박하다는 뜻이야!
소똥이 : ♨_♨ ㅅㅂ (  )(  )(  )(  )!!!

마지막 대사의 괄호 안을 채워넣으려 노력하지 말고 sparse하다는 말에 좀 더 집중해보도록 하자. sparse라는 단어와 관련된 것을 생각해보면 "sparse matrix(희소행렬)"라는 단어가 떠오를 것이다!

sparse matrix(희소 행렬)의 모습은 아래와 같다.

 

col #1 

col #2 

col #3 

col #4 

col #5 

col #6 

col #7 

... 

col #n 

 row #1

 

 

 

 

 

 

 

 

 13

 row #2

 

 

 8

 

 

 

 

 

 

 row #3

 

 

 

 

 

 

 

 

 row #4

 5

 

 

 

 

 

 

 

 

 row #5

 

 

 

 

 

 

 

 

 

 row #6

 1

 

 

 

 

 

 

 

 row #7

 

 

 

 

 

 

 

 

 

 ...

 

 

 

 

 

 

 

 

 

 row #m

 

 

 

 

 

 

 

 

이와 같이 대부분의 항목이 비어있거나 0의 값을 가지는 행렬을 sparse matrix(희소 행렬)이라 한다. Bigtable의 sparse하다는 특징은 정형화된 테이블에 대부분의 값이 들어가있는 모습이 아닌 sparse matrix의 데이터 구성과 유사하다는 것을 의미한다.


distributed

distributed라는 영어 단어는 "분산된"이라는 뜻을 가지고 있다. 흔히 사용되는 단어이고 말 그대로 데이터가 분산되어 관리된다는 것을 의미한다.


persistent multidimensional sorted map

각 단어의 의미를 알아보면 다음과 같다.

persistent = 지속적인
multidimensional = 다차원의
sorted = 정렬된
map = 지도

persistent라는 단어는 "지속적인"으로 해석되어 메모리 같은 휘발성 저장소가 아닌 하드 디스크와 같은 비휘발성 저장소에 저장된다고도 해석될 수 있다. 하지만 여기서 말하는 persistent라는 속성은 persistent data structure를 나타내는 것이다. persistent data structure는 데이터의 version이 관리되는 데이터 구조를 의미한다.

multidimensional은 말 그대로 다차원을 의미한다. Bigtable의 데이터 모델의 다차원은 row key, column key, timestamp를 의미한다.

sorted 또한 말 그대로 정렬되었다는 것을 의미한다. 

데이터에 대해서 얘기하면서 map을 "지도"라고 해석하는 사람은 없을 것으로 생각한다. 자료구조에서 말하는 map 형태의 데이터를 의미한다.

각 단어에 대한 이해를 했다면 이제 각 단어를 조합하는 응용을 해보면 다음과 같다. 

persistent    multidimensional    sorted    map
~~~~~~    ~~~~~~~~~~     ~~~~   ~~~
  형용사            형용사             형용사   형용사

※ 아래와 같은 순서로 해석한다.

1단계) sorted map = 정렬된 map
2단계) multidimensional sorted map = 다차원의 정렬된 map
3단계) persistent multidimensional sorted map = 데이터의 버전이 관리되는 다차원의 정렬된 map


그렇다면 이제 HBase의 데이터 모델에 대해서 알아보자. 그냥 알아보면 재미없으니 Perl을 사용해서 표현해보면 다음과 같다.

$bigtable = "A Bigtable is a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp.";

$hbase = $bigtable =~ s/bigtable/HBase/gir;

요약하자면.. Bigtable에 대한 설명에서 "Bigtable"이라는 단어를 "HBase"로 변경하면 된다.

이제 HBase에 대해서 정의해보자.

HBase는 분산되고 확장 가능하면서 큰 데이터를 저장하기 위한 Hadoop Database이다.

HBase의 데이터 모델은 희소 행렬과 유사한 데이터 구성을 가지면서 분산되어있고 데이터의 버전이 관리되는 다차원(rowkey, column key, timestamp)의 정렬된 map이다. 


참고자료


Posted by 알 수 없는 사용자
,