iot物联网平台建设(物联网IoT技术)

 

本文是2年前NB-IoT物联网刚火的时候研究撰写的，当时正值作者所在公司研制物联网水表，针对解决采集系统数据量以及生产检测过程中数据量的指数级增长，经过研究最终软件系统架构中数据库采用了工业时序数据库，通过增量形式完成海量数据的存储与读取。欢迎不同见解，欢迎互相探讨，E-Mail:279109777@qq.com

摘 要：随着智慧城市的发展，物联网和云计算技术首当其冲，预测到2020年世界上将有200亿到2000亿的物联网终端设备接入到网络。物联网平台承担着大量的物联网设备终端的高频度数据上报、异常预警以及后端大数据分析和挖掘功能。如何确保物联网平台数据存储的稳定，数据处理的高效是当前的技术瓶颈，那么选取一种优质、高效数据库技术就显得刻不容缓。本文主要结合我司实际项目研发，简单的探讨了当前环境下基于NB-IoT物联网平台的数据库建设。

关键字：物联网 NB-IoT 平台 数据库 时序数据库

随着智慧城市的发展，物联网（IoT）、云计算（Cloud Computing）是当下最具有发展前景的技术趋势。全球各大科技公司预测到2020年世界将有大约200亿至2000亿的物联网设备（ABI预测有300亿、Gartner预测有260亿、Oracle预测有500亿、Intel预测有2000亿）。NB-IoT（Narrow Band Internet of Things，基于蜂窝的窄带物联网）是IoT领域的一个新兴技术，是物联网中的一个重要分支。它支持低功耗终端设备在广域网的蜂窝数据连接，具有广覆盖、大容量、低功耗、低成本等优势。

互联网小常识：异常检测主要包括基于统计异常检测、基于数据挖掘的异常检测、基于神经网络入侵检测等。

NB-IoT在水务行业的使用中，最显著的特点就是广覆盖和大容量。在同样的频段下，NB-IoT比现有的网络增益20dB，其覆盖面积扩大100倍；其具有海量连接的支撑能力，一个扇区能够支持10万个连接。如中国电信部署了31万个基站，那么可以接入的物联网终端设备数将高达310亿个，这还不包括移动和联通的基站部署。

如此多的联网设备产生的数据都是动态数据，相比于传统的（静态）数据在管理要复杂得多，而最大的技术瓶颈在于数据量的大幅提升和实时处理性能要求上。在物联网系统的发展过程中，传感器单元的不断增加；数据采样的频率加快；数据保存的时间也越来越久；因此产生的数据量时非常庞大的，动辄将是几十亿、上百亿、千亿的规模；而且数据产生的频度也非常高，随着数量的上涨以每秒十万、百万级别增长；同时传感器单元上报的数据很多时候是用于异常、预警、趋势预测等，要求能根据异常预警及时反馈做出响应。因此对上报的数据在实时处理上有较高的性能响应要求。

那么在数据量剧增以及对数据处理能力要求非常高的前提下，我们对NB-IoT的数据库存储和响应服务可以尝试提出如下要求：

写入实时性：

1） 数据写入数据库，立即能被第三方应用程序使用；

2） 支持数据Ad-Hoc 点对点的查询和分析响应；

读写高响应性：

1） 因为主要为数据上报，与传统数据库和NoSql数据库正好相反，对数据库的写操作大大多于读操作，但是读和写都要求高速响应；

2） 数据主要以新增追加为主，少量进行更新操作；

3） 数据新增追加主要按照时间写入为主，但是也要有时间顺序错乱时的容错处理机制；

4） 按照时间顺序建立索引机制；可以按照时间索引进行删除，也可以在给定时间段索引范围内，根据指定字段进行精确、模糊查询；

5） 读写并发要求响应性能高，尤其时读写同时并发，以及读并发；

6） 海量数据的存储支持（T-P 级别）；

检索和分析便捷性：

1） 支持过滤（Filtering，条件范围过滤数据集）、投影（Projection，快速获取索引中属性，减少和数据库的交互）和分面（Faceted Search，垂直分类搜索）检索分析；

2） 支持聚合分析（Aggregation Analysis），即多维度分组呈现可分析性数据；

3） 支持关联分析（Relational Analysis），即通过类似关系型数据JOIN关键字关联多个数据进行数据呈现；

4） 通过以上方式实现数据挖掘（Data Mining），即通过分类（Classification）、估计（Estimation）、预测（Prediction）、关联（Association）、聚类合（Clustering）以及复杂数据类型挖掘（文档、Web、图形图像、视频、音频等非结构化数据）来挖掘信息背后的可利用性；

高可用和高可扩展性：

1） 高可用和高可扩展性也是传统关系型数据库以及非关系型数据库解决单点故障，确保数据库稳定运行的瓶颈技术点之一。即要确保数据库可以7x24小时在线稳定运行，而且在资源不足的情况下可以按需要随时在线增加节点以实现水平扩展；

目前我们所使用的数据库技术分为关系型数据库（Relational DataBase，如：SQL Server、Oracle、MySQL）和非关系型数据库（Not Only SQL，如：Redis、MongoDb、CouchDB、Oracle BDB）。关系型数据库具备复杂的检索分析能力，但是其受限于数据库方式导致其读写速度不足；非关系型数据库具有良好的性能和可扩展性，读写速度很快，但是其受限于数据库的列存储方式导致检索和分析能力不足；

由此可见，目前传统的关系型数据库与非关系型数据库等都无法满足NB-IoT系统平台对数据库的要求。

那么是否有一种数据库能满足我们的NB-IoT系统平台对数据库的要求？答案是有的，而且是有成熟的数据库能满足我们的要求，它叫做：时序数据库。

时序数据库（Time Series DataBase，TSDB，如InfluxDb,OpenTSDB,Kairosdb），全称为时间序列数据库。维基百科的解释是：A time series database（TSDB） is a software system that is optimized for handling time series data, arrays of num bersindexed by time ( a datetime or a datetime range). 简单翻译过来就是时序数据库是一种用来存储时序列（time-series）数据并以时间（时间点或时间区间范围）来建立索引的软件。它拥有了关系型数据库的检索和分析的关联规则优势和非系型数据库读写响应快的列存储方式两大优势。

目前已经有了许多开源的或商用的时序数据库，我们就以我司在用的OpenTSDB为例，来简单介绍：

OpenTSDB是基于HBase存储时间序列数据的一个开源数据库。

存储到OpenTSDB的数据，是以metric为单位的，metric是一个监测项，譬如假设，我们采集一个水表的使用情况，发现该水表在凌晨3:00的时候，水表的一组上报数据：流经水表的瞬时流量是0.05立方米/时、正转累计流量是132.55立方米、电压是3.5伏特、安装点信号强度是88、累计运行时间是466小时等这些metric；

互联网小常识：RIP是一种分布式、基于距离向量的路由选择协议；一个计算题：路由信息协议的工作过程：初始化的路由器只包含所有与该路由器直接相连的网络的路由，其它均为0；更新和维护：路由表建立以后，各路由器会周期地向外广播其路由表的内容。当一个路由器收到路由表内容时就与在自己的路由表中寻找，如果没有就将该路由项加上与该路由器的跳数，加入自己的路由表中，如果有则比较，取较小者。

结合以上数据，我们来看看OpenTSDB存储的核心概念：

1） Metric：监控单元，也就是我们通常理解的监控项；比如上面监控的一组水表数据；

2） Tags：标签项，在时序数据库中，Tags由tagk和tagv组成，类似key-value关系一一对应。标签是用来描述Metric的，譬如我们上面标记的瞬时流量、正转累计流量、电压、信号、累计运行时间等都是一个个的标签项；

3） Value：表示一个Metric的实际值，譬如上面的一组数据；但是对应的存储可能是多列或者以特定方式存储；

4） Timestamp：时间戳，用来描述存储的Value值上报的时间节点，譬如上面描述的3：00；一般是一个Unix的时间戳，通常使用秒级别以上精度（比如influxdb里面是nano秒），具体以实际监控项的业务要求来确定。比如水表行业可能使用时间戳间隔为每5分钟等；

5） Data Point：某一个Metric在某一个时间节点的值。Data Point包括一下部分：Metric、Tags、Value、Timestamp，上面描述的水表在凌晨3：00上报了一组数据，就是一个Data Point；将每个时间节点上报的数据都存储到OpenTSDB数据库，那就是无数个Data Point，最后进行数据分析和挖掘；

我们了解了OpenTSDB时序数据库的核心概念了，那么我们来看一下它是如何存储的。比如一个Data Point（即一块水表凌晨3：00上报的一组数据）的核心概念项为如下：

Metric（name）：100716120001（水表编号）

Timestamp：1234567890（表示一个Unix时间戳）

Value：133.55

Tags：instanflow=0.05,battery=3.5,rssi=88,runhour=466

因为OpenTSDB是基于HBase存储的，所以存储会有两张表，tsdb和tsdb-uid，一张用来保存数据，一张用来保存一些metric、tagk、tagv的映射关系，两个表之间通过唯一关键标识字RowKey进行弱关联。

为了数据分析和数据挖掘，一般我们设计一条数据的RowKey，会包含至少一个指标和一个标签，这样的数据才是有意义的，利于检索和分析的，所以我们RowKey设计一般为如下格式为最简单的设计：

RowKey：metric|timestamp|tagk1|tagv1|[tagkN|tagvN]，所以上述数据的RowKey设计为：

RowKey：

100716120001 |1234567890|instanflow|0.05|battery|3.5|rssi|88|runhour|466

针对水表行业的NB-IoT水表上报数据频率，为了减少存储空间，针对同一天作为时间前缀，而且对于变化频度大的tagk标签属性我们作为value存储，那么我们的RowKey设计为：

RowKey：metric|timestamp

RowKey：100716120001|20180507030000 + 偏移量

参见下图的tsdb表的存储设计：

为了能提高数据分析性能和业务要求，我们针对RowKey也会做双向映射，故数据存储在tsdb_uid 的表设计为：

从以上的核心概念介绍以及针对水表上报数据的表存储结构设计来看，因为数据的存储是基于HBase的，所以与NoSQL的列存储类似，但是它有因为可以自主的扩展很多的列，又朝着关系型数据库的设计贴近，同时OpenTSDB又不需要受到范式的限制，所以说针对物联网（IoT）的定时上报大量数据的业务来说，时序数据库技术是完全符合和适用于我们的NB-IoT的物联网平台对后台数据库的要求。

总结

本文简单的讨论了基于NB-IoT的物联网平台在数据库方面的需求，提出了时序数据库的技术特点，并针对其中一种时序数据库（OpenTSDB）进行了简单的介绍和对于水表数据上报业务在使用上的初步设计。目前我司正在研究和使用OpenTSDB作为NB-IoT平台的数据存储技术，接下来，还有比如数据压缩、拘束均衡性、查询性能、设计方案的优缺点以及数据分析等很多方面的评估和研究。希望更多的有兴趣水务同行和技术同行和我们一起共同探讨和研究。

参考文献：

[1] 赵华.时间序列数据分析：R软件应用.清华大学出版社，2016.

[2] 郭宝,张阳,顾安,刘毅. 万物互联NB-IoT关键技术与应用实践. 机械工业出版社. 2017.

[3] [美]Jean-Marc,Spaggiari.Kevin. HBase 应用架构. 中国电力出版社，2017.

[4] 黄健宏. Redis设计与实现.机械工业出版社,2017.

[5] 黄晓君,周志斌. 浅谈远传水表系统. 科技信息学术版,2008（16）：260+262.

互联网小常识：因为蓝牙技术可以方便地嵌入到单一的CMOS芯片中，因此它特别适用于小型的移动通信设备。

免责声明：本站所有信息均搜集自互联网，并不代表本站观点，本站不对其真实合法性负责。如有信息侵犯了您的权益，请告知，本站将立刻处理。联系QQ：1640731186