HBa读写性能优化
⼀个系统上线之后，开发和调优将会⼀直伴随在系统的整个⽣命周期中，HBa也不例外。下⾯我们要学习如何进⾏HBa读写性能调优，以获取最⼤的读写效率。ceo全称
HBa写⼊优化
客户端优化george clooney
批量写
采⽤批量写，可以减少客户端到RegionServer之间的RPC的次数，提⾼写⼊性能。批量写请求要么全部成功返回，要么抛出异常。
HTable.put(List<Put>);
异步批量提交
如果业务可以接受异常情况下丢失少量数据，可以使⽤异步批量提交⽅式提交请求。
⽤户提交写请求之后，数据会先写⼊客户端缓存，并返回⽤户写⼊成功（此时数据并为提交到RegionServer），当客户端缓存达到阈值（默认2M，可通过hba.client.write.buffer配置）时才会批量提交给RegionServer。需要注意的是，在某些情况下客户端异常的情况下缓存数据有可能丢失。
HTable.tWriteBufferSize(writeBufferSize); // 设置缓存⼤⼩
custom是什么意思
HTable.tAutoFlush(fal);
多线程并发写
客户端开启多个HTable写线程，每个写线程负责⼀个HTable对象的flush操作，这样结合定时flush和写buffer，可以即保证在数据量⼩的时候，数据可以在较短时间内被flush，同时⼜保证在数据量⼤的时候，写buffer⼀满就即使进⾏flush。
使⽤BulkLoad写⼊
在HBa中数据都是以HFile形式保存在HDFS中的，当有⼤量数据需要写⼊到HBa的时候，可以采⽤BulkLoad⽅式完成。
使⽤MapReduce或者Spark直接⽣成HFile格式的数据⽂件，然后再通过RegionServer将HFile数据⽂件移动到相应的Region上去。
写数据表设计调优
COMPRESSION
配置数据的压缩算法，这⾥的压缩是HFile中block级别的压缩。对于可以压缩的数据，配置压缩算法可以有效减少磁盘的IO，从⽽达到提⾼性能的⽬的。但是并不是所有数据都可以进⾏有效压缩，如图⽚，因为图⽚⼀般是已经压缩后的数据，所以压缩效果有限。常⽤的压缩算法是SNAPPY，因为它有较好的压缩和解压速度和可以接受的压缩率。
IN_MEMORY
配置表的数据优先缓存在内存中，这样可以有效提升读取的性能。适合⼩表，⽽且需要频繁进⾏读取操作的。
预分区
在HBa中数据是分布在各个Region中的，每个Region都负责⼀个起始RowKey和结束Rowkey的范围，在向HBa中写数据的时候，会根据RowKey请求到对应的Region上，如果写请求都集中在某⼀个Region或某⼏个Region上的时候，性能肯定不如写请求均匀分布在各个Region上好。默认情况下，创建的HBa的只有⼀个Region分区，会随着数据量的变⼤，进⾏split，拆分成多个Region，最开始的性能肯定会很不好
同事用英语怎么说
建议在设计HBa的的时候，进⾏预分区，并设计⼀个良好的Rowkey⽣成规则（关于RowKey设计，
可以参考《⼀篇⽂章带你快速搞懂HBa RowKey 设计》），尽量将数据分散到各个Region上，那样在进⾏HBa的读写的时候，对性能会有很好的改善。
合理设置WAL存储级别
数据在写⼊HBa的时候，先写WAL，再写⼊缓存。通常情况下写缓存延迟很低，WAL机制⼀⽅⾯是为了确保数据即使写⼊缓存后数据丢失也可以通过WAL恢复，另⼀⽅⾯是为了集群之间的复制。默认WAL机制是开启的，并且使⽤的是同步机制写WAL。
如果业务不特别关⼼异常情况下部分数据的丢失，⽽更关⼼数据写⼊吞吐量，可考虑关闭WAL写，这样可以提升2~3倍数据写⼊的吞吐量。
如果业务不能接受不写WAL，但是可以接受WAL异步写⼊，这样可以带了1~2倍性能提升。
HBa中可以通过设置WAL的持久化等级决定是否开启WAL机制、以及HLog的落盘⽅式。
WAL的持久化等级分为如下四个等级：
1. SKIP_WAL：只写缓存，不写HLog⽇志。这种⽅式因为只写内存，因此可以极⼤的提升写⼊性能，但是数据有丢失的风险。在实际应⽤过程中并不
建议设置此等级，除⾮确认不要求数据的可靠性。
2. ASYNC_WAL：异步将数据写⼊HLog⽇志中。英语六级成绩查询2021
3. SYNC_WAL：同步将数据写⼊⽇志⽂件中，需要注意的是数据只是被写⼊⽂件系统中，并没有真正落盘，默认。
4. FSYNC_WAL：同步将数据写⼊⽇志⽂件并强制落盘。最严格的⽇志写⼊等级，可以保证数据不会丢失，但是性能相对⽐较差。
同样，除了在创建表的时候直接设置WAL存储级别，也可以通过客户端设置WAL持久化等级，代码：
put.tDurability(Durability.SYNC_WAL);
HBa读取优化
客户端优化
批量get请求
使⽤批量请求，可以减少RPC的次数，显著提⾼吞吐量。需要注意的是，批量get请求要么成功返回所
有请求数据，要么抛出异常。
Result[] re= (List<Get> gets);
合理设置scan缓存⼤⼩
⼀次scan可能会返回⼤量数据，但是实际客户端发起⼀次scan请求，并不会将所有数据⼀次性加载到本地，⽽是分成多次RPC请求进⾏加载，这样设计⼀⽅⾯是因为⼤量数据请求可能会导致⽹络带宽严重消耗进⽽影响其他业务，另⼀⽅⾯是有可能因为数据量太⼤导致客户端发⽣OOM。所以采⽤先加载⼀部分数据到本地，然后进⾏遍历，每次加载⼀部分数据，如此往复，直⾄所有数据加载完成。数据加载到本地就存放在scan缓存中，默认100。
增⼤scan的缓存，可以让客户端减少⼀次scan的RPC次数，从⽽从整体上提升数据读取的效率。
scan.tCaching(int caching); //⼤scan可以设置为1000
指定请求列族或者列名
HBa是列族数据库，同⼀列族的数据存储在⼀块，不同列族是分开存储的，如果⼀个表由多个列族，只是根据RowKey⽽不指定列族进⾏检索的话，不同列族的数据需要独⽴进⾏检索，性能必然会⽐指定列族的查询差的多。
此外指定请求的列的话，不需要将整个列族的所有列的数据返回，这样就减少了⽹路IO。
scan.addColumn();headache
设置只读Rowkey过滤器
在只需要Rowkey数据时，可以为Scan添加⼀个只读取Rowkey的filter（FirstKeyOnlyFilter或KeyOnlyFilter）。
关闭ResultScanner
在使⽤Scanner之后，记得关闭，否则它会和服务器端⼀直保持连接，资源⽆法释放，从⽽导致服务端的某些资源不可⽤。
scanner.clo();
离线计算访问HBa建议禁⽤缓存
口腔医师培训班当离线访问HBa时，往往会对HBa表进⾏扫描，此时读取的数据没有必要存放在BlockCache中，否则会降低扫描的效率。
scan.tBlockCache(fal);
建议在对HBa表进⾏扫描时禁⽤缓存。
对于频繁查询HBa的应⽤场景不需要禁⽤缓存，并且可以考虑在应⽤程序和HBa之间加⼀层缓存系统（如Redis），先查询缓存，缓存没有命中再去查询HBa。
读数据表设计调优
COMPRESSION
同写性能优化COMPRESSION部分。
BLOCKSIZE
配置HFile中block块的⼤⼩，不同的block⼤⼩，可以影响HBa读写数据的效率。越⼤的block块，配置压缩算法，压缩的效率就越好；但是由于HBa 的读取数据时以block块为单位的，所以越⼤的block块，对于随机读的情况，性能可能会⽐较差，如果要提升写⼊的性能，⼀般扩⼤到128kb或者256kb，可以提升写数据的效率，也不会影响太⼤的随机读性能。
clock
DATA_BLOCK_ENCODING
配置HFile中block块的编码⽅法。当⼀⾏数据中存在多个列时，⼀般可以配置为"FAST_DIFF"，可以有效的节省数据存储的空间，从⽽提升性能。
BloomFilter
优化原理：BloomFilter主要⽤来过滤不存在待检索RowKey或者Row-Col的HFile⽂件，避免⽆⽤的IO操作。它会告诉你在这个HFile⽂件中是否可能存在待检索的KeyValue，如果不存在，就可以不⽤⼩号IO打开⽂件进⾏ek。通过设置BloomFilter可以提升读写的性能。
BloomFilter是⼀个列族级别的配置属性，如果列族设置了BloomFilter，那么HBa会在⽣成StoreFile时包含⼀份BloomFilter的结构的数据，称为MetaBlock（⼀旦写⼊就⽆法更新）。MetaBlock和DataBlock（真实的KeyValue数据）⼀起由LRUBlockCache维护，所以开启了BloomFilter会有⼀定的存储即内存cache开销。
HBa利⽤BloomFilter可以节省必须读磁盘过程，可以提⾼随机读（get）的性能，但是对于顺序读（scan）⽽⾔，设置BloomFilter是没有作⽤的（0.92版本以后，如果设置了BloomFilter为ROWCOL，对于执⾏了qualifier的scan有⼀定的优化）
BloomFilter取值有两个，ROW和ROWCOL，需要根据业务来确定具体使⽤哪种。
2013江苏英语高考
如果业务⼤多数随机查询仅仅使⽤row作为查询条件，BloomFilter⼀定要设置为ROW。
如果⼤多数随机查询使⽤row+col作为查询条件，BloomFilter需要设置为ROWCOL。
如果不确定业务查询类型，设置为ROW。‘
预分区
同写性能优化预分区部分。
HBa服务端调优
GC_OPTS
HBa是利⽤内存完成读写操作。提⾼HBa内存可以有效提⾼HBa性能。GC_OPTS主要需要调整HeapSize和NewSize的⼤⼩。调整HeapSize⼤⼩的时候，建议将Xms和Xmx设置成相同的值，这样可以避免JVM动态调整HeapSize⼤⼩的时候影响性能。调整NewSize⼤⼩的时候，建议把其设置为HeapSize⼤⼩的1/9。
当HBa集群规模越⼤，Region数量越多时，可以适当调⼤HMaster的GC_OPTS参数
RegionServer需要⽐HMaster更⼤的内存，在内存充⾜的情况下，HeapSize可以相对设置⼤⼀些。
HMaster的HeapSize为4G的时候，HBa集群可以⽀持100000个Region的规模。根据经验值，单个RegionServer的HeapSize不建议超过20GB。
1. # HMaster、RegionServer GC_OPTS配置如下：
2. HMaster: -Xms2G -Xmx2G -XX:NewSize=256M -XX:MaxNewSize=256M
3. RegionServer: -Xms4G -Xmx4G -XX:NewSize=512M -XX:MaxNewSize=512M
RegionServer并发请求处理数量
建议根据CPU的使⽤情况，可以设置为100⾄300之间的值。
michael page控制MemStore的⼤⼩
store.flush.size默认值128M，单位字节，⼀旦有MemStore超过该值将被flush，如果regionrver的jvm内存⽐较充⾜(16G以上)，可以调整为256M。在内存⾜够put负载⼤情况下可以调整增⼤。
BlockCache优化
BlockCache作为读缓存，合理设置对于提⾼读性能⾮常重要。默认情况下，BlockCache和MemStore的配置各占40%，可以根据集群业务进⾏修正，⽐如
读多写少业务可以将BlockCache占⽐调⼤。另外BlockCache的策略也很重要，不同策略对读性能来说影响并不⼤，但是对GC的影响却很显著。HBa缓存区⼤⼩，主要影响查询性能。根据查询模式以及查询记录分布情况来决定缓存区的⼤⼩。如果采⽤随机查询使得缓存区的命中率较低，可以适当降低缓存⼤⼩。
1. hfile.block.cache.size，默认0.4，⽤来提⾼读性能
2. store.size，默认0.4，⽤来提⾼写性能
控制HFile个数
MemStore在flush之前，会进⾏StoreFile的⽂件数量校验（通过hba.hstore.blockingStoreFiles参数配置），如果⼤于设定值，系统将会强制执⾏Compaction操作进⾏⽂件合并，在合并的过程中会阻塞MemStore的数据写⼊，等待其他线程将StoreFile进⾏合并。通常情况下发⽣在数据写⼊很快的情况下。
pactionThreshold表⽰启动Compaction的最低阈值，该值不能太⼤，否则会积累太多⽂件，⼀般建议设置为5～8左右。
hba.hstore.blockingStoreFiles默认设置为7，可以适当调⼤⼀些。
Split优化
hba.hregion.max.filesize表⽰HBa中Region的⽂件总⼤⼩的最⼤值。当Region中的⽂件⼤于该参数时，将会导致Region分裂。
如果该参数设置过⼩时，可能会导致Split操作频繁
如果该参数设置过⼤时，会导致Compaction操作需要处理的⽂件个数增⼤，影响Compaction执⾏效率
Compaction优化
paction.min当⼀个Store中⽂件超过该值时，会进⾏Compaction，适当增⼤该值，可以减少⽂件被重复执⾏Compaction。但是如果过⼤，会导致Store中⽂件数过多⽽影响读取的性能。
paction.max控制⼀次Compaction操作时的⽂件数据量的最⼤值。
paction.max.size如果⼀个HFile⽂件的⼤⼩⼤于该值，那么在Minor Compaction操作中不会选择这个⽂件进⾏Compaction操作，除⾮进⾏Major Compaction操作。这个值可以防⽌较⼤的HFile参与Compaction操作。在禁⽌Major Compaction后，⼀个Store中可能存在⼏个HFile，⽽不会合并成为⼀个HFile，这样不会对数据读取造成太⼤的性能影响。
原则是：尽量要减⼩Compaction的次数和Compaction的执⾏时间
总结
在HBa使⽤过程中，要想获取好的读写性能，可以从以下⼏个⽅⾯进⾏优化：
1. ⼀个优秀的HBa表列族设置⽅案，可以参考
2. ⼀个优秀的HBa RowKey设计⽅案，可以参考
3. 读写时客户端相关配置
4. HBa服务器优化
