[HBase] 3. HBase Architecture / 읽기, 쓰기 경로

HBae의 Architecture를 살펴보기 이전에 다시 한번 복습해보자. 

 

HBase의 필요성

Hadoop은 빠른 쓰기 및 읽기를 처리할 수 없으며, 파일을 완전히 다시 작성하지 않고서는 파일을 변경할 수도 없다. 

HBase는 최적화된 방식으로 빠른 임의 쓰기 및 읽기를 허용하므로 HDFS의 단점을 극복하기 위해 Hadoop위에 구축된 NoSQL, 열지향 데이터베이스 이다. 

 

기본이해

대량의 정형 또는 비정형 데이터에 대한 임의 엑세스를 제공하도록 설계된 Google의 빅테이블과 유사한 데이터 모델이다. 

HBase는 HDFS의 내결함성 기능을 활용하는 Hadoop 에코시스템의 중요한 구성 요소이다. 

HBase는 기존 RDBMS의 몇 가지 중요한 기능을 놓치기 때문에 데이터베이스 대신 데이터 저장소라고 할 수 있다. 

 

HBase의 데이터 모델

HBase 데이터 모델은 데이터 유형, 열 크기 및 필드 크기다 다른 반구조화된 데이터를 저장한다. 

컬럼지향 데이터베이스이다. 

행 지향 접근 방식은 상대적으로 적은 수의 행과 컬럼을 효율적으로 분석해야할 때 컬럼 중심 접근 방식을 사용한다. 데이터 마이닝, 데이터 웨어하우징, 분석을 포함한 애플리케이션 등과 같은 온라인 분석 처리를 다루는 애플리케이션 등. 

 

HBase의 컬럼 패밀리는 정적이지만 컬럼 자체는 동적이다. ?

Column Families :  다양한 Column이 Column Familiy로 결합되어 있다. 이러한 컬럼 패밀리는 함께 저장되므로 동일한 컬럼 패밀리에 속한 데이터를 단일 검색으로 함께 액세스할 수 있으므로 검색 프로세스가 더 빨라진다. 

 

HBase Table

 

HBase를 사용해야 하는 경우

고정된 스키마가 필요하지 않으므로 개발자는 사전 정의된 모델을 준수하지 않고도 필요할 때 새 데이터를 추가할 수 있다.

 

사용자에게 Hadoop 규모 저장소에 대한 엑세스와 같은 데이터베이스를 제공하므로 개발자는 전체 데이터 세트를 스캔할 필요 없이 데이터 하위 집합에 대해 효율적으로 읽기 또는 쓰기를 수행할 수 있다.

 

 

 

HBase의 특징

• 장점
  • 성능 이슈가 발생할 경우 RegionServer만 추가하면 성능 유지가 가능하다. 
  • Fail Over가 쉽고 관리가 용이하다. 
  • Hadoop MapReduce의 Input으로 사용하기가 편리하다. 
  • Region 분할에 따른 스케일링 자동화가 가능하다
  • WAL 기반의 복구 기능이 제공된다.
• 단점
  • 적절한 HBase설정을 하기 위한 팁들이 있으나 클러스터의 규모나 기본 Spec차이로 인해 성능 튜닝을 바로 적용하기가 어렵다. 
  • 특정 RegionServer에 특정 Table의 Region이 집중되기 쉬우며, 이는 성능 저하로 이어진다. 
  • Crash Recovery, WAL replay, Major Compaction 등이 상당이 느리다. 

 

HBase Architecture

주요 구성요소 
1. HMaster
2. Region Server
3. Zookeeper

 

HMaster

로드 밸런싱을 위해 Hadoop 클러스터 리전 서버에 리전을 할당하는 경량 프로세스 이다. 

Hadoop의 NameNode와 유사하게 작동한다. (HDFS에서)

• Hadoop 클러스터 관리 및 모니터링
• 관리(테이블 생성, 업데이트 및 삭제를 위한 인터페이스)를 수행
• 장애 조치 제어 (클러스터에 있는 모든 리전 서버의 인스턴스를 모니터링하고 리전 서버가 다운될 때마다 복구 활동을 수행한다.)
• DDL 작업 (테이블 생성 및 삭제) 수행. 리전 서버에 리전을 할당한다. 
• 클라이언트가 스키마를 변경하고 메타데이터 작업을 변경하려고 할 때마다 HMaster는 이러한 모든 작업을 담당한다. 

HMaster가 DataNode에 상주하는 Region Server 컬렉션을 처리한다. 

 

하지만, HBase는 HMaster만으로는 모든 것을 관리하기에 충분하지 않다. Zookeeper를 통해 거대한 HBase 환경을 관리할 수 있다. 

Region Server

 

Region 

많은 리전이 리전 서버에 할당되어 해당 리전 집합에서 읽기 및 쓰기 작업을 처리, 관리, 실행한다.

 

• 테이블은 여러 리전으로 나눌 수 있다. 리전은 start Key와 end Key 사이에 데이터를 저장하는 정렬된 컬럼 범위이다. 
• 리전의 기본 크기는 256MB로 필요에 따라 구성할 수 있다. 
• 리전 그룹은 리전 서버에 의해 클라이언트에게 제공된다. 
• 리전 서버는 약 1000개의 리전을 클라이언트에게 제공할 수 있다. 

클라이언트의 읽기, 쓰기, 업데이트 및 삭제 요청을 처리하는 작업자 노드. 리전 서버 프로세스는 hadoop 클러스터의 모든 노드에서 실행된다. 리전 서버는 HDFS DataNode에서 실행되며 다음 구성 요소로 구성.

• 블록캐시 : 읽기 캐시. 가장 많이 읽은 데이터는 읽기 캐시에 저장되며 블록 캐시가 가득 찰 때마다 최근에 사용한 데이터가 제거된다. 
• MemStore : 쓰기 캐시. 아직 디스크에 기록되지 않은 새 데이터를 저장. 지역의 모든 컬럼 패밀리에는 MemStore가 있다. 
• WAL(Write Ahead Log)은 영구 저장소에 유지되지 않는 새 데이터를 저장하는 파일
• HFile은 디스크에 정렬된 키 값으로 행을 저장하는 실제 스토리지 파일이다. 

     Region Server또한 여러가지 주요 Component들을 가진다. 

      https://dkfl8151.tistory.com/57?category=957744

 

 

Zookeeper

HBase는 주키퍼를 사용하고 작동하는 다른 리전서버에 로드하여 리전 서버 충돌을 복구한다. 

주키퍼는 구성 정보를 유지 관리하고 분산 동기화를 제공하는 중앙 모니터링 서버이다. 

 

• Zookeeper는 HBase 분산 환경 내에서 코디네이터 역할을 한다. 세션을 통해 통신하여 클러스터 내부의 서버 상태를 유지하는 데 도움이 된다. 
• HMaster서버와 Region Server는 일정한 간격으로 지속적인 Heartbeat를 Zookeeper에 전송한다. 또한, 어떠한 서버가 활성 상태이고 사용 가능한지 확인한다. 서버 장애 알림을 제공하여 복구 조치를 실행 할 수 있다. 
• 활성 HMaster는 Zookeeper에 하트비트를 보내고 -> 비활성 HMaster는 활성 HMaster가 보내는 알림을 수신한다. 활성 HMaster가 하트비트 전송에 실패하면 세션이 삭제되고 비활성 HMaster가 활성이 된다.
• 리전 서버가 하트비트를 보내지 못하면 세션이 만료되고 모든 수신기에 이에 대한 알림이 전송된다. -> 그 다음 HMaster는 복구 작업을 수행하게 된다. 
• Zookeeper는 .META Server의 경로를 유지 및 관리. 모든 클라이언트가 모든 리전을 검색할 수 있게 한다. 클라이언트는 먼저 리전 서버가 속한 .META 서버를 확인해야하며, 해당 리전 서버의 경로를 가져온다. 

 

Recovery 복구작업 방식

• 어느 한 리전 서버가 중단되면 리전 서버(Crash)의 WAL을 분할하여 다른 리전 서버들 (Active)의 리전서버로 복제 후 WAL 기반 재실행을 수행한다. 
• 복구된 MemStore 데이터는 Flush를 통해 최종적으로 디스크에 저장된다. 
• ResionServer Failover time = Zookeeper session timeout + split time + assignment/replay time

 

즉, Zookeeper는 HMaster와 리전 서버의 상태를 전송 받으면서
HBase가 잘 운영이 되고 있는지 확인하는 역할을 한다.
이때, Active HMaster / Inactive HMaster 가 존재하는데 HMaster는 Master/Slave 구조를 따르게 된다. ! 이 역시 Zookeeper가관리하게 된다. 

 

HBase Write Mechanism

 

 

step1 : 클라이언트에 쓰기 요청이 있을 때마다 클라이언트는 데이터를 WAL에 입력한다. 

 

Step2 : 데이터가 WAL에 기록되면 MemStore에 복사된다.

 

Step3: 데이터가 MemStore에 배치되면 클라이언트는 승인을 받는다. 

 

Step4: MemStore가 임계값에 도달하면 데이터를 Hfile에 덤프하거나 커밋한다. 

 

Hbase에서 데이터를 저장할 때 기본적으로 두 장소에 저장하게 된다.

하나는 WAL(Write Ahead Log), 또 하나는 멤 스토어(Memstore) 이다.

양쪽에 쓰는 이유는 데이터 지속성의 유지 때문이다. 양쪽 모두 두에서 변경이 발생했다는 사실이 확인되면 쓰기 작업은 완료된 것이다.

 

멤스토어는 디스크에 영구히 쓰기를 하기 전에  HBase 의 메모리에 데이터를 모두 축적하고 있는 쓰기 버퍼이다.

멤스토어의 파일이 가득 차게 되면  HFile 형태로 디스크에 플러시(Flush)를 하며 메모리를 비운다. 

플러시를 할때는 기존의 파일에 추가하는게 아니라 새로운 파일을 만든다.

 

HFile 은 HBase 저장을 위한 포멧이다. HFile 은 컬럼 패밀리 내에 속하고 컬럼 패밀리는 여러개의 HFile 을 가질 수 있다.

하지만 단일 HFile 은 여러 개의 컬럼 패밀리를 위한 데이터를 가질 수 없다. 

컬럼 패밀리 하다당 하나의 멤스토어만 가진다. 

( write 속도가 간혹 느린 경우가 있는데 이럴때는 컬럼 패밀리를 어떻게 설계 했느냐에 따라서 성능이 달라진다. 동일한 컬럼 패밀리에 적재하는 것 보다 여러개의 컬럼 패밀리로 의미상 나누는 전략도 필요하다.)

 

쓰기 작업이 일어나다가 장애가 발생할 경우 멤스토어의 데이터는 잃어 버리지만 WAL 의 변경사항이 기록된 것을 기준으로 복구한다. 

WAL을 끄게 되면 쓰기 속도는 올라갈 수 있으나 장애 상황시 데이터를 잃게 된다. 

 

• Put 요청 -> HRegionServer에 전달 -> HRegion 인스턴스에 요청사항 전달 -> WAL에 데이터 저장 (SequenceFile, HLogKey의 인스턴스 저장) -> WAL 기재시 멤스토어에 저장 -> 멤스토어 검사 -> 꽉찬 경우 Disk Flush -> HFile에 기록 -> 마지막으로 비워진 데이터의 일련번호도 저장하여 WAL 저장 위치 확인

Flush

• Client Flush 
  • 데이터 쓰기 시 AutoFlush를 이용하는 경우 매 Put() 요청 마다 Flush가 수행된다.
  • AutoFlush를 해제하는 경우 Put() 요청은 클라이언트 측 버퍼에 임시 저장되어 RPC가 발생하지 않는다.
• MemStore Flush
  • CF 당 한개씩 존재하며. 임계치가 되면 정렬된 KeyValue 데이터의 All Flush가 수행된다. 
  • MemStore의 Flush 결과로 새로운 HFile이 생성된다.

 

 

HBase Read Mechanism

일반적으로 데이터에 빠르게 접근하고 있다면 메모리에 많이 '유지'하고 '정렬'해서 저장하면 된다. 

Hbase의 읽기는 영속적인 HFile 과 멤스토어에 있는 데이터 사이에 균형을 이루어야 한다.

HBase는 읽기를 위해 LRU(Least Recently Used- 최근에 사용한 것은 메모리에 저장, 가장 활용되지 않은 것은 디스크에 내림) 캐시를 가짐. 이를 블록 캐시(Block Cache)라고 부른다.

이 캐시는 JVM 힙 메모리 내 멤스토어와 같은 영역에 있으며,  블록 캐시는 자주 접속되는 메모리에 있는 HFile 에서 데이터를 유지할 수 있도록 설계되어 있다.

 

각 컬럼 패밀리는 자신만의 블록캐시를 가진다.

(때문에 모든 컬럼을 한 컬럼 패밀리 안에 유지하는 것이 안 좋을 수 있음)

 

블록 캐시의 블록은 Hbase가 읽을 수 있는 데이터의 조각임. HFile은 물리적으로 블록들의 Sequence 로 배치된다.  

블록상의 인덱스도 같이 배치된다.

블록은 가장 작은 데이터의 인덱스된 단위이고 디스크에서 읽을 수 있는 가장 작은 단위이다.

 

블록의 크기는 64KB이지만 컬럼 패밀리별로 변경이 가능하다.  

더 작은 블록은 더 큰 인덱스를 만들 수 있고 그렇게 해서 더 많은 메모리를 소비한다. 

(블록이 작아질 수록 내부에서 관리해야 하는 인덱스량이 늘게 된다. 메모리를 소비하는 만큼 Search 속도는 향상된다.)

 

Hbase에서 로우를 읽을 때 멤스토에에서 먼저 체크 -> 블록캐시는 로우를 가지고 있는 블록이 최근에 접근되었는지 조사 ->  디스크상에 있는 적절한 HFile에 접근하게 된다.

 

완전한 로우를 읽기 위해서 HBase 는 HFile에게서 데이터를 읽어야 함. 

 

HFile Compaction 

Minor Compaction 

 

최근에 생성된 작은 파일들을 큰 파일로 재작성하는 임수를 수행. 

너무 큰 값으로 설정할 경우 minor가 지연되어 나중에 한번에 처리하게 되면 부하가 생긴다. 

오래된 파일이 먼저 minor compaction의 대상이된다. 

 

Major Compaction 

 

모든 파일을 하나의 파일로 구성함. => Column Famailiy 당 1개의 HFile로 전체를 재구성하는 과정

Major Compaction은 DIsk I/O와 네트워크 트래픽을 많이 소모한다. 

Tombstones Marker가 존재하는 데이터를 최종적으로 삭제함 (기본값 7일에 1번 수행)

 

어떤 컴팩션이 수행될지는 컴팩션 상태로 자동 결정된다.

hbase.hregion.majorcompaction.jitter 속성(기본 0.2로 20%) 은 저장 파일별로 주 컴팩션이 수행되는 시점을 흩어지게 만든다.  만약 없으면 주 컴팩션이 매 24시간 마다 동시에 수행된다. 

 

 

추가적으로 봐야할 것 
1. Row Key 설계
2. 블룸 필터
3. Data 버저닝