1、基本概念
HBase是一个开源的非关系型分布式数据库（NoSQL），参考了谷歌的BIgTable建模，实现的编程语音为Java。是Apache软件基金会的Hadoop项目的一部分，运行于HDFS文件系统上，所以可以容错地存储海量稀疏的数据
- HBase的特性：
- 高可靠
- 高并发读写
- 面向列
行存储 VS 列存储
行存储：优点是，写入一次性完成，保持数据完整性；缺点是，数据读取过程中产生冗余数据，若有少量数据可以忽略；
列存储：优点是，读取过程不会产生冗余数据，特别适合对数据完整性要求不高的大数据领域； 缺点是，写入效率差，保证数据完整性方面差 - 可伸缩
- 易构建
- Hbase优势：
- 海量数据存储
- 快速随机访问
- 大量写操作的应用
- Hbase应用场景：
- 互联网搜索引擎数据存储
- 海量数据写入
- 消息中心
- 内容服务系统（schema-free）
- 大表负责&多维护索引
- 大批量数据读取
2、Data Modeling
RowKey：是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要；
Column Family：列簇，拥有一个名称（String），包含一个或者多个相关列
Column : 属于某一个Columnfamily，familyName:columnName，每条记录可动态添加
Version Number：类型为Long，默认值是系统时间戳，可由用户自定义，每个rowkey唯一
Value（Cell）：Byte array
三维有序 {rowkey => {family => {qualifier => {version => value}}}}
默认都是按字典顺序，即字母顺序排列（如下，bar在foo前）；
a:cf1:bar:1368394583:7
a:cf1:foo:1368394261:hello
3、体系架构
Client :
1、整个HBase集群的访问入口；
2、使用HBase RPC机制与HMaster和HRegionServer进行通信；
3、与HMaster通信进行管理类操作；
4、与HRegionServer通信进行数据读写类操作；
5、包含访问HBase的接口，并维护cache来加快对HBase的访问
Zookeeper：
1、保证任何时候，集群中只有一个HMaster；
2、存储所有HRegion的寻址入口；
3、HMaster和HRegionServers启动时会向ZooKeeper注册；
4、实时监控HRegion Server的上线和下线信息，并实时通知给HMaster；
5、存储HBase的schema和table元数据。
6、容错：Zookeeper是一个可靠的服务，一般配置3或者5个Zookeeper实例。
HMaster：主要负责Table和Region的管理工作
1、HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master在运行；
2、管理用户对table的增删改查操作；
3、管理HRegionServer的负载均衡，调整Region分布；
4、Region Split后，负责新Region的分配；
5、在HRegionServer停机后，负责失效HRegionServer上Region迁移工作；
6、Client访问hbase上数据的过程并不需要HMaster参与（寻址访问Zookeeper和HRegionServer，数据读写访问HRegionServer）,HMaster仅仅维护着table和Region的元数据信息，负载很低；
7、容错：Zookeeper重新选择一个新的的Master
—无HMaster过程中，数据读取依旧照常进行；
—无HMaster过程中，region切分，负载均衡等无法进行
RegionServer：
1、维护HRegion，处理对这些HRegion的IO请求，向HDFS文件系统中读写数据；
2、负责切分在运行过程中变得过大的HRegion；
3、HRegionServer内部管理了一系列的HRegion对象，每个HRegion对应了table中的一个region，HRegion中由多个HStore组成。每个HStore对应了Table中的一个column family(列簇)，每个HStore 是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个column family中，这样最高效；
4、HStore存储是HBase存储的核心，由两部分组成，一部分是MemStore，一部分是StoreFile；MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore中，当MemStore满了以后会Flush成一个StoreFile(底层实现是HFile)
5、Regionserver容错：定时向Zookeeper汇报心跳，如果一段时间内未出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer。
注：split分为切分（regionserver负责）和分配（master负责）两个过程
4、物理模型
region，Hbase上的分区概念，不同rewkey存储在不同的region上
当region被分为两个新的region时，master会将这两个region分配到不同的regionServer上
5、在HDFS上目录结构
WALs：预写日志，用来记录日志；RegionServer在往表中写入数据时，会先往WALs下的Hlog写一份，然后再往内存写（和mysql的binlog类似），避免内存丢失数据，可以从日志文件中恢复
data：是真正存储数据的
下面第一层是namespace（nstest）
第二层是table（tb1），第三层是region，第四层是列簇Column Family，第五层是StoreFile
6、在HDFS上数据存储
HBase中的所有数据文件都存储在HDFS上，主要有两种文件类型
1、Hfile : HBase中
当用户写入时候，先写入memstore，当memstore满了以后会flush成一个storefile（就是Hdfs上的Hfile）；
用户也可以手动flush，将内存中的数据直接溢写到磁盘上，手动干预
2、Hlog File : HBase中WAL（Write Ahead Log预写日志）的存储格式，物理上是Hadoop的squence File序列化文件
WAL类似Mysql中的binlog，用来做灾难恢复。Hlog记录数据的所有变更，一旦数据修改，就可以从log中进行恢复。每个HRegionServer维护一个HLog；这样不同region(来自不同表table)的日志会混在一起，这样做的目的是不断追加单个文件，相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能；但是，因此带来的缺点是，如果一台HRegionServer下线，为了恢复其上的region，需要将HRegionServer上的log进行拆分，然后分发到其他HRegionServer上进行恢复
HBase中默认有张系统表（'hbase:namespace'，下图），存储hbase中所有namespace的信息；还有张'hbase:meta'表：记录元数据，它的rowkey存储的是hbase中所有表的region 的位置信息
7、在Zookeeper上数据存储：
除了HDFS存储信息，HBase还在Zookeeper中存储信息，其中的znode信息：
– /hbase/root-region-server ，Root region的位置(系统'hbase:meta'元数据表的region信息)
– /hbase/table/-ROOT-，根元数据信息
– /hbase/table/.META.，元数据信息
– /hbase/master，当选的Mater
– /hbase/backup-masters，备选的Master
– /hbase/rs ，Region Server的信息
– /hbase/unassigned，未分配的Region
8、Hbase读写数据流程：
Hbase读取数据流程：
1、首先，Client先访问zookeeper，获取系统'hbase:meta'元数据表的region信息和HRegionServer信息（确定'hbase:meta'元数据表的位置），从而获取到'hbase:meta'元数据表
2、其次，根据namespace、tablename、rowkey，在'hbase:meta'元数据表查找对应的的Region信息和HRegionserver信息
3、最后，根据已经获取到的regionserver 和 region信息，去regionserver节点上查找数据，先从memstore读取，如果没有，再到storeFile上读取（为了读取的效率）
从这个过程可以看出，真正的读写并不依赖于master，在读写的过程中如果master节点出现宕机，短暂性的是不会出现太大的问题
Hbase写入数据流程：
1、当客户端发起一个Put请求时，首先它从hbase:meta表中查出该Put数据最终需要去的HRegionServer；然后客户端将Put请求发送给相应的HRegionServer，在HRegionServer中它首先会将该Put操作写入WAL日志；
2、写完WAL日志文件后，HRegionServer根据Put中的TableName和RowKey找到对应的HRegion，并根据Column Family找到对应的HStore，并将Put写入到该HStore的MemStore中，此时写成功，并返回通知客户端。
9、Regionserver的内存：Memstore & BlockCache
HBase上Regionserver的内存分为两个部分，一部分作为Memstore，主要用来写；另外一部分作为BlockCache，主要用来读。
写请求会先写入Memstore，Regionserver会给每个region提供一个Memstore，当Memstore满128M(可配置)后，会启动flush刷新到磁盘。当Memstore的总大小超过限制时(heapsizehbase.regionserver.global.memstore.upperLimit0.9)——一个Regionserver有多个Region，多个region中memstore的总大小——，会强行启动flush进程，从最大的Memstore开始flush，直到低于限制；
读请求先到Memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上磁盘上读，并把读的结果放入BlockCache。由于BlockCache采用的是LRU策略(Least recently used，最近最少使用)，因此BlockCache达到上限（headsizehfile.block.cache.size0.85）后，会启动淘汰机制，淘汰掉最老的一批数据
在注重读响应时间的应用场景下，可以将BlockCache设置大些，Memstore设置小些，以加大缓存的命中率
10、Hbase的Compaction和Split：
Compaction过程：
Client写入 -》 存入MemStore，一直到MemStore满 -》Flush成一个StoreFile，直至增长到一定阈值 -》触发Compaction合并操作 -》 多个StoreFile合并成一个StoreFile，同时进行版本合并和删除 -》 当StoreFiles Compaction后，逐步形成越来越大的StoreFile -》当个StoreFile大小超过一定阈值后，触发Split操作，把当前Region Split成2个Region，Region会下线，新Split出的2个子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。
HBase只是增加数据，所有的更新和删除操作，都是在Compaction阶段做的，所以用户写操作只需要进入到内存即可立即返回，从而保证I/O高性能；
Compaction：会从一个region的一个store中选择一些Hfile文件进行合并；
—》合并原理：先从这些待合并的数据文件中读出KeyValues，再按照由小到大排列后写入一个新的文件中，之后，这个新生成的文件就会取代之前合并的所有文件对外提供服务；
—》合并类型：Minor Compaction & Major Compaction
Minor Compaction：是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Delete或Expired的Cell。一次Minor Compation的结果是更少并且更大的StoreFile；这个过程实际上是个多路归并的过程，因为HFile的每个文件都是经过归类的，所以合并速度很快，只受到磁盘IO性能的影响；
Major Compaction：是指将所有的StoreFile合并成一个StoreFile，这个过程还会清理三类无意义数据，被删除的数据，TTL过期数据、版本号超过设定版本号的数据；major合并能扫描所有的键/值对，顺序重写全部的数据，重写数据的过程中会略过做了删除标记的数据，多余断言删除此时生效，例如，对于那些超过版本号限制的数据以及生存时间到期的数据，在重写数据时就不再写入磁盘了；所以Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响，因此线上业务都会关闭自动触发Major Compactio功能，改为手动在业务低峰期触发;
minor compaction，轻量级，将符合条件的最早生成的几个storefile合并成一个大的sotrefile文件，它不会删除被标记为“删除”的数据和已过期的数据，并且执行过一次minor合并操作后，还会有多个storefile文件；
major compaction，重要级，把所有的storefile合并成一个单一的storefile文件，在文件合并期间系统会删除标记为“删除”标记的数据和已过期失效的数据，同时会block（阻塞）所有客户端对该操作所属region的请求直到合并完毕，最后删除已合并的storefile文件
—》Compaction本质：使用短时间的IO消耗以及带宽消耗换取后续查询的低延迟；
—》conpact的速度远远跟不上Hfile生产的速度，这样就会使Hfile的数量越来越多，导致读性能急剧下降，为了避免这种情况，在HFile的数量过多的时候，会限制写请求的速度
—》Split和Major Compaction可以手动或者自动触发；
Split：当一个Region太大时，将其分裂成两个Region