(1)数据是时序的,一定带有时间戳:联网的设备按照设定的周期,或受外部事件的触发,源源不断地产生数据,每个数据点是在哪个时间点产生的,这个时间对于数据的计算和分析十分重要,必须要记录。

(2)数据是结构化的:网络爬虫的数据、微博、微信的海量数据都是非结构化的,可以是文字、图片、视频等。但物联网设备产生的数据往往是结构化的,而且是数值型的,比如智能电表采集的电流、电压就可以用4字节的标准的浮点数来表示。

(3)数据极少有更新操作:联网设备产生的数据是机器日志数据,一般不容许而且也没有修改的必要。很少有场景,需要对采集的原始数据进行修改。但对于一个典型的信息化或互联网应用,记录是一定可以修改或删除的。

(4)数据源是唯一的:一个物联网设备采集的数据与另外一个设备采集的数据是完全独立的。一台设备的数据一定是这台设备产生的,不可能是人工或其他设备产生的,也就是说一台设备的数据只有一个生产者,数据源是唯一的。

(5)相对互联网应用,写多读少:对于互联网应用,一条数据记录,往往是一次写,很多次读。比如一条微博或一篇微信公众号文章,一次写,但有可能会有上百万人读。但物联网设备产生的数据不一样,对于产生的数据,一般是计算、分析程序自动读,而且计算、分析次数不多,只有分析事故等场景,人才会主动看原始数据。

(6)用户关注的是一段时间的趋势:对于一条银行记录,或者一条微博、微信,对于它的用户而言,每一条都很重要。但对于物联网数据,每个数据点与数据点的变化并不大,一般是渐变的,大家关心的更多是一段时间,比如过去5分钟,过去1小时数据变化的趋势,一般对某一特定时间点的数据值并不关注。

(7)数据是有保留期限的:采集的数据一般都有基于时长的保留策略,比如仅仅保留一天、一周、一个月、一年甚至更长时间,为节省存储空间,系统最好能自动删除。

(8)数据的查询分析往往是基于时间段和某一组设备的:对于物联网数据,在做计算和分析时,一定是指定时间范围的,不会只针对一个时间点或者整个历史进行。而且往往需要根据分析的维度,对物联网设备的一个子集采集的数据进行分析,比如某个地理区域的设备,某个型号、某个批次的设备,某个厂商的设备。等等。

(9)除存储查询外,往往需要实时分析计算操作:对于大部分互联网大数据应用,更多的是离线分析,即使有实时分析,但实时分析的要求并不高。比如用户画像,可以在积累一定的用户行为数据后进行。但是对于物联网应用,对数据的实时计算要求往往很高,因为需要根据计算结果进行实时报警,以避免事故的发生。

(10)流量平稳、可预测:给定物联网数量、数据采集频次,就可以较为准确地估算出所需要的带宽和流量、每天新生成的数据大小。

(11)数据处理的特殊性:与典型的互联网相比,还有不一样的数据处理需求。比如要检查某个具体时间的设备采集的某个量,但传感器实际采集的时间不是这个时间点,这时往往需要做插值处理。还有很多场景需要基于采集量进行复杂的数学函数计算。

(12)数据量巨大:以智能电表为例,一台智能电表每隔15分钟采集一次数据,每天自动生成96条记录,全国就有接近5亿台智能电表,每天生成近500亿条记录。一台联网的汽车每隔10到15秒就采集一次数据发送到云端,一台汽车一天就很容易产生1000条记录。如果中国2亿辆车全部联网,那么每天将产生2000亿条记录。5年之内,物联网设备产生的数据将占世界数据总量的90%以上。

从工具维度看,时序数据处理工具与传统时序数据库的差异很大。后者局限于车间级的可编程逻辑控制器,而非企业级。企业级的时序数据处理,首先是基于数据架构和数据模型的。

数据架构决定哪些时序数据需要采集,如何处理,用于哪些业务场景,用于时序数据采集的规划与设计开发;数据模型用于解析时序数据的数据结构。

在物联网、车联网、工业互联网兴起之后,大家都想用通用的大数据平台来处理其中的数据。现在市场上流行的物联网、车联网等大数据平台几乎无一例外都是这类架构,但这套通用处理工具的效果如何?可以说有很多不足,主要表现在以下几个方面:

数字化工厂产生的时序数据量是巨大的,处理它有相当的技术挑战。以数控机床加工生产为例,由于工业行业的要求,需要将包括报警在内的各种工况数据存储起来。假设企业每个厂区具有2000个监测点,5秒一个采集周期,全国一共200个厂区。这样粗略估算起来每年将产生惊人的几十万亿个数据点。假设每个点0.5KB,数据总量将达PB级别(如果每台服务器的硬盘容量是10TB,那么总共需要100多台服务器)。这些数据不仅要实时生成,写入存储,还要支持快速查询,实现可视化的展示,帮助管理者分析决策;并且也能够用来做大数据分析,发现深层次的问题,帮助企业节能减排,增加效益。这样看来,需要解决的关键技术问题如下。

传统的数据采集体系面临着数据质量差、查询速度慢、缺少实时智能分析等问题。

(1)高并发、高吞吐量的写入能力:如何支持每秒钟上千万数据点的写入,这是最关键的技术能力。

(2)数据高速聚合:如何支持以秒级的速度对上亿数据进行分组聚合运算,如何能高效地在大数据量的基础上将满足条件的原始数据查询出来并聚合,要知道统计的原始值可能因为时间比较久远而不在内存中,因此这可能是一个非常耗时的操作。

(3)降低存储成本:如何降低海量数据存储的成本,这需要时序数据库提供高压缩率。

(4)多维度的查询能力:时序数据通常会有多个维度的标签来刻画一条数据,如何根据几个维度进行高效查询就是必须要解决的一个问题。

时序数据在各行各业有着广泛应用的,例如在电力行业智能电表、电网发电设备集中监测;在石油化工行业油井、运输管线运输车队的实时监测;在园区,在智慧城市实时路况、卡口数据路口流量监测,在金融行业交易记录、存取记录ATM、POS机监测,智能安防(楼宇门禁、车辆管理、井盖、电子围栏)、应急响应(消防、人群聚集、危化品、结构健康、电梯)等。

1、智慧城市、能源行业智能应急指挥和融合通信调度

智慧城市、智慧工厂智能应急指挥和融合通信指挥调度方案是采用数字化BIM+GIS+NBIOT+AI+5G+算法技术,围绕监控、指挥、调度、会议、通讯等多种功能合一的可视化指挥调度方案。在突发事件预警、上报、响应、指挥等各个环节实现及时有效的可视化指挥,满足突发事件现场实时图像传送和视频会商的快速响应需求。

2、园区智能巡检和安防

在各种园区日常巡检、隐患上报、三维地图以及融合调度上有很多应用场景。设备管理运行状态、HSE风险等级、工艺流程、过程控制运行参数等检修情况各类业务现场及管理实时数据及信息的直观展示,及时发现问题,分析原因,提出整改建议,并贯彻执行。

3、能源行业设备智能运维

物联网平台还可被应用于对海量设备终端的统一管理与运维,对设备的状态进行在线监测与诊断,并及时进行故障预警。还可以通过多维图表展示运维数据等。

与通用的大数据处理工具相比,它具备什么样的特点呢?

1、必须是高效的分布式系统

工业互联网产生的数据量巨大,比如,全国有5亿多台智能电表,每台智能电表每隔15分钟采集一次数据,全国的智能电表一天就会产生500多亿条记录。这么大的数据量,任何一台服务器都无法处理,因此时序数据处理系统必须是分布式的、水平扩展的。为降低成本,一个节点的处理性能必须是高效的,需要支持数据的快速写入和快速查询功能。

2、必须是实时的处理系统

对于互联网大数据的应用场景,大家所熟悉的都是用户画像、推荐系统、舆情分析等,这些场景并不需要数据计算具有实时性,批处理即可。但是对于工业互联网大数据的应用场景,则需要基于采集的数据做实时预警、决策,延时要控制在秒级以内。如果没有实时计算,则其商业价值就大打折扣。

3、需要运营商级别的高可靠服务

工业互联网系统对接的往往是生产、经营系统,如果数据处理系统宕机,则会直接导致停产,无法对终端消费者正常提供服务。因此,时序数据处理系统必须是高可靠的,必须支持数据实时备份,必须支持异地容灾,必须支持软件、硬件在线升级,必须支持在线IDC机房迁移,否则服务一定有被中断的可能。

4、需要高效的缓存功能在绝大部分场景中,都需要能快速获取设备当前状态或其他信息,用以报警、大屏展示等。时充数据处理系统需要提供高效机制,让用户可以获取全部或符合过滤条件的部分设备的最新状态。

5、需要实时流式计算各种实时预警或预测已经不是简单地基于某一个阈值进行的,而是需要通过将一个或多个设备产生的数据流进行实时聚合计算(并且不只是基于一个时间点,而是基于一个时间窗口进行计算)。不仅如此,计算的需求也相当复杂,因场景而异,应容许用户自定义函数进行计算。

6、需要支持数据订阅时序数据处理系统与通用大数据平台比较一致的地方是,同一组数据往往有很多应用都需要,因此,时序数据处理系统应该提供订阅功能:只要有新的数据更新,就应该实时提醒应用。而且这个订阅也应该是个性化的,容许应用设置过滤条件,比如只订阅某个物理量5分钟的平均值。

7、实时数据和历史数据的处理要合二为一

实时数据被存储在缓存里,历史数据被存储在持久化存储介质里,而且可能依据时长,被存储在不同的存储介质里。时序数据处理系统应该隐藏背后的存储介质,给用户和应用呈现的是同一个接口和界面。无论是访问新采集的数据还是10年前的老数据,除输入的时间参数不同外,其余都应该是一样的。

8、需要保证数据能持续、稳定地写入

对于物联网系统,数据流量往往是平稳的,因此数据写入所需要的资源往往是可以估算的。其中变化的是查询、分析,特别是即席查询,有可能耗费很多的系统资源,不可控。因此,时序数据处理系统必须保证分配足够的资源以确保数据能够写入系统而不被丢失。准确地说,时序数据处理系统必须是一个写优先系统。

9、需要支持灵活的多维度数据分析对于联网设备产生的数据,需要进行各种维度的统计分析,比如根据设备所处的地域进行分析,根据设备的型号、供应商进行分析,根据设备所使用的人员进行分析等。这些维度的分析是无法事先设计好的,而是在实际运营过程中,根据业务发展需求定下来的。因此,工业互联网大数据平台需要一个灵活的机制来增加某个维度的分析。

10、需要支持数据降频、插值、特殊函数计算等操作原始数据的采集可能频次较高,但在具体分析时,往往不需要对原始数据进行分析,而是需要对数据进行降频。时序数据处理系统需要提供高效的数据降频操作。不同设备采集数据的时间点是很难一致的,因此,分析一个特定时间点的值,往往需要插值才能解决,系统需要提供线性插值、设置固定值等多种插值策略。

11、需要支持即席分析和查询为提高数据分析师的工作效率,时序数据处理系统应该提供命令行工具或容许用户通过其他工具,执行SQL查询,而不是非要通过编程接口。并且查询分析结果可以很方便地被导出,以及被制作成各种图表。

12、需要提供灵活的数据管理策略一个大的系统,其中采集的数据种类繁多,而且除采集的原始数据外,还有大量的衍生数据。这些数据各自有不同的特点,有的采集频次高,有的要求保留时间长,有的需要保存多个副本以保证更高的安全性,有的需要能快速访问。因此,工业互联网大数据平台必须提供多种策略,让用户可以根据特点进行选择和配置,而且各种策略并存。

13、必须是开放的时序数据处理系统需要支持业界流行的标准,提供各种语言开发接口,包括C/C++、Java、Go、Python、RESTful等,也需要支持Spark、R、MATLAB等,方便集成各种机器学习、人工智能算法或其他应用,让大数据处理平台能够不断扩展,而不是成为一个数据孤岛。

14、必须支持异构环境大数据平台的搭建是一个长期工作,每个批次采购的服务器和存储设备都会不一样,时序数据处理系统必须支持各种档次、各种不同配置的服务器和存储设备并存。

15、需要支持边云协同时序数据处理系统要有一套灵活的机制将边缘计算节点的数据上传到云端,根据具体需要,可以将原始数据、加工计算后的数据,或仅仅符合过滤条件的数据同步到云端,并且同步可以随时取消,同步策略可以随时修改。

16、需要单一的后台管理系统

单一的后台管理系统便于查看系统运行状态、管理集群、管理用户、管理各种系统资源等,而且能让系统与第三方IT运维监测平台无缝集成,便于统一管理和维护。

17、便于私有化部署因为很多企业出于安全及各种因素的考虑,希望时序数据处理系统采用私有化部署。而传统的企业往往没有很强的IT运维团队,因此在时序数据处理系统安装、部署上需要做到简单、快捷,可维护性强。

时序数据的采集一般都是通过传感器自动进行的,包括光电、热敏、气敏、力敏、磁敏、声敏、湿敏、电量等不同类别的工业传感器。就某一个具体的物理量而言,数据采集是很容易的。但就整个系统而言,数据采集是相当复杂的,具体表现在以下几个方面:

1、工业数据的协议不标准

在现实场景中,往往会出现ModBus、OPC、CAN、ControlNet、Profibus、MQTT等各种类型的工业协议,而且各个自动化设备生产及集成商还会自己开发各种私有的工业协议,导致在实现工业协议的互联互通时出现极大的难度。很多开发人员在工业现场实施综合自动化等项目时,遇到的最大问题即是面对众多的工业协议,无法有效地进行解析和采集数据。

2、通信方式不统一

由于历史原因,采集的数据往往会通过局域网、蓝牙、Wi-Fi、2.5G、3G、4G等各种传输方式被传送到服务器中,导致各种通信方式并行存在,连接管理变得复杂。

3、对现有MES系统的数据获取难度大

在工业企业实施大数据项目时,数据采集往往不是针对传感器或者PLC,而是从已经完成部署的MES系统获取。这些系统在部署时厂商水平参差不齐,大部分系统是没有数据接口的,文档也大量缺失,大量的现场系统没有点表等基础设置数据,使得对于这部分数据采集的难度极大。

4、安全性考虑不足

传统的工业系统都运行在局域网中,安全问题不是考虑的重点。若需要通过云端(特别是公有云)调度工业行业中核心的生产数据,又没有充分考虑安全问题,则很有可能造成难以弥补的损失。

根据上述原因,企业在实际采集数据时,往往配有工业互联网网关盒子,该盒子支持各种物理接口、通信协议和工业标准协议,将不同协议进行转换,对数据进行安全加密,统一以MQTT(Message Queuing Telemetry Transport,ISO/IEC PRF 20922)协议或其他协议发往云端。

对于数据采集部分,因为标准性不够,就不对具体工具做介绍了。

采集后的数据一般通过网络被送往服务器或云端进行处理。相对数据采集工具而言,数据处理工具比较统一,下面对几个流行的工具进行介绍。

1、以PI为代表的实时数据库

从20世纪80年代起,就涌现一批实时数据库(时序数据库的一种),专门用于处理工业自动控制或流程制造行业的实时数据。其中美国OSIsoft公司的PI(PlantInformation)实时数据库最典型,它提供成套的工具,包括实时写入、实时计算、存储、分析、可视化、报警等系列功能,GE、Simens、Honeywell都有类似产品。国内有庚顿、朗坤、麦杰、力控等产品。这些产品在一定程度上满足了工业数据处理的需求,但在测点数量暴涨、数据采集频率不断提高的大数据时代,传统实时数据库暴露出以下问题:

1)没有水平扩展能力,数据量增加,只能依靠硬件的纵向扩展解决。

2)技术架构老旧,很多还是运行于Windows系统中的。

3)数据分析能力偏弱,不支持现在流行的各种数据分析接口。

4)不支持云端部署,更不支持SaaS。

5)在传统的实时监控场景,由于对各种工业协议的支持比较完善,实时数据库还占有较牢固的市场地位,但是在工业大数据处理上,因为上述几个原因,几乎没有任何大数据平台采用它们。

下面对几个典型的实时数据库进行介绍。

1、InfluxDB

InfluxDB由Golang语言编写,也是由Golang编写的软件中比较著名的一个,在很多Golang的沙龙或者文章中可能都会把InfluxDB当标杆来介绍,这也间接帮助InfluxDB提高了知名度。InfluxDB的主要特点包括:

• schemaless(无结构),可以是任意数量的列

• 可扩展(集群)

• 方便、强大的查询语言

• Native HTTP API

• 集成了数据采集、存储、可视化功能

• 实时数据Downsampling

• 高效存储,使用高压缩比算法,支持retention polices

• 数据采集支持多种协议和插件:行文本、UDP、Graphite、CollectD、OpenTSDB

InfluxDB是时序数据库中为数不多的进行了用户和角色方面实现的,提供了Cluster Admin、Database Admin和Database User三种角色。

2、Graphite

Graphite是分布式时序列数据存储数据库,容易扩展,具备功能强大的画图Web API,提供了大量的函数和输出方式。主要功能包括:

• 存储数值型时序列数据

• 根据请求对数据进行可视化(画图)

Graphite本身不带数据采集功能,但是你可以选择很多第三方插件,比如适用于collectd、Ganglia或Sensu的插件等。同时,Graphite也支持Plaintext、Pickle和AMQP这些数据输入方式。

Graphite使用了类似RRDtool的RRD文件格式,它也不像C/S结构的软件一样,没有服务进程,只是作为Python library使用,提供对数据的create/update/fetch操作。Google、Etsy、GitHub、豆瓣、Instagram、Evernote和Uber等很多知名公司都是Graphite的用户。

3、OpenTSDB

这是一个Apache开源软件,是在HBase的基础上开发的,底层存储是HBase,但其依据时序数据的特点做了一些优化。其最大的好处就是建立在Hadoop体系上,各种工具链成熟,但这也是它最大的缺点,因为Hadoop不是为时序数据打造的,导致其性能很一般,而且需要依赖很多组件,安装部署相当复杂。

OpenTSDB采用Schemaless模式,不用预先定义数据结构,因此写入灵活,但每个时间序列只能写入一个采集量,不支持多列写入。每个序列可以被打上多个标签,以方便聚合操作。总的来讲,OpenTSDB的性能无论是写入还是查询,都很一般,而且系统的稳定性欠佳。但吸引人的是,它支持集群部署和支持水平扩展。

以腾讯的CTSDB时序数据库为例,CTSDB是腾讯云推出的一款分布式、可扩展、支持近实时数据搜索与分析的时序数据库。该数据库为非关系型数据库,提供高效读写、低成本存储、强大的聚合分析能力、实例监控以及数据查询结果可视化等功能。整个系统采用多节点多副本的部署方式,有效保证了服务的高可用性和数据的高可靠性。CTSDB 在处理海量时序数据时具有的优势包括:

• 高并发写入:数据先写入内存,再周期性的 Dump 为不可变的文件存储。且可以通过批量写入数据,降低网络开销

• 低成本存储:通过数据上卷(Rollup),对历史数据做聚合,节省存储空间。同时利用合理的编码压缩算法,提高数据压缩比

强大的聚合分析能力:支持丰富的聚合查询方式,不仅支持 avg、min、max 等常用的聚合方式,还支持 Group By、区间、Geo、嵌套等复杂聚合分析。

4、TDengine

这是来自中国的开源软件,由涛思数据研发推出。它不仅是一款时序数据库,而且还提供缓存、消息队列、数据订阅、流式计算等系列功能,是时序数据的全栈技术解决方案。而且它不依赖任何第三方软件,安装包只有1.5MB,使系统设计、安装、部署和维护都变得极为简单。