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开始选择
2、写表操作
  • 多个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日志进行恢复
    • 批量写
    • 多线程并发写 
3、读表操作
  • 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,以加大缓存的命中率 
上一篇:write()方法和flush()的作用


下一篇:MySQL drop table 影响及过程