一、数据模型

1.数据模型例子

2.数据模型解析

1）存储（keyvalue）

HBase什么样的数据都能储存，数据的话在HBase当中都是以字节数组的形式储存的；HBase中数据的存储是以key-value格式来存储的，key是rowkey+时间戳+列簇，valuValue部分没有那么复杂的结构，就是纯粹的二进制数据

引用原文：https://blog.csdn.net/ping_hu/article/details/77115998

和https://blog.csdn.net/weixin_33750452/article/details/90308038

2）Row Key

<1> rowkey介绍

如果你想对HBase的表进行防问的时候必须通过row key，那么row key是什么呢：Row Key代表了一行数据；它可以是任意的字符，但是最大只有64k；并且按照字典排序的；

注：我们可以利用字典排序这个点，将经常使用的数据放在一块，最近要访问的放在一块，来进行小小的优化一下

<2> rowkey设计

row key设计的时候需要注意的是，row key 的设计规则，规则有这么几个

定长

为什么定长呢？那是以为内在HBase当中，row的排序是按照字典排序的，如果不定长的话，排序就有可能会打乱。

越短越好

为什么定长呢？那是以为内在HBase当中，每条数据都会呆着rowkey，所以说rowkey越长，所消耗掉额空间就越多，适当的减少rowkey的长度可以提高存储空间的利用

唯一

按照实际的业务来

3）CF（Clumu Family）

· 列簇的话，它是shcema的一部分，所以它必须预先给出；

· 在HBase表中，列名以列簇为前缀，一个列簇可以有很多个成员（列）；

· 成员的话可以按照业务的需求随时追加（动态加入）；

· HBase存储把同一个列簇下的数据放在同一个目录下，就是说是以列簇 为目录存储的，目录下的文件存储该列簇的数据；

· 需要注意的是列簇一般最多只能有三个，一般只用一个就行，这是因为当一个列簇flush的时候，因为关联效应其他的列簇同样也会flush，最终导致系统产生更多的IO。

4）TimeTamp

时间戳是有系统生成的，精确到毫秒的64位整数，而且它本身就代表了唯一性；在HBase当中每个cell存储单元对同一份数据有多个版本，而版本 是根据时间戳来区分的，并且这些版本是按照时间倒序排序的，最新的数据版本排在前面的。

5）cell单元格

是row key和列簇交叉决定的，并且是带有版本的；

实际上存储的是一些未解析的字节数组，由row key ， clumn（family | qualifier）， ersion来定位。

6）Hlog

Hlog其实就是一个普通的hadoop序列文件，它会记录你对HBase表的操作，也会记录你操作的数据。它的key是HLogKey对象，HLogKey中记录了写入数据的归属信息，比如table和region的名字，还有时间戳和序列号，时间戳的值是写入的时间，而序列号的初始值是0,或者是最近一次的写入时间。

7）注意事项

row的设计和列簇的设计

二、HBase架构

架构图

1.架构解析

1）client

包含HBase的接口，并维护cache来加快对HBase的访问

2）zookeeper

保证在任意时刻，只有一个Master是在工作状态的；

并且存储了region的寻址入口；

以及HBase的shcame和表的元数据；

它还有一个作用就是实时的监控者region server的上线和下线状态，并通知给Master，就像个秘书一样。

3）Master

管理region server 的负载均衡和管理用户对表的增删改查；

在一个即使负责为regionserver分配region，以及发现失效的regionserver并重新分配region。

4）RegionServer

负责region的维护以及region的IO请求，还有即使负责将膨胀的region进行切分

5）Region

<1>介绍

先介绍一下region，HBase会吧一张表分成多个区域，每个区域就是一个region，region里面保存的是某一段连续的数据，刚开始的时候就只有一个region，当随着数据的不断插入，region到达某个阀值的时候，这个region就会等分裂变为两个region随着region的不断增多，master会把它分配到不同的节点上，所以说一张表也有可能分配到不同的regionserver上。而一个region又是由多个store组成的，一个store对应的是一个列簇，这是他们之间的关系，我接着说一下store

<2>Store

Store包含了位于内存的memestore和位于磁盘的storeFile，当进行写入操作的时候，数据会先写入memstore，当memestore到达某个阀值，regionserver会启动flashcache，将memestore的数据写入到磁盘，形成一个新的storefile

<3>StoreFile

当storefile增大到一个阀值以后，系统会进行合并，在版本合并过程中，系统会进行版本合并和删除工作，合并成一个更大的storrefile；

当storefile的大小和数量都达到一个阀值以后，region会进行裂变分裂成两个相等的region，然后由master分配，实现负载均衡

<4>Memestore

Memestore的就是一个内存缓冲区，当这个缓冲区满的时候就会溢写数据到形成新的storefile，当客户端检索数据的时候，会先从memestore中检索，检索不到再到storefile中检索

<5>合并（compaction）

说架构的时候可以扯到这个上，合并是发生在写文件的时候，合并的作用 是合并小文件；清楚过期，多余的版本数据；提高读写数据的效率

<6>注意事项

region是HBase中最小的存储和负载均衡的最小单元，最小单元也就意味着分布在不同的regionserver上，而一个region由多个store组成，每个store就是一个列簇，每个store又是由一个memstore和0个或者多个storeFile组成。最终的数据是以HFile的格式存储在HDFS上的，最终数据就是storeFile

三、HBase优化

1.热点问题优化

1）热点现象以及原因

热点问题是指客户端的大量的访问并只在一个节点上访问，这是热点问 题。产生的原因主要是因为大量相似的rowkey都在一个节点上

解决方案

· 有一种解决方案是加盐，这所谓的加盐，是在row key前面加上随机数， 让rowkey之间的差异化变大，至于加多少个随机数就要看你想要分到多少个region了。加盐以后的rowkey就会根据随机生成的前缀分配到不同region上去，避免热点问题。这是加盐

· 将rowkey进行反转也能解决热点问题，虽然这样可以解决热点问题，但是也牺牲了rowkey的有序性

· 使用哈希也可以解决这个问题，将哈希作为rowkey的前缀。

2）表设计

<1>预分区

HBase默认建表的时候只有一个region，在数据写入时，只会往这一个中写入，这就有两个问题，第一个数据都往一个region上写，会有热点问题，第二个当region足够大的时候要进行切分，会消耗集群的IO资源。我们在建表的时候添加一些空的region来预防这两个问题,创建包含预分区表的命令如下：

> create 't1', 'cf', SPLITS => ['20150501000000000', '20150515000000000', '20150601000000000']

<2>rowkey的设计

唯一性；rowkey默认字典升序排序；越短越好，定长；散列；取反；Hash；根据实际的业务来

<3>clumn family的设计

一张表中最多不要定义超过三个，一般一个就行。这么做是因为，如果在有多个列簇的情况下，其中一个flush的时候，它邻近的列簇因为关联效应也会flush，最终导致系统产生更多的IO。还有就是当region到达阀值的时候，要进行裂变了，假设这个region中有两个列簇，一个列簇100000行数据，一个100行数据，这样就会导致100的列同样被分到多个region中，当查询的时候效率会变低

<4>参数优化

设置表在regionserver缓存：In Memory HClumnDiscriptor.setInMemory(true)

设置表的最大版本数：Max VersionsHClumnDiscriptor.setMaxVersions(int versions)

设置表的存储时间：Time To Live HClumnDiscriptor.setTimeToLive(int TimeToLive)

<5>compation

HBase为了防止被刷到磁盘的memorstore的文件太小和过多，以及为了整合storeFile，以保证查询效率，HBase在必要的时候会进行合并，这个过程叫做compation

分类

minor conpaction：minor conpaction的作用是将小文件进行合并优化建议（按照实际需求修改下列参数）

· hbase.hstore.compaction.min :默认值为 3 ，表示一次minor compaction中最少选取3个store file. minor compaction才会启动

· hbase.hstore.compaction.max 默认值为10，表示一次minor compaction中最多选取10个store file

· hbase.hstore.compaction.min.size 表示文件大小小于该值的store file 一定会加入到minor compaction的store file中

·hbase.hstore.compaction.max.size 表示文件大小大于该值的store file 一定会被minor compaction排除

·hbase.hstore.compaction.ratio 将store file 按照文件年龄排序（older to younger），minor compaction总是从older store file开始选择

major compaction： major compaction试讲所有的storeFile合并成一个大的storeFile

major compaction触发条件

major compact命令

major compact()API

region Server自动运行

优化建议是将系统的默认启动改为手动启动

3）写表优化

<1>多table并发写

创建多个HTable客户端用于写操作，提高写数据的吞吐

<2>参数设置

· 关闭自动Flush：将这个参数HTable.setAutoFlush(false)设置为false以后，系统就不用一条数据一更新了，而是等客户端的缓存满了以后再更新，这样就 大大减少了flush的次数

· 设置写数据的缓存大小：将HTable.setWriteBufferSize(WriteBufferSize)这个参数的值设置为实际要写入数量的值，如果实际写入Buffer中的数据量大于这个值的时候，buffer就会将数据flush到服务端。

4）读表优化

<1>多table并发读

创建多个HTable客户端用于读操作，提高读数据的吞吐量

<2>HTabke参数设置

· Scanner Caching：将HBase.Client.Scanner.Caching这个参数设置为一个合理的值，可以减少Scann过程中next（）的时间开销，它的代价就是需要客户端通过内存来维持这些cashe 的行为记录

· Scan Attribute Selection：将scan.addColumn("cf1".getBytes(), "name".getBytes());指定列簇来读取，可以减少网络传输的数据量

· Close ResultScanner：释放资源scan取完数据后，要关闭ResultScanner来释放资源再就是使用安全的HTbalePool因为HTbalePool可以自动创建HTble对象，这就解决HTbale线程不安全的的问题还有HTablePool和HTbale是公用的congfiguration连接的，可以减少网络开销再就是使用安全的HTbalePool

四、HBase读写流程

1.写流程

1）Client端先访问zookeeper，通过mate表获取region的信息，并且读取meta表中的数据根据nameSpace、表名和rowkey在mate表中找到对应的region信息接着通过这个region，找到对应的regionserver

2）把数据分写在memostore和Hlog上一份，这么做是为了防止memostore中的数据丢失，可以使用Hlog来恢复

3）我们都知道数据写入的时候会先写入位于内存的memstore，当到达memstore存储的80%的时候，memstore会溢写到磁盘，成为一个新的shtoreFile文件，我们也都知道当storeFile文件到达一定阀值的时候，系统会进行一次合并，将小的storeFile文件合并成一个大的StoreFile文件，当storeFile文件的大小和数量都到达一个阀值的收，当前region就会等分裂变为两个region，接着通过master分配到对应 的regionserver上去。

2.读流程

1）client先访问zookeeper，通过meta表获取region信息，并且读取mate表中的数据

2）接着在通过namespace、表名以及rowkey在mate表中获取对应的region信息通过这个region信息呢，找到对应的regionserver信息这样的话数据的路径就知道了，接着我们就通过这个路径找到对应的rergion

3）读取的时候是先去memstore查找，如果没有的再去storeFile中查找，这么做是因为系统设置的就是这么做