共计 8670 个字符，预计需要花费 22 分钟才能阅读完成。
1 HBase 表结构设计调优
1.1 Row Key 设计
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，这样能保障新写入的数据在读取时能够被疾速命中。
Rowkey 规定：
rowkey 是一个二进制码流，长度越小越好，个别不超过 16 个字节，次要出于以下思考：
数据的长久化文件 HFile 中是依照 KeyValue 存储的，即你写入的数据可能是一个 rowkey 对应多个列族，多个列，然而理论的存储是每个列都会对应 rowkey 写一遍，即这一条数据有多少个列，就会存储多少遍 rowkey，这会极大影响 HFile 的存储效率；
MemStore 和 BlockCache 都会将缓存局部数据到内存，如果 Rowkey 字段过长内存的无效利用率会升高，零碎将无奈缓存更多的数据，这会升高检索效率。
目前操作系统个别都是 64 位零碎，内存 8 字节对齐。管制在 16 个字节，8 字节的整数倍，利用操作系统的最佳个性。
Rowkey 的设计是要依据理论业务来，常拜访的数据放到一起。
对于须要批量获取的数据，比方某一天的数据，能够把一整天的数据存储在一起，即把 rowkey 的高位设计为工夫戳，这样在读数据的时候就能够指定 start rowkey 和 end rowkey 做一个 scan 操作，因为高位雷同的 rowkey 会存储在一起，所以这样读是一个程序读的过程，会比拟高效。
然而这样有一个很显著的问题，违反了“rowkey 散列设计”准则，很可能会呈现数据歪斜问题。所以说没有最好的设计，具体如何衡量就得看理论业务场景了。
散列性
咱们已知 HBase 的 Rowkey 是依照字典序排列的，而数据分布在 RegionServer 上的形式是做高位哈希，所以如果咱们的 rowkey 首位存在大量反复的值那么很可能会呈现数据歪斜问题，对于数据歪斜的问题上面会具体阐明，总之，原则上就是 rowkey 的首位尽量为散列。
a) 取反 001 002 变为 100 200
b) Hash
唯一性：数据写入的时候两条数据的 rowkey 不能雷同
1.2 Column Family
不要在一张表里定义太多的 column family。
目前 Hbase 并不能很好的解决超过 2~3 个 column family 的表。次要有以下两个方面思考：
HBase 架构
如图，咱们已知 Region 由一个或者多个 Store 组成，每个 Store 保留一个列族。当同一个 Region 内，如果存在大小列族的场景，即一个列族一百万行数据，另一个列族一百行数据，此时总数据量达到了 Region 决裂的阈值，那么不光那一百万行数据会被散布到不同的 Region 上，小列族的一百行数据也会散布到不同 region，问题就来了，扫描小列族都须要去不同的 Region 上读取数据，显然会影响性能。
在 memstore flush 时，某个大的 column family 在 flush 的时候，它邻近的小 column family 也会因关联效应被触发 flush，只管小列族的 memstore 还没有达到 flush 的阈值，这样会导致小文件问题，也使得零碎产生更多的 I/O。
1.3 表参数调优
Pre-Creating Regions(预分区)
默认状况下，在创立 HBase 表的时候会主动创立一个 region 分区，当导入数据的时候，所有的 HBase 客户端都向这一个 region 写数据，直到这个 region 足够大了才进行切分。这样的局限是很容易造成数据歪斜，影响读写效率。
预分区是一种比拟好的解决这些问题的计划，通过事后创立一些空的 regions，定义好每个 region 存储的数据的范畴，这样当数据写入 HBase 时，会依照 region 分区状况，在集群内做数据的负载平衡。
指定 rowkey 宰割的点，手动设定预分区
create ‘table1′,’f1’,SPLITS => [‘1000’, ‘2000’, ‘3000’, ‘4000’]
rowkey 前缀齐全随机
create ‘table2′,’f1’, {NUMREGIONS => 8 , SPLITALGO => ‘UniformSplit’}
rowkey 是十六进制的字符串作为前缀的
create ‘table3′,’f1’, {NUMREGIONS => 10, SPLITALGO => ‘HexStringSplit’}
BLOOMFILTER 布隆过滤器
默认值为 NONE，布隆过滤器的作用是能够过滤掉大部分不存在指标查问值的 HFile（即略去不必要的磁盘扫描），能够有助于升高读取提早。
配置形式：create ‘table’,{BLOOMFILTER =>’ROW |ROWCOL‘}
ROW，示意对 Rowkey 进行布隆过滤，Rowkey 的哈希值在每次写入行时会被增加到布隆过滤器中，在读的时候就会通过布隆过滤器过滤掉大部分有效指标。
ROWCOL 示意行键 + 列簇 + 列的哈希将在每次插入行时增加到布隆。
VERSIONS 版本
默认值为 1，大数据培训咱们晓得 HBase 是一个多版本共存的数据库，屡次写入雷同的 rowkey + cf + col 则会产生多个版本的数据，在有些场景下多版本数据是有用的，须要把写入的数据做一个比照或者其余操作；然而如果咱们不想保留那么多数据，只是想要笼罩原有值，那么将此参数设为 1 能节约 2/3 的空间。所以第一步搞清楚你的需要，是否须要多版本共存。
配置形式：create ‘table’,{VERSIONS=>’2′}
COMPRESSION 压缩形式
默认值为 NONE，罕用的压缩形式是 Snappy 和 LZO，它们的特点是用于热数据压缩，占用 CPU 少，解压 / 压缩速度较其余压缩形式快，然而压缩率较低。Snappy 与 LZO 相比，Snappy 整体性能优于 LZO，解压 / 压缩速度更快，然而压缩率稍低。各种压缩各有不同的特点，须要依据需要作出抉择。另外，不晓得选什么的状况下，我倡议选 Snappy，毕竟在 HBase 这种随机读写的场景，解压 / 压缩速度是比拟重要的指标。
配置形式：create ‘table’,{NAME=>’info’,COMPRESSION=>’snappy’}
Time To Live
创立表的时候，能够通过 HColumnDescriptor.setTimeToLive(int timeToLive) 设置表中数据的存储生命期，默认值为 Integer.MAX_VALUE，大略是 64 年，即约等于不过期，这个参数是阐明该列族数据的存活工夫。超过存活工夫的数据将在表中不再显示，待下次 major compact 的时候再彻底删除数据。须要依据理论状况配置。
配置形式：create ‘table’,{NAME=>’info’, FAMILIES => [{NAME => ‘cf’, MIN_VERSIONS => ‘0’, TTL => ‘500’}]}
Memory
创立表的时候，能够通过 HColumnDescriptor.setInMemory(true) 将表放到 RegionServer 的缓存中，保障在读取的时候被 cache 命中。
BLOCKCACHE 是读缓存，如果该列族数据程序拜访偏多，或者为不常拜访的冷数据，那么能够敞开这个 blockcache，这个配置须要审慎配置，因为对读性能会有很大影响。
配置形式：create ‘mytable’,{NAME=>’cf’,BLOCKCACHE=>’false’}
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 的产生。
hbase 为了避免小文件（被刷到磁盘的 menstore）过多，以保障保障查问效率，hbase 须要在必要的时候将这些小的 store file 合并成绝对较大的 store file，这个过程就称之为 compaction。在 hbase 中，次要存在两种类型的 compaction：minor compaction 和 major compaction。
minor compaction: 是较小的、很少文件的合并。
minor compaction 的运行机制要简单一些，它由一下几个参数独特决定：
hbase.hstore.compaction.min : 默认值为 3，示意至多须要三个满足条件的 store file 时，minor compaction 才会启动
hbase.hstore.compaction.max 默认值为 10，示意一次 minor compaction 中最多选取 10 个 store file
hbase.hstore.compaction.min.size 示意文件大小小于该值的 store file 肯定会退出到 minor compaction 的 store file 中
hbase.hstore.compaction.max.size 示意文件大小大于该值的 store file 肯定会被 minor compaction 排除
hbase.hstore.compaction.ratio 将 store file 依照文件年龄排序（older to younger），minor compaction 总是从 older store file 开始抉择
major compaction 的性能是将所有的 store file 合并成一个，触发 major compaction 的可能条件有：
major_compact 命令、
majorCompact() API、
region server 主动运行
相干参数：hbase.hregion.majoucompaction 默认为 24 小时、hbase.hregion.majorcompaction.jetter 默认值为 0.2 避免 region server 在同一时间进行 major compaction
hbase.hregion.majorcompaction.jetter 参数的作用是：对参数 hbase.hregion.majoucompaction 规定的值起到浮动的作用，如果两个参数都为默认值 24 和 0.2，那么 major compact 最终应用的数值为：19.2~28.8 这个范畴。
此外，hbase.regionserver.regionSplitLimit 最大的 region 数量，hbase.hregion.max.filesize 每个 region 的最大限度，这 2 个参数是用来管制 Region 决裂的。
在生产环境下，这两个操作个别都会设置为禁止主动合并和禁止主动 split，因为这两步的操作都是比拟消耗资源的，主动会让操作工夫不可控，如果是在业务忙碌的工夫做了这些操作造成的影响是十分大的，所以个别配置禁止主动，转为本人治理，在零碎没那么忙碌的早晨手动登程相干操作。
2 HBase 写调优
2.1 多 HTable 并发写
创立多个 HTable 客户端用于写操作，进步写数据的吞吐量。举一个例子：
2.2 HTable 写参数设置
2.2.1 Auto Flush
通过调用 HTable.setAutoFlush(false) 办法能够将 HTable 写客户端的主动 flush 敞开，这样能够批量写入数据到 HBase，而不是有一条 put 就执行一次更新，只有当 put 填满客户端写缓存时，才理论向 HBase 服务端发动写申请。默认状况下 auto flush 是开启的。
2.2.2 Write Buffer
通过调用 HTable.setWriteBufferSize(writeBufferSize) 办法能够设置 HTable 客户端的写 buffe r 大小，如果新设置的 buffer 小于以后写 buffer 中的数据时，buffer 将会被 flush 到服务端。其中，writeBufferSize 的单位是 byte 字节数，能够依据理论写入数据量的多少来设置该值。
2.2.3 WAL Flag
在 HBae 中，客户端向集群中的 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 日志进行复原。
2.3 批量写
通过调用 HTable.put(Put) 办法能够将一个指定的 row key 记录写入 HBase，同样 HBase 提供了另一个办法：通过调用 HTable.put(List) 办法能够将指定的 row key 列表，批量写入多行记录，这样做的益处是批量执行，只须要一次网络 I/O 开销，这对于对数据实时性要求高，网络传输 RTT 高的情景下可能带来显著的性能晋升。
2.4 多线程并发写
在客户端开启多个 HTable 写线程，每个写线程负责一个 HTable 对象的 flush 操作，这样联合定时 flush 和写 buffer（writeBufferSize），能够既保证在数据量小的时候，数据能够在较短时间内被 flush（如 1 秒内），同时又保障在数据量大的时候，写 buffer 一满就及时进行 flush。上面给个具体的例子：
3 HBase 读调优
3.1 多 HTable 并发写
创立多个 HTable 客户端用于读操作，进步读数据的吞吐量，举一个例子：
3.2 HTable 读参数设置
3.2.1 Scanner Caching
hbase.client.scanner.caching 配置项能够设置 HBase scanner 一次从服务端抓取的数据条数，默认状况下一次一条。大数据培训通过将其设置成一个正当的值，能够缩小 scan 过程中 next() 的工夫开销，代价是 scanner 须要通过客户端的内存来维持这些被 cache 的行记录。
有三个中央能够进行配置：
在 HBase 的 conf 配置文件中进行配置；
通过调用 HTable.setScannerCaching(int scannerCaching) 进行配置；
通过调用 Scan.setCaching(int caching) 进行配置。
三者的优先级越来越高。
3.2.2 Scan Attribute Selection
scan 时指定须要的 Column Family，能够缩小网络传输数据量，否则默认 scan 操作会返回整行所有 Column Family 的数据。
3.2.3 Close ResultScanner
通过 scan 取完数据后，记得要敞开 ResultScanner，否则 RegionServer 可能会呈现问题（对应的 Server 资源无奈开释）。
3.3 批量读
通过调用 HTable.get(Get) 办法能够依据一个指定的 row key 获取一行记录，同样 HBase 提供了另一个办法：通过调用 HTable.get(List) 办法能够依据一个指定的 row key 列表，批量获取多行记录，这样做的益处是批量执行，只须要一次网络 I/O 开销，这对于对数据实时性要求高而且网络传输 RTT 高的情景下可能带来显著的性能晋升。
3.4 多线程并发读
在客户端开启多个 HTable 读线程，每个读线程负责通过 HTable 对象进行 get 操作。
上面是一个多线程并发读取 HBase，获取某电商网站上店铺一天内各分钟 PV 值的例子：
3.5 缓存查问后果
对于频繁查问 HBase 的利用场景，能够思考在应用程序中做缓存，当有新的查问申请时，首先在缓存中查找，如果存在则间接返回，不再查问 HBase；否则对 HBase 发动读申请查问，而后在应用程序中将查问后果缓存起来，下次便可间接在缓存中查找。至于缓存的替换策略，能够思考 LRU 等罕用的策略。
3.6 BlockCache
HBase 上 Regionserver 的内存分为两个局部，一部分作为 Memstore，次要用来写；另外一部分作为 BlockCache，次要用于读。
写申请会先写入 Memstore，Regionserver 会给每个 region 提供一个 Memstore，当 Memstore 满 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，以加大缓存的命中率。
无关 BlockCache 机制，感兴趣的小伙伴能够去深刻理解！
4 如何解决数据歪斜问题？
数据歪斜是分布式畛域一个比拟常见的问题，在大量客户端申请拜访数据或者写入数据的时候，只有少数几个或者一个 RegionServer 做出响应，导致该服务器的负载过高，造成读写效率低下，而此时其余的服务器还是处于闲暇的状态。
造成这种状况次要的起因就是数据分布不平均，可能是数据量散布不平均，也可能是冷热数据分布不平均。而蹩脚的 rowkey 设计就是产生热点即数据歪斜的源头，所以这里会具体说说防止数据歪斜的 rowkey 设计办法。
加盐：加盐即在本来的 rowkey 后面加上随机的一些值。
随机数：加随机数这种形式在各种材料中常常会被提到，就是在 rowkey 的后面减少随机数来打散 rowkey 在 region 的散布，然而我感觉这不是一种好的抉择，甚至都不能作为一种抉择，因为 HBase 的设计是只有 rowkey 是索引，rowkey 都变成随机的了，读数据只能做性能极低的全表扫描了。总之不举荐。
哈希：哈希的形式显著比随机数更好，哈希会使同一行永远用一个前缀加盐。同样能够起到打散 rowkey 在 region 的散布的目标，使负载扩散到整个集群，最重要读是能够预测的。应用确定的哈希能够让客户端重构残缺的 rowkey，能够应用 get 操作精确获取某一个行数据。
反转：反转即把低位的随机数反转到高位。比方手机号码或者工夫戳的反转，高位根本固定是 1 结尾的，而末位是随机的。这种同样是一种比拟惯例的形成散列的形式。
hbase 预分区：预分区下面曾经提到过，这种形式对于解决数据量散布不平均，和冷热数据分布不平均都是有肯定成果的，然而须要对业务的利用场景做好精确的预判。