转载

Hbase-Region-split-policy

hbase-1.0简介

在 HBase 中，Table 被横向划分为 Region，它是一段数据的管理者，Region 被分发到

RegionServer 上进行管理，一个 Region 只被一个 RegionServer

管理，它的数据存储在 HDFS 上，是可以有多个副本的。

也就是说：管理者 (Region) 只有一个，数据有多个副本。

HBase 的以前实现中，当一台 RegionServer

不可用时，需要数十秒甚至数分钟才可以完成发现和恢复工作，在这段时间内，这台

RegionServer 上的 Region 是不可用的。当一个 Region

不可用时，它需要一段时间才可以被其他 RegionServer 接管。

在最新的实现中，一个 Region 可以有多个副本（Region是数据的管理者，是实际数据的抽象），分布在多个 RegionServer 上。

特点：

1.有一个主 Region，多个从 Region。
2.只有主 Region 接收写请求，并把数据持久化到 HDFS 上。
3.从 Region 从 HDFS 中读取数据并服务读请求。
4.从 Region 可能会读到脏数据（主 Region 内存中的数据）。
5.读操作可以只读主，或者既可以读主又可读从（可配置）。

这样在主 Region 不可用时，用户仍可以读从 Region

的数据。目前社区在进行的开发：主 Region 异步同步数据到从 Region，从而减少从

Region 缺少的数据量。

Family 粒度的 Flush（减少小文件，优化磁盘 IO，提高读性能 HBASE-10201）

split-compact

hbase.hregion.max.filesize ：配置region大小，0.94.12版本默认是10G，region的大小 与集群支持的总数据量有关系，如果总数据量小，则单个region太大，不利于并行的数据 处理，如果集群需支持的总数据量比较大，region太小，则会导致region的个数过多，导 致region的管理等成本过高，如果一个RS配置的磁盘总量为3T*12=36T数据量，数据复制3 份，则一台RS服务器可以存储10T的数据，如果每个region最大为10G，则最多1000个regio n，如此看，94.12的这个默认配置还是比较合适的，不过如果要自己管理split，则应该调 大该值，并且在建表时规划好region数量和rowkey设计，进行region预建，做到一定时间 内，每个region的数据大小在一定的数据量之下，当发现有大的region，或者需要对整个 表进行region扩充时再进行split操作，一般提供在线服务的hbase集群均会弃用hbase的自 动split，转而自己管理split。  hbase.hregion.majorcompaction：配置major合并的间隔时间，默认为1天，可设置为0， 禁止自动的major合并，可手动或者通过脚本定期进行major合并，有两种compact：minor 和major，minor通常会把数个小的相邻的storeFile合并成一个大的storeFile，minor不会 删除标示为删除的数据和过期的数据，major会删除需删除的数据，major合并之后，一个s tore只有一个storeFile文件，会对store的所有数据进行重写，有较大的性能消耗。

hbase region

Compact,Split
- hbase.hregion.memstore.flush.size default:128M
- hbase.hregion.max.filesize (table_att==>MAX_FILESIZE) default:10G
- hbase.hstore.compactionThreshold default:3
- hbase.hregion.majorcompaction default:7day

Merge

多个region合并,需要top cluster

hbase  org.apache.hadoop.hbase.util.Merge  <table_name> <region1> <region2>

Scan cache
block cache default：hfile.block.cache.size=0.4
bloom filter

Hbase访问数据时Compact,Split带来的问题

region offline,mapper访问region识别
调整参数控制Compact,Split
- hbase.hregion.majorcompaction
  - 真的设置为0就行了？
- hbase.hstore.compactionThreshold
  - Region中文件个数多于此值,开始compact
  - 可能进入minor,合并较小StoreFile
- hbase.hregion.memstore.flush.size
  - memstore何时写入HStore
- hbase.hregion.max.filesize (table_att==>MAX_FILESIZE)
  - Region何时开始split
- hbase.hstore.blockingStoreFiles
  - max.filesize < flush.size*blockingStoreFiles以保证region不会被block
  有两种类型的紧缩：次紧缩和主紧缩。minor紧缩通常会将数个小的相邻的文件合并成一个大的。Minor不会删除打上删除标记的数据，也不会删除过期的数据，Major紧缩会删除过期的数据。有些时候minor紧缩就会将一个store中的全部文件紧缩，实际上这个时候他本身就是一个major压缩。对于一个minor紧缩是如何紧缩的，可以参见ascii diagram in the Store source code.
  
  在执行一个major紧缩之后，一个store只会有一个sotrefile,通常情况下这样可以提供性能。注意：major紧缩将会将store中的数据全部重写，在一个负载很大的系统中，这个操作是很伤的。所以在大型系统中，通常会自己Section 2.8.2.8, “管理 Splitting”。
  
  紧缩不会进行分区合并。参考 Section 14.2.2, “Merge” 获取更多合并的信息。
- offpeak hour规定在集群不繁忙的时候hbase做自动split,Compact,比如凌晨
```
配置项     默认值     含义 hbase.hstore.compaction.ratio   1.2F     hbase.hstore.compaction.ratio.offpeak   5.0F    与下面两个参数联用 hbase.offpeak.start.hour    -1  设置hbase offpeak开始时间[0,23] hbase.offpeak.end.hour  -1  设置hbase offpeak结束时间 [0,23]  http://www.binospace.com/index.php/in-depth-understanding-of-the-hbase-compaction/
```
- merge
```
hbase org.apache.hadoop.hbase.util.Merge <tablename> <region1> <region2>
```

案例

hbase.hregion.majorcompaction default：7  ==>  hbase.hstore.compactionThreshold default: 3  ==> 8,如果集群中storefile超过8个,和flush.size相关,region超过4G,才开始split  hbase.hregion.memstore.flush.size default: 128M ==> 512M 防止storefile过多,过多storefile导致region compaction hbase.hregion.max.filesize default: 10G   ==> 32G,评估一天写入数据量,分配到不同region最大大小. hbase.hstore.blockingStoreFiles default: 10 ==>  16,避免一个region产生过多storefile,storefile就被block了。

获取region详细信息

scan 'hbase:meta', {COLUMNS => 'info:regioninfo'}       hbase(main):017:0> scan 'hbase:meta', {COLUMNS => 'info:regioninfo', LIMIT => 1} ROW                                    COLUMN+CELL                                                                                                       cust_info,,1450145518714.ddefa1ac4420 column=info:regioninfo, timestamp=1450145519580, value={ENCODED => ddefa1ac442063171ca6ef9f9f0e9e2f, NAME => 'cu  63171ca6ef9f9f0e9e2f.                 st_info,,1450145518714.ddefa1ac442063171ca6ef9f9f0e9e2f.', STARTKEY => '', ENDKEY => ''}'}   hbase(main):008:0> scan 'hbase:namespace', {COLUMNS => 'info:d'} ROW                                    COLUMN+CELL                                                                                                       default                               column=info:d, timestamp=1446179703117, value=/x0A/x07default                                                     hbase                                 column=info:d, timestamp=1446179703143, value=/x0A/x05hbase                                                      2 row(s) in 0.0150 seconds

hbase snappy

snappy hbase 结果>>  表名                    未压缩大小   压缩后大小   压缩比例% user_last_live20151230   2.3 T        0.35T         15

参考： http://hbase.apache.org

原创文章，转载请注明：转载自sparkjvm的博客

本博客的文章集合: http://www.itweet.cn/archives/

正文到此结束

所属分类：编程技术

本文标签： 凌晨 PHP HBase key 博客 apache HDFS App 集群时间删除 tar 管理 http 数据同步 2015 tab Region 开发文章 Hadoop 配置参数 ACE 服务器 map value
版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
本文海报： 生成海报一生成海报二

其他链接

关于本站

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。

问题交流

Hbase-Region-split-policy

hbase-1.0简介

split-compact

hbase region

hbase snappy

热门推荐

相关文章

说给你听

本文目录

随机标签

书籍教程

近期评论

网站信息

其他链接

关于本站

问题交流