.

Data_Engineering_studynote(20200420)

1. 학습 시 참고한 URL

1) https://mapr.com/blog/in-depth-look-hbase-architecture/ An In-Depth Look at the HBase Architecture

2) https://m.blog.naver.com/talag/221019176724 / ‘네가 불던 날 ‘블로그 [HBase] 이해

3) https://www.joinc.co.kr/w/man/12/hadoop/hbase/about / HBase 소개

4) https://dydwnsekd.tistory.com/4?category=775994 / ‘IT 삽질기’ 블로그 HBase란 - HBase의 특징과 장단점

2. HBase 개요

1) Hadoop 플랫폼을 위한 구글의 BigTable를 구현 아이디어로 채택하여 자바를 기반으로 만들어진 데이터 비관계형 분산 데이터 베이스

2) NoSQL라고 할 수 있으며 스키마 지정 및 변경 없이 데이터를 저장할 수 있음

3) HDFS에서 동작하기 때문에 가용성 및 확장성 특징을 그대로 살릴 수 있음

3. HBase 장점

1) 선형 확장성

2) 읽기와 쓰기의 일관성

3) Hadoop 시스템과 연계하여 source와 destination으로 사용 가능

4) 클러스터를 통한 데이터 복제로 fail over 가능

5) 안정적인 데이터 처리 및 일관성

중앙의 전체 분산 시스템을 통제하는 마스터를 두고 전체 데이터의 일관성을 관리하여 복제 데이터 사이의 일관성을 보장

6) 대용량 데이터 처리 및 분석에 적합

HDFS, mapreduce등과 함께 사용하기 때문에 적합하다고 할 수 있음

7) region 서버를 추가하여 확장 및 성능개선 가능

4. HBase 기본용어

이 테이블은 info 와 nationality 두 개의 컬럼 패밀리로 구성

info 컬럼 패밀리는 Name과 passport num 두 개의 컬럼으로 구성

nationality 컬럼 패밀리는 nation과 country code 두 개의 컬럼으로 구성

Row는 Row Key, info CF, nationality CF로 구성

1) Table

다중 로우로 구성된 집합 RDB에서의 table와 비슷한 개념이지만 테이블을 만들때 Column을 지정해주는 것이 아니라 Column Family만 지정

2) Row

RowKey와 Column으로 구성되며, RowKey를 기준으로 알파벳 오름차순으로 정렬되어 저장되기 때문에 로우키 설계가 매우 중요

HBase 데이터는 리전 서버에 저장이 되는데 이때 같은 리전서버에 있는 것과 다른 리전서버에 있는 데이터를 불러오는 경우 속도차이가 날 수 있어 로우키를 어떻게 설계하는지가 중요함

3) Row Key

Row를 구분하기 위한 구분자로 RDB에서의 primary key와 비슷한 개념이라고 할 수 있음

4) Column Famaily

물리적으로 모든 Column Family단위로 파일 시스템에 저장이 되는데 이 때문에 사실상 Table에 Column Family가 많아지면 서로 다른 Table에 저장하는 것과 같은 성능이 나타날 수 있음

5) Column Qualifier

HBase에서의 Column Qualifier은 Table 생성시 지정하지 않으며 Table 생성시 지정한 [Column Family]:[Column Qualifier]형식과 같이 :으로 구분하여 사용됨

Column Family와의 구분자가 : 이기 때문에 Column Qualifier에는 :이 들어가면 안됨

6) Column

Column Famaily와 Column Qualifler이 합쳐진 것으로 :으로 구분

7) Cell

Row Key, Column, Version이 명시된 튜플

8) Timestamp

주어진 값의 버전 식별자로 값과 나란히 기록되며 데이터가 기록될 때의 RegionSever의 시간을 가짐

Version옵션을 이용하여 각기 다른 Timestamp의 값을 한 row에 저장하는 것이 가능

5. HBase 특징

컬럼 패밀리는 단순히 컬럼의 그룹이라고 할 수 있는데 왜 HBase는 컬럼 패밀리라는 개념이 있는 것인지는 HBase의 데이터베이스 특징을 알아야 함. 특징은 아래와 같음

1) distirbuted

테이블은 수백만개의 Row와 컬럼들로 구성되며, 이들 컬럼들은 쉽게 분산 할 수 있음

2) Sparse (밀도가 희박한)

sparse matrix 방식으로 데이터를 저장가능

-> 굳이 모든 필드에 값을 채울 필요가 없음

3) Column-Oriented

RDBMS는 row 단위로 데이터를 저장하는 반면에 HBase는 Sparse하기 때문에, 컬럼 단위로 데이터를 읽고 쓸 수 있음

4) versioned

위 테이블은 Customer ID를 Row key로 사용하고 있음

고객은 하나 이상의 물건을 구매할 수 있기 때문에 하나의 row key에 여러 개의 row를 저장 가능

이 경우 Timestamp가 버전이 되며, 질의를 할 경우 가장 최근 timestamp의 row를 읽어오는 형태

5) Non-relational

관계형 데이터베이스의 ACID 속성을 따르지 않음

6. HBase 확장성

• 데이터의 Row가 너무 많이 쌓이면 나눠서 로드를 분산하는 것이 기본

• Region은 HBase에서 수평확장(Scale-in/out)의 기본단위로 함께 저장되는 테이블의 부분집합

• 처음에는 테이블은 오직 한개의 Region에만 있는데 만약 Region에 많은 row 들이 추가되서 그 크기가 너무 커지면, 중간키를 이용해서 Region을 반으로 나눠서 저장할 수 있음

7. Region

• HBase Tables are divided horizontally by row key range into “Regions”

• A region contains all rows in the table between the region’s start key and end key.

• Regions are assigned to the nodes in the cluster, called “Region Servers”, and these serve data for reads and writes. A region server can serve about 1,000 regions.

• Region = Contiguous Keys

table은 하나또는 여러개의 Region으로 divided됨

Region은 start key와 end key사이에 연속적으로 정렬된 범위의 row를 갖음

디폴트로 각각의 Region은 1G 사이즈임

각 Region은 RegionServer에 의해 client에게 서비스를 제공함

Region server은 1000개 정도의 Region을 관리함

8. Master 개념

• 각 테이블은 RegionServer가 관리하고, 전체 HBase 클러스터는 Master가 관리

• Master 역할

1) Region 서버 조정

1-1) Region의 시작을 관리

1-2) 로드밸런싱을 위해 Region을 재할당하거나 복구하는 등의 역할 수행

1-3) 클러스터에 있는 모든 Region Server들을 주키퍼를 이용해서 모니터링

2) 관리기능

Table Create, Delete, Update

3) 참고사항 : “그러면 메타는 어떻게 관리하는지?”

테이블이 region으로 나눠지면, key를 관리하기 위한 장치가 필요한데 Key와 Region의 맵핑정보는 META라는 이름의 시스템테이블에 저장됨

따라서 클라이언트는 Master와 통신하지 않고 Region server와 통신하는 것으로 읽기/쓰기 작업을 할 수 있음

9. 클러스터 코디네이터 : 주키퍼

• HBase는 주키퍼를 이용해서 클러스터를 구성하는 서버들의 상태를 관리

• 주키퍼는 서비스들이 살아 있는지 그리고 사용 가능한지를 모니터링하며, 실패할 경우 이를 이를 공유함

• 클러스터간의 정보공유를 위한 저장소의 역할도 수행

• 주키퍼 자체 가용성을 위해서 3대 혹은 5대로 구성됨

• 활성화된 Region Server와 Master는 주키퍼에 연결이 되고, 주키퍼는 하트비트를 통해서 이들 노드의 상태를 관리함

• 각 Region Server는 ‘ephemeral 노드’로 등록이 되기 때문에 Region Server에 문제가 생기면, 이 노드는 클러스터에서 즉시 제외됨

• Master역시 ephemeral node로 등록이 되고, Master가 실패는 전체 클러스터의 실패로 이어질 수 있으므로, 두 대 이상의 노드가 Master/Slave 방식으로 구성됨

• 하나의 Master 노드만 활성화 되는데, 이 역시 주키퍼가 관리함

9. 메타테이블

• HBase는 메타테이블이라고 부르는 ‘HBase Catalog table’을 유지함

• 여기에는 클러스터에 포함된 Region의 위치정보를 저장하고 있으며 이 테이블은 주키퍼가 관리함

• 메타테이블 동작과정

step 1) 클라이언트는 주키퍼의 메타테이블을 서비스하는 Region server의 호스트 정보를 읽어옴

step 2) 클라이언트는 Region server에 메타테이블을 질의해서 접근하려는 row 키를 가지고 있는 리전 서버 정보를 가져옴

step 3) 클라이언트는 메타테이블의 정보를 캐싱

step 4) 해당 Region server로 부터 row를 Read

• 메타테이블 구조

1) 클러스터에 있는 모든 리전정보를 저장

2) b tree 구조

3) key(리전의 id와 테이블,start key)와 value(Region server)로 구성

10. Components of Region server

1) WAL

• Write Ahead Log파일로 분산 파일 시스템에 기록

• 데이터는 하드디스크에 저장되기전에 WAL에 먼저 저장이 되는 구조

• 데이터 저장 실패를 복구하기 위해서 사용됨

2) BlockCache

• 일종에 읽기 캐시로 자주 접근하는 데이터는 메모리에 저장해서 읽기 성능을 높이는데 목적이 있음

3) MemStore

• Key/Value 데이터를 정렬해서 저장하고, 이 데이터를 그대로 HFile에 저장

• 일종에 쓰기 캐시로 아직 디스크에 기록되지 않은 데이터들이 저장됨

• 데이터는 디스크에 쓰기전에 정렬되고 각 리전의 컬럼 패밀리당 하나의 MemStore가 있음

4) Hfile

• 데이터는 Key, Values 형태로 Hfiles에 저장

• MemSotre는 데이터가 충분히차면 새로운 HDFS에 새로운 HFile을 만들어서 저장함

• 랜덤엑세스를 최소화하는 구조로 이 과정은 매우 빠르게 이루어진다.

• Hfile 구조

HBase는 데이터를 효율적으로 찾기 위해서 multi-layerd index(B tree와 유사)를 사용

Key/Value는 increasing order로 저장

색인은 64KB 크기의 블록을 가리킴

각 블럭은 자체적으로 leaf-index를 가지고 있음

각 블럭의 마지막 키는 중간색인이 됨

루트 인덱스는 중간색인을 가리킴

• 색인작업

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

11. HBase Write Steps

STEP 1) 클라이언트에서 데이터와 함께 Put 요청을 전송하면, 이 데이터는 WAL에 기록됨

STEP 2) WAL은 로그파일 시스템으로 입력된 데이터는 맨 마지막에 추가됨

** 서버에 어떤 문제가 생길 경우 데이터를 복구하기 위해서 사용된다.

STEP 3) WAL에 쌓인 데이터는 MemStore로 복사되고, 동시에 클라이언트에 acknowledgement가 리턴됨

12. HBase Region Flush

• MemStore에 충분히 많은 데이터가 쌓이면, 정렬된 전체 집합을 HDFS에 새로운 HFile을 생성해 저장함

• MemStore가 컬럼패밀리단위로 연산을 하기 때문에 HFile도 각 컬럼패밀리당 HFile을 생성함

• 컬럼패밀리가 늘어나면 HFile이 늘어나는 구조 때문에, HBase는 컬럼패밀리에 제한을 둠.

• 하나의 컬럼패밀리당 하나의 MemStore가 있고, MemStore이 꽉차면 모든 내용을 flush(Hfile을 생성해서 저장하는 작업) 함

• 또한 마지막으로 기록된 시퀀스 번호를 저장해서 지금까지 저장한 내용을 추적할 수 있게 해놓음

• 가장 높은 sequence number는 각 HFile에 메타필드로 저장되기 때문에 어느 시점에서 저장이 끝났는지를 알 수 있음

13. HBase Compaction

1) Minor Compaction

• 데이터가 writing 되다 보면 여러 개의 작은 HFile들이 만들어지는데 파일들이 많아지면 성능이 떨어질 수 있다. 따라서 HBase는 자동으로 여러개의 HFile을 좀 더 큰 몇 개의 HFiles로 다시만드는 방식으로 HFile의 개수를 관리한다

• Minor compaction은 여러 개의 HFile들을 하나의 큰 HFile로 통합한다. HFile에 저장된 데이터는 정렬되 있으므로 merge sort를 이용해서 빠르게 합병 가능하다.

2) Major compaction

• Major compaction은 리전에 있는 모든 HFiles들을 모아서 컬럼당 하나의 HFile로 만드는 작업이다. 이 과정에서 필요없는 셀, 시간이 초과된 셀등을 제거해서 전반적인 읽기 성능을 증대시킨다.

• 대량의 파일들에 대한 읽기/쓰기 작업이 일어나기 때문에 디스크 I/O와 트래픽 증가가 발생한다.

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

14. Region Split

• 기본적으로 하나의 table은 하나의 Region에 저장하는데 Region이 너무커지면, Hbase는 이 Region을 두 개의 Region으로 split한다.

• Region을 split 할 경우 이 정보를 Master에 알려주고, Master는 로드를 조정하기 위해서 새 Region을 다른 server로 이동하기 위한 작업을 수행한다.

• Hfile의 물리적인 이동은 HBase compaction에서 일어난다.

15. Read Load Balancing

• Region split을 한다고해서 다른 server로 table이 이동하는 것은 아니다. Region server만 다른 노드에 두어 Region server의 로드를 분산하는 방식이다.

Splitting happens initially on the same region server, but for load balancing reasons, the Master may schedule for new regions to be moved off to other servers. This results in the new Region server serving data from a remote HDFS node until a major compaction moves the data files to the Regions server’s local node. HBase data is local when it is written, but when a region is moved (for load balancing or recovery), it is not local until major compaction.

16. HBase Crash Recovery

• Region server가 fail나면, fail을 감지하고 복구하기 전까지는 해당 Region을 사용 할 수 없어야 한다. 주키퍼는 Region server에 주기적으로 Heartbeat 메시지에 대한 응답을 체크한다.

• 만약 Region server가 Heartbeat 요청에 대한 응답을 하지 않은 경우 노드가 실패했다고 판단한다. 동시에 Master는 Region server가 fail났다는 통지를 받게된다.

• 복구 STEP 1) Region 재할당

Region server fail를 감지한 Master는 다른 Region server에 할당 한다. 이제 Memstore에서 디스크로 flush되지 않은 데이터는 복제된 WAL 데이터를 이용해서 복구한다.

• 복구 STEP 2) WAL 분리 및 복원

Master는 복제된 WAL 데이터를 별도의 파일로 분할하고, 이 파일을 새로 할당한 Region server의 데이터노드에 저장한다. 이제 각 Region server는 데이터노드에 저장된 WAL 파일로 부터 WAL을 재생해서 Memstore를 재구성 한다.