目录
1. 什么是 HBase
2. 大数据中为何要使用 HBase（HBase 在大数据中的优势）
3. HBase 与传统的关系数据库的区别
4. RowKey 的设计原则
5. RowKey 如何设计可以避免热点问题
6. HRegionServer 架构
7.HBase 性能优化方法总结
表的设计
写表操作
读表操作
8. Hbase读写流程
hbase的读操作：
hbase的写操作：
9. HBase 物理存储原理
10. HBase 中的 HFile 什么时候要合并成大文件，什么时候拆分成小文件
合并操作的时机对象与作用
拆分（对region进行拆分）
11. HBase 查询快的原因
1. 什么是 HBase
- 是一个高可靠性、高性能、列存储、可伸缩、实时读写的分布式数据库系统。
- 适合于存储非结构化数据，基于列的而不是基于行的模式
2. 大数据中为何要使用 HBase（HBase 在大数据中的优势）
Hadoop可以很好地解决大规模数据的离线批量处理问题，但是，受限于HadoopMapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用的需求
HDFS面向批量访问模式，不是随机访问模式
传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题（分库分表也不能很好解决）
传统关系数据库在数据结构变化时一般需要停机维护；空列浪费存储空间
因此，业界出现了一类面向半结构化数据存储和处理的高可扩展、低写入/查询延迟的系统，例如，键值数据库、文档数据库和列族数据库（如BigTable和HBase等）
HBase已经成功应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中
3. HBase 与传统的关系数据库的区别
数据类型：
关系数据库采用关系模型，具有丰富的数据类型和存储方式，HBase则采用了更加简单的数据模型，它把数据存储为未经解释的字符串
数据操作：
关系数据库中包含了丰富的操作，其中会涉及复杂的多表连接。HBase操作则不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等，因为HBase在设计上就避免了复杂的表和表之间的关系
存储模式：
关系数据库是基于行模式存储的。HBase是基于列存储的，每个列族都由几个文件保存，不同列族的文件是分离的
数据索引：
关系数据库通常可以针对不同列构建复杂的多个索引，以提高数据访问性能。HBase只有一个索引——行键（RowKey），通过巧妙的设计，HBase中的所有访问方法，或者通过行键访问，或者通过行键扫描，从而使得整个系统不会慢下来
数据维护：
在关系数据库中，更新操作会用最新的当前值去替换记录中原来的旧值，旧值被覆盖后就不会存在。而在HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留
可伸缩性：
关系数据库很难实现横向扩展，纵向扩展的空间也比较有限。相反，HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的，能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩
4. RowKey 的设计原则
长度原则：
Rowkey是一个二进制码流，最大长度为64kb，Rowkey的长度被很多开发者建议说设计在10~100个字节，以 byte[]形式保存，一般设置为定长。建议是越短越好，不要超过16字节，原因如下：
- HBase的持久化文件HFile是按照KeyValue存储的，如果Rowkey过长比如500个字节1000万列数据光Rowkey就要占用500*1000万=50亿个字节，将近1G数据，这会极大影响HFile的存储效率；
- MemStore缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率会降低，系统无法缓存更多的数据，这会降低检索效率；
- 目前操作系统都是64位系统，内存8字节对齐，控制在16字节，8字节的整数倍利用了操作系统的最佳特性
需要指出的是不仅Rowkey的长度是越短越好，而且列族名、列名等尽量使用短名字，因为HBase属于列式数据库，这些名字都是会写入到HBase的持久化文件HFile中去，过长的Rowkey、列族、列名都会导致整体的存储量成倍增加。
唯一原则：
必须在设计上保证其唯一性。由于在HBase中数据存储是Key-Value形式，若HBase中同一表插入相同Rowkey，则原先的数据会被覆盖掉(如果表的version设置为1的话)，所以务必保证RowKey的唯一性
排序原则：
HBase 的 RowKey 是按照 ASII 有序排序的，因此我们在设计 RowKey 的时候要充分利用这一点，例如 CSDN 的评论是按照时间倒序的，这时候 RowKey 的设计应与时间有关
散列原则：
我们设计的Rowkey应均匀的分布在各个HBase节点上。拿常见的时间戳举例，假如Rowkey是按系统时间戳的方式递增，Rowkey的第一部分如果是时间戳信息的话将造成所有新数据都在一个RegionServer上堆积的热点现象，也就是通常说的Region热点问题， 热点发生在大量的client直接访问集中在个别RegionServer上（访问可能是读，写或者其他操作），导致单个RegionServer机器自身负载过高，引起性能下降甚至Region不可用，常见的是发生jvm full gc或者显示region too busy异常情况，当然这也会影响同一个RegionServer上的其他Region。
5. RowKey 如何设计可以避免热点问题
Reverse反转：
针对固定长度的Rowkey反转后存储，这样可以使Rowkey中经常改变的部分放在最前面，可以有效的随机Rowkey。
反转Rowkey的例子通常以手机举例，可以将手机号反转后的字符串作为Rowkey，这样的就避免了以手机号那样比较固定开头(137x、15x等)导致热点问题，
这样做的缺点是牺牲了Rowkey的有序性。
Salt加盐：
Salt是将每一个Rowkey加一个前缀，前缀使用一些随机字符，使得数据分散在多个不同的Region，达到Region负载均衡的目标。
比如在一个有4个Region(注：以 [ ,a)、[a,b)、[b,c)、[c, )为Region起至)的HBase表中，
加Salt前的Rowkey：abc001、abc002、abc003
我们分别加上a、b、c前缀，加Salt后Rowkey为：a-abc001、b-abc002、c-abc003，可以看到，加盐前的Rowkey默认会在第2个region中，加盐后的Rowkey数据会分布在3个region中，理论上处理后的吞吐量应是之前的3倍。由于前缀是随机的，读这些数据时需要耗费更多的时间，所以Salt增加了写操作的吞吐量，不过缺点是同时增加了读操作的开销。
Hash散列或者Mod：
用Hash散列来替代随机Salt前缀的好处是能让一个给定的行有相同的前缀，这在分散了Region负载的同时，使读操作也能够推断。确定性Hash(比如md5后取前4位做前缀)能让客户端重建完整的RowKey，可以使用get操作直接get想要的行。
例如将上述的原始Rowkey经过hash处理，此处我们采用md5散列算法取前4位做前缀，结果如下：
9bf0-abc001 （abc001在md5后是9bf049097142c168c38a94c626eddf3d，取前4位是9bf0）
7006-abc002
95e6-abc003
若以前4个字符作为不同分区的起止，上面几个Rowkey数据会分布在3个region中。实际应用场景是当数据量越来越大的时候，
这种设计会使得分区之间更加均衡。
如果Rowkey是数字类型的，也可以考虑Mod方法。
6. HRegionServer 架构
StoreFile
在HRegionServer架构图中，StoreFile是保存实际数据的物理文件，StoreFile是以HFile的形式存储在HDFS上，每个Store会有一个或多个StoreFile，并且数据在每个StoreFile中都是有序的。
MemStore
它是写缓存的意思。由于HFile是要求数据是有序的，要按照存储在HDFS上的数据需要按照rowkey排序，所以数据先存储在MemStore中，排好序后，达到阈值后才会flush到StoreFile中，每次flush生成一个新的StoreFIle。
实现MemStore模型的数据结构是SkipList跳表，跳表它可以实现高效的查询、插入、删除操作。因为跳表本质上是由有序链表构成的，很多KV数据库都会使用跳表实现有序数据集合。所以呢，数据传入MemStore后，会利用跳表实现这些数据的有序。
WAL
WAL，全称是Write Ahead Log，预先写日志的意思。由于数据要经MemStore排序后才能刷写到HFile，但把数据保存在内存中会有很高的概率导致数据丢失的，所以为了解决这个问题，数据会先写在一个叫做Write Ahead Log的文件中，然后再写入MemStore中。所以当系统出现故障的时候，数据就可以通过这个日志文件重建，避免数据丢失。
BlockCache
它是读缓存的意思。每次查询出来的数据会先缓存在BlockCache中，方便下次查询数据。
7.HBase 性能优化方法总结
表的设计
Pre-Creating Regions（预分区）
默认情况下，在创建HBase表的时候会自动创建一个region分区，当导入数据的时候，所有的HBase客户端都向这一个region写数据，直到这个region足够大了才进行切分。一种可以加快批量写入速度的方法是通过预先创建一些空的regions，这样当数据写入HBase时，会按照region分区情况，在集群内做数据的负载均衡。
RowKey
HBase中row key用来检索表中的记录，支持以下三种方式：
- 通过单个row key访问：即按照某个row key键值进行get操作；
- 通过row key的range进行scan：即通过设置startRowKey和endRowKey，在这个范围内进行扫描；
- 全表扫描：即直接扫描整张表中所有行记录。
在HBase中，row key可以是任意字符串，最大长度64KB，实际应用中一般为10~100bytes，存为byte[]字节数组，一般设计成定长的。
row key是按照字典序存储，因此，设计row key时，要充分利用这个排序特点，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块。
举个例子：如果最近写入HBase表中的数据是最可能被访问的，可以考虑将时间戳作为row key的一部分，由于是字典序排序，所以可以使用Long.MAX_VALUE - timestamp作为row key，这样能保证新写入的数据在读取时可以被快速命中。
Column Family
不要在一张表里定义太多的column family。目前Hbase并不能很好的处理超过2~3个column family的表。因为某个column family在flush的时候，它邻近的column family也会因关联效应被触发flush，最终导致系统产生更多的I/O。
In Memory
创建表的时候，可以通过HColumnDescriptor.setInMemory(true)将表放到RegionServer的缓存中，保证在读取的时候被cache命中。
Max Version
创建表的时候，可以通过HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本，如果只需要保存最新版本的数据，那么可以设置setMaxVersions(1)。
Time To Live
创建表的时候，可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命期，过期数据将自动被删除，例如如果只需要存储最近两天的数据，那么可以设置setTimeToLive(2 * 24 * 60 * 60)。
Compact & Split
在HBase中，数据在更新时首先写入WAL 日志(HLog)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时， 系统会在zookeeper中记录一个redo point，表示这个时刻之前的变更已经持久化了(minor compact)。
StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(major compact)，将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行分割(split)，等分为两个StoreFile。
由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的StoreFile和MemStore，将它们按照row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，通常合并过程还是比较快的。
实际应用中，可以考虑必要时手动进行major compact，将同一个row key的修改进行合并形成一个大的StoreFile。同时，可以将StoreFile设置大些，减少split的发生。
写表操作
多HTable并发写
创建多个HTable客户端用于写操作，提高写数据的吞吐量
HTable参数设置
（1）Auto Flush：
通过调用HTable.setAutoFlush(false)方法可以将HTable写客户端的自动flush关闭，这样可以批量写入数据到HBase，而不是有一条put就执行一次更新，只有当put填满客户端写缓存时，才实际向HBase服务端发起写请求。默认情况下auto flush是开启的。
（2）Write Buffer：
通过调用HTable.setWriteBufferSize(writeBufferSize)方法可以设置HTable客户端的写buffer大小，如果新设置的buffer小于当前写buffer中的数据时，buffer将会被flush到服务端。其中，writeBufferSize的单位是byte字节数，可以根据实际写入数据量的多少来设置该值。
（3）WAL Flag：
在HBase中，客户端向集群中的RegionServer提交数据时（Put/Delete操作），首先会先写WAL（Write Ahead Log）日志（即HLog，一个RegionServer上的所有Region共享一个HLog），只有当WAL日志写成功后，再接着写MemStore，然后客户端被通知提交数据成功；如果写WAL日志失败，客户端则被通知提交失败。这样做的好处是可以做到RegionServer宕机后的数据恢复。
因此，对于相对不太重要的数据，可以在Put/Delete操作时，通过调用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函数，放弃写WAL日志，从而提高数据写入的性能。
值得注意的是：谨慎选择关闭WAL日志，因为这样的话，一旦RegionServer宕机，Put/Delete的数据将会无法根据WAL日志进行恢复。
批量写
通过调用HTable.put(Put)方法可以将一个指定的row key记录写入HBase，同样HBase提供了另一个方法：通过调用HTable.put(List<Put>)方法可以将指定的row key列表，批量写入多行记录，这样做的好处是批量执行，只需要一次网络I/O开销，这对于对数据实时性要求高，网络传输RTT高的情景下可能带来明显的性能提升。
多线程并发写
在客户端开启多个HTable写线程，每个写线程负责一个HTable对象的flush操作，这样结合定时flush和写buffer（writeBufferSize），可以既保证在数据量小的时候，数据可以在较短时间内被flush（如1秒内），同时又保证在数据量大的时候，写buffer一满就及时进行flush。
读表操作
多HTable并发读
创建多个HTable客户端用于读操作，提高读数据的吞吐量
HTable参数设置
（1）Scanner Caching
hbase.client.scanner.caching配置项可以设置HBase scanner一次从服务端抓取的数据条数，默认情况下一次一条。通过将其设置成一个合理的值，可以减少scan过程中next()的时间开销，代价是scanner需要通过客户端的内存来维持这些被cache的行记录。
有三个地方可以进行配置：
1）在HBase的conf配置文件中进行配置；
2）通过调用HTable.setScannerCaching(int scannerCaching)进行配置；
3）通过调用Scan.setCaching(int caching)进行配置。
三者的优先级越来越高。
（2）Scan Attribute Selection
scan时指定需要的Column Family，可以减少网络传输数据量，否则默认scan操作会返回整行所有Column Family的数据。
（3）Close ResultScanner
通过scan取完数据后，记得要关闭ResultScanner，否则RegionServer可能会出现问题（对应的Server资源无法释放）。
批量读
通过调用HTable.get(Get)方法可以根据一个指定的row key获取一行记录，同样HBase提供了另一个方法：通过调用HTable.get(List<Get>)方法可以根据一个指定的row key列表，批量获取多行记录，这样做的好处是批量执行，只需要一次网络I/O开销，这对于对数据实时性要求高而且网络传输RTT高的情景下可能带来明显的性能提升。
多线程并发读
在客户端开启多个HTable读线程，每个读线程负责通过HTable对象进行get操作。下面是一个多线程并发读取HBase
缓存查询结果
对于频繁查询HBase的应用场景，可以考虑在应用程序中做缓存，当有新的查询请求时，首先在缓存中查找，如果存在则直接返回，不再查询HBase；否则对HBase发起读请求查询，然后在应用程序中将查询结果缓存起来。至于缓存的替换策略，可以考虑LRU等常用的策略。
Blockcache
HBase上Regionserver的内存分为两个部分，一部分作为Memstore，主要用来写；另外一部分作为BlockCache，主要用于读。
写请求会先写入Memstore，Regionserver会给每个region提供一个Memstore，当Memstore满（新版128MB，老版64MB）以后，会启动 flush刷新到磁盘。当Memstore的总大小超过限制时（heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9），会强行启动flush进程，从最大的Memstore开始flush直到低于限制。
读请求先到Memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上读，并把读的结果放入BlockCache。由于BlockCache采用的是LRU策略，因此BlockCache达到上限(heapsize * hfile.block.cache.size * 0.85)后，会启动淘汰机制，淘汰掉最老的一批数据。
一个Regionserver上有一个BlockCache和N个Memstore，它们的大小之和不能大于等于heapsize * 0.8，否则HBase不能启动。默认BlockCache为0.2，而Memstore为0.4。对于注重读响应时间的系统，可以将 BlockCache设大些，比如设置BlockCache=0.4，Memstore=0.39，以加大缓存的命中率。
8. Hbase读写流程
hbase的读操作：
ZooKeeper---meta--regionserver--region--memstore--storefile
- 首先从zookerper找到meta表的region的位置，然后读取meta表中的数据。而meta中又存储了用户表的region信息
- 根据namespace、表名和rowkey根据meta表中的数据找到写入数据对于的region信息
- 然后找到对于的regionserver
- 查找对应的region
- 先从Memstore找数据，如果没有，再到StoreFile上读
hbase的写操作：
ZooKeeper---meta--regionserver--1、Hlog 1、MemStore--storefile
- 首先从zookerper找到meta表的region的位置，然后读取meta表中的数据。而meta中又存储了用户表的region信息
- 根据namespace、表名和rowkey根据meta表中的数据找到写入数据对于的region信息
- 然后找到对于的regionserver
- 把数据分别写到Hlog和memstore各一份
- 当memstore达到阈值后把数据刷成一个storefile文件，当compact后，逐渐形成越来越大的storefile后触发spilt，把当前的StoreFile分成两个，这里相当于把一个大的region分割成两个region
- 若MemStore中的数据有丢失，则可以从HLog上恢复，当多个StoreFile文件达到一定的大小后，会触发Compact合并操作，合并为一个StoreFile，这里同时进行版本的合并和数据删除
9. HBase 物理存储原理
存储原理：
Hbase 里的一个 Table 在行的方向上分割为多个 HRegion，即HBase中一个表的数据会被划分成很多的 HRegion，HRegion 可以动态扩展并且 HBase 保证 HRegion 的负载均衡。HRegion 实际上是行键排序后的按规则分割的连续的存储空间
拆分流程图：
HRegion是按大小分割的，在没有设定预分区的情况下，每个表一开始只有一个HRegion，随着数据不断插入表，HRegion不断增大，当增大到一个阀值的时候，HRegion就会等分两个新的HRegion。当table中的行不断增多，就会有越来越多的Hregion
一张 Hbase 表，可能有多个 HRegion，每个 HRegion 达到一定大小（默认是10GB）时，进行分裂。
按照现在主流硬件的配置，每个 HRegion的大小可以是1～20GB。这个大小由hbase.hregion.max.filesize 指定，默认为10GB。HRegion 的拆分和转移是由 HBase（HMaster）自动完成的，用户感知不到。
HRegion 是 Hbase 中分布式存储和负载均衡的最小单元
HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元。
事实上，HRegion由一个或者多个HStore组成，每个Hstore保存一个columns family。
每个HStore又由一个memStore和0至多个StoreFile组成，StoreFile以HFile格式保存在HDFS上，如图：
总结：
HRegion是分布式的存储最小单位，StoreFile(Hfile)是存储最小单位
10. HBase 中的 HFile 什么时候要合并成大文件，什么时候拆分成小文件
合并操作的时机对象与作用
合并的时机：
- hfile文件进行更新、删除操作时，每操作一次生成一个hfile文件，当有大量更新或删除操作后，需要对hfile文件进行合并，生成一个新的hfile文件；
- 新文件生成之后，以前操作留存的文件就会被清理，可以释放资源，节省空间；
- 当进行大量更新或删除操作后，region管理范围变小，需要对region进行合并；
- region合并后，表结构也要进行相应的更改，表也要进行合并（释放资源）（可自动合并或手动合并，因其占用大量资源，一般选择周末、节假日这种非工作日进行）；
- 当属性中设置了DDL（过期时间）后，一段时间之后，hfile文件中的数据会过期，hbase会自动将文件进行合并，释放资源。
合并的对象：
hfile文件、region、表。
合并的作用：
对更新、删除后的数据进行有效管理；释放资源。
拆分（对region进行拆分）
为什么进行拆分
- HBase是以表的形式存储数据的，一个表被划分成多个region，分布咋不同的RegionServer中，单个region只能分布在一个从节点上，不能跨节点存储；
- 当表中的数据量增多，region管理的数据也会相应增加，默认每个region的大小是128M；
- 当数据量太多，处理读/写请求出现热点问题的概率会增加，当所有请求都分到了一个region上，region所在的节点可能会因负载过重而宕机；
- 此时，需要进行region的拆分，分配到不同的节点上，同时对数据进行管理。
拆分的方式：
（1）ConstantSizeRegionSplitPolicy：0.94版本前默认拆分方式
当region的大小大于某个阈值(hbase.hregion.max.filesize=10G)之后就会触发切分，一个region会等分为2个region。但是这种切分策略却有相当大的弊端：切分策略对于大表和小表没有明显的区分。阈值设置较大对大表比较友好，但是小表就有可能不会触发分裂，极端情况下可能就1个，这对业务来说并不是什么好事。如果设置较小则对小表友好，但一个大表就会在整个集群产生大量的region，这对于集群的管理、资源使用、failover来说都不是一件好事。
（2）IncreasingToUpperBoundRegionSplitPolicy：0.94版本~2.0版本默认拆分方式
切分策略稍微有点复杂，总体看和ConstantSizeRegionSplitPolicy思路相同，一个region大小大于设置阈值就会触发切分。但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值，而是会在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系。
（3）SteppingSplitPolicy：2.0版本之后默认拆分方式
相比之前的IncreasingToUpperBoundRegionSplitPolicy，它会简单一些，依然和待分裂region所属表在当前regionserver上的region个数有关系，如果region个数等于1，切分阈值为flush size * 2，否则为MaxRegionFileSize。这种切分策略对于大集群中的大表、小表会比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不会再产生大量的小region，而是适可而止。
11. HBase 查询快的原因
主要原因是由其架构和底层的数据结构决定的，即由 LSM-Tree(Log-Structured Merge-Tree) + HTable(region分区) + Cache 决定——客户端可以直接定位到要查数据所在的 HRegion server 服务器，然后直接在服务器的一个 region 上查找要匹配的数据，并且这些数据部分是经过 cache 缓存的。
由于 HBase 会将数据保存到内存中，在内存中的数据是有序的，如果内存空间满了，会刷写到 HFile 中，而在HFile中保存的内容也是有序的。当数据写入 HFile 后，内存中的数据会被丢弃。
HFile 文件为磁盘顺序读取做了优化，按页存储。下图展示了在内存中多个块存储并归并到磁盘的过程，合并写入会产生新的结果块，最终多个块被合并为更大块。
多次刷写后会产生很多小文件，后台线程会合并小文件组成大文件，这样磁盘查找会限制在少数几个数据存储文件中。HBase 的写入速度快是因为它其实并不是真的立即写入文件中，而是先写入内存，随后异步刷入HFile。所以在客户端看来，写入速度很快。另外，写入时候将随机写入转换成顺序写，数据写入速度也很稳定。
而读取速度快是因为它使用了 LSM 树型结构，而不是B或B+树。磁盘的顺序读取速度很快，但是相比而言，寻找磁道的速度就要慢很多。HBase 的存储结构导致它需要磁盘寻道时间在可预测范围内，并且读取与所要查询的 rowkey 连续的任意数量的记录都不会引发额外的寻道开销。比如有5个存储文件，那么最多需要5次磁盘寻道就可以。而关系型数据库，即使有索引，也无法确定磁盘寻道次数。而且，HBase 读取首先会在缓存（BlockCache）中查找，它采用了 LRU（最近最少使用算法），如果缓存中没找到，会从内存中的 MemStore 中查找，只有这两个地方都找不到时，才会加载 HFile 中的内容，而上文也提到了读取 HFile 速度也会很快，因为节省了寻道开销。