Skywalking IoTDB存储插件设计步骤

该项目来自开源软件供应链写作计划 - Summer 2021 Apache IoTDB - Apache Skywalking Adapter 项目。 该项目已提交给 Skywalking 社区（IoTDB 存储插件 #7766），目前正在开发中。 社区审查。

实现思路

该项目的目标是为 Skywalking 开发一个适配器，使用 IoTDB 来读写相关数据。 了解 Skywalking 目前如何使用 InfluxDB、H2 和 E。Elasticsearch 的适配器。 Skywalking提供了存储扩展的开发指南和参考链接。 此外，需要 Skywalking 和 InfluxDB 调试过程才能完全理解 Skywalking 的界面和用法。

IoTDB 建议您使用其提供的本机客户端包（会话或会话池）与 IoTDB 服务器交互。

开发平台：Win10，IoTDB版本：0.12.2

相关概念

Skywalking存储模型

Skywalking 8.0+存储模型为如下： 它分为四类：Record、Metrics、NoneStream 和 ManagementData。 所有这些都实现了 StorageData 接口。 StorageData 接口必须实现 id() 方法。 下面分别介绍这四种存储模型。

记录：大部分记录是原始日志数据或任务记录。 应存储该数据而不进行进一步分析。 Record类的所有模型都有一个time_bucket字段，用于记录当前Record所在的时间窗口。 具体示例有 SegmentRecord、AlarmRecord、BrowserErrorLogs、LogRecord、ProfileTaskLogRecord、ProfileThreadSnapshotRecord、TopN。

SegmentRecord：跟踪段的详细记录模型。 TraceSegment是skywalking-trace-receiver-plugin插件接收并解析Skywalking Agent发送的链接数据后得到的。 AlarmRecord：报警详细记录模型。 当指标触发报警规则时，会生成对应报警的详细数据模型。 TopN：TopN是一个带有statement字段的采样模型（用于解释）。（采样数据的关键信息）、latency字段（用于记录采样数据的时延）、track_id字段（用于描述采样数据的关联分发链路ID）、service_id字段（用于记录采样数据的关联分发链路ID） ),（用于记录服务ID中的延迟）。 目前，采样模型默认仅包含TopNDatabaseStatement。 TopNDatabaseStatement：按延迟排序的数据库采样记录。

指标：指标代表统计数据。 统计数据是通过OAL脚本或硬编码对源数据进行聚合和分析而产生的存储模型。 它的生命周期由TTL（生存时间）控制。 Metrics 类中的所有模型都有一个 time_bucket 和一个entity_id 字段。 示例：NetworkAddressAlias、Event、InstanceTraffic、EndpointTraffic、ServiceTraffic、EndpointRelationServerSideMetrics、ServiceInstanceRelationServerSideMetrics、ServiceInstanceRelationClientSideMetrics、ServiceRelationServerSideMetrics、ServiceRelationClientSideMetrics

NoneStream：NoneStream 基于 Record，time_bucket 到 TTL 支持转换。 示例：ProfileTaskRecord

ManagementData：UI模板管理相关数据。 默认情况下只有一个 UITemplate 实现类。

部分参见 Apache Skywalking 实战，第 9 章：SkyWalking OAP。 服务器存储模型

p>

IoTDB数据模型

查看官方IoTDB数据模型介绍。 简单来说，是可以的使用树结构了解 IoTDB 的数据模型。 按级别，从高到低：存储组 -> (LayerName) -> 设备 -> 时间序列。 从顶层到下面特定层的路径称为路径。 最顶层是存储组，倒数第二层是设备，从第一层到最后一层是时间序列。 中间可以有很多层，每个层称为一个 LayerName。

请注意，每个存储组都需要一个线程，因此存储组过多会降低存储性能。 此外，LayerName 值存储在内存中，Timeseries 值及其下面的数据存储在硬盘上。

Skywalking的IoTDB-适配器存储解决方案

概念上的拆分

Skywalking中的每个存储模型都可以被认为是一个模型，一个模型可以有多个包含列。 每列都有一个 ColumnName 和 ColumnType 属性，分别表示列的名称和类型。 每个ColumnName下存储了多个ColumnType数据类型的数据值。 从关系数据库的角度来看，模型是关系表，列是关系表的字段。

方案一：类关系数据库存储方案（不可行）

将所有Skywalking存储模型写入IoTDB的存储组（例如root.skywalking存储组）。 模型对应于设备，列对应于时间序列。 也就是说，Skywalking 中的“数据库- > 模型- > 列”对应 IoTDB 中的“存储组- > 设备- > 时间序列”。 该解决方案只有4个IoTDB存储路径图层：root.skywalking.ModelName.ColumnName。 该方案的优点是逻辑清晰，实现难度较小。 但由于数据存储在硬盘上，查询效率比较差。

结果：该方案无法实现
原因：部分存储接口要求实现按entity_id查询分组的功能，但IoTDB仅支持按时间分组的功能。 解决方案2必须通过基于级别的小组来采用和实施。

选项 2：部署索引存储解决方案

IoTDB 中的每个 LayerName 都存储在内存中，因此可以被视为索引，使您可以利用它。 此功能提高了 IoTDB 查询性能。

继续将所有Skywalking存储模型写入IoTDB中的存储组，例如root.skywalking存储组。 Model对应一个LayerName，需要索引的Column也对应一个LayerName。 不过LayerName存储的并不是ColumnName，而是对应的Value。 这相当于为同一分支下同一层中需要索引的列存储不同的值。 不需要索引的列对应于路径的最后一级Timeseries。 最终，同一模型的数据将分布在多个设备上。

这种方案丢失了需要建立索引的ColumnName，因此需要通过硬编码的方式记录需要建立索引的ColumnName和ColumnType。 另外，还需要保证模型中多个索引列的顺序，避免存储混乱。 计划是对模型应索引的列的存储顺序进行硬编码。

本方案中IoTDB存储路径的长度是可变的。 索引中的列越多，路径就越长。 示例：

当前 model1(column11,column12)、model2(column21、column22、column23)、model3(column31)，下划线表示该字段必须建立索引。

需要索引的模型：root.skywalking.model1_name.column11_value.column12_nameroot.skywalking.model2_name.column21_value.column22_value.column23_name 不需要索引的模型索引 所需索引：root.skywalking.model3_name.column31_Name

插入：

[ k4]- 插入模型 1插入  根。    skywalking。model1_name。column11_value值 (次tamp,column12_value);-- 插入模型 2插入 到 root .skywalking.model2_name.column21_value ">.column22_value值 (时间戳 , column23_name);

--查找model1中的所有数据select *来自根。skywalking .model1_name;-- 查找model2中column22_value="test"的数据选择 *从根 .skywalking.model2_name.* .测试;--根据第21列对模型2第23列求和进行分组统计选择 总计(column23)来自  root。skywalking。model2_name。*。* 组 span> 按 级别 =  3;