HBase工作中的一些优化方法
作者：互联网
1、表的设计
- Pre-creating Regions（预分区）
- 默认情况下，在创建Hbase表的时候会自动创建一个region分区，当导入数据的时候，所有的Hbase客户端都向这一个region写数据，直到这个region足够大了才进行切分。一种可以加快批量写入速度的方法是通过预先创建一些空的regions，这样当数据写入Hbase时，会按照region分区情况，在集群内做数据的负载均衡。
- rowkey：Hbase中rowkey用来检索表中的记录，支持一下三种方式
- 通过单个rowkey访问：即按照某个rowkey键值进行get操作
- 通过rowkey的range进行scan：通过startRowkey和endRowkey，在这个范围内进行扫描
- 全表扫描：即直接扫描整张表中所有行记录
- 在Hbase中rowkey可以是任意字符串，最大长度64K，一般为10～100bytes，一般设计为定长
- rowkey规则
- 越小越好
- rowkey的设计是要根据实际业务来
- 散列性：
- 取反
- Hash
- column family
- 不要在Hbase一张表里定义太多的column family。目前Hbase并不能很好的处理超过2～3个column family的表。因为某个column family在flush的时候，它邻近的column family也会因关联效应出发flush，最终导致系统产生更多的I/O。
- In memory：创建表时，可以通过HColumnDescriptor.setInMemory(true) 将表放到RS的缓存中，保证在读取的时候被chache命中
- 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，将他们按照rowkey进行合并，由于storeFile和Memstore都是经过排序的，并且storeFile带有内存中索引，通常合并过程还是比较快的
- 实际应用中，可以考虑必要时手动进行major compact，将同一个rowkey的修改进行合并形成一个较大的storeFile。同时将storeFile设置大些，减少split的发生
- Hbase为了防止小文件（被刷到磁盘的memstore）过多，以保证查询效率，Hbase需要在必要的时候将这些小的storeFile合并成相对较大的storeFile，这个过程称之为compact。在Hbase中，主要存在两种类型的compact：minor compaction和major compaction
-
- minor compaction：是较小、很少文件的合并
- major compaction：将所有的storeFile合并成一个，触发major compaction的可能条件有：major_compact命令、majorCompact() API、RS自动运行(相关参数：hbase.hregion.majorcompaction 默认为24小时、hbase.hregion.majorcompaction.jetter 默认0.2、防止RS在同一时间进行major compaction)
- hbase.hregion.majorcompaction.jetter 作用：对参数hbase.hregion.majorcompaction规定的值起到浮动的作用，假如两个参数都为默认值24和0.2，那么major compact最终使用的数值为：19.2～28.8这个范围
- 关闭自动 major compaction
- 手动编程 major 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开始选择
- 多个HTable并发写
- HTable参数设置
- Auto flush：HTable.setAutoFlush(false)，关闭客户端的自动flush，这样可以批量写入数据到Hbase，而不是有一条put就执行一次更新，只有当put填满客户端写缓存时，才实际向Hbase服务端发起写情趣。默认auto flush是开启的
- write buffer：设置客户端的buffer大小，如果新设的buffer小于当前写buffer中的数据，buffer将会被flush到服务端
- WAL Flag
-
- 注意：谨慎选择关闭WAL日志，因为这样，如果RS宕机，put/delete的数据将无法根据WAL日志进行恢复
- 批量写
- 多线程并发写
- scan caching
- Hbase的conf配置文件中配置
- 通过调用HTable.setScannerCaching()进行配置
- 通过调用scan.setCaching() 进行配置
- 三者的优先级越来越高级
- 批量读
- 多线程并发读
- 缓存查询结果
- Blockcache
- Hbase上RS的内存分为两个部分，一部分作为Memstore，主要用来写，另外一部分作为BlockCache，主要用来读
- 写请求会先写入memstore，RS会给每个region提供一个memstore，当memstore满64M以后，会启动flush刷新到磁盘。当memstore的总大小超过限制时（heapsize * hbase.regionserver.global.memstore.upperlimit * 0.9），会强行启动flush进程，从最大的memstore开始flush直到低于限制
- 读请求先到memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上读，并把结果放入BlockCache。由于BlockCache采用LRU策略，因此BlockCache达到上线（heap size * hfile.block.cache.size * 0.85）后，会启动淘汰机制，淘汰掉最老的一批数据
- 一个RS上有一个BlockCache和N个Memstore，他们的大小和不能大于等于heapsize * 0.8，否则Hbase不能启动。默认BlockCache为0.2，memstore为0.4。对于注重读响应时间的系统，可以将BlockCache设大些，比如BlockCache=0.4，memstore=0.39，以加大缓存的命中率
标签：major,优化,storeFile,compaction,memstore,flush,HBase,方法,Hbase 来源： https://www.cnblogs.com/liufei-yes/p/11520801.html