本文简要介绍HBase，以及数据库的使用场景、产品定位、数据存储知识， keyvalue，然后从服务分别介绍。RegionServer， HMaster， Zookeeper，HBase数据写入和读取过程。

HBase是一种高可靠性、高性能、面向列、可伸缩的分布式存储系统。

• 适用于存储大表数据(数十亿行和数百万列表），读写访问可达到实时水平

  BigTable 疏松分布式持久多维排序map，这个map有行健、列键和时间戳索引，每个值都是连续的byte数组

• 利用HDFS作为文件存储系统

• 利用Zookeeper作为协同服务

  1. 分布式锁	2. 事件监控	3. Region Server数据的存储

HBase该架构包括三个主要功能组件：

• 库函数：链接到每个客户端
• Hmaster主服务器
• 多个HRegionServer服务器

Table
	- Region    1 to n
		- Store    1 to n     一个列族（column family）对应一个store
			- MemStore   1 to 1
			- StoreFile    1 to n
				- Block	    1 to n  

• HBase开始只有一个Region，后来不断分裂
• Region拆分操作非常快，接近瞬间，拆分过程中的region不可读，直到把region存储文件异步地写到独立的文件之后，才会读取新文件

Region分为元数据Region以及用户Region两类

• Meta Region记录了每一个User Region的路由信息
• 读写Region数据的路由，需要先找Meta Region的地址，再由Meta Region找寻User Region地址

HBase：meta表被保存在Zookeeper中。

假设HBase：meta表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制meta表大小为128M，那么二层表结构可以保存的Region数目是128M/1KB = 2^17个Region

客户端包含：

• 访问HBase的接口
• 缓存已访问的Region位置信息

访问过程：

• 查询HBase：meta表，然后确定Region的位置
• 客户端直接访问Region（不经过HMaster）进行读写

• 读取数据时，HRegionServer会先访问MemStore缓存，如果找不到，再去StoreFile中寻找
• 根据时间范围，RowKey范围，以及布隆过滤器缩短定位HFile的时间

• Client 请求RegionServer地址（Zookeeper中meta表或缓存）
• 用户数据先写入到HLog（WAL）中，再写入MemStore中，最终写入磁盘StoreFile
• 只有当操作写入Hlog后，commit()命令才返回给客户端

分布式环境必须要考虑系统出错，HBase采用HLog保证系统恢复。

• HBase系统为每个HRegionServer配置了一个HLog文件，它是一种预写式日志（Write Ahead Log）
• 用户更新数据必须在写入日志之后，才能写入到MemStore进行缓存，直到缓存内容对应的日志写入到磁盘，缓存内容才能flush到磁盘

Hlog工作原理：

• Zookeeper实时监测每个HRegionServer的状态，当某个HRegionServer发生故障时，Zookeeper会通知HMaster
• HMaster首先会处理该故障HRegionServer上面遗留的HLog文件，根据Region对象对HLog数据进行拆分，分别放到相应Region的目录下，然后再重新分配HLog到相应的HRegionServer
• HRegionServer领取分配给自己的Region对象以及HLog，重新做一遍日志记录中的各种操作，把日志记录中的数据写入MemStore缓存中，然后，刷新到磁盘的StoreFile

多个Region共用日志的优点：提高表的读写性能，缺点是故障时需要分拆。

当HFile的数量越来越多，同样的查询，需要同时打开的文件也越来越多，查询时延也越来越大。

Compaction分为两类：

Compaction首先会对File进行一一排查，排除不满足条件的部分文件：

• 排除当前正在执行compact的文件以及比这些文件更新的所有文件（SequenceId更大）
• 排除某些过大的单个文件，否则会产生大量IO消耗

经过排除的文件称为候选文件，HBase接下来会判断是否满足major compaction条件，如果满足，就会选择全部文件进行合并，判断条件有3条，只要满足其中一条就会执行major compaction：

• 用户强制执行major compaction
• 长时间没有进行compact且候选文件数小于hbase.hstore.compaction.max(默认为10)
• Store中含有Reference文件，Reference文件是split region产生的临时文件，只是简单的引用文件，一般必须在compact过程删除

如果不满足major条件，就必然为minor

在寻找到rowkey所对应的RegionServer和Region之后，需要打开一个查找器Scanner，由其具体执行查找数据， Region中会包含内存数据MemStore，文件数据Hfiles，那么在openscanner的时候就需要分别读取这两块数据，打开对应不同的scanner做查询操作

• HFile对应的Scanner为StoreFileScanner
• MemStore对应的Scanner为MemStoreScanner

Bloom用来优化一些随机读取的场景，即Get场景。它可以被用来快速地判断一条用户数据在一个大的数据集合中是否存在。

• Bloom在判断一个数据是否‘’存在‘’，具有一定的误判率，但对于一个数据是否‘’不存在‘’的判断结果是可信的
• HBase的BloomFilter相关数据，被保存在HFile中

行键是字典序存储，因此设计行键时要充分利用这一特点，将经常一起读取的数据存储到一起。

比如：最近写入HBase的数据是最可能被访问的，可以考虑将时间戳作为行键的一部分

HBase只有一个针对行键的索引。

访问HBase表中的行，只有三种方式：

• 通过单个行键访问
• 通过一个行键的区间访问
• 全表扫描

可以通过Apache Phoenix进行二级索引。 客户端发起请求时，数据处理模块会对请求进行解析，然后向Phoenix的二级处理模块发起请求，找到对应数据记录的rowkey，然后根据rowkey去查询数据，避免了全表扫描。

Apache Phoenix让Hadoop中支持低延迟OLTP和业务操作分析。

• 提供标准的SQL以及完备的ACID事务支持

• 通过利用HBase作为存储，让NoSQL数据库具备通过有模式的方式读取数据，我们可以使用SQL语句来操作HBase，例如：创建表、以及插入数据、修改数据、删除数据等

• Phoenix通过协处理器在服务器端执行操作，最小化客户机/服务器数据传输

Apache Phoenix可以很好地与其他的Hadoop组件整合在一起，例如：Spark、Hive、Flume以及MapReduce。