1. HBase 쓰기 프로세스
HBase 서버는 업데이트 및 삭제 인터페이스를 제공하지 않습니다. HBase의 데이터 업데이트 및 삭제 작업은 쓰기 작업으로 간주되며 업데이트 작업은 쓰기 작업으로 간주됩니다. 최소 버전의 데이터를 입력하면 삭제 작업을 통해 삭제된 것으로 표시된 KV 데이터가 기록됩니다.
1.1 쓰기 프로세스의 세 단계 개요
1) 클라이언트 처리 단계: client 사용자 요청을 전처리하고, 클러스터 메타데이터를 기반으로 데이터가 기록되는 RegionServer를 찾아 RS로 요청을 보냅니다.
2) 지역 작성 단계: RS는 요청을 받은 후 데이터를 구문 분석하고 먼저 WAL에 데이터를 쓰고 해당 Region에 해당하는 MemStore에 씁니다.
3) MemStore Flush 단계: Region의 MemStore 용량이 특정 임계값에 도달하면 시스템이 비동기적으로 Flush 작업을 수행합니다. 그리고 HFile
을 형성하기 위해 파일에 메모리를 씁니다. 1.2. 사용자 쓰기 요청은 MemStore에 쓰기가 완료된 후 성공적으로 반환됩니다. MemStore Flush는 비동기 실행 프로세스입니다.
1.3. 클라이언트 처리 단계의 자세한 설명:
1) 클라이언트는 일괄 제출을 설정할 수 있습니다(autoflush=false). 데이터를 먼저 작성하십시오. 로컬 버퍼는 특정 임계값에 도달할 때까지 커밋되지 않습니다. 그렇지 않으면 Put 요청이 처리를 위해 서버에 직접 제출됩니다.
2) RS 주소 지정, 제출 전에 HBase는 메타데이터 테이블 hbase:meta의 rowkey를 기반으로 자신이 속한 RS를 찾습니다.
2.1) 작성된 테이블을 기반으로 하는 클라이언트 그리고 rowkey를 메타데이터에서 검색하면 rowkey가 위치한 RS와 Region을 찾을 수 있으면 직접 쓰기 요청을 보냅니다.
2.2) 클라이언트가 rowkey 정보를 찾지 못하면 필요합니다. 먼저 zk에서 hbase를 찾으려면: 메타 테이블이 있는 RS는 해당 RS에 쿼리 요청을 보내 메타데이터를 얻은 다음 메타데이터에서 rowkey가 있는 RS를 검색하고 다음 사용을 위해 메타데이터를 로컬로 캐시합니다.
3) 클라이언트는 RS에 원격 RPC 요청을 보내고 대상 지역의 MemStore에 데이터를 씁니다.
1.4 지역 쓰기 단계에 대한 자세한 설명:
p>
1) 행 잠금을 얻습니다. HBase에서는 행 잠금을 사용하여 동일한 데이터 행에 대한 업데이트가 성공 또는 실패 여부에 관계없이 업데이트의 원자성을 보장하는 상호 배타적인 작업인지 확인합니다.
2) 기록할 모든 keyValues 업데이트 타임스탬프는 현재 시스템 시간입니다
3) 동일한 지역에 동시에 기록되는 하나 이상의 KeyValues에 대한 WALEdit 레코드를 구성하는 것입니다. 이는 지역 수준 트랜잭션의 쓰기 원자성을 보장하기 위한 것입니다.
p>4) HLog에 WALEdit를 작성합니다. HLog는 HDFS에 저장되며 실제로 HLog를 HDFS에 구현하려면 동기화 작업이 필요합니다. HBase는 효율적인 생산자와 소비자를 구현하기 위해 중단자를 사용합니다. 대기열은 WAL의 추가 쓰기 작업을 비동기적으로 구현합니다.
5) WAL에 쓴 후 MemStore에 데이터를 씁니다. /p>
6) 행 잠금 해제
7 ) sync WAL: 실제로 HLog를 HDFS에 동기화합니다. 동기화가 실패하면 롤백 작업을 수행하여 MemStore 데이터를 제거합니다.
8 ) 쓰기 트랜잭션을 종료합니다.
업데이트는 외부에 표시되고 적용됩니다.
1.5. MemStore Flush 단계에 대한 자세한 설명:
1.5.1 플러시 조건 실행
1.5 .1.1. MemStore 수준 제한, Rgion의 MemStore 크기가 임계값(hbase.hrgion.memstore.flush.size)에 도달하는 경우 기본값은 128M입니다.
1.5.1.2 지역 수준 제한. Region 내 모든 MemStore의 크기가 상한에 도달(hbase.hregion.memstore.block.multiplier * hbase.hrgion.memstore.flush.size) memstore 크기의 배수가 이 값에 도달하면 모든 쓰기 요청이 차단됩니다. 플러시의 경우 기본 자체 보호는 2입니다.
1.5.1.3, RegionServer 수준 제한: RS의 MemStore 전체 크기가 낮은 수위 임계값 hbase.regionserver.global.memstore.size를 초과하는 경우. lower.limit * hbase.reagionserver.global.memstore.size RS는 전체 MemStore 크기가 낮은 수위로 떨어질 때까지 Region Flush의 MemStore 크기를 큰 크기에서 작은 크기로 따라 강제 플러시를 시작합니다.
1.5.1.4 RegionServer의 HLog 수가 특정 상한(hbase.regionserver.maxlogs)에 도달하면 시스템은 Flush를 위해 가장 빠른 HLog에 해당하는 Rgion을 선택합니다. > 1.5.1.5. 정기적으로 HBase 플러시를 수행합니다. MemStore가 오랫동안 지속되지 않도록 기본값은 1시간입니다. 동시에 플러시되는 것을 방지하기 위해 일반 플러시 작업에는 임의의 지연이 있습니다.
1.5.1.6 수동 플러시, 사용자는 'tablename' 플러시 또는 'regionname' 플러시를 통해 테이블이나 지역을 플러시할 수 있습니다. ' 플러시 수행
1.5.2 플러시 실행 단계
1.5.2.1 준비 단계
스냅샷을 찍기 위해 현재 영역에서 MemStore를 탐색하고 그런 다음 새 ConcurrentSkipListMap을 만듭니다. 새 데이터 요청을 수락합니다. 이 단계에서는 쓰기 요청을 차단하기 위해 잠금이 필요하며, 이 프로세스의 잠금 유지 시간은 매우 짧습니다.
1.5.2.2. >
스냅샷 데이터의 특정 형식에 따라 HFile을 생성합니다. 지속성은 .tmp 디렉터리에 있는 임시 파일입니다. 이 프로세스에는 상대적으로 시간이 많이 소요되는 디스크 IO 작업이 포함됩니다.
1.5.2.3 커밋 단계
임시 파일을 지정된 CF 디렉터리로 이동합니다. 그런 다음 스냅샷 데이터를 지웁니다.
1.5.3. MemStore Flush가 비즈니스에 미치는 영향
1.5.3.1. 대부분의 MemStore Flush 작업은 비즈니스 읽기 및 쓰기에 큰 영향을 미치지 않습니다.
1.5.3.2. 지역 서버 수준에서 느린 플러시는 RS의 사용자 요청 및 블록 쓰기 작업에 더 큰 영향을 미칩니다.
1.6. HLog 쓰기 모델
1.6.1. HLog 지속성 수준
SKIP_WAL: 캐시만 쓰고 HLog를 쓰지 않음
ASYNC_WAL: HLog의 비동기 쓰기
SYNC_WAL: 로그 파일의 동기 쓰기, 데이터는 파일 시스템 캐시에만 기록되며 실제로 디스크에는 기록되지 않습니다. 기본값은 이 수준입니다.
FSYNC_WAL: 데이터를 로그 파일에 동기적으로 기록하고 이를 디스크에 강제로 기록합니다. 이는 데이터가 손실되지 않고 성능이 상대적으로 좋지 않음을 보장하는 가장 엄격한 쓰기 수준입니다.
p>
USER_DEFAULT: 사용자가 지속성 수준을 지정하지 않으면 기본적으로 HBase는 SYN_WAL 수준을 사용하여 데이터를 유지합니다. put.setDurability(Durability.SYNC_WAL);
1.6.2, HLog 쓰기 모델
1, HLog 쓰기는 수동으로 로컬 캐시에 데이터 쓰기, 로컬 캐시를 파일 시스템에 쓰기, 마지막으로 syn 작업을 수행하여 디스크에 동기화하는 세 단계를 거쳐야 합니다.
p>
2. HBase는 LMAX Disruptor 프레임워크를 사용하여 Lock-free 경계 대기열 작업을 구현하며, 쓰기 모델은 아래와 같습니다.
2. BulkLoad 프로세스
2.1. 사용 시나리오: 사용자 데이터는 HDFS에 있으며 비즈니스에서는 이 대용량 데이터를 정기적으로 전송해야 합니다. HBase 시스템을 가져옵니다.
2.2 핵심 프로세스는 두 단계로 나뉩니다.
2.2 .1. HFile 생성 단계: MapReduce 작업을 실행하여 HDFS 파일의 데이터를 읽고 키가 rowkey이고 값이 KeyValue일 수 있는 복합 KV를 어셈블해야 합니다. 객체, Put 객체 또는 심지어 삭제 객체는 HBase에 의해 처리되며, 이는 테이블 정보를 기반으로 전역적으로 정렬된 파티셔너를 구성하고 파티셔너 파일을 HDFS 클러스터에 업로드합니다. 대상 테이블의 지역입니다. 각 지역에 해당하는 HFile 파일 생성
2.2.2. HFile 가져오기 단계: HFile 마스터와 백업이 준비된 후 HFile을 온라인 클러스터에 로드합니다.
2.3. Bulkload에서 발생하는 몇 가지 일반적인 문제
2.3.1. 올바른 권한 설정
2.3.1. BulkLoad 작업 프로세스에 참여하는 사용자 p>
첫 번째 단계는 MapReduce 작업을 통해 HFile을 생성하는 것입니다. 이 프로세스에 사용된 HDFS 계정은 u_mapreduce라고 가정합니다.
두 번째 단계는 HFile을 HBase 클러스터에 로드하는 것입니다. 이 단계에서 사용된 계정은 u_load라고 가정합니다.
일반적으로 HBase 클러스터는 HBase 데이터를 관리하기 위해 특수 계정을 사용합니다. 이 계정은 HBase 클러스터의 모든 테이블 중 가장 높은 권한을 갖습니다.
동시에 읽기 및 관리가 가능합니다. HBase 루트 디렉토리에 작성합니다. 이 계정이 hbase_srv라고 가정합니다.
2.3.2. 권한 설정
2.3.2.1 MapReduce 작업을 통해 HFile을 생성합니다. HFile 파일은 u_mapreduce입니다.
2.3.2.2. u_load에는 HFile 파일 및 디렉터리에 대한 읽기 및 쓰기 권한이 필요합니다. 쓰기 권한은 HFile이 여러 지역에 걸쳐 있을 때 분할 작업이 HFile에서 수행되어야 하기 때문입니다.
또한 u_load 계정에는 HBase 테이블의 생성 권한이 필요합니다.
2.3.2.3 hbase_srv 계정은 사용자의 데이터 디렉터리에서 HFile 파일의 이름을 HBase 데이터 디렉터리로 변경합니다. 따라서 hbase_sHrv에는 사용자 데이터 디렉터리 및 HFile 읽기 권한이 있어야 합니다
. 그러나 실제로는 읽기 권한만으로는 충분하지 않습니다. HBase 데이터 디렉터리에 로드된 HFile 디렉터리의 소유자는 여전히 u_mapreduce입니다. 압축 작업이 수행되면
이러한 파일을 아카이브 디렉터리로 이동할 수 없으므로 파일이 점점 더 많아집니다. 이 문제는 HBase 2.x에서 해결되었습니다.
2.3.2. 지역성에 미치는 영향
HFile이 생성된 HDFS 클러스터와 HBase가 위치한 HDFS 클러스터가 동일한 경우 MapReduce는 HFile을 생성하므로 HFile과 대상 지역은 동일한 시스템에 속합니다. 이는 지역성을 보장합니다. 전체 논리는 hbase.bulkload.locality.sensitive.enabled 매개변수에 의해 제어되며, 기본값은 true입니다. 따라서 기본적으로 지역성이 보장됩니다.
사용자가 MapReduce를 사용하여 클러스터 A에 HFile을 생성하는 경우 distcp를 통해 클러스터 B에 복사합니다. 이러한 방식으로 BulkLoad to HBase 클러스터 데이터는 Locality를 보장할 수 없습니다. Loaclity를 향상하려면 BulkLoad를 실행한 후 주요 압축을 수동으로 실행해야 합니다.
2.3.3. BulkLoad 데이터 복제
1.3 이전 버전에서는 BulkLoad에서 HBase 클러스터로의 데이터가 대기 클러스터로 복사되지 않아 의도하지 않게 대기 클러스터가 발생할 수 있습니다. 클러스터가 기본 클러스터보다 느려집니다. 클러스터에 많은 데이터가 누락되었습니다. BulkLoad 데이터 복제는 HBase 버전 1.3 이후에 지원됩니다. 스위치를 켜야 합니다: hbase.replication.bulkload.enabled=true.