HBase를 운영하다보면 직면하는 문제 중 하나가 바로 Region이 Too Much하게 Split되는 현상이다. 이를 관리하기 위해서는 Split되는 기준 즉, SplitPolicy를 이해해야 한다. 가장 기본이 되는 Policy는 ConstantSizeRegionSplitPolicy이다. 하지만 0.94 버전 이후에는 IncreasingToUpperBoundRegionSplitPolicy가 기본 Policy로 설정된다. 물론 아래와 같이 전역 설정으로 변경하면 기본 Policy를 변경할 수 있고, 테이블 별 설정도 가능하다. hbase.regionserver.region.split.policy org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundR..

HBase 성능 튜닝 (시스템) Garbage Collection 마스터 서버는 무관하며, 리전 서버 중 MemStore에서 디스크로 Flush된 후 메모리 상 빈 공간이 듬성듬성 생김 128MB로 시작하여 모니터링에 따라 부하가 심한 리전 서버는 상향 조정 압축 사용하지 말아야 할 특별한 이유가 없다면 무조건 사용을 권장 GZIP for Cold data / Snappy or LZO for Hot data 압축/해제에 따른 CPU 부하가 디스크에서 많은 데이터를 읽어야하는 오버헤드보다 적음 리전 분할 관리 일정하게 리전 크기가 증가하면 동시다발적 분할로 디스크 입출력 부하가 급증할 수 있음 적은 개수에서 임계 파일 크기에 따라 적당한 키 값 범위로 단계적 분할을 수행하는 것이 좋으며, 이는 자동으로 수..

HBase CRUD Data Write (Put) 동일 Row에서 원자성 보장 (실패 시 연산은 버림) 데이터는 먼저 WAL(HDFS)에 저장된 후 MemStore에 저장 Data Read (Get) BlockCache, MemStore에서 먼저 검색 후 HDFS의 StoreFile을 탐색함 Data Delete “Tombstones Marker”를 표시하여, 탐색 시 반환되지 않도록 함 (HDFS 때문) Marker가 표시된 삭제 대상은 Major Compaction 과정 중 영구 삭제 일괄처리 시에는 순서가 보장되지 않아 Delete와 Put 연산을 섞지 않는 것이 좋음 Schema Update 만약 테이블이나 CF가 업데이트 되는 경우 (Region 크기, Block 크기 등) Major Compa..

HBase의 특징 구글 BigTable을 모델로 하여 개발된 컬럼 기반 분산 데이터베이스 HBase 데이터 모델 Table: Row들의 집합 Row Key: 사전순으로 내림차순 정렬되기 때문에 Row key의 설계는 상당히 중요함 Column Family (CF): 컬럼들의 그룹으로 모든 컬럼패밀리의 Member는 같은 접두사를 사용 Cell: Row Key & Column & Version이 명시된 튜플 Timestamp: 데이터가 쓰기될 때 같이 작성되는 것으로 각 값의 버전을 나타냄 HBase 구조 HMaster: RS 모니터링, 배정, Failover, 메타데이터 관리, etc. Zookeeper: RS 상태 추적 RegionServer (RS): Region 별 데이터 제공 및 관리 도서관 HB..

Scheduler 계층형 큐 부모 큐: 조직과 하위 조직의 자원을 관리 리프 큐: 부모 아래에서 동작하는 큐로 더 이상 자식 큐가 없는 마지막 큐 부모 큐는 직접 애플리케이션을 제출할 수 없으며, 오직 리프 큐만 애플리케이션을 제출함 ROOT는 어떤 조직에도 속하지 않으며, 클러스터 자체를 의미함 Capacity Scheduler 스케줄러 특징 특별한 설정을 하지 않을 경우 기본으로 Capacity Scheduler를 사용함 각 리프 큐의 내부 스케줄링은 FIFO 방식으로 자원을 할당함 다른 조직에서 애플리케이션을 제출한 후 제어권을 돌려주는 식으로 자원 공유 가능 잘 사용하지 않는(가장 작은 비율의) 큐에 더 높은 우선순위를 줌 탄력성을 보장하기 위해 설정은 되어 있지만 수요가 부족해 사용률이 저조한 ..

Apache Hadoop 3.0.0 Minimum required Java version increased from Java 7 to Java 8 Support for Erasure Coding(EC) in HDFS 오버헤드 비교 기존 방식에서 3개 Replication의 경우 200% 오버헤드를 초래함 1개의 Data Block을 분할시킨 여러 조각(Stripe)의 Data Block과 2개 이상의 Parity Block으로 구성 시 50% 오버헤드만 존재 Directory-level EC policies 표현: codec-num data blocks (Ndb)-num parity blocks (Npb)-cell size 최소 요구 구성 노드: Ndb + Npb 현재 6개의 Policy (RS: Ree..