天数润科开源贡献 OpenTSDB-Keeper

 

东方网 2018-04-10 09:31:51

OpenTSDB是一款社区的时序数据库产品，其构建与HBase之上的设计使得它拥有很好的可扩展性，尤其适合于监控领域，然而，OpenTSDB仍存在几个问题：(1)作为一个中间件，其稳定性、可靠性与底层HBase的表现休戚相关，基于Hadoop生态也决定其在运维方面的复杂性。(2)尽管OpenTSDB可以多节点部署，但这完全依赖于HBase本身的分布式设计，其自身仅仅被设计为一个单体应用，并没有定义或实现节点间交互的细节，没有充分发挥分布式多节点的能力。因此，我们希望针对这两点展开一些工作，打造一个可靠的、稳定的、分布式的TSDB集群，这就是我们规划中的OpenTSDB-Keeper组件。它将作为OpenTSDB集群的大脑，监控各节点状态，平衡各节点间负载，组织节点间在读写方面的协作。从2016年开始，我们采用实时计算+时序数据库的存储平台架构来解决IoT场景的数据存储需求。上千台设备的传感器数据实时接入，需要每秒能响应百万点以上的并发写需求。多层的流式计算/存储架构，需要充分考虑每层通道提供的读写带宽。技术上，我们使用自研的SkyCompute高性能计算引擎中的SparkStreaming作为流计算引擎，OpenTSDB作为存储引擎，数据架构参考下图：图1 基于SparkStreaming+OpenTSDB的流式时序数据存储架构如上图所示，单个节点的OpenTSDB无法满足一个Spark集群的并发写入，也无法保障实时写的高可用。因此，我们采用分布式的方式，启动多个OpenTSDB节点来响应SparkStreaming写请求。为了均匀分散写请求的负载，在每1个计算节点都部署了1个OpenTSDB节点，这样每个计算节点只写往本机的OpenTSDB节点，同时还节省了部分网络通信的开销。图2 简单的负载均衡架构在上线运行验证期间，我们发现，整个Spark Streaming的任务经常受OpenTSDB+HBase存储层的响应拖累，既无法发挥系统的全部性能，也无法达到承诺的数据稳定落盘。主要表现在，受更底层HBase的响应影响以及OpenTSDB自身负载，导致了响应时间不稳定，乃至出现OpenTSDB节点崩溃。我们一方面着力于解决OpenTSDB与HBase之间的连接问题，调节OpenTSDB资源，一方面认为集群形式的OpenTSDB同样需要一个监控以及资源分配组件。我们需要在OpenTSDB节点负载过程或出现故障时，及时将计算节点连接到另一个健康的OpenTSDB节点，并且对这样的故障增加报警与错误记录，以通知到运维人员，并为错误分析、调优提供原始记录。于是，我们开发了一个非常轻量的组件OpenTSDB-Keeper。在我们的业务场景中，该组件的加入，显著地提高了从计算节点到存储节点的效率、减少了IO等待时间，且避免了OpenTSDB节点无响应导致的持续的存储失败，将整个系统的处理效率提高了三倍。本文来源：东方网责任编辑：王晓易_NE0011

OpenTSDB是一款社区的时序数据库产品，其构建与HBase之上的设计使得它拥有很好的可扩展性，尤其适合于监控领域，然而，OpenTSDB仍存在几个问题：

(1)作为一个中间件，其稳定性、可靠性与底层HBase的表现休戚相关，基于Hadoop生态也决定其在运维方面的复杂性。

(2)尽管OpenTSDB可以多节点部署，但这完全依赖于HBase本身的分布式设计，其自身仅仅被设计为一个单体应用，并没有定义或实现节点间交互的细节，没有充分发挥分布式多节点的能力。

因此，我们希望针对这两点展开一些工作，打造一个可靠的、稳定的、分布式的TSDB集群，这就是我们规划中的OpenTSDB-Keeper组件。它将作为OpenTSDB集群的大脑，监控各节点状态，平衡各节点间负载，组织节点间在读写方面的协作。

从2016年开始，我们采用实时计算+时序数据库的存储平台架构来解决IoT场景的数据存储需求。上千台设备的传感器数据实时接入，需要每秒能响应百万点以上的并发写需求。多层的流式计算/存储架构，需要充分考虑每层通道提供的读写带宽。技术上，我们使用自研的SkyCompute高性能计算引擎中的SparkStreaming作为流计算引擎，OpenTSDB作为存储引擎，数据架构参考下图：

图1 基于SparkStreaming+OpenTSDB的流式时序数据存储架构

如上图所示，单个节点的OpenTSDB无法满足一个Spark集群的并发写入，也无法保障实时写的高可用。因此，我们采用分布式的方式，启动多个OpenTSDB节点来响应SparkStreaming写请求。为了均匀分散写请求的负载，在每1个计算节点都部署了1个OpenTSDB节点，这样每个计算节点只写往本机的OpenTSDB节点，同时还节省了部分网络通信的开销。

图2 简单的负载均衡架构

 

在上线运行验证期间，我们发现，整个Spark Streaming的任务经常受OpenTSDB+HBase存储层的响应拖累，既无法发挥系统的全部性能，也无法达到承诺的数据稳定落盘。主要表现在，受更底层HBase的响应影响以及OpenTSDB自身负载，导致了响应时间不稳定，乃至出现OpenTSDB节点崩溃。

我们一方面着力于解决OpenTSDB与HBase之间的连接问题，调节OpenTSDB资源，一方面认为集群形式的OpenTSDB同样需要一个监控以及资源分配组件。我们需要在OpenTSDB节点负载过程或出现故障时，及时将计算节点连接到另一个健康的OpenTSDB节点，并且对这样的故障增加报警与错误记录，以通知到运维人员，并为错误分析、调优提供原始记录。

资源

健康

于是，我们开发了一个非常轻量的组件OpenTSDB-Keeper。在我们的业务场景中，该组件的加入，显著地提高了从计算节点到存储节点的效率、减少了IO等待时间，且避免了OpenTSDB节点无响应导致的持续的存储失败，将整个系统的处理效率提高了三倍。