HBase学习笔记——基于HBase的日志系统的性能优化

我之前参与过一个日志系统的开发,存储用HBase。我简单罗列下用到的HBase优化,备忘。以后把它整理成更友好的介绍性文章。

系统简介

  • 有一张大的日志数据表,保存所有日志。row key是 hash + app id + log-severity + timestamp + host等,cell保存日志正文数据。

    • 可以看到row key的hash保证日志散列在各个region中,写入、查询的负载均衡。但是无法通过它进行范围查询,所以为不同查询模式,建立了多张索引表。
  • 为不同的日志级别(DEBUG, INFO, WARN, ERROR, FATAL)分别建立了一张索引表。在每张索引表中,row key是 app id + timestamp + host等。也就是说,用于通常选择一个应用,加上时间范围,也可以进一步选择一台应用服务器,来查询日志。

表结构相关优化

  • 多条日志打包,压缩保存。

    • 我们发现,如果简单地将一条日志保存为HBase表中的一行,会导致HBase表记录数很大,row key数量很大,region数量很多,HBase元数据开销很大。这会造成HBase集群不稳定。
    • 于是,我们决定将多条日志打成一个包(chunk)。一个包作为HBase表中的一行保存,大大减少了HBase表的记录数,减轻了HBase元数据的开销。打包是通过写入日志时,在应用服务器的内存中收集日志直到字节数超出一定阈值来实现的。
    • 除了打包,压缩也是在应用服务器端完成的,而不是依靠HBase (column family的compression配置)完成。因为我们希望压缩不仅能节省HBase存储空间,还要能节省应用服务器和HBase之间的网络流量。
    • 打包时,根据row key的语义,正确设置row key。比如开始时间是第一条日志的开始时间,结束时间是最后一条日志的结束时间。
    • 时间上相邻的日志,其正文内容往往很相似。因此,将多条日志打包压缩,比一条一条日志分开压缩,能获得更高的压缩率,节省网络传输带宽和存储。
    • 打包意味着查询时的解包。为此我们部署了coprocessor在HBase集群中,充分利用HBase集群的CPU解包。
  • fuzzy row filter

    • 通常来说,只有查询条件是row key的前缀,这个row key才能被用于查询。例如如果某张表的row key是 app id + host,则它能被用于根据某个应用id 的日志查询, 和 根据应用id + host的查询。
    • 如果要根据host查询,上述row key就不行了,不符合前缀匹配。我们得遍历整个表中所有的row key,对每个row key检查它是否以查询条件中给定的host结尾——十分低效。假如有10个应用,每一个应用有100个host,我们只能遍历10*100=1000条记录,找到给定host的记录。
    • 但是,应用FuzzyRowFilter后,我们仍然可以部分利用这个row key,只根据host查询。

      • 虽然row key的首部是app id,导致我们必须遍历所有app id,但是在扫描一个app id下的所有row key时,通过fuzzy row filter,可以利用row key的全局分布式索引树(-ROOT-, .META, region ) 直接跳转到查询条件给定的host开始处进行扫描。因此,我们只需要为每个app id,从查询条件的host处开始扫描,共100次扫描。

系统配置类优化

  • HBase客户端优化——牺牲可靠性,提高日志写入的吞吐量

    • 关闭WAL,直接写入日志。
    • 适当增加writer buffer大小。
    • 批量Put,传入List;关闭autoFlush。
  • 压缩算法改用snappy,牺牲压缩率,降低CPU消耗,提高吞吐量。
  • 调整HFile data block大小。data block越大,索引粒度越粗,顺序访问吞吐量越高。

    • 在一个data block内部,通常只能顺序遍历,看我们搜索的Key是否存在。但是,也可以启用bloom filter,很快地告诉我们,一个Key是否一定不在这个data block中。
  • 关闭某些column family的block cache缓存。

    • 查询时,只有重复性的、随机的访问,才能命中block cache。如果某一个列只是用于海浪数据的顺序访问,那么对它缓存没有意义,相反,它能冲掉block cache本应该缓存的其他列的数据。对于这样的列, 应该关闭block cache缓存。
  • 日志归档
      * 写入HBase的日志,TTL设为7天。HBase用于实时的web查询,只能看这7天的日志。

    • 这个系统有另外一路,实时写日志进HDFS,供HIVE分析。这是用于离线查询7天以前的历史日志的。
  • HBase默认存三个版本的cell,对日志来说没有必要,只需要存一个版本。

顺便提下与HBase无关的其他优化

  • 通常我们会用先进先出的队列保存临时积压的日志。但是,在日志系统的场景中,当日志积压时,让用户看到最新写入的日志,比让用户看到历史日志更重要。所以我们用先进后出的栈,保存临时积压的日志。
上一篇:使用canal增量订阅MySQL binlog


下一篇:Windows2003配置集群详解