如何解析Hbase原理以及基本运行方式和优化

16次阅读
没有评论

如何解析 Hbase 原理以及基本运行方式和优化,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

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

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

Hbase 的特征:

BIGTABLE:所谓的大表,一个表可以有数十亿行,和百万个列。

面向列:面向列(族)的存储和权限控制,列(族)独立检索

稀疏:空(null)列并不占用存储空间,表可以设计的非常稀疏;

数据多版本:每个单元中的数据可以有多个版本,默认情况下版本号自动分配,是单元格插入时的时间戳;(所以说,Hbase 中没有修改这一个概念,如果修改就是增加数据,只不过时间戳变了。查询出来的数据也就变了。)

数据类型单一:Hbase 中的数据都是字符串,没有类型。

注:针对字符串   我需要解释一下:最适合使用 Hbase 存储的数据是非常稀疏的数据(非结构化或者半结构化的数据)。Hbase 之所以擅长存储这类数据,是因为 Hbase 是 column-oriented 列导向的存储机制,而我们熟知的 RDBMS 都是 row- oriented 行导向的存储机制

结构化数据:结构化信息,我们通常接触的数据库所管理的信息,包括生产、业务、交易、客户信息等方面的记录

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

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

Hbase 存储模型:

HBase 的基本元素:

表、行、列、单元格:  表的基本要素

键:一般是指行的键,即唯一标识某行的元素。表中的行,可以根据键进行排序,而对表的访问,也通过键。

列族:所有列族成员拥有相同的前缀,某列族的成员,需要预先定义,但也可以直接进行追加。

列族成员会一起放进存储器。而 HBase 面向列的存储,是面向列族的数据存储,数据存储与调优都在这个层次,HBase 表与 RDBMS 中表类似,行是排序的,客户端可以把列添加到列族中去。

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

区域 region:将表水平划分,是 HBase 集群分布数据的最小单位。在线的所有区域就构成了表的内容。

 

 

Hbase 的存储原理:

自动分区:(跟 hadoopHDFS 很相似)

Hbase 中一个表被划分了很多个 Region,它可以动态扩展,保证整个系统的负载均衡。

让一个 Region 达了上限的时候,就会自动拆分二个相等的 Region。(原理就是 Hbase 中的 split 和 compaction)

每个 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  过多影响读性能。

关于如何解析 Hbase 原理以及基本运行方式和优化问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注丸趣 TV 行业资讯频道了解更多相关知识。