一、时序数据库概述

（一）时序数据

时序数据，即时间序列数据，我们把按照时间戳的大小顺序排列的一系列记录值的数据称为时间序列数据（Time Series Data）。

时间序列数据（简称“时序数据”），顾名思义，是以时间顺序作为组织形式的数据。时序数据这一概念早期起源于金融行业，金融时序分析技术是考察金融变量随时间演变规律的关键技术，是金融量化分析的基础技术。对规模巨大的金融时间序列进行有效分析的前提是对时序数据进行有效管理。

在日常生活中，时序数据相当常见，比如，汽车的位置定位，在一段时间内某辆特定汽车的其他属性，包括型号、颜色、车牌号、所有者等都是不变的，但它的位置数据是随着时间变化不断在变化的，那么根据时间确定的位置值及其他属性所组成的一系列数据就是一组时序数据，当我们驾驶汽车开启导航时，就需要根据这一组时序数据判断接下来到达目的地的路线以及存储驾驶记录，在即将到来的无人驾驶中更是必不可少的。在互联网中，时序数据更是无处不在，比如，用户访问网站的记录、应用系统的系统日志数据等等。

近年来，时序数据的应用更为广泛，包括物联网（以前述汽车定位为例外还有各类传感器数据等）、经济金融领域、环境监控领域、医学领域、工业制造领域、农业生产领域、硬件和软件系统监控等各方面，都在大量使用时序数据，揭示研究对象的趋势性、规律性、异常性，而在5G 与人工智能的浪潮下，时序数据作为大数据、机器学习、实时预测、预警的基础数据的作用更加显著，因此，对时序数据的研究与应用更为深入。从前述汽车定位的例子可以看到，时序数据与关系型数据存在较大的差异：

最明显的特征是时序数据都存在唯一的时间戳，并且以时间戳大小进行排序，以时间戳作为唯一标识进行区分，而关系型数据通常有其他字段作为标识，比如学生的数据通常使用学号作为唯一标识进行区分。

时序数据的数据量持续呈线性增长，每隔一定时间粒度就会产生新的数据，将会持续产生海量数据，因此数据量庞大。而关系型数据的增长通常不是随着时间持续增长的，比如一所学校的学生数据量在一段时间内都是相对稳定的。

时序数据很少会有更新操作，在某个时刻的测量值产生将不会发生变化，所以几乎不需要对时序数据进行更新。对于关系型数据，则是已存在的数据经常发生更新，比如学生的个人信息，包括年龄、身高等属性。

（二）时序数据库

基于快速增长的时序数据应用需求以及区别于传统关系型数据的特征，时序数据库应运而生，时序数据库一般具有以下特点：

（1）高吞吐量数据高速写入能力。由于时序业务会持续产生海量数据，并且对写入的速度有很高的要求，写入的并发量大，这就要求时序数据库系统实现高吞吐量的数据高速写入功能。

（2）高压缩率。时序数据库需要存储大量的数据，并且有的监控数据可能需要存储很长时间，5 年到10 年都有需求，因此需要根据时序数据的特征对数据进行压缩。

（3）高效时间窗口查询能力。时序业务的查询需求分为两类，一是实时数据查询，反映当前监控对象的状态；二是主要是查询某个时间段的历史数据，历史数据的数据量非常大，这时候需要针对时间窗口大量数据查询进行优化。

（4）高效聚合能力。时序业务场景通常会关心数据的聚合值，比如count、mean 等聚合值来反映某个时间段内的数据情况，因此时序数据库需要提供高效的聚合函数。

（5）批量删除能力。时序业务对于过期的数据需要进行批量删除操作。

（6）通常不需要具备事务的能力。

时序数据库与传统关系型数据库不同，传统关系型数据库注重增删改查和事务功能，而时序数据库针对海量数据写入，其读取查询多是一段时间段内的数据。

（三）时序数据库的发展历史

图1 时序数据库演进历史

1、第一代时序数据库存储系统

虽然通用关系数据库可以存储时序数据，但是由于缺乏针对时间的特殊优化，比如按时间间隔存储和检索数据等等，因此在处理这些数据时效率相对不高。

第一代时序数据典型来源于监控领域，直接基于平板文件的简单存储工具成为这类数据的首先存储方式。以RRDTool，Wishper为代表，通常这类系统处理的数据模型比较单一，单机容量受限，并且内嵌于监控告警方案。

2、基于通用存储的时序数据库

伴随着大数据和Hadoop的发展，时序数据量开始迅速增长，系统业务对于处理时序数据的扩展性等方面提出更多的要求。基于通用存储而专门构建的时间序列数据库开始出现，它可以按时间间隔高效地存储和处理这些数据。像OpenTSDB，KairosDB等等。

这类时序数据库在继承通用存储优势的基础上，利用时序的特性规避部分通用存储的劣势，并且在数据模型，聚合分析方面做了贴合时序的大量创新。比如OpenTSDB继承了HBase的宽表属性结合时序设计了偏移量的存储模型，利用salt缓解热点问题等等。

然而它也有诸多不足之处，比如低效的全局UID机制，聚合数据的加载不可控，无法处理高基数标签查询等等。

3、垂直型时序数据库

随着docker，kubernetes, 微服务等技术的发展，以及对于IoT的发展预期越来越强烈。在数据随着时间而增长的过程中，时间序列数据成为增长最快的数据类型之一。

高性能，低成本的垂直型时序数据库开始诞生，以InfluxDB为代表的具有时序特征的数据存储引擎逐步引领市场。它们通常具备更加高级的数据处理能力，高效的压缩算法和符合时序特征的存储引擎。比如InfluxDB的基于时间的TSMT存储，Gorilla压缩，面向时序的窗口计算函数p99，rate，自动rollup等等。

但同时由于索引分离的架构，在膨胀型时间线，乱序等场景下依然面临着很大的挑战。

二、应用场景

在工业场景中，80%以上的监测数据都是实时数据，且都是带有时间戳并按顺序产生的数据，这些来源于传感器或监控系统的数据被实时地采集并反馈出系统或作业的状态。在工业上，通常会使用实时/历史数据库作为核心枢纽，对这些数据进行采集、存储以及查询分析。

传统工业控制领域，由于其自身的特殊性，有很多对实时数据处理的要求，特别是流程工业中，对各生产环节的监控要求十分严苛，需要通过监测数据实时反应出系统的状态，所以对于实时数据的处理十分看重，并且经过长时间的积累已经形成了一套独有的成熟的体系。对实时/历史数据库的应用是其中重要的一环，在工控领域已经有很多年的历史，实时数据库主要用于工业过程数据的采集、存储以及查询分析，以实现过程状态的实时监控。工业上的实时数据有这些特征：都带有时间戳，并且是按时间顺序生成的；大多为结构化数据；采集频率高、数据量大等。

以一个中等规模的工业企业为例，在流程监控的环节中，可能会涉及到5 万～10 万个传感器测点，每天产出的数据量能达到上百GB。在通常情况下，工业企业都会要求数据能够被长时间存储，这样可以随时查询到历史趋势。上述的需求显示出了传统实时数据库需要具备的一些能力，如因为测点多、采集频率高，所以要求非常高的写入能力；因为要求长期存储，所以需要强大的数据压缩能力；因为数据量庞大，所以要求快速的查询响应；同时最重要的是实时分析能力，能快速反映出系统的状态。表1 是传统工业项目中对实时数据库的考核要求。

表1 工业项目中对实时数据库的考核项

（一）工业生产

1、生产车间数据库需求分析

（1）数据特点分析

工业行业生产车间工艺复杂，生产设备多，产生过程中需要实时的进行数据采集。生产过程中涉及到的数据包括水分、温度、液位、流量、风量、频率等多种数据，这些数据在生产过程中实时产生，其产生频率快，每个监测点每秒能产生多条数据；这些数据依托于采集时间，每一条数据都有唯一的一个时间与之相对应；监测点的数据量大，整个生产车间约有十万个的监测点；这些数据极其的耗费磁盘的存储空间。经初步统计每个月的生产数据需要消耗近1TB的存储空间。由于是实时采集记录生产数据，对数据不需要进行频繁的更新和删除操作。

（2）数据存储分析

目前数据的存储主要是使用关系型数据库来存储。使用关系型数据库为了实现生产过程中数据的存储，一般采用降低数采频率的方法来实现。如几秒甚至几十秒才采集一个监测点的数据。关系型数据库的表模型是行列结构,含用来标识唯一行的主键或者多条索引,每一行标识一条记录,这样会存在大量冗余的属性数据,对磁盘空间产生极大的消耗。即使这样降低数采频率每月也能产生1TB左右的数据，极其耗费磁盘空间，使得数据存储成本上升。而且这样的做法也极大的降低了实时数据的精确性和可靠性，不利于数据的监控及分析。为了系统能较快的实现数据查询结果，会在关系数据表中建立主键或索引，面对高并发的数据写入时，需要不断的重建这些索引，极大的降低数据的写入性能。在数据存储达到一定数量级时，为了提高系统性能常采用删除历史数据的做法，这样对采集到的数据造成了极大的浪费，也使得给系统和数据的维护带来了极大的困难。

对于生产车间的实时、高频率、海量写入和存储的需求，关系型数据库表现的不尽人意。而时序数据库则能很好的满足需求。相对于关系型数据库它极大的减小了存储空间，减小数据的存储成本。时间序列函数不但有着优越的写入性能并且能实现较快查询性能和存储较长时间的历史数据，这使得数据的使用价值也有了极大的提高。

（3）数据访问分析

生产车间中控管理系统应具备实时化、自动化、智能化这些特点。中控管理系统需要实现生产过程的实时监测、进行完善的质量分析、故障监测及报备、综合管理等功能，而这些功能的实现需要建立在海量实时信息高效处理的基础上。为了使生产能够有序的进行，系统需要实时监测设备的运行参数、进行生产统计分析报表、设备负载分析及预测等功能。为了实现这些功能，数据库需要长时间的处于快速且高负荷的运行。而关系型数据库处于这种运行环境要实现这些功能会产生严重的性能瓶颈。当数据长时间处于无响应的状态时容易导致服务器宕机，严重影响生产任务。而时序数据库支持大规模的数据监测点，在普通服务器上能支持上百万个监测点。具有10万-60万事件/秒的数据存储能力、100万-800万事件/秒的数据访问能力。时序数据库这些优越的性能可以很好的实现生产车间中控管理系统的这些需求。

2、时序数据库在生产车间的应用

（1）趋势曲线

在生产车间应用中。采用关系型数据库进行数据采集时，因数采周期长，单个数采周期内时间跨度长、数值变化大。这样采集到的数据不能够准确的反应生产中设备的瞬时值，用此方式绘制出来的趋势曲线与实际状态趋势存在一定的差异，在显示精密趋势曲线时显然表现的不太可靠。而时序数据库可以很好的解决数据采集周期长的问题，因为它的采样频率能达到上千赫兹，也就是说时序数据库能在一毫秒内完成一个数据甚至多个数据采样周期，这样绘制出来的趋势曲线更加真实的还原实际状态趋势，较完整的再现数据的实时变化情况，这大大提高了数据的准确性，可为专业的分析人员提供高精度、高密度的数据来源，有利于产品质量及设备质量的分析。

（2）报警提示信息

工业企业生产车间对生产环境的要求较高。各个产品在每个工艺段的温度、水分、风量等要求不尽相同，当生产环境不符合要求时系统需及时报警，告知相关人员进行处理，需要对这些环境因素进行实时监测来确保生产环境符合工艺要求。除环境因素外生产过程中还有许多参数需要进行实时监测，如加香/加料精度、各流量秤的瞬时值、设备运行的电压电流、电机频率等。当参数发生异常时，管理系统能够对参数值进行判断及时发出并记录报警信息。因为时序数据库可以高密度、高精度的记录实时数据，相关人员可以通过分析发生异常前后的数据或趋势曲线来分析发生异常的原因，从而制定准确有效的应对措施。

（3）多平台多系统的数据共享

大部分时序数据库都实现了数据集成、协同、服务共享，并且提供了丰富的应用程序接口和服务共享调用。能兼容多种操作系统如：Windows、Linux等。支持多种编程语言：如C语言、C#、PHP、JAVA等，这种优越的兼容性可以方便的实现多个系统的数据共享。各个应用系统可以直接通过API快速的从数据中心获取到自己所需要的数据。实现多系统之间的集成、数据互联。如可以结合仓储物流系统实现物料运输及物料存储信息的共享、集成MES系统实现生产制造执行的数据共享等。集成多种系统使车间生产和管理更加多元化、智能化，使数据分析更加准确、专业、全面。

（二）设备运维

1、监测设备运维现状

（1）监测设备运维需求

伴随着监控设备数量的急速上升，在运行维护方面我们也遇到了新的压力和挑战。主要表现为：

A.监控设备的维护和替换代价高，很多设备是在恶劣环境下使用，容易损坏。

B.维护时间成本高。监控设备的分布非常零散，很多安装位置地点较为偏僻，这就造成了维护工作的强度提升，代价巨大。

C.故障判断困难，无法精准维护。尤其是当监控设备处于离线状态时, 我们很难判断故障原因是供电故障还是网络故障。这就造成了大量原本只需要断电重启即可解决的故障，我们却花费了更大的代价去到现场解决。

有鉴于以上三大问题，如何快速定为故障原因，进行远程故障排除，就成为了运维监控平台所急需解决的问题。

（2）当前运维平台的不足

根据我们的观察，当前现有的运维管理平台存在着很大的问题和不足，主要有以下三点：

A.监控运维平台可同时管理的监控设备数量有限，其性能急待提升。

B.监控运维平台的安全性和可靠性不足，产品没有进行冗余设计。

C.监控运维平台和前端数据采集设备兼容性不足，一些其他类型和其他厂家的监控设备，不能与之互通，也不能对已有设备进行升级。

因此，面对如此多的问题，基于时序数据库的通用监控运维平台就成为了我们的必要选择。

2、时序数据库在设备运维中的应用

简要来讲，我们可以将监控运维平台，划分为三大部分。他们分别为：状态采集设备、运维管理平台以及运维可视化系统。

状态采集设备，主要负责采集各种监控设备的运行状态和信息，比如，电源、网络、传感器等。其一般会被安装在前端设备的监控箱内，并具有通用性、可扩展性、高可靠性和易维护性的特点。当状态采集设备采集到数据后，其会将数据信息发送给运维管理平台。

运维管理平台主要负责接收、存储、管理来自状态采集设备的运行数据。也正是在此环节，时序数据库将展现他的强大作用。由于监控设备的状态数据具有明显的时序数据特征，所以在使用传统的关系型数据库方面，在存储空间、写入和查询速度以及可靠性方面都无法满足需求。因此，我们可以采用时序数据库来存储大量带有时序特征的监控设备数据，而其他非时序特征的业务数据则继续用传统关系型数据库进行存储。

最后，我们将这些存储的数据搭建出一套可视化的运维平台系统，通过对监控运维数据的可视化渲染呈现，我们可以为企业的智能化运维提供必要的支持。

图2 设备运维平台架构

综上所述，基于时序数据库的监控运维平台解决了传统运维平台设备故障定位困难以及运维成本高的问题。其提供了一种更加智能、低廉、高效的解决方案，并能支持大量监控设备的运维管理工作。其已经展现了巨大的经济效益和市场潜力。

三、现阶段应用痛点

随着物联网技术逐步渗透工业，不断增长的传感器、飙升的数据量以及更高的大数据分析需求对原有的技术架构提出了挑战。几个问题必须直面：

（一）扩展性遇到瓶颈

传统的技术架构虽然能保证单机具备极高的性能，也可以通过增加机器使性能线性扩展，但是不能像分布式系统那样实现动态灵活的扩容和缩容，需要提前进行规划。当业务升级需要系统扩容时，老架构的扩展性就很难满足需求了。

（二）无法和大数据生态对接

数据采集的最终目的是被理解和使用，大数据产业中对于海量数据的存储分析已经有很成熟的方案，不论是Hadoop 还是Spark 的生态圈，都面临着新老技术的对接。很多工业企业因为想使用新的大数据分析技术，不得不对现有的系统进行升级或是替换。

（三）价格高昂

传统的工业实时数据库解决方案价格都十分昂贵，一般只有大型企业能接受。但是随着新技术、新理念的普及，更多的中小企业也意识到数据的重要性，但考虑到资金投入，会倾向于寻找价格更低廉的方案。

四、应用及技术发展

随着工业互联网发展的需求日益清晰，在这两种数据库技术互相渗透的过程中，可以观察到一些技术的发展趋势。

（一）步向分布式架构转变

传统的实时数据库多是主备的部署架构，通常要求有较高配置的机器，来追求单机极致的性能；同时，在稳定性方面，会对运行软件的稳定性做极高的要求，完全由高质量的代码来保证运行的稳定；由于存储容量有限，也会要求超高的数据压缩比。但时序数据库的分布式架构，使得系统能够轻松地进行水平扩展，让数据库不再依赖昂贵的硬件和存储设备，以集群天然的优势来实现高可用，不会出现单点的瓶颈或故障，在普通的x86 服务器甚至是虚拟机上都可以运行，大大降低了使用成本。

（二）更灵活的数据模型

传统的实时数据库由于工业场景的特殊性，常使用的是单值模型，一个被监控的参数称为一个测点，在写入时会对每一个测点建一个模型，比如一个风机的温度指标算一个测点，10 个风机的10 个指标就是100 个测点，每个测点会附带描述信息（名称、精度、数据类型、开关量/模拟量等），查询的时候就会针对每个测点去查询数值。单值模型的写入效率会很高。

而时序数据库，开始采用多值模型，类似面向对象的处理方式，例如风机是一种数据模型，可以包括温度、压力等多个测量维度，还包括经纬度、编号等标签信息，这样对外提供服务时会更适合分析的场景。当然，单值模型和多值模型是可以互相转换的，很多数据库对外提供的服务为多值模型，但是底层存储还是单值模型。

（三）查询要求以及表现形式更多样化

在互联网时代，查询的要求已经不仅仅是满足于一些基础的条件查询或是插值查询，随着物联网场景的丰富以及人们对信息全面掌控的需求，基于地图的应用越来越多，查询会由时间的维度逐步扩展到空间的维度，除了保证实时性之外，更丰富的可视化的展现也是一大趋势。

（四）逐步转向云服务

传统的工业场景处理实时数据出于安全和性能等原因都会使用私有化部署。机器、软件以及后续的服务是一笔十分高昂的开销，还需要配备专业的技术人员进行系统的维护。当服务逐步上云后，一方面省去了购置机器的成本，不需要特别安排维护机器和软件系统的工程师，只需要懂得如何开发和维护业务就可以。另外，服务使用多少就购买多少，避免一次性购买服务造成的资源浪费或者资源不足再进行二次建设，可以为企业减少很大一笔开销。随着网络和云计算技术的成熟，相关的性能和安全性也会不断的升级，最终趋近于私有化部署的效果，服务上云已经成为了一个不可阻挡的趋势。

（五）逐步向边缘计算发展

工业领域是IoT 的重要试验田，工业互联网的发展势必会带来更多传感器的使用以及更多数据的采集。当数据过于庞大，集中化的处理方式就很难响应实时的数据分析需求，这就带来了数据计算向边缘的发展，需要实时响应的监控就通过边缘设备及时的处理并反馈，需要用于大规模分析的数据再进行集中存储，这种分级的处理方式能够有效地提升时效性数据的价值，同时减轻存储系统的负担，所以许多时序数据库正在研发边缘计算版本，并配合流计算的能力使功能更加丰富。融合了边缘计算的时序数据解决方案会更适合工业互联网的处理场景。

文章转载自网络 ，如有涉及版权等问题请及时联系我们。