文档章节

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

等待救赎
 等待救赎
发布于 2016/06/12 11:12
字数 2595
阅读 350
收藏 4

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

本文转载自:http://my.oschina.net/u/559635/blog/475252?fromerr=GOt9hN06

等待救赎
粉丝 6
博文 79
码字总数 35355
作品 0
程序员
私信 提问

暂无文章

枚举 创建/获取key,name,list

创建枚举 public enum MessageTypeEnum { // 类型:0.一般消息,1.公告消息,2交易消息,3.活动消息,4.其他消息 type_general("一般消息", "0"), type_ann("公告消息", "1")......

龘游戏人生龘
29分钟前
1
0
Linus 本尊来了!为什么 KubeCon 越来越火?

阿里妹导读: 从200人的小会议到3500 多位云原生和开源领域工程师齐聚一堂的大会,KubeCon 只用了四年,昨天,在KubeCon China 2019 上阿里巴巴宣布开源 OpenKruise,今天,Linus 本尊竟然现...

阿里云云栖社区
今天
3
0
五小时构建云原生电商平台 | KubeCon SOFAStack Workshop 详解

本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理, 文末包含文档、PPT 地址,欢迎试用和提出建议。 2019 年 6 月 25 日,在 KubeCon China 2019,全球知名开...

SOFAStack
今天
6
0
跨平台开发框架DevExtreme v19.1.4正式发布|附下载

DevExtreme Complete Subscription是性能最优的 HTML5,CSS 和 JavaScript 移动、Web开发框架,可以直接在Visual Studio集成开发环境,构建iOS,Android,Tizen和Windows Phone 8应用程序。D...

FILA6666
今天
2
0
数据库链接断开 Cause: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

报错信息如下: Cause: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failureThe last packet successfully received from the server was 97,130 mill......

为了美好的明天
今天
4
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部