HBase必备知识点

Hbase是基于HDFS的面向列的分布式数据库,用于海量结构化数据存储。内部的文件全部存储在HDFS上

HBase中表的特点:
1 大,一个表可以有几十亿行,上百万列
2 面向列,面向列族的存储和权限控制,列簇的独立检索
3 稀疏,对于为空的列,并不占据空间,因此表的设计可以非常稀疏
4 无模式,每行又有一个可排序的主键和任意多的列,列可以根据需要动态的添加,同一张表不同的行可以使用不同的列

Hbase的存储实例:
1 每个column family存储在HDFS上的一个单独的文件中
2 key和version number在每个column family中均有一份
3 空值不会被保存
4 hbase为每个值维护了多级索引,即row key、column family、column name、timestamp等

物理存储:
1 table中的所有行都按照row key的字典序排列
2 table在行的方向上分割为多个region
3 region按大小分割的,每个表开始只有一个region,随着数据的增大,region会不断的增大,当增大到一个阈值的时候,region就会等分为两个新的region,之后会有越来越多的region
4 region是hbase中分布式存储和负载均衡的最小单元。不同的region分布到不同的regionserver上。
5 region虽然是分布式存储的最小单元,但不是存储最小单元。Region由一个或者多个store组成。每个store保存一个column family,每个store又由一个memstore和0至多个storeFile组成,memStore存储在内存中,storeFile存储在HDFS上

Hbase架构图:
HBase必备知识点

Zookeeper:
1 保证在任何时候,集群中只有一个master(负责Hmaster的选举)
2 存储所有region的寻址入口
3 实时监控regionServer的状态,将regionserver的上线和下线信息实时通知给master(服务器之间的状态同步)
4 存储Hbase的schema(元数据信息),其中保存table和table中的colume family

Hmaster:主要负责table和region的管理工作
1 region分裂后,为regionServer分配新的region
2 负责regionServer的负载均衡,调整region的分配
3 发现失效的region Server并重新分配其上的region(region自动切分是Hbase能够拥有良好拓展性的重要因素之一)
4 管理用户对table的增删改查操作
5 监听zookeeper,基于zookeeper感应rs的上下线和保证HA(高可用)
6 处理schema更新请求(对表的增删改查)
7 不参与对表的访问读写
8 在一个regionServer宕机后,负责失效节点的region的迁移

HregionServer(负责响应用户对其上region的I/O请求,向HDFS读写数据):
1 HregionServer维护master分配给它的region
2 维护region的cache
3 处理region的flush、compact、split
4 内部管理一系列的Hregion对象
5 一个HRegionServer会有多个Hregion和一个HLog

Region/Hrgion:
1 每一个region由很多的store组成,每一个store存储的是一个列簇(columnFamily)下所有的数据。在每个store中又包含memstore,memstore驻留在内存中,数据到来时首先要更新到memstore中,当到达阈值后再flush(默认64M)到对应的storeFile/Hfile中。storeFile负责的是实际数据存储,为HBase中最小的存储单元
2 当region到达阈值时(默认为256M),开始分裂。一个HRegionServer管理多个表,一个表下有多个region,一个Hregion有多少个列族就要多个列族就有多少个store,store下有多个storeFile文件,是Hbase中最小的存储单元。
3 每个column Family单独存储:storeFile。storeFile的数量达到阈值,合并。
4 当某个columnFamily累计的大小超过阈值时,自动分裂为两个region。

StoreFile:
Memstore内存中的数据写入到文件之后就是storeFile,storeFile底层是以Hfile格式保存

Hbase的容错性:
1 master容错:
Zookeeper重新选择一个新的master
没有master的过程中,数据读取依旧运行,但region的切分、负载均衡无法进行

2 regionServer容错
定时向zookeeper汇报心跳,如果一旦一段时间未出现心跳,master将该regionServer上的region重新分配到其他regionServer上。
失效服务器上日志(HLOG)由主服务器进行分割并派送给新的regionServer

3 zookeeper容错
Zookeeper后会介绍

什么时候适合使用HBase?
1 半结构化和非结构化数据:对于数据结构字段不确定或杂乱无章,很难以一个概念进行抽取的数据适合HBase,因为HBase支持动态添加列
2 记录很稀疏:传统的行列是固定的,null的存储浪费空间。而HBase的null不会被存储,这样既节省了空间又提高了读性能
3 多版本号数据:依据rowkey和column key 定位的value能够有随意数量的版本号,因此对于需要存储变动历史记录的数据,HBase很方便
4 仅要求最终一致性:对于数据存储事务的要求不像金融行业和财务系统那么高,只要保证最终一致性就可以。
5 高可用和海量数据以及很大的瞬间写入量
6 索引插入比查询更频繁的情况。例如,对历史记录表和日志文件
7 业务场景简单:不需要太多的关系型数据库特定

Rowkey 的设计:
Rowkey的概念和mysql中的主键概念是一致的,HBase使用rowkey来唯一的标识一行数据
HBase中仅支持三种查询方式:
1 基于rowkey的范围扫描
2 基于rowkey的单行查询
3 全表扫描
Rowkey的行键在实际应用中,长度一般为(10-100bytes),最好16bytes。在HBase的内部,rowkey保存为字节数组。Hbase会对表中的数据按照rowkey排序(字典序)

设计原则:
1 唯一原则。必须保持其唯一性。如果同一张表插入相同的rowkey,则原先的数据会被覆盖掉
2 排序原则。根据实际情况。如对视频下方的评论,按时间作为rowkey排序最佳
3 散列原则:rowkey应该均匀的分布在HBase的各个节点上。如常见的时间戳,如果rowkey是按照系统时间戳的方式递增,rowkey的第一部分如果是时间戳信息的话,将会造成所有的新数据都在一个regionServer上堆积的热点现象。
解决热点问题:
Reverse反转:针对固定长度的rowkey反转后存储
Salt加盐:将每一个rowkey加一个前缀,前缀前使用一些随机字符,使数据分散在多个不同的region,达到region负载均衡的目标
Hash散列或者mod:将原始的rowkey进过hash处理
4 长度原则:Rowkey的行键在实际应用中,长度一般为(10-100bytes),最好16bytes。

HBase 宕机如何处理
宕机分为 HMaster 宕机和 HRegisoner 宕机,如果是 HRegisoner 宕机, HMaster 会将其所管理的 region 重新分布到其他活动的 RegionServer 上,由于数据和日志都持久在 HDFS中,该操作不会导致数据丢失。所以数据的一致性和安全性是有保障的。如果是 HMaster 宕机, HMaster 没有单点问题, HBase 中可以启动多个 HMaster,通过Zookeeper 的 Master Election 机制保证总有一个 Master 运行。即 ZooKeeper 会保证总会有一个 HMaster 在对外提供服务。