58 HBase 平台实践和应用：时序数据库篇

OpenTSDB 是一个分布式、可伸缩的时序数据库，支持高达每秒百万级的写入能力，支持毫秒级精度的数据存储，不需要降精度也可以永久保存数据。其优越的写性能和存储能力，得益于其底层依赖的 HBase ， HBase 采用 LSM 树结构存储引擎加上分布式的架构，提供了优越的写入能力，底层依赖的完全水平扩展的 HDFS 提供了优越的存储能力 。

在 58 ， OpenTSDB 目前主要用于数据平台监控系统中相关性能指标的存储查询， 58 智能监控系统中回归模型和分类模型原始明细数据存储查询，以及风铃监控预警系统数据的存储查询等。

OpenTSDB 架构：

OpenTSDB 主要由以下几部分组成：

(1) 、 Collector ：负责从服务器上收集并通过 telnet 或 http 协议发送数据给 TSD 实例；

(2) 、 TSD 实例： TSD 是无状态的服务，负责接收 Collector 发送过来的数据，并对外提供数据查询服务，可以部署多个读写实例；

(3) 、 HBase 集群： TSD 接 收到监控数据后，通过 AsyncHbase 将数据写入到 HBase ， AsyncHbase 是完全异步、非阻塞、线程安全的 HBase 客户端，使用更少的线程、锁以及内存，可以提供更高的吞吐量，特别对于大量的写操作。

一、数据模型和存储优化

1、 数据模型

OpenTSDB 采用按指标建模的方式，一个 datapoint 包含以下几个部分：

(1) 、 metrics ：指标名称，例如 sys.cpu.user ；

(2) 、 timestamp ：秒级或毫秒级的 Unix 时间戳，代表该时间点的具体时间；

(3) 、 tags ：一个或多个标签，也就是描述主体的不同的维度。 Tag 由 TagKey 和 TagValue 组成， TagKey 就是维度， TagValue 就是该维度的值；

(4) 、该指标的值，目前只支持数值类型的值。

2、存储优化

OpenTSDB 对 HBase 深度依赖，并且根据 HBase 底层存储结构的特性，做了很多巧妙的优化。

(1) 、缩短 rowkey 的长度。 OpenTSDB 使用一个字典表 tsdb-uid ，将 metrics 和 tag 映射成 3 位整数的 uid ，存储指标数据时按 uid 存储，节省了大量存储空间，同时提高了查询效率。 tsdb-uid 表结构如下图所示：

(2) 、减少 keyvalue 的数量。 OpenTSDB 实际存储数据的表为 tsdb 表， 对于一小时内相同 metrics 和 tags 的 datapoint ，在 tsdb 表中 OpenTSDB 会合并成一行数据，并且更进一步，将所有列的数据会合并成一列，通过合并数据行和列减少了大量冗余 key 的存储，节省大量存储空间。 tsdb 表结构如下图所示：

(3) 、并发写优化。为了避免热点问题， OpenTSDB 支持在建数据存储表时，设置分桶， 当某一个 metrics 下数据点很多时，可以将写压力分散到多个桶中，避免了写热点的产生。

二、案例分享

1 、数据平台监控系统

监控系统架构：

数据平台监控系统监控的相关组件包括： Hadoop 、 HBase 、 Kafka 、 Flume 和 Zookeeper 等。由于 TSD 实例是无状态的，我们部署了多个读写实例，对外通过域名进行数据读写分离，保证服务的高可用。采集的监控数据最终通过 TSD 实例存储到 HBase 集群，并基于 HBase 的 RSGroup 机制进行物理隔离。由于 OpenTSDB 的可视化能力较弱，并且没有报警功能，我们选择了 Grafana 作为监控系统的可视化和报警模块， Grafana 支持多种数据源， OpenTSDB 是支持的其中一个数据源，而且可视化效果非常好。

在我们的实际使用中， TSD 单实例写 QPS 最高到达了 10 万 + ，存储到 HBase 的监控数据量半年预估达到 10T+ ，而支撑这一能力的后端 HBase 集群只用了 5 个节点，从而可以看出 OpenTSDB 强大的写性能。

Grafana 中 RegionServer 活跃 handler 线程数的可视化截图：

2 、 58 智能监控系统

58 智能监控系统架构：

58 智能监控系统中， OpenTSDB 主要用于存储网络出口和业务的进出流量、集群和域名的访问量、宏观业务数据等的原始数据，并使用回归模型按天预测流量变化趋势，使用分类模型对实时流量做异常检测。

以下是流量预测效果图：

三、遇到的问题

在 58 智能监控系统和 风铃监控预警系统 使用 OpenTSDB 时 ，我们遇到了一个相同的问题：

某个 metrics 在同一时间段内写入了大量的 datapoint ，而且 datapoint 属于不同的标签组合，标签基数达到百万级，结果在查询这一时段该 metrics 数据时，响应非常缓慢，甚至将 HBase 的 RegionServer 所有 handler 线程阻塞，导致 TSD 实例最终不可用，严重影响了用户体验，但是发现查询其它时段该 metrics 的数据是没有问题的。

问题分析：

OpenTSDB 数据存储表 tsdb 的 rowkey 结构： metrics+timestamp+tags ，第一个是 metrics ，第二个是时间戳，第三个是 tags ， tags 可能包含了多个标签名称和标签值，而这些标签之间是没有特定顺序的，比如 tags 可能取值为： {tk3=tv3,tk1=tv1,tk2=tv2,…} ，如下图中 tsdb 表 rowkey 部分。在进行查询时，查询条件包括该 metrics ，查询时间范围包括了有查询问题的时间段，查询标签取值为 {tk2=tv2} ，如下图查询条件部分。在查询的时候由于无法知道数据写入时 rowkey 中标签之间的顺序，导致所有的 OpenTSDB 查询都只能进行前缀查询 +filter ，前缀查询字段包括 metrics 和 timestamp ，而标签匹配只能通过 HBase 的 filter 机制在 RegionServer 内存中进行过滤，如下图红色虚线部分。

而由于该查询时间段内 metrics 写入了大量标签的数据，标签量基数达到百万级， datapoint 更是达到上亿，根据 metrics+ts 的前缀过滤后，需要在 RegionServer 内存中 filter 的标签数据量达到百万级，进行百万级的数据量 filter 自然会导致查询响应变慢了。

问题解决：

(1) 、建 tsdb 表时设置预分桶存储，提升并发查询性能，但是由于已经在生产环境中，无法重建该表，该方案舍弃。

(2) 、删除多余数据。经过和业务沟通，多余入库的这部分数据暂时不需要统计分析，可以删除。考虑到在线删除数据肯定会对线上业务造成干扰，并且考虑到 Hbase 的 LSM 存储结构特性，最终采取在测试 HBase 集群删除数据然后合并到在线集群的方式解决了该问题。

以下是整个删除数据的操作流程，包括 4 个步骤：

①、在测试集群创建和在线集群相同表结构（包括分区信息）的 tsdb 表，修改 hbase 集群配置保证不要触发 minor compact 和 major compact 。使用跨集群拷贝工具 distcp 将在线集群 tsdb 表的 hfile 文件拷贝到测试集群，最后将 hfile 通过 bulkload 工具加载到测试 tsdb 表中。

②、在测试环境部署一个 tsdb 实例，并开启 tsd.http.query.allow_delete=true ，允许 tsdb 实例支持查询的同时删除对应记录，最后根据要删除的数据列表，执行查询删除操作。

③、通过 distcp 拷贝测试环境 tsdb 表的 hfile 到 hbase 在线集群，并执行 bulkload 操作导入正式的 tsdb 表。

④、对在线集群 tsdb 表执行 major compact ，删除问题数据，最终查询性能恢复正常。

更多思考：

如果后续还需要对这种删除的数据进行分析，其实我们可以转变思路，数据存储的时候将 tag 变成 metrics 来存储，这样就不用担心查询性能问题了。

四、总结

本文从 OpenTSDB 的整体架构，存储模型，存储优化，在 58 的使用情况和使用过程中遇到的问题等多个方面进行了详细描述。展望未来，我们希望 OpenTSDB 在数据安全，多租户方面得到进一步的优化和完善，这样可以将 OpenTSDB 打造成一个统一的平台，简化现有的部署流程，用户也可以更放心和更容易接入使用。

58HBase平台实践和应用系列文章回顾：

《 58HBase平台实践和应用—平台建设篇 》

《 58HBase平台实践和应用—OLAP篇 》

最后，58集团数据平台部长期招聘大数据研发工程师。

58数据平台部是58集团唯一的大数据架构部门，负责包括海量数据采集接入，万亿级消息引擎、离线/实时计算引擎，海量存储引擎以及多维分析平台等的建设和优化。支持了58集团大部分的业务线，日接入流量达 200 T ，总存储过百 P ，日 30 万 的计算，随着大数据应用广泛增长，技术挑战极大。

招聘职位：   

1、存储方向：主要负责 HDFS/Hbase 等相关系统架构研发优化   

2、计算方向：负责 Spark/Flink 等相关架构研发优化   

3、 OLAP 方向：负责 Druid/Kylin/ES 等系统的架构研发优化   

4、消息中间件：负责 Kafka/Flume 等平台的架构研发优化   

5、资源管理：负责 YARN/K8s 等资源管理平台架构研发优化 

招聘要求：

1、熟悉 Java/Scala/C++ (任意一种即可），熟练掌握数据结构算法 

2、对 HDFS/Hbase/Spark/Flink/Druid/Kafka/FLume/YARN 等任一 组件有源 码 级 优化经验优先

3、有大规模分布式系统实践经验优先

工作地点：北京市朝阳区酒仙桥北路甲10号院101号楼  

联系方式： yuyi03@58.com