Hbase原理以及基本运行方式和优化

HBase是一个构建在HDFS上的分布式列存储系统；
HBase是基于Google BigTable模型开发的，典型的key/value系统；
HBase是Apache Hadoop生态系统中的重要一员，主要用于海量非结构化数据存储；
从逻辑上讲，HBase将数据按照表、行和列进行存储。
与hadoop同样，Hbase目标主要依靠横向扩展，经过不断增长廉价的商用服务器，来增长计算和存储能力

:总结一点，都知道Hbase是一个基于HDFS的列数据库对不对！

Hbase的特征：

1. BIGTABLE：所谓的大表，一个表能够有数十亿行，和百万个列。

2. 面向列：面向列（族）的存储和权限控制，列（族）独立检索

3. 稀疏：空（null）列并不占用存储空间，表能够设计的很是稀疏；

4. 数据多版本：每一个单元中的数据能够有多个版本，默认状况下版本号自动分配，是单元格插入时的时间戳；（因此说，Hbase中没有修改这一个概念，若是修改就是增长数据，只不过期间戳变了。查询出来的数据也就变了。）

5. 数据类型单一：Hbase中的数据都是字符串，没有类型。

注：针对字符串 我须要解释一下：最适合使用Hbase存储的数据是很是稀疏的数据（非结构化或者半结构化的数据）。Hbase之因此擅长存储这类数据，是由于Hbase是column-oriented列导向的存储机制，而咱们熟知的RDBMS都是row- oriented行导向的存储机制

结构化数据：结构化信息，咱们一般接触的数据库所管理的信息，包括生产、业务、交易、客户信息等方面的记录

非结构化数据：非结构化数据,包括全部格式的办公文档、文本、图片、XML、HTML、各种报表、图像和音频/视频信息等等

分析：在许多大型像奇艺，搜狐，腾讯视频 优酷视频。他们的资源可能大部分是非结构化数据。

Hbase存储模型：

1. HBase的基本元素:

2. 表、行、列、单元格： 表的基本要素

3. 键：通常是指行的键，即惟一标识某行的元素。表中的行，能够根据键进行排序，而对表的访问，也经过键。

4. 列族：全部列族成员拥有相同的前缀，某列族的成员，须要预先定义，但也能够直接进行追加。

5. 列族成员会一块儿放进存储器。而HBase面向列的存储，是面向列族的数据存储，数据存储与调优都在这个层次，HBase表与RDBMS中表相似，行是排序的，客户端能够把列添加到列族中去。

6. 单元格cell： 单元格中存放的是不可分割的字节数组。而且每一个单元格拥有版本信息。HBase的是按版本信息倒序排列。

7. 区域region：将表水平划分，是HBase集群分布数据的最小单位。在线的全部区域就构成了表的内容。

8.  

‍

Hbase的存储原理：

自动分区：（跟hadoopHDFS很类似）

1. Hbase中一个表被划分了不少个Region，它能够动态扩展，保证整个系统的负载均衡。

2. 让一个Region达了上限的时候，就会自动拆分二个相等的Region。（原理就是Hbase中的split和compaction）

3. 每一个Region由一个RegionServer管理，一个RegionServer能够管理多个Region。

4. RgionServer管理100-1000个region比较合适。 Region的大小通常在1-20GB

表设计优化：

HBase 是一个高可靠性、高性能、面向列、可伸缩的分布式数据库，可是当并发量太高或者已有数据量很大时，读写性能会降低。咱们能够采用以下方式逐步提高 HBase 的检索速度。

预先分区

默认状况下，在建立 HBase 表的时候会自动建立一个 Region 分区，当导入数据的时候，全部的 HBase 客户端都向这一个 Region 写数据，直到这个 Region 足够大了才进行切分。一种能够加快批量写入速度的方法是经过预先建立一些空的 Regions，这样当数据写入 HBase 时，会按照 Region 分区状况，在集群内作数据的负载均衡。

Rowkey 优化

HBase 中 Rowkey 是按照字典序存储，所以，设计 Rowkey 时，要充分利用排序特色，将常常一块儿读取的数据存储到一块，将最近可能会被访问的数据放在一块。

此外，Rowkey 如果递增的生成，建议不要使用正序直接写入 Rowkey，而是采用 reverse 的方式反转 Rowkey，使得 Rowkey 大体均衡分布，这样设计有个好处是能将 RegionServer 的负载均衡，不然容易产生全部新数据都在一个 RegionServer 上堆积的现象，这一点还能够结合 table 的预切分一块儿设计。

减小ColumnFamily 数量

不要在一张表里定义太多的 ColumnFamily。目前 Hbase 并不能很好的处理超过 2~3 个 ColumnFamily 的表。由于某个 ColumnFamily 在 flush 的时候，它邻近的 ColumnFamily 也会因关联效应被触发 flush，最终致使系统产生更多的 I/O。

缓存策略 (setCaching)

建立表的时候，能够经过 HColumnDescriptor.setInMemory(true) 将表放到 RegionServer 的缓存中，保证在读取的时候被 cache 命中。

设置存储生命期

建立表的时候，能够经过 HColumnDescriptor.setTimeToLive(int timeToLive) 设置表中数据的存储生命期，过时数据将自动被删除。

硬盘配置

每台 RegionServer 管理 10~1000 个 Regions，每一个 Region 在 1~2G，则每台 Server 最少要 10G，最大要 1000*2G=2TB，考虑 3 备份，则要 6TB。方案一是用 3 块 2TB 硬盘，二是用 12 块 500G 硬盘，带宽足够时，后者能提供更大的吞吐率，更细粒度的冗余备份，更快速的单盘故障恢复。

分配合适的内存给 RegionServer 服务

在不影响其余服务的状况下，越大越好。例如在 HBase 的 conf 目录下的 hbase-env.sh 的最后添加 export HBASE_REGIONSERVER_OPTS="-Xmx16000m $HBASE_REGIONSERVER_OPTS”

其中 16000m 为分配给 RegionServer 的内存大小。

写数据的备份数

备份数与读性能成正比，与写性能成反比，且备份数影响高可用性。有两种配置方式，一种是将 hdfs-site.xml 拷贝到 hbase 的 conf 目录下，而后在其中添加或修改配置项 dfs.replication 的值为要设置的备份数，这种修改对全部的 HBase 用户表都生效，另一种方式，是改写 HBase 代码，让 HBase 支持针对列族设置备份数，在建立表时，设置列族备份数，默认为 3，此种备份数只对设置的列族生效。

WAL（预写日志）

可设置开关，表示 HBase 在写数据前用不用先写日志，默认是打开，关掉会提升性能，可是若是系统出现故障 (负责插入的 RegionServer 挂掉)，数据可能会丢失。配置 WAL 在调用 Java API 写入时，设置 Put 实例的 WAL，调用 Put.setWriteToWAL(boolean)。

批量写

HBase 的 Put 支持单条插入，也支持批量插入，通常来讲批量写更快，节省来回的网络开销。在客户端调用 Java API 时，先将批量的 Put 放入一个 Put 列表，而后调用 HTable 的 Put(Put 列表) 函数来批量写。

客户端一次从服务器拉取的数量

经过配置一次拉去的较大的数据量能够减小客户端获取数据的时间，可是它会占用客户端内存。有三个地方可进行配置：

1）在 HBase 的 conf 配置文件中进行配置 hbase.client.scanner.caching；

2）经过调用 HTable.setScannerCaching(int scannerCaching) 进行配置；

3）经过调用 Scan.setCaching(int caching) 进行配置。三者的优先级愈来愈高。

RegionServer 的请求处理 IO 线程数

较少的 IO 线程适用于处理单次请求内存消耗较高的 Big Put 场景 (大容量单次 Put 或设置了较大 cache 的 Scan，均属于 Big Put) 或 ReigonServer 的内存比较紧张的场景。

较多的 IO 线程，适用于单次请求内存消耗低，TPS 要求 (每秒事务处理量 (TransactionPerSecond)) 很是高的场景。设置该值的时候，以监控内存为主要参考。

在 hbase-site.xml 配置文件中配置项为 hbase.regionserver.handler.count。

Region 大小设置

配置项为 hbase.hregion.max.filesize，所属配置文件为 hbase-site.xml.，默认大小 256M。

在当前 ReigonServer 上单个 Reigon 的最大存储空间，单个 Region 超过该值时，这个 Region 会被自动 split 成更小的 Region。小 Region 对 split 和 compaction 友好，由于拆分 Region 或 compact 小 Region 里的 StoreFile 速度很快，内存占用低。缺点是 split 和 compaction 会很频繁，特别是数量较多的小 Region 不停地 split, compaction，会致使集群响应时间波动很大，Region 数量太多不只给管理上带来麻烦，甚至会引起一些 Hbase 的 bug。通常 512M 如下的都算小 Region。大 Region 则不太适合常常 split 和 compaction，由于作一次 compact 和 split 会产生较长时间的停顿，对应用的读写性能冲击很是大。

此外，大 Region 意味着较大的 StoreFile，compaction 时对内存也是一个挑战。若是你的应用场景中，某个时间点的访问量较低，那么在此时作 compact 和 split，既能顺利完成 split 和 compaction，又能保证绝大多数时间平稳的读写性能。compaction 是没法避免的，split 能够从自动调整为手动。只要经过将这个参数值调大到某个很难达到的值，好比 100G，就能够间接禁用自动 split(RegionServer 不会对未到达 100G 的 Region 作 split)。再配合 RegionSplitter 这个工具，在须要 split 时，手动 split。手动 split 在灵活性和稳定性上比起自动 split 要高不少，并且管理成本增长很少，比较推荐 online 实时系统使用。内存方面，小 Region 在设置 memstore 的大小值上比较灵活，大 Region 则过大太小都不行，过大会致使 flush 时 app 的 IO wait 增高，太小则因 StoreFile 过多影响读性能。