Hbase学习笔记

1 HBase介绍

(1) HBase是什么

HBase是一个开源的非关系型分布式、实时数据库(Nosql)，运行于HDFS文件系统之上，因此key容错地存储海量稀疏的数据。

海量稀疏就是说不能保证每一个key它的列都有value。

关系型数据库：mysql、oracle

非关系型数据库：Nosql

(2) HBase特点

大量数据存储在HDFS，少量在内存上

特点：高可靠、高并发读写、面向列、可伸缩、易构建

面向列：数据库的存储来说它分两种，一个是行存储，一个是列存储

(3) 行存储：传统关系型数据库

优点:写入一次性完成，保持数据完整性(一步写完一整行)
缺点:数据读取过程中产生冗余数据，若有少量数据可以忽略

比如：下面图片，要去只是读取name字段的内容，但是读取的时候是会全部字段读取的，只是过滤出name的内容输出，优点是写，缺点是读。

(4) 列存储：Nosql数据库

优点：读取过程不会产生冗余数据，特别适合对数据完整性要去不高的大数据领域

缺点：写入效率差，保证数据完整性方面差

比如下图，查找name的数据，就是直接查找name就行了，不会再查找其他的，不会产生冗余数据；稀疏数据，不能保证每一个key它的列都有value，所以是保证数据完整性方面差。

(5) Hbase优势：海量数据存储、快速随机访问、大量写操作的应用

(6) Hbase应用场景：互联网搜索引擎数据存储、海量数据写入、消息中心、内容服务系统、大表复杂&多维度索引、大批量数据读取

应用：主要就是把非结构化数据转换成结构化数据，通过Hbase数据库进行结构化维护

2 数据模型

(1) 组件

Rowkey：是Byte array，是表中每条记录的”主键”，方便快速查找。

时间戳：新修改的排前面，每一个时间戳背后都代表一个版本，具体存了多少版本可通过配置设置。

Column Family：列族，拥有一个名称(string)，包含一个或者多个相关列。

Column：属于一个column family，familyName:columnName，每条记录可以动态添加。

Version Number：类型为Long。默认值是系统时间戳，可由用户自定义。

Value(Cell): Byte array 。

(2) 二分法目的就是为了检索

(3) Hbase Schema设计的时候要指定好CF列族，一个CF里面包含多个columnqualifier，每一个CF代表的属性是不一样的。

比如下图：Rowkey=Itemid，有两个CF，一个是物品属性，一个是用户行为

(4) rowkey按顺序排序，时间戳倒序排序

(5) 修过记录，不会在原来记录修改，是会复制这条，在复制的记录上修改，这样可以回头看这条数据的所有记录。

(6) 三维有序：rowkey(主键)，列(columnfamily、columnqualifier)，时间戳

如：{rowkey =>{family => {qualifier => {version}}}} ===》a:cf1:bar:13456321:9

3 物理模型

(1) 物理模型支撑数据模型的实现

(2) Hbase一张表由一个或多个Hregion(区域)组成，region是按行划分的，

记录之间按照Row Key的字典，Hbase相当于MR里面的Partition，相同的key肯定会在一个region上。

(3) Region是对应Table的一个Region，然后HRegion相当于是对应Region的封装，Region是逻辑概念，HRegion是物理概念。每个逻辑的region背后都是有HRgion去封装的。

(4) 一个用户的表格它可以分出多个区域，然后每一个region包含了很多的行，也就是记录，region内部rowkey是按顺序排序的，region与region之间也是按照这种全局排序的。

(5) Redion按大小分隔的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阈值的时候，Hregion就会等分为两个新的Hregion。当table中的行越来越多，就会有更多的Hregion。

(6) Region有默认大小，10G，数据超过10G，就会分裂为小region，Region是HBase中数据分布的最小单位。

(7) Hbase的锁，是行粒度，行锁定的(读写行不能同步)

(8) region类似一个节点，所在的机器名字就叫regionServer，一个region仅属于一台机器，如果一个regionserver挂了，里面的数据会被其他的regionserver接管。

(9) Hdfs中，为了数据平衡，一个datanode挂了，里面的block也会被其他的datanode接管，这里regionserver也是一样的。

(10)一个region只能属于一个regionserver，但一个regionserver是可以拥有多个region(不一定来自同一个table)

(11)regionServer主要负责用户的IO(读写)请求，然后与HDFS进行交互，机器上有一个进程:HRegionServer，一个HRegionServer内部管理了一系列的HRegion对象

(12)表—》HTable：在Hbase中，一个数据表叫做HTable

(13)按RowKey范围分的Region—》Hegion—》RegionServers

(14)HRegionServer里面存储很多HRegion，HRegion有很多HStore组成，HStore是HBase核心存储单元，HStore内部由两部分组成：Memstore(内存区)和StoreFile(真正落地磁盘的数据)，这两部分均是有序kv的，即按key进行排序的，StoreFile本质是HFive，HFive直接落地到HDFS上(datanode)

(15)Mapreduce中map阶段，数据先读到内存，当数据达到80%，它就会自动锁住然后把这80%的数据进行从内存溢写到磁盘。

(16)Memstore是一块内存，主要负责写入数据，如果当达到Memstore的阈值(128M)，可改，会将内存信息Flush成为一个StoreFile，StoreFile存储在磁盘上。

(17)HRgion按列族(Column Family)—》多个HStore，一个列族就代表一个文件

(18)HStore对应着table中的Column Family，无论CF内部内部有多少数据，都会创建一个HStore，相同属性的数据要放到相同的CF中，避免一次访问，访问多个HStore，性能底下。

(19)HRgion是Hbase中分布式存储和负载均衡的最小单元，但并不是存储的最小单元，最小单元就表示不同的Hrgion可以分布在不同的HRgion server上。但一个Hregion是不好拆分到多个server上的。

(20)往HStore写数据是先往memStor去写，随着数据增多，memStor不断往外输出，然后变成一个个Storefile，Storefile多了的话需要一个合并机制。

(21)BlockCache是读缓存，类似像memStor一样的内存区域，是一个整体的缓冲区，加快读取。

(22)memstor是写缓存，它是在每一个HStore里面，HStore里面都有一个Memchche。

(23)RegionServer---Rgion----HRegion----HStore---MemStore-----StoreFile---HFive。

4 系统架构

(1) Hbase整个系统架构分为四部分：Client、Master、Zookeeper、RegionServer

(2) Client：访问Hbase的接口，并且有一个Cache，维护Cache加速RegionServer的访问

(3) Hdfs中，访问block，要先访问namedoce，从而得知block是在哪个datanode上，这个读表也是一样的，要先知道在哪一个regionserver，进而知道是哪一个region，才能去读key，Cache缓存中就有这些映射关系。没有Cache的话就需要去找zookeeper中寻址。

(4) Master

负载均衡：管理和分配HRgion
DDL：就是增删改操作，对象是table，cf，namespace
类似namenode，管理元数据，就是table的结构
ACL权限控制，就比如多个部门使用同一个HBase，不同部门权限不同

(5) Region Server

管理和存放本地HRgion，即自己管理自己的HRgion
提供了接口，读写HDFS来管理table中的数据
本地化：跟mapreduce一样，数据不移动，计算框架移动，数据迁移需要时间，也怕损坏或丢失，一个HRegionServer可以存放1000个HRegion，尽可能保证HRegion的数据和datanode在一起，目的为了实现本地化，加快数据的读写。但是这个本地化不能总是满足和实现，因为region是会分裂不断移动的，只有当region分裂后的小region合并后，才能继续本地化。

(6) Zookeeper：协同和服务于分布式应用程序的一个服务

保护集群只有一个Master(运行状态)
存储所有Region的入口(ROOT)地址(新版本已经取消)
实时监控Region Server的上下线信息，并通知Master，监控方式：心跳

(7) HBase里面可以有多个Master，但是真正服务的时候，只有一个Master来服务，数据存储在了zookeeper，Master挂了的话，不影响数据读取，但是会影响数据写入，进入影响到region的分裂，导致region越来越大，master也就无法实现负载均衡这一概念

(8) HDFS上的数据是真数据，而zookeeper存的数据是元数据

5 容错

(1) Zookeeper容错：zookeeper是一个可靠性地服务，一般配置3或5个zookeeper实例

(2) Zookeeper协调集群所有节点的共享信息，在HMaster和HregionServer连接到ZooKeeper后，创建Ephemeral(临时)节点，并使用Heartbeat机制维持这个节点的存活状态，如果某个Ephemeral节点实效，则HMaster会收到通知，并做相应的处理

(3) 临时节点特点/作用：监控和心跳，通过临时节点进行一个监控容错

(4) zookeeper是文件目录树结构的，维护了很多节点，每个节点可以存储一定的数据，节点路径是绝对路径的方式，节点的数据都是加密的，二进制形式。

(5) 除了HDFS存储信息，HBase还在Zookeeper中存储信息，其中的znode信息：

/hbase/root-region-server,Rootregion的位置
/hbase/table/-ROOT-，根元数据信息
/hbase/table/.META.，元数据信息
/hbase/master，当选的master
/hbase/backup-master，备选的Master
/hbase/rs，RegionServer的信息
/hbase/unassigned，未分配的Region

(6) Master容错

master挂了，zookeeper会重新选一个新的master
无master过程中，不影响数据读取，但会影响数据写入，进而影响region分裂，region切分，负载均衡也就无法进行

(7) Region Server容错

定时向zookeeper汇报心跳，如果一旦时机内出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割，并派送给新的RegionServer(怎么分配？)

(8) 当RegionServer挂了，它里面运行的Region会迁移到新的节点上去，依赖的是预写功能

(9) WAL(Write-Ahead-Log)预写日志

是Hbase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志
在每次put、delete等一条记录时，首先将其数据写入到regionserver对应的Hlog文件的过程

(10)对数据操作的第一步是要把这个操作写到一个日志中去，这个日志不属于任何一个regionserver，这个日志是共享的数据区域，每一个regionserver都可以读这个HLog，这个数据区域存在HDFS上。

(11)当regionserver挂了，数据操作日志还在HDFS上，重新读取日志即可恢复数据，像mysql日志一样。

(12)客户端往RegionServer端提交数据的时候，会先写WAL日志，只有当WAL日志写成功以后，客户端才会被告诉提交数据成功，如果写WAL失败会告知客户端提交失败。后台数据可通过异步方式更新，跟HDFS写流程一样，写成功一份，即是数据提交成功，其他的异步来获取这份写成功的数据。

(13)数据落地过程

在一个regionserver上的所有的region都共享一个HLog，一次数据的提交是先写WAL，写入成功，再写memstore。当memstore值到达一定阈值(128M)，就会形成一个个StoreFile(理解为HFile格式的封装，本质上还是以HFile的形式存储的)

6 操作

(1) Hbase基础操作跟普通数据块是一样的，有PUT(写)，GET(读)，DELETE等，但这些只是针对单行记录来说的，如果需要多行操作，只能通过SCAN命令

(2) 扫描一段范围的Rowkey使用SCAN，由于Rowkey有序而让Scan变得有效

(3) GET和SCAN支持各种Filter(过滤)，将逻辑推给RegionServer，以此为基础可以实现复杂的查询，如where，时间戳

(4) 支持一些原子操作，INCREMENT、APPEND、CheckAnd{put,delete}

(5) 在单行上可以加锁，具备强一致性，这能满足很多应用的需求。强一致性是说能保证同一时间内数据不会出现多人同写，数据混乱的状态。

7 数据映射

(1) ROOT表和META表是两个比较特殊的表

META表记录了用户表的Region信息，里面可以有多个region，还存储有元数据
ROOT记录了META表的Region信息，ROOT只有一个region，zookeeper中记录了ROOT表的location

(2) 数据映射需要三步

从zookeeper节点获取ROOT的地址，到达ROOT
ROOT表再去META表，拿取用户表的Region信息和元数据
META中的元数据记录了数据所在的RegionServer

(3) 但是Hbase0.96之后就去掉了ROOT表，因为：

三次请求才能获取用户table真正所在位置，效率低
去掉ROOT-Table，也还可以支持2^17(131072)个Hregion，对于集群阿里说，存储空间也足够

(4) 目前流程为：

第一：从Zookeeper(/hbase/meta-region-server)找到META表

META表不会分裂，里面只存储了用户的元数据

第二：从META的元数据中查找要访问的table表(应用层上的应用表)

即是映射了数据具体在哪一个HRegionServer上

根据Rowkey去定位到相应数据

8 写流程--寻址

(1) 上面的映射流程就是寻址流程

(2) 从这个过程中，可以发现客户会缓存这些位置信息，然而第二步它只是缓存当前RowKey对应的HRegion的位置，因而如果下一个要查的Rowkey不在同一个HRegion中，则需要继续查询META所在的HRegion，然而随着时间的推移，客户端缓存的位置信息越来越多，以至于不需要再次查找hbase:meta Table的信息，除非某个HRegion因为宕机或Split被移动，此时需要重新查询并且更新缓存。

可以说是客户端缓存越来越多，可以自己去找了，不需要meta