1. 概述

随着“中国制造2025”战略的深入推进，制造业的数字化、智能化转型也在不断加速。伴随着物联网以及工业互联网项目不断落地，企业对于工业制造、设备运维等生产制造过程中产生的数据治理提出了新的需求。而在这些数据中，大部分数据都是时序数据—即生产经营活动中各种随时间顺序而不断产生并记录下的各类指标等数据。因此，如何高效地解决这些海量时序数据的“存、算、管、用”问题成为实现制造业数字化转型过程中的一个重要挑战。

Lindorm多模超融合数据库便是在该时代背景下诞生的数据库产品，其中的时序引擎便是专为时序数据设计的数据库引擎。为时序数据的存储、计算、管理、应用提供了企业运用所需的功能与性能。

2. 目标读者

本文的目标读者如下所示：

• 在时序数据应用场景下进行技术选型的技术负责人。

• 物联网、工业互联网、企业应用监控领域的架构师、产品经理。

• 从事大规模数据密集型应用系统设计开发的技术人员。

3. 产品优势

Lindorm时序引擎作为一款领域专精型的数据库产品，提供了强大且丰富的产品能力。包括且不限于以下方面：

• 云原生架构

Lindorm时序引擎面向物联网、互联网、车联网等时序数据应用场景进行了设计和优化，并创新性地使用存储计算分离、多模共享融合的云原生架构，以适应云计算时代资源解耦和弹性伸缩的诉求。

Lindorm时序引擎的技术架构如下图所示：

• 支持标准SQL

为了降低学习成本、提升使用体验，Lindorm时序引擎提供了标准SQL作为管理、访问数据的统一接口，并针对时序特性进行了SQL语法的扩展。并根据时序数据的模型特征，抽象出一套半结构化模型用于适配各种时序应用场景的数据建模需求。

• 高性价比的时序存储技术

为了适应海量时序数据的实时接入场景，Lindorm时序引擎提供了可扩展至每秒千万数据点的写入能力。同时针对时序数据的特点，提供了高压缩比的存储能力以及云原生的冷热分离能力，提升用户存储时序数据的性价比。

• 贴合时序场景的查询计算能力

对于时序数据的应用特点，Lindorm时序引擎默认为时序数据提供了数据源维度以及时间维度的双重索引，为用户对时序数据进行实时查询分析提供了性能保证。同时、针对时序应用中常用的最新值查询及降采样查询提供了语法扩展及优化。对于时序数据海量存储时的查询分析查询，还提供了内置的持续查询能力加速此类查询。

此外，Lindorm时序引擎已经通过了中国信息通信研究院所举行的针对时序数据库的功能、性能、稳定性认证，能够广泛服务于各行各业对于时序数据应用的场景。

4. 最佳实践

本文基于一个虚拟的空气检测设备上报数据的应用场景，从以下几个角度介绍使用Lindorm时序引擎的最佳实践：

• 数据建模

• 数据写入

• 数据管理

• 数据查询&应用

4.1 时序数据建模

物联网、应用监控、工业互联网等典型的时序场景下，生产设备或监控设备通常会按一定的周期持续产生时序数据。一条时序数据记录通常会由三部分构成：

• 标签（TAG）

  用于描述产生该时序数据源属性的元数据。比如：设备管理编号、设备所属区域、设备特征等。这部分属性数据与数据源本身强相关，不会随时间变化而变化。

• 时间戳（TIMESTAMP）

  用于描述该时序数据产生的时间。

• 字段（FIELD）

  该时序数据记录对应的描述实际业务含义的数据。由于一个数据源在同一时间点可能会上报多个指标的数据，因此将不同的指标对应不同的字段。

因此，在Lindorm时序中进行数据建模时建议把具有相同特征的一类数据设计为一张时序数据表（Table）。同时，可以将同一个业务相关联的时序数据表都设计为同一个数据库（Database）。

比如将各条生产线上的某个型号的传感器的数据都设计到一张时序数据表中，专门用于记录此型号传感器上报的数据。各传感器的编号、所属生产线信息便对应着标签；传感器不断上报的指标便对应着字段。

以上文所述的空气检测的场景为例，假设各监测点的同类检测仪（假定型号为"GW_FM801"）上报数据的业务模型如下所示：

在Lindorm时序引擎中，便可利用以下SQL进行库、表定义：

-- 创建数据库
CREATE DATABASE AQM;
-- 创建保存原始时序数据的时序表
CREATE TABLE AQM.GW_FM801_DATA (
    city        VARCHAR TAG,
    district    VARCHAR TAG,
    id          VARCHAR TAG,
    time        TIMESTAMP,
    pm2_5       DOUBLE,
    pm10        DOUBLE,
    so2         DOUBLE,
    no2         DOUBLE,
    PRIMARY KEY(id)
);

说明

对于使用Java语言进行应用开发的技术人员，Lindorm时序引擎也提供了符合标准JDBC规范的接口实现，推荐直接使用JDBC操作SQL访问Lindorm时序引擎。Lindorm时序引擎的JDBC驱动程序的安装与使用可参见 JDBC API Reference。

时序数据写入

Lindorm时序引擎支持多种方式的数据写入，分别包括：

• 基于SQL的数据写入。

• 基于MQTT协议将设备数据直接上报。

• 基于InfluxDB的Protocol Line格式的数据写入。

• 支持Prometheus以Remote Storage的形式写入监控数据。

对于应用开发而言，最常见的做法就是通过SQL将设备上报的数据写入Lindorm时序引擎。以上文空气监测的场景为例，写入一条时序数据最简单的方法便是执行一条INSERT语句进行写入。如下所示：

INSERT INTO AQM.GW_FM801_DATA (city, district, id, time, pm2_5, pm10, so2, no2) 
VALUES ('shanghai', 'pudong', 'SH0001', '2019-04-18 10:00:00', 31, 66, 10,43);

或者通过INSERT语句一次写入多条数据。如下所示：

INSERT INTO AQM.GW_FM801_DATA (city, district, id, time, pm2_5, pm10, so2, no2) 
VALUES ('shanghai', 'pudong', 'SH0002', '2019-04-18 10:00:00', 36, 60, 13, 40),
('shanghai', 'pudong', 'SH0002', '2019-04-18 10:01:00', 36, 61, 14, 40),
('shanghai', 'pudong', 'SH0002', '2019-04-18 10:02:00', 36, 60, 13, 41),
('shanghai', 'pudong', 'SH0002', '2019-04-18 10:03:00', 37, 62, 15, 42),
('shanghai', 'pudong', 'SH0002', '2019-04-18 10:04:00', 37, 61, 15, 42);

4.2 时序数据保存与管理

对于Lindorm时序引擎接入海量设备上报时序数据的场景，随着时间的不断增长，存储成本便会不断增长。由于时序数据的查询普遍具有冷热分层的特性——即通常会频繁查询距离当前较近的数据，较少查询距今已有一段时间的数据。因此，大多数时序数据应用场景普遍需求能够将存量历史数据的存储降低。

尽管如此，很多情况下对于距今已有较长时间的历史数据也不能简单清理了之，因为很多时候对于质量管控的需求需要能够对历史数据回溯，因此历史数据虽然不常使用，也不能删除。另一方面，历史数据的一些过往的统计计算结果也可能会因为业务需求在后续的应用中被频繁引用。因此对于时序数据的长期处理的效率追求以及历史数据保存成本之间的矛盾，则是在时序应用场景中经常需要考虑的问题。

在使用Lindorm时序引擎的情况下，则可以利用引擎的持续查询能力与冷数据归档能力来解决上述困境。其解决思路如下：

1. 对于保存原始时序数据的数据库启用冷数据归档功能，实现原始数据随着时间增长逐渐被归档到廉价存储介质上。

2. 同时，基于业务的实际查询分析需求，对于频繁需要引用的基于原始数据计算的统计固化为Lindorm时序引擎的持续查询，从而让Lindorm时序引擎定期对原始时序数据按要求进行计算，并将计算结果写入另一个数据库中。保证对这些计算结果查询时的低延时。

以上文的空气监测场景为例，原始数据的写入频率是每个设备每分钟上报一组指标。为了降低大量设备接入后时序数据的存储成本问题，可以在对Lindorm实例开通冷存储后，将原始时序数据所在的数据库AQM设置冷热分离的分界线（如：30天）。从而使得原始的时序数据对应的时间戳超过当前30天以上时，这部分数据就会被逐步归档到廉价的冷存储上。该操作仅需一条SQL即可实现：

ALTER DATABASE AQM WITH (cold_boundary=30);

此外，假设该业务应用经常需要使用每个设备的日平均指标，因此可以对原始时序数据表创建一个持续查询定期计算日平均指标，并将结果写入一个新数据库中的结果表供后续业务使用。而这些操作也仅需要有限的几条SQL即可实现：

-- 创建保存计算结果的数据库，以免受原库冷数据归档的影响
CREATE DATABASE AQM_STATS;
-- 创建计算结果表
CREATE TABLE AQM_STATS.GW_FM801_DATA_DAILY (
    city        VARCHAR TAG,
    district    VARCHAR TAG,
    id          VARCHAR TAG,
    time        TIMESTAMP,
    avg_pm2_5       DOUBLE,
    avg_pm10        DOUBLE,
    avg_so2         DOUBLE,
    avg_no2         DOUBLE,
    PRIMARY KEY(id)
);
-- 创建持续查询，查询体是一个降采样计算。
CREATE CONTINUOUS QUERY CQ_AVGDAILY WITH (`interval`='1d') 
AS INSERT INTO AQM_STATS.GW_FM801_DATA_DAYLY(city, district, id, time, avg_pm2_5, avg_pm10, avg_so2, avg_no2)
  SELECT city, district, id, time, mean(pm2_5) AS avg_pm2_5, mean(pm10) AS avg_pm10, mean(so2) AS avg_so2, mean(no2) AS avg_no2
  FROM AQM.GW_FM801_DATA SAMPLE BY 1d;

4.3 时序数据查询与应用

当时序数据被存入Lindorm时序引擎后，用户可以像操作普通关系型数据库一样使用SELECT语句对数据进行查询。比如类似以下的查询：

SELECT * FROM GW_FM801_DATA 
WHERE id='SH0002' 
AND time >= '2019-04-18 10:00:00' 
AND time < '2019-04-18 10:05:00';

不过更多时候，应用中固然可以通过程序代码固化了一些业务所需的SQL查询，但由于时序数据是不断地写入Lindorm时序引擎，作为数据的拥有方可能会需要实时地以“所见即所得”的方式关注写入的时序数据的实时变化趋势。因此，在这种场景下，建议使用开源的Grafana接入Lindorm时序引擎，从而可以方便的关注时序数据的变化。

说明

Grafana是用于图形化展示大型测量数据的开源可视化工具，在互联网应用分析中应用范围十分广泛，并且在工业监控、气象监控、家居自动化和过程管理等领域也有着较广泛的用户基础。

若要在业务中使用Grafana，通常需要以下几个步骤

1. 部署安装Grafana。

2. 安装Lindorm时序引擎对接Grafana的定制插件。

3. 在Grafana上创建连接至数据所在的Lindorm时序引擎的数据源（DataSource）。

   以上文所述的空气监测业务为例，其在Grafana上的DataSrouce设置即可按类似下图的方式配置。

4. 基于步骤3创建的数据源，按照Grafana的使用方法，对所需关注的数据创建Dashboard、Panel等相关对象，并配置对应的查询条件。

   如对于上文空气监测示例中写入的监测数据，可以通过类似以下方式在Grafana上创建可视化查询，并查看其查询结果。

说明

关于使用Grafana接入Lindorm时序引擎的详细方法，包括定制插件的安装，查询条件的设置等等。都可以参见Lindorm时序引擎手册中的 通过Grafana访问Lindorm时序引擎。

5. 总结

综上所述，Lindorm时序引擎在时序数据应用场景提供了解决时序数据“存、算、管、用”的产品能力，是助力企业数字化、智能化转型的优良工具。Lindorm的产品首页地址：云原生多模数据库Lindorm。除公有云部署形态外，也支持专有云部署和纯软件化部署形态。欢迎广大用户垂询、试用。