复杂场景,从OpenTSDB迁移到TDengine的佳实践

2022-02-11 00:00:00 数据 模型 支持 迁移 写入



在上一篇文章中,我们介绍了运维监控场景下,如何从OpenTSDB迁移到TDengine。

如果应用特别复杂,或者应用领域并不是运维监控场景,本文将更加全面深入地介绍将OpenTSDB应用迁移到TDengine的话题。

其他场景的迁移评估与策略

1、TDengine 与 OpenTSDB 的差异

本节将详细介绍OpenTSDB与TDengine在系统功能层面上存在的差异。

读完本节之后,你可以全面地评估是否能将某些基于OpenTSDB的复杂应用迁移到TDengine上,以及迁移之后应该注意的问题。

TDengine当前只支持Grafana的可视化看板呈现,所以如果应用中使用的是其他看板(例如TSDash、Status Wolf等),那么暂时无法直接迁移到TDengine,需要将其重新适配到Grafana才可以正常运行。

截止到2.3.0.x 版本,TDengine只能够支持collectd和StatsD作为数据收集汇聚软件,当然后面会陆续提供更多的数据收集聚合软件的接入支持。如果收集端使用了其他类型的数据汇聚器,则需要适配到这两个数据汇聚端系统,才能正常写入。除了上述两个数据汇聚端软件协议以外,TDengine还支持通过 InfluxDB的行协议和OpenTSDB的数据写入协议、Json格式将数据直接写入,可以重写数据推送端的逻辑,使用TDengine支持的行协议来写入数据。

此外,如果应用中使用了OpenTSDB的以下特性,在迁移之前还需要了解以下注意事项:

  1. /api/stats:如果应用中使用了该项特性来监控OpenTSDB的服务状态,并在应用中建立了相关的逻辑来联动处理,那么这部分状态读取和获取的逻辑需要重新适配到TDengine。TDengine提供了全新的处理集群状态监控机制,来满足应用对其进行的监控和维护的需求。
  2. /api/tree:如果依赖于OpenTSDB的该项特性来进行时间线的层级化组织和维护,那么便无法将其直接迁移至TDengine。TDengine采用了数据库->超级表->子表这样的层级来组织和维护时间线,归属于同一个超级表的所有的时间线在系统中同一个层级,但是可以通过不同标签值的特殊构造来模拟应用逻辑上的多级结构。
  3. Rollup And PreAggregates:采用了Rollup和PreAggregates,需要应用来决定在合适的地方访问Rollup的结果,在某些场景下又要访问原始的结果,这种结构的不透明性让应用处理逻辑变得极为复杂而且完全不具有移植性。我们认为这种策略是时序数据库无法提供高性能聚合情况下的妥协与折中。TDengine暂不支持多个时间线的自动降采样和(时间段范围的)预聚合,由于 其拥有的高性能查询处理逻辑,即使不依赖于Rollup 和 (时间段)预聚合计算结果,也能够提供很高性能的查询响应,而且让你的应用查询处理逻辑更加简单。
  4. Rate: TDengine提供了两个计算数值变化率的函数,分别是Derivative(其计算结果与InfluxDB的Derivative行为一致)和IRate(其计算结果与Prometheus中的IRate函数计算结果一致)。但是这两个函数的计算结果与 Rate 有细微的差别,但整体上功能更强大。此外,OpenTSDB提供的所有计算函数,TDengine 均有对应的查询函数支持,并且TDengine的查询函数功能远超过OpenTSDB支持的查询函数,可以极大地简化应用处理逻辑。

通过上面的介绍,相信你应该能够了解OpenTSDB迁移到TDengine带来的变化,这些信息也有助于你正确地判断是否可以接受将应用迁移到TDengine之上,体验TDengine提供的强大的时序数据处理能力和便捷的使用体验。

2、迁移策略

首先将基于OpenTSDB的系统进行迁移涉及到的数据模式设计、系统规模估算、数据写入端改造,进行数据分流、应用适配工作;之后将两个系统并行运行一段时间,再将历史数据迁移到 TDengine 中。当然如果你的应用中有部分功能强依赖于上述OpenTSDB特性,同时又不希望停止使用,可以考虑保持原有的OpenTSDB系统运行,同时启动 TDengine来提供主要的服务。

数据模型设计

一方面,TDengine 要求其入库的数据具有严格的模式定义。另一方面,TDengine 的数据模型相对于 OpenTSDB 来说又更加丰富,多值模型能够兼容全部的单值模型的建立需求。 现在让我们假设一个运维监控场景,我们使用了collectd收集设备的基础度量(metrics),包含了 memory、swap和disk 等几个度量,其在 OpenTSDB 中的模式如下:

TDengine要求存储的数据具有数据模式,即写入数据之前需创建超级表并指定超级表的模式。对于数据模式的建立,有两种方式来完成此项工作:

1)充分利用TDengine对OpenTSDB的数据原生写入的支持,调用TDengine提供的API将(文本行或 JSON 格式)数据写入,并自动化地建立单值模型。采用这种方式不需要对数据写入应用进行较大的调整,也不需要对写入的数据格式进行转换。 在C语言层面,TDengine提供了taos_insert_lines来直接写入OpenTSDB格式的数据(在2.3.x 版本中该函数对应的是 taos_schemaless_insert )。其代码参考示例请参见安装包目录下示例代码 schemaless.c。

2)在充分理解TDengine数据模型的基础上,结合生成数据的特点,手动建立OpenTSDB到TDengine的数据模型调整的映射关系。TDengine能够支持多值模型和单值模型,考虑到OpenTSDB均为单值映射模型,这里推荐使用单值模型在TDengine中进行建模。

  • 单值模型

具体步骤如下:将度量(metrics)的名称作为 TDengine 超级表的名称,该超级表建成后具有两个基础的数据列—时间戳(timestamp)和值(value),超级表的标签等效于 度量 的标签信息,标签数量等同于度量 的标签的数量。子表的表名采用具有固定规则的方式进行命名:metric + '_' + tags1_value + '_' + tag2_value + '_' + tag3_value ...作为子表名称。

在TDengine中建立3个超级表:

create stable memory(ts timestamp, val float) tags(host binary(12),memory_type binary(20), memory_type_instance binary(20), source binary(20));
create stable swap(ts timestamp, val double) tags(host binary(12), swap_type binary(20), swap_type_binary binary(20), source binary(20));
create stable disk(ts timestamp, val double) tags(host binary(12), disk_point binary(20), disk_instance binary(20), disk_type binary(20), source binary(20));

相关文章