每分钟写入6亿条数据，携程监控系统Dashboard存储升级实践

一、 背景概述

框架Dashboard是一款携程内部历史悠久的自研监控产品，其定位是企业级Metrics监控场景，主要提供用户自定义Metrics接入，并基于此提供实时数据分析和视图展现的面板服务，提供可定制的基于时间序列的各类系统级性能数据和业务指标数据的看板。还可以提供灵活的数据收集接口、分布式的大容量存储和灵活的展现方式。

由于时间较早，那时候业界还没有像样的TSDB产品，类似Prometheus，InfluxDB都是后起之秀，所以Dashboard选型主要使用了HBase来存储Metrics数据。并且基于HBase来实现了TSDB，解决了一些HBase热点问题，同时将部分查询聚合下放到HBase，目的是优化其查询性能，目前看来总体方案依赖HBase/HDFS还是有点重。

近些年，随着携程监控All-in-One产品的提出。对于内部的Metrics存储统一也提出了新的要求。由于Dashboard查询目前存在的诸多问题以及Metrics统一的目标，我们决定替换升级Dashboard现有的HBase存储方案，并且在Metrics场景提供统一的查询层API。

二、 整体架构

Dashboard产品主要分了6个组件，包括dashboard-engine，dashboard-gateway，dashboard-writer，dashboard-HBase存储，dashboard-collector，dashboard-agent。目前实时写入数据行数6亿条/分钟，架构图如下：

• dashboard-engine是查询引擎。​
• dashboard-gateway是提供给用户的查询界面。
• dashboard-writer是数据写入HBase的组件。
• dashboard-collector是基于Netty实现的Metrics数据收集的服务端。
• dashboard-agent是用户打点的客户端，支持sum，avg，max，min这几种聚合方式。
• dashboard-HBase是基于HBase实现的Metrics存储组件。

产品主要特性如下：​

• 支持存储精确到分钟级的基于时间序列的数据。
• 单个指标数据可支持多个tag。
• 展现提供任意形式的视图同时可灵活基于tag进行分组。

三、 目前的存在问题

基于HBase的Metrics存储方案虽然具有良好的扩展性，比较高的吞吐，但是随着时间发展，已经不是最优的TSDB方案了，可以归纳总结为如下几个痛点。​

• 在TSDB场景查询慢，整体表现不如专业的TSDB。
• HBase热点问题，容易影响数据写入。
• HBase技术栈运维操作很重。
• 采用自研协议，不支持业界标准的Prometheus协议，无法和内部All-in-one监控产品较好的融合。