hbase分区数，hbase分区大小

怎么保证服务可靠性,数据一致性,以及一旦宕机数据恢复

1、Zab协议是zookeeper专门设计的一种 支持崩溃恢复 的 原子广播协议， 是Zookeeper保证数据一致性的核心算法。

2、宕机的leader活过来也像follower一样同步数据，来保证数据的一致性。

3、保证数据最小化丢失 上面的方案设计及架构比较复杂，如果能容忍数据的丢失，可以考虑使用淘宝的TMHA复制管理工具。当master宕机后，TMHA会选择一个binlog接收最大的slave作为master。

相关问答

Q1: hbase预分区表能调整吗

默认情况下，在创建HBase表的时候会自动创建一个region分区，当导入数据的时候，所有的HBase客户端都向这一个region写数据，直到这个region足够大了才进行切分。

自然split的几率也会大大降低。当然随着数据量的不断增长，该split的还是要进行split。像这样预先创建hbase表分区的方式，称之为预分区。

预分区后，可以从 HBase ui 页面观察到： HBase API 建预分区表 为防止热点问题，同时避免 Region Split 后，部分 Region 不再写数据或者很少写数据。

hbase.hregion.max.filesize 设定的region大小，超过了就会split，就会增加一个region，对预分区没什么影响。

hbase.hstore.blockingStoreFiles默认设置为7，可以适当调大一些。

- Region Server 上运行的 Region 总数 Region 越多，Region Server 上维护的 MemStore 就越多。根据业务表读写请求量和 RegionServer 可分配内存大小，合理设置表的分区数量（预分区的情况）。

Q2: hbase预分区与region切割的关系

默认，HBase 在创建表的时候，会自动为表分配一个 Region，正处于混沌时期，start-end key 无边界，所有 RowKey 都往这个 Region里分配。

HBase表的列族在创建之初只有一个Region，随着插入数据的增多Region变得越来越大。

整个region切分是一个比较复杂的过程，涉及子步骤，因此必须保证整个 Split 过程的事务性，即要么完全成功，要么完全未开始，在任何情况下也不能出现 Split 只完成一半的情况。

以fileServer为例，在使用默认的split策略--IncreasingToUpperBoundRegionSplitPolicy 的情况下，16个预分区Region， 则单个Resion容量达到 min(32，50)，即32GB时分裂。

hbase分区数的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于hbase分区大小、hbase分区数的信息别忘了在本站进行查找喔。