4 数据平台
为什么会有物联网的数据平台呢？从某种程度上说，数据平台才是最具物联网特色的东西。虽然提到物联网，很多人脑海中第一个闪现的是传感网络，但实际上，如果你读过前几章就会发现，实际上所谓物联网，获得表征物体的数据是关键，而表征物体数据的获取办法很多，并不见得要另外加装传感网络——这一点在工业领域尤为明显。这是因为，因为工业领域自动化控制的需求，实际上很多关于机器的数据已经被获取了，只不过，这些数据暂时还局限在直接控制机器的控制系统中，没有被更大内涵的系统所用于更广泛的目的罢了。既然物联网的而核心在于表征物体的数据的使用，那么数据平台位于核心地位也就顺理成章了。
数据平台还有一个使其成为物联网核心商业模式和产品形态的潜质：数据平台是最容易产品化的。没错，虽然不同的业务对数据的最终利用方式千差万别，而不同行业现场对数据的采集获取手段也千差万别，但是数据的获取、存储和基本处理逻辑却是惊人的相似。
4.1 数据收发方式
在第1章中，我们把数据分为以下几类，从平台的角度上看，其手法方式一般也不同。
4.1.1 时序数据
时序数据是物联网数据平台的基本数据，也是物联网之区别于普通的面向人的联网应用的地方。时序数据的特点是，一般是均匀的数据流。也就是说，对于一个物体、设备，一旦开始发送数据，则一般是按照一定的采样周期发送的均匀、持续的数据。但是这并不是说物联网就没有一般面向人的互联网那种数据峰值-估值的变化。就以工业互联网为例，因为多数工厂是白天工作，所以很明显白天的日常工作时间端，比如说从8点到18点之间，数据处于一个高位的平台，因为一般这个时候设备都在上电运行。但是这种高位相对难以出现尖峰，因为设备时序数据一般都是均匀采集并发送到平台的。但是这也造成了另外一个问题：类似电网的峰谷差，我们在构建数据平台的时候，计算能力和带宽也必须按照预测的峰值来设计。对于油气管道之类的物联网，这个数据峰谷差可能基本上是不存在的，因为油气、城市水网等系统是全天24小时都处于工作状态的，其相关的数据也一直在向平台提交，而且和水网、油气的负载没有关系。但是对于离散制造业，一般是白天大家都在加工，所有的机器都在提交数据，而晚上只有少部分工厂在轮班工作，才会提交数据。总之，在构建数据接收模块乃至整个服务端的时候，物联网系统所服务的业务和客户的特点需要加以考虑。
时序数据在出现的时候一般是一个均匀的数据流。借鉴实时数据库的实现方式，我们在接收过程中要考虑数据在内存中的缓存，以防因为云端系统的算力问题丢失数据。所幸的是，目前大多数数据库都具有这种缓存能力。
另外需要注意的一点就是数据的重发。数据重发是数据平台和设备端之间的互动。当网络通道出现问题的时候，设备端可能会选择丢弃数据，但更好的实现方法也许是在就地存储未能发送到服务端的数据，并在网络信道畅通后集中发出。这样的策略虽然无法缓解数据的实时性所面临的挑战，但至少保证了数据在时间轴上的完整性。考虑到物联网服务端很多应用四基于统计和分析的，这种对数据完整性的保障经常是值得投资的，甚至是必须的。
4.1.2 事件数据
类似设备告警等数据是偶发的，虽然也带有时间戳，但是其一般没有特别的规律。此类数据的接受对及时性和完整性都非常强调，因为一个没能及时收到或者干脆被丢失的报警数据可能是致命的。当然也未必需要过度地追求，因为很多场合下并没有那么糟糕：现场的自动化控制系统还有第一道防线。也正是如此，在设计自动化系统的时候，必须要注意不能因为有更上一个层次的物联网系统而有任何的疏忽；而将原本属于自动化系统的安全保障工作转移到物联网系统中，更是不可原谅的错误。
4.1.3 指令数据
指令数据主要是从服务器发送到设备的。可能并不带时间戳，但是建议最好是带有，因为有时指令的有效性和时间可能有关系：互联网并没有保证数据包按照你预想的次序到达的能力，如果你的应用中很强调这一点就要自己建立识别指令次序或指令发出的时间的机制，以便抛弃过期的指令，或者按照正确的次序来执行指令。
4.1.4 文件数据
文件类数据是双向的，但是一般不强调及时性。只要文件被完整无误地传递即可。FTP等现成的协议很多，所以此类数据一般并不需要过多关注。但是无论如何，“无误”还是要关注的，起码的校验，如MD5，还是有必要的。
4.1.5 媒体数据
实际上为了配合组建完整的业务平台，有时还要加上媒体数据。主要是视频、音频的采集。此类数据，尤其是视频数据，实际上已经有很完善的解决方案。但是之前一般是在安防等领域应用的，并不太被理解为物联网数据。但是最近几年，随着AI识别等技术的应用，从视频图像中自动识别设备状态也成为一项设备故障诊断技术，所以此类数据也开始和物联网平台发生关联。比如某数控机床厂商开发的关于断刀的在线诊断，就是在加工中心中附加一个摄像头采集实时视频上传到服务器，由服务器判断是否发生了刀具断裂的事故。一旦系统判定发生断刀，会立即向加工中心发送停机指令以防止故障影响的进一步扩大。
4.2 数据存储
当然是采用各种数据库来实现。此时的选项其实很多。无论是SQL类关系型数据库还是NoSQL类菲关系型数据库都有自己的用武之地。典型的情况是将二者结合，两个数据库分别存储不同的数据类型，以期达到整个系统的最优化。物联网业务目前在各类企业中都还处于较新的业务，所以不确定性较大，数据库内部架构也可能会因此发生持续的调整。因此在设计关系型数据库表结构的时候要有一定的预见性，或者采用某些对此类情景有设计考量的数据库。
4.3 数据模型
为什么要提到数据模型？主要是我们要考虑到进一步的数据整合、交换和业务开发的过程。实际上数据模型在非物联网业务中已经开始了应用，因为大家都在力图寻找一种可以对不断变化的业务具有一定自适应能力的系统。而一个具有一定自解释能力的数据模型对开发普适的数据处理工具至关重要。以制造业为例，OPC UA协议就包含了一个可以自定义数据模型的机制，但是遗憾的是其并没有为各行业提供标准或者流行的模型。这种模型一般是某个企业、行业协会甚至国家标准组织来定义并在一定范围内执行的。而MTConnect协议则自带了一个建议的标准的机床模型，使得开发机床联网系统的时候，做一个可以对接不同厂商的机床的系统成为一种可能。
数据模型方面的工作迄今为止还是需要各行业不断努力去完善。
4.4 数据整合
数据整合的发起者实际上是上层的应用平台的各类业务逻辑，虽然人们因为这个过程叫做数据整个而将其归为数据平台。当然，这么做的原因也因为数据整合虽然与具体的业务逻辑息息相关，但实际上是可以抽象为各种可配置的算法和自动触发的服务的。市场上这种面向开开发者的物联网平台，其核心技术之一，如果不是最核心的技术的话，就是各种数据自动处理的引擎。这些引擎有的可以在人机界面上进行配置，类似工业自动化中广泛使用的组态软件，也有的只是一系列的API，需要采用某种开发语言去调用。而后一种情况下，开发者往往会在应用平台为数据整合提供一个自己定义的配置界面。
4.5 数据平台的计费
较早出现的数据平台一般采取虚拟机销售的方式。所以实际上是按照虚拟机的配置来收费的。虚拟机上的服务无论你是否使用、使用的量如何，并不影响费用的计算。而随着可配置化的数据整合引擎的出现和各类功能的服务化，越来越多的物联网平台开始采用按照服务收费的，更加细的粒度的收费模式。
4.6 数据平台案例
实际上，很多互联网背景的物联网平台基本上都是数据平台模式。如Amazon的AWS云。国内一些电信运营商的物联网平台，如中国移动的OneNET也是。此类业务的运营主体的特点是自身并没有可最终交付的物联网业务，但是具有网络带宽、计算能力等资源，另外业务层面追求规模，所以一般会走这条道路，也往往只能走这条道路。
上一篇：工业物联网：3 网络层（2）
下一篇：工业物联网：5 业务平台