HBASE架构

主要特点

分布式，无限的最大数据量。CP架构。非严格上的高可用。

采用HDFS作为存储。一般推荐region server和HDFS的datanode的部署在同一机器。

使用LSM存储机制。

HBase在80-90W的写TPS是没有问题。

Hbase可以设置过期时间，应该合理设置。HBase一般采取全量初始化，然后每天批量增加数据的方法。（因为每天全量导入数据影响性能）。所以，TTL有可能回设置成无限长，来避免长期不更新的数据的失效。

Hbase可以设置最大版本数量和版本号。比如说一个版本数是10个，那么只会存储最近10个版本的数据。可以按照时间戳来指定版本，这样不用担心写入Hbase过程造成乱序。通过这个版本号可以支持版本回滚（查询时指定版本号）。

庞大Hbase的集群中单机挂掉的概率。但是默认是三个副本。但是会短暂的对下游应用报出拒绝服务或者连接超时，引起下游服务抖动。推荐访问Hbase的超时设置为30s到1min（等待挂掉的server恢复，这也体现了Hbase是CP形）

Hbase不推荐过多的列族（1-3个最合适）也不推荐过多的列（几百个就不要了）

rowkey的设计最容易闯祸。特别是需要scan的场景。

基本构造

HBase中的表的存储逻辑结构如下

• Master
  HBase Master用于协调多个Region Server，侦测各个RegionServer之间的状态，并平衡RegionServer之间的负载。HBaseMaster还有一个职责就是负责分配Region给RegionServer。HBase允许多个Master节点共存，但是这需要Zookeeper的帮助。不过当多个Master节点共存时，只有一个Master是提供服务的，其他的Master节点处于待命的状态。当正在工作的Master节点宕机时，其他的Master则会接管HBase的集群。

• Region Server
  对于一个RegionServer而言，其包括了多个Region。RegionServer的作用只是管理表格，以及实现读写操作。Client直接连接RegionServer，并通信获取HBase中的数据。对于Region而言，则是真实存放HBase数据的地方，也就说Region是HBase可用性和分布式的基本单位。每一个 Region 都只存储一个 Column Family 的数据，并且是该 CF 中的一段（按 Row 的区间分成多个 Region）。如果当一个表格很大，并由多个Column Family组成时，那么表的数据将存放在多个Region之间，并且在每个Region中会关联多个存储的单元（Store）。

当一个 Client 需要访问 HBase 集群时，Client 需要先和 Zookeeper 来通信，然后才会找到对应的 Region Server来读取root表（root表在哪个RS上存储在zk上），然后根据root表的记载找到实际存储的Region Server，通过该Region Server记录的meta表判断所查询的rowkey具体属于那个region。最终向region发出请求操作实际数据。root表会被缓存在client，直到读取miss。

HBASE在zookeeper上注册的数据麻烦移步
https://blog.csdn.net/qq_35995514/article/details/121940993

Region Server包含多个Region。

meta表结构，meta表就是存储每一个用户表的指定key的region的具体位置。

root表结构，root表就是存储每一个meta表指定key，region server的具体位置。

HBase的持久化文件是HFile。存储在HDFS上。

region写数据是

1. 如果此Region的MemStore已经有缓存已有写入的数据, 则直接返回;
2. 如果没有缓存, 写入HLog(WAL机制), 再写入MemStore.成功后再返回.
3. MemStore内存达到一定的值调用flush成为StoreFile,存到HDFS
   region的结构如下。一个region对应一个表中的一个列簇。
   
   region会尽量利用memstore作为缓存提高自己随机写入的能力。也会定期的持久化到HFile。

在上面我们可以看到，除了每个region所持有的MemStore，所有region公用region server上的BlockCache来加快读取速度。

Hbase支持LZO和GZ两种压缩格式，前者省CPU，后者省磁盘。

BlockCache

BlockCache是RegionServer级别的，即每个RegionServer会有一个BlockCache，BlockCache会将要读取的block放到内存中，以便后续的访问。HBase提供了4种BlockCache的方案

• 最初的LruBlockCache
• SlabCache,见HBASE-4027,0.92版本提供
• BucketCache,见HBASE-7404,0.95版本
• ExternalBlockCache，见HBASE-13170,1.10版本

其中SlabCache由于以下原因，在1.0版本后被废弃了HBASE-11307

• 使用了单一cache大小，由于有多种类型的blocksize这样会导致内存使用率低
• 使用了DoubleBlockCache，block会在SlabCache和LRUBlockCache都缓存一份，当在SlabCache中命中block时会把block放到LRUBlockCache中，这样会导致CMS GC和造成堆碎片。比单独用LRUBlockCache没有改善。
• 堆外内存的性能没有堆内存高

WAL（Write-Ahead-Log)）机制

HLogs 是region server上的几个region共享的日志文件。一个region server上只有一个。HBase 1.0后一个region server也可以又多个Hlog对象。

Compact机制

在hbase中每当有memstore数据flush到磁盘之后，就形成一个storefile，当storeFile的数量达到一定程度后，就需要将 storefile 文件来进行 compaction 操作。
Compact 的作用：

1. 合并文件
2. 清除过期，多余版本的数据
3. 提高读写数据的效率
   HBase 中实现了两种 compaction 的方式：minor and major. 这两种 compaction 方式的区别是：
4. Minor 操作只用来做部分文件的合并操作以及包括 minVersion=0 并且设置 ttl 的过期版本清理，不做任何删除数据、多版本数据的清理工作。
5. Major 操作是对 Region 下的HStore下的所有StoreFile执行合并操作，最终的结果是整理合并出一个文件。

split机制

split机制用于HBase内部的负载均衡。将大的region分成小region放到不同的region server，从而使负载平均化。region的默认分裂点是1G。在上线前，请预估数据量，来进行预分裂，避免引起后续维护困难。

持久化和HDFS

hdfs的目录大致如下

hdfs dfs -ls -h /apps/hbase/data
Found 9 items
drwxr-xr-x   - hbase hdfs          0 2018-10-05 07:41 /apps/hbase/data/.tmp
drwxr-xr-x   - hbase hdfs          0 2018-10-05 07:41 /apps/hbase/data/MasterProcWALs
drwxr-xr-x   - hbase hdfs          0 2018-10-05 08:16 /apps/hbase/data/WALs ##负责存储WAL日志
drwxr-xr-x   - hbase hdfs          0 2018-10-07 04:59 /apps/hbase/data/archive
drwxr-xr-x   - hbase hdfs          0 2017-11-06 14:51 /apps/hbase/data/corrupt
drwxr-xr-x   - hbase hdfs          0 2017-11-02 10:40 /apps/hbase/data/data ## 存储实际的用户表和HBase的内部表
-rw-r--r--   3 hbase hdfs         42 2017-11-02 09:26 /apps/hbase/data/hbase.id ##存储HBase集群的唯一UUID
-rw-r--r--   3 hbase hdfs          7 2017-11-02 09:26 /apps/hbase/data/hbase.version ##存储HBase的版本号
drwxr-xr-x   - hbase hdfs          0 2018-10-09 13:38 /apps/hbase/data/oldWALs

LSM的思想

以HBase存储的设计主要思想：

因为小树先写到内存中，为了防止内存数据丢失，写内存的同时需要暂时持久化到磁盘，对应了HBase的MemStore和HLog
MemStore上的树达到一定大小之后，需要flush到HRegion磁盘中（一般是Hadoop DataNode），这样MemStore就变成了DataNode上的磁盘文件StoreFile，定期HRegionServer对DataNode的数据做merge操作，彻底删除无效空间，多棵小树在这个时机合并成大树，来增强读性能（campaction操作）。

minor compaction是上面的流程。
major compaction，将所有storefile合成唯一一个，同时根据TTL和版本号等来清理数据，会消耗大量的资源。线上生产一般关闭该选项。

读写流程

读流程如下

写流程如下

根据WAL

存储的逻辑结构

列族

hbase表中的每个列，都归属与某个列族。列族是表的schema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如courses:history ， courses:math 都属于 courses 这个列族。
访问控制、磁盘和内存的使用统计都是在列族层面进行的。实际应用中，列族上的控制权限能 帮助我们管理不同类型的应用：我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据（甚至可能因 为隐私的原因不能浏览所有数据）。一个实际存储在HDFS的实际文件只包含一个表的一个列族。

rowkey

Hbase的每一行都有一个row key，用于数据的检索。与nosql数据库们一样,row key是用来检索记录的主键。访问hbase table中的行，只有三种方式：

1. 通过单个row key访问
2. 通过row key的range
3. 全表扫描

布隆滤波器

bloom filter的数据存在StoreFile的meta中，一旦写入无法更新，因为StoreFile是不可变的。Bloomfilter是一个列族（cf）级别的配置属性，如果你在表中设置了Bloomfilter，那么HBase会在生成StoreFile时包含一份bloomfilter结构的数据，称其为MetaBlock；MetaBlock与DataBlock（真实的KeyValue数据）一起由LRUBlockCache维护。所以，开启bloomfilter会有一定的存储及内存cache开销。
布隆滤波器主要用题提升随机读的性能。hbase的storefile有很多，随机查的时候可能需要遍历很多storefile，如果在建表的时候指定了bloomfilter，则在get查询的时候就可以过滤掉很多不符合规则的storefile，提高查询效率。但是Scan查询无法利用到布隆滤波器。

二级索引

在Hbase中,表的RowKey 按照字典排序, Region按照RowKey设置split point进行shard，通过这种方式实现的全局、分布式索引. 成为了其成功的最大的砝码。

然而单一的通过RowKey检索数据的方式,不再满足更多的需求，查询成为Hbase的瓶颈，人们更加希望像Sql一样快速检索数据，可是，Hbase之前定位的是大表的存储，要进行这样的查询，往往是要通过类似Hive、Pig等系统进行全表的MapReduce计算，这种方式既浪费了机器的计算资源，又因高延迟使得应用黯然失色。于是，针对HBase Secondary Indexing的方案出现了。

基于Coprocessor

Apache Phoenix

Lily HBase Indexer

CDH Search

Hbase常见命令

describe 'ns1.t1'//描述表结构
get 'ns1:t1', 'r1'//查询数据
scan 'nstest:tb1' //全表扫描
scan 'ns1:t1', {COLUMNS => ['c1', 'c2'], LIMIT => 10, STARTROW => 'xyz'} //范围扫描,仅返回10条数据
deleteall 'ns1:t1','r1' //删除
put 'ns1:tb1','r1','cf1:c1','20' //修改

hbase不但提供了简单查询，还提供了各种filter。

Scan scan = new Scan();
RegexStringComparator comp = new RegexStringComparator("you."); // 以 you 开头的字符串
SingleColumnValueFilter filter = new SingleColumnValueFilter(Bytes.toBytes("family"), Bytes.toBytes("qualifier"), CompareOp.EQUAL, comp);
scan.setFilter(filter);

命令行

hbase(main):106:0> import org.apache.hadoop.hbase.filter.PrefixFilter;
hbase(main):107:0* import org.apache.hadoop.hbase.util.Bytes;
hbase(main):108:0* scan 'hbaseFilter',{FILTER=>PrefixFilter.new(Bytes.toBytes('row3'))}
ROW                                              COLUMN+CELL                                                                                                                                   
 row3                                            column=f:age, timestamp=1499150787882, value=age3                                                                                             
 row3                                            column=f:name, timestamp=1499150787882, value=name3                                                                                           
1 row(s) in 0.1670 seconds

或者

scan 'test1', FILTER=>"ValueFilter(=,'binary:sku188')"  
  
ROW                          COLUMN+CELL                      
 user1|ts2                   column=sf:c1, timestamp=1409122354918, value=sku188

高可用

严格意义上，HBASE不存在单点故障，因为其底层数据是存储在HDFS上的。