hbase基础小结

阅读更多

hbase简介

HBase（Hadoop Database）是一个高可靠性、高性能、面向列、可伸缩的分布式大数据存储系统。具有最理想化的写和极好的读性能。它支持可插拔的压缩算法（用户可以根据其列族中的数据特性合理选择其压缩算法），充分利用了磁盘空间。

 

 

如上图所示，它是Google BigTable的开源实现，利用Hadoop HDFS作为它文件存储，利用Hadoop MapReduce处理海量数据，使用Zookeeper进行协调服务。利用HBase技术可在廉价PC Server上搭建起大规模NoSql存储集群。值得一提的是，BigTable只支持一级索引，Hbase不仅支持一级索引，还支持二级索引。

 

hbase数据结构

逻辑结构
 

• 表(Table)：HBase会将数据组织进一张张的表里面
• 行(Row)：每一行代表着一个数据对象，每一行都是以一个行键（Row Key）来进行唯一标识的
• 列族(Column Family)：简单理解为对于表一些列的分类，中所有的列都需要组织在列族里面，列族一旦确定后，就不能轻易修改。
• 列标识(Column Qualifier)：列名，列族中的数据通过列标识来进行映射；也可以理解为一个键值对,Column Qualifier就是Key。
• 单元(Cell)：每一个 行键，列族和列标识共同组成一个单元，存储在单元里的数据称为单元数据。
• 时间戳(Timestamp)：默认下每一个单元中的数据插入时都会用时间戳来进行版本标识。

 

物理模型

系统架构

先来看一下hbase的系统架构

 

 

Client：访问HBase的接口，有缓存机制会缓存比如像Region的位置信息等，用以加快HBase的访问，与HMaster（管理类操作）和HRegionServer（读写类操作）通信。

 

Zookeeper：主要做三件事情，存储-ROOT-表和HMaster的地址，会以临时节点机制感知

HRegionServer的监控状态，Zookeeper还可以避免HMaster的单点问题（可以启动多个HMaster）。

 

HMaster：可以启动多个HMaster，利用Zookeeper的选举机制防止单点问题，它主要完成一些对Table和Region的管理工作：

（1）为RegionServer分配Region
（2）负责RegionServer的负载均衡
（3）发现失效的RegionSever并重新分配Region
（4）管理用户对Table的增删改查等操作

 

RegionServer: 主要负责响应用户请求，并向HDFS中读写数据，是HBase最核心的模块儿：

 

HRegionServer内部包含一些列的HRegion对象，每一个HRegion对应到一个Region，正如上文物理模型中提到，每个Region中又包括多个Store，每个Store又包括一个memStore（内存存储）和多个storeFile（storeFile封装了HFile，存储在HDFS之上）。

 

用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile，当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除（数据删除时会首先打一个标记但没有真正删除），因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。

当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前Region Split成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上

 

HRegionServer采用WAL（Write-Ahead-Log）机制来实现数据的容错和恢复，这种机制类似于mysql中的Binary Log。每个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中，HLog文件定期会滚动出新的，并删除旧的文件（已持久化到StoreFile中的数据）。当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的 HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应region的目录下，然后再将失效的region重新分配，领取到这些region的HRegionServer在Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。

 

物理模型

（1） Table中的行会按照Row Key的字典顺序进行排序

（2）每个Column Family其实就是一个集中的存储单元，最好将具备共同IO特性的column放在一个Column Family中，这样最高效。Row Key和Version会在每个Column Family中都有一份，HBase会为每个值维护一个多级索引。  列簇中的列和值实际按照Key/Value进行存储，所以在物理结构上数据并没有逻辑结构中体现的稀疏。

（3）Table会在行的方向上分割为多个Region，开始时表只有一个Region，随着数据增多，Region就会等分成两个新的Region并重新分布到不同RegionServer。

 

（4）HBase中有两张特殊的表-ROOT-和.META.，Zookeeper中记录了-ROOT-的位置信息；-ROOT-又记录了.META.表的Region信息，-ROOT-表只能有一个region；.META.表记录了用户表的Region信息，它可以有多个region。

 

（5）Region是分布式存储的最小单元，但Region中又包括多个Store，每个Store又包括一个memStore（内存存储）和多个storeFile（storeFile封装了HFile，存储在HDFS之上） 

 

适用场景

（1）大数据量存储，大数据量并发操作
（2）需要对数据随机读写操作
（3）读写访问均是非常简单的操作，没有关系型数据库那么复杂的读写操作

 

• 
• 大小: 118.5 KB

• 
• 大小: 167.3 KB

• 
• 大小: 273.5 KB

• 
• 大小: 202.3 KB

• 
• 大小: 51.7 KB

• 查看图片附件