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

2017-09-20 601

我之前参与过一个日志系统的开发，存储用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无关的其他优化

通常我们会用先进先出的队列保存临时积压的日志。但是，在日志系统的场景中，当日志积压时，让用户看到最新写入的日志，比让用户看到历史日志更重要。因此我们用先进后出的栈，保存临时积压的日志。

微信关注我们

原文链接：https://yq.aliyun.com/articles/213702

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

日志系统之HBase日志存储设计优化

本人博客文章如未特别注明皆为原创！如有转载请注明出处：http://blog.csdn.net/yanghua_kobe/article/details/46482319 继续谈论最近接手的日志系统，上篇关于日志收集相关的内容，这篇我们谈谈日志存储相关的话题。简介我们首先来总结一下日志这种数据的业务特点：它几乎没有更新的需求，一个组件或一个系统通常有一个固定的日志格式，但就多个组件或系统而言它会存在各种五花八门的自定义的tag，这些tag建立的目的通常是为了后期查询/排查线上问题的需要，因此日志的检索字段也灵活多变。我们的日志存储选择是HBase，这主要是因为我们认为HBase的如下特点非常适合日志数据：（1）HBase的qualifier相当灵活，可以动态创建，非常适合日志这种tag不固定的半结构化数据（这里的灵活性主要针对tag

2017-09-20

731

hbase中的宽表是指很多列较少行，即列多行少的表，一行中的数据量较大，行数少；高表是指很多行较少列，即行多列少，一行中的数据量较少，行数大。 hbase的row key是分布式的索引，也是分片的依据。hbase的row key + column family + column qualifier + timestamp + value 是HFile中数据排列依据。HFile据此，对数据的索引到data block级别，而不是行级别。所以这种key是HFile内部的粗粒度（data block粒度）本地索引的主键。据此，在HBase中使用宽表、高表的优劣总结如下：查询性能：高表更好，因为查询条件都在row key中, 是全局分布式索引的一部分。高表一行中的数据较少。所以查询缓存BlockCache能缓存更多的行，以行数为单位的吞吐量会更高。分片能力：高表分片粒度更细，各个分片的大小更均衡。因为高表一行的数据较少，宽表一行的数据较多。HBase按行来分片。元数据开销：高表元数据开销更大。高表行多，row key多，可能造成region数量也多，- root -、 .meta表数据...

2017-09-21

789

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。