一、概述
hbase 写入优化除了参数配置之外，很大的一块要考虑避免region的热点问题，避免region 热点问题，主要的目的是提高hbase 数据表rowkey的分散。结合实际情况主要有以下几个办法
1.1 rowkey的创建规则 避免， 比如 通过rowkey前几位的hash。业务规则避免，比如 用户id+时间、手机号的倒叙、
1.2 通过hbase的访问API的扩展，在HBASE的访问API 通过对读写的封装，实现自动在hbase的rowkey前面增加随机码的方式实现region的进一步分散
1.3 通过表的创建预分区 实现region的分散
二、预分区表的创建
结合实际情况，创建预分区需要注意，预分区的创建也要尽可能的分散。
在实际业务中，全链路数据表的rowkey是采用guid ,由于GUid 仅采用0-9,a-f 16个字段，也就是如果仅按照第一个字母创建，仅能创建16个分区，也就是16个region，为了更好的利用水平扩展的能力，需要尽可能多的创建预先多的region，但是也要综合考虑，创建过多额region，会导致查询比较慢。结合实际的集群和使用情况，全链路的写入压力比较大，tps需要达到2.5w，并且要非常稳定。因此 为了提升写入速度，决定第全链路创建尽可能多的rgion
操作命令如下：
---采用基于前面的2个字段创建，一定要注意要尽可能的平均，否则会造成热点问题
create \'TTrace_20190817\',\'d\',
SPLITS =>
[\'00|\',\'06|\',\'0a|\',\'0d|\',
\'10|\',\'16|\',\'1a|\',\'1d|\',
\'20|\',\'26|\',\'2a|\',\'2d|\',
\'30|\',\'36|\',\'3a|\',\'3d|\',
\'40|\',\'46|\',\'4a|\',\'4d|\',
\'50|\',\'56|\',\'5a|\',\'5d|\',
\'60|\',\'66|\',\'6a|\',\'6d|\',
\'70|\',\'76|\',\'7a|\',\'7d|\',
\'80|\',\'86|\',\'8a|\',\'8d|\',
\'90|\',\'96|\',\'9a|\',\'9d|\',
\'a0|\',\'a1|\',\'a5|\',\'ab|\',\'ac|\',\'ad|\',\'ae|\',\'af|\',\'aa|\',\'a8|\',\'a9|\',
\'b0|\',\'b1|\',\'b5|\',\'b8|\',\'b9|\',\'ba|\',\'bb|\',\'bc|\',\'bd|\',\'be|\',\'bf|\',
\'c0|\',\'c1|\',\'c5|\',\'c8|\',\'c9|\',\'ca|\',\'cb|\',\'cc|\',\'cd|\',\'ce|\',\'cf|\',
\'d0|\',\'d1|\',\'d5|\',\'d8|\',\'d9|\',\'da|\',\'db|\',\'dc|\',\'dd|\',\'de|\',\'df|\',
\'e0|\',\'e1|\',\'e5|\',\'e8|\',\'e9|\',\'ea|\',\'eb|\',\'ec|\',\'ed|\',\'ee|\',\'ef|\',
\'f0|\',\'f1|\',\'f5|\',\'f8|\',\'f9|\',\'fa|\',\'fb|\',\'fc|\',\'fd|\',\'fe|\',\'ff|\'
]
----由于目前hbase的查询缓存 gc回收算法 仍然是 LruBlockCache ，目前这个表的查询重复的场景并不多，同时为了防止查询内存的GC，从而影响写入速度的问题，将此表的缓存设置为false
alter \'TTrace_20190817\', {NAME=>\'d\',BLOCKCACHE=>\'false\'}
--预写日志禁用，提升写入速度
alter \'TTrace_20190817\', METHOD => \'table_att\', DURABILITY => \'SKIP_WAL\'
三、ttl表数据的删除
1.数据的及时清理，降低存储成本
业务特点：1.写入tps 高 2.热数据需要保存的时间不长 3.查询不是按照时间序列查询 4.存储采用hbase 5.查询延迟要求较低
针对此类数据，为了降低存储 节约成本，主要有2个方案，
1. 数据落盘之前，进行数据的清理，此方案的架构如下，但是 遇到的技术问题 -会对流计算带来非常大的压力，内存和cpu占用非常高，因此不宜采用
2.数据落盘之后，采用离线任务，将有用的数据进行及时清洗出来，并通过TTL 及时将冷数据进行删除。降低存储，采用的架构如下：
为了配合数据的删除，并且之前发生过hbase 删除单表超过5t的数据表时，速度非常慢，并且容易对集群的稳定性有影响，结合hbase 数据删除的原理 ，主要采用如下方法，删除大表
场景：
1.表每天的数据为3t。需要保留的热数据为2个小时。冷数据需要及时删除，降低存储
方案：
1.hbase 每天创建一个表，查询和写入 对表的分区 通过数据治理实现对表分区的隔离，实现用户访问端的无感知
2.hbase的表的ttl 设置为2个小时，及时删除数同时提升查询速度
3.hbase 每天对天表删除–先进行大合并（大合并时对数据进行真实删除），前提是 表已经无实时的写入，大合并时，不会对数据文件进行合并，因为数据都已经过期了。大合并之后，删除表即可