转载

数据驱动型的 IoT 体系架构设计，第 3 部分: 高级数据抽象模型下 IoT 的次级数据扩展

数据驱动型的 IoT 体系架构设计，第 3 部分

高级数据抽象模型下 IoT 的次级数据扩展

场景扩展篇

宋辰

2019 年 4 月 24 日发布

系列内容：

此内容是该系列 3 部分中的第 # 部分：数据驱动型的 IoT 体系架构设计，第 3 部分

https://www.ibm.com/developerworks/cn/views/global/libraryview.jsp?contentarea_by=Internet+of+Things&search_by=%E6%95%B0%E6%8D%AE%E9%A9%B1%E5%8A%A8%E5%9E%8B%E7%9A%84+IoT+%E4%BD%93%E7%B3%BB%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1&topic_by=%E6%89%80%E6%9C%89+Internet+of+Things+%E4%B8%BB%E9%A2%98&type_by=%E6%89%80%E6%9C%89+Internet+of+Things+%E7%A7%8D%E7%B1%BB%E5%9E%8B&ibm-search=%E6%90%9C%E7%B4%A2

敬请期待该系列的后续内容。

此内容是该系列的一部分：数据驱动型的 IoT 体系架构设计，第 3 部分

敬请期待该系列的后续内容。

前言

在前序文章中，我们已经定义了一个完备的通用数据定义规则，对绝大部分类目的物联网设备都已经能够做到很好的覆盖。但是这个定义规则只是一套描述模式，可以足够充分的描述物联网终端的数据模型和系统表象，在对设备完成 1：1 的表述能力之外，仍然具备进一步更广范围的应用潜力。本文的主要目标就是针对这套定义规则的潜在扩展方向展开一些作者本人的思考，大概分解为下述几个场景：

结合边缘计算下的智能属性融合
多设备组合下的簇抽象设备概念
事件类记录与预聚合类记录
应用服务型高层抽象设备的封装

这些场景属于比较典型的物联网应用领域的前向扩展探索，当然除物联网方向外也存在其他方向如中台战略、业务系统等领域的部分场景应用。技术的诞生依赖于一个特定场景环境的孵化，但是技术的发展却并不受限于孵化地本身，合适的适配才能够给技术带来更大的价值。

边缘计算

由于物联网设备成本、功耗、体积等限制的存在，存在最为广泛的物联网设备往往都是一些简单且直接的传感器与控制器组合，能够做的也只有最简单的输入输出工作。简单的 IO 往往并不等同我们对与此类终端的最终性能要求，我们会要求基于这些输入数据的前提下进行一些组合运算、智能分析等等，从而产生出我们所希望的结果数据。产生这些分析数据有两种应用模型，一种是云端实时结构化分析，另一种是端分析。由于云分析天然存在对传输延时、传输带宽、公网联通性等外部环境的依赖问题，所以一般意义上我们采用的都是设备局部环境内通过近距通道接入一些分析机（一般为 PC/盒子）来实时分析的方式来扩展设备的这些能力，也就是这些能力并不能有终端本身来完成。

虽然数据并不直接由终端本身直接产出，但是由于终端是分析节点的注入的数据源，所以边缘分析的结果一般都唯一关联到源头终端（数据来源于多个终端的情况会在下一节说明），也就是严格意义上划属于基于设备根节点扩展的基础属性，进而也就可以进行直接的数据关联。即使是进行参数调配、算法调配，虽然有可能是批量成组的修改，但原子粒度也一定是映射到某个终端的分析标准，所以也都是可以认为针对于终端节点或者终端子节点的创建、修改操作。

为了更好的理解这个说明，我们设计一个场景，在监控网络环境下，我们设计一个客流量功能的扩展。现场通过一台部署在局域网内的服务器/分析机来实时接收作为 IoT 终端的监控点视频流数据，然后再通过分析机上的 CPU/GPU 来对数据进行实时的 AI 模型分析，从而判断出来当前视频中是否有移动、包含几个人，然后划定一条基线并定义一个正方向，再进一步引入通过客流与方向统计。

簇设备集合

某些情况下，我们的分析结果是以一组设备的汇聚数据流为输入的，这时候归属于簇类应用。换句话说，我们会抽象一个虚拟设备可以提供完备的功能，如针对同类型设备下，通过一个空间内所有的监控摄像头合成一个区域内的全域无死角全景画幅监控摄像头，然后构建全场目标实时追踪的能力。或是通过一个空间内散部在各处的温度感应器、湿度感应器、空气质量检测器的采集数据，定义舒适度函数来为一个虚拟的屋内舒适度监控器实时提供舒适度指数。

虽然数据来源可能来自于多个同类或者不同类型的设备，部分特殊场景下甚至在物理上相距很远的不同终端，但是数据的输出都可以认为是一个看起来像一个设备的虚拟设备代理的身份输出的。也就是说，我们将用来做数据输出的这个设备抽象出来成为一个定义的设备节点，理论上也可以清晰的满足使用者的需求。

针对客流相机，我们引入一个簇的应用场景，即区域客流。我们针对一个商场划分数个区域，在假定所有的用户流入流出能且仅能统计在有限个通道的前提下，可以在所有通道处都配置一个复合客流侦测功能的相机。针对区域我们构造一个虚拟的 区域热度 监控设备，通过聚合所有通道客流侦测相机的进出统计数据，我们就可以针对这个虚拟的区域热度监控设备注入一个实时更新的区域内当前的停留人数的属性了。当然，如果我们继续耦合人脸识别、人体识别、轨迹追踪等功能，这个虚拟监控设备就可以进一步扩充其功能集合，而从使用者的角度来看，这跟我们安装了一台神奇的能实时直接统计一整个区域内各类信息的设备并没有本质上的区别。这也引出另外一个建议指导原则，工程师应该致力于对于使用者尽可能缩小抽象需要理解的对象，同时尽可能简单化交互的界面。

事件

对于一个设备来讲除了可以读取的瞬态变量外，还有大量事件需要行为来进行记录。虽然原则上，这应该是来自于服务侧进行的应用策略，但是换个角度来看，事件亦属于创建后无法配置且无法更改的一种特殊节点，由设备的 ID 与流水创建的标示 ID 唯一的定位，对应一些典型的应用领域，包括阈值预警、特征抓取、定时任务等。而且这些应用场景一般都是针对一类设备设定的必备监控指标，关联于理论类型而不是设备能力也是定义体系的初衷之一。引入事件概念后，对应的物联网服务层就能进一步精简逻辑，扩充的原子能力也可以让应用开发者将更多的精力和事件分配到真正有意义的解决方案交付上。另外应用解耦的预处理能力，也可以进一步减低设备升级或者算法升级时对应用层迭代变更的依赖，在完全不干扰正常应用系统运行的前提下，大幅度提高团队协作效率和产出质量，预留足够的技术升级时间与空间。

继续拿客流相机来进行扩展，我们可以定义进入客流突破 1000 人的事件，每日清零，从而统计出来每日客流突破 1000 人的时间，即门店的热度。同时也可以另外定义一个事件是连续 1 小时内进入人数通过 100 人，从而发出门店热度预警，提醒运营人员及时确认相关变量发现引流要素。这类事件从多个维度上都可以快速检索分析，从而拟合运营策略的变更和调整，提供相关性分析依据。

事件-预聚合

事件类应用本身还可以进行一个扩展，也就是在大数据分析场景下的一种特例应用，即预聚合。我们在进行分析或者过滤的时候，一般会将数据进行聚合处理来分类甄别需要关注的对象。由于物联网设备很多情况下都是持续性的上报数据，直接进行全量聚合的话，会面临海量设备和海量采样点的计算，并且如果查询的频率较高，对应的计算代价和响应时间都会变得无法接受。但是这种查询有一个特点，每次计算在同样时间段内的数据都会重复演算多次，会有大量的算力浪费情况存在，所以理论上这种情况是存在优化方法的。以时间维度的统计为例，我们可以采用 量级下降 的方法，针对日常时间轴进行块级切分，如日、周、月、年为单位进行预聚合统计，这样就不用每次都全量扫描所有的原始数据点，而大幅度减少重复过滤查询下的系统性能消耗。

针对预聚合事件，一个非常典型的例子是针对 GPS 类坐标采集设备，我们可以按日聚合统计行驶里程，行驶范围，行驶时间，最高/平均行驶速度等，这些聚合后的数据都可以快速提升车辆用途的分类、车辆使用度统计等需要长时间坐标轨迹聚合分析的运行效率，让每次运算过程中的重复部分只需要做一次就可以了。

服务层应用的物联网化

这一个类目，实际上是想要引出一个概念，即部分的软件应用服务也可以抽象成一些智能硬件系统，即使所有的实现部分中除了用来承载的服务器外不存在任何物理意义上的设备，我们也可以从设备的角度来理解并使用一个应用。

虽然说我们的数据定义标准来自于我们对物联网设备的高层数据模型抽象，但是这并不等同于这套标准只能应用于物联网设备的模型定义。我们回归到这个数据定义的形式来看的话，可以发现任何可以使用五元组（ID、固有属性、可配属性、只读属性、功能函数）来进行完备描述（可以是五元组的一个子集）的应用，都可以套用这套描述模型。而应用模型所带来的最大优势，就是可以使用一个清晰的树状结构和说明来给应用提供一个解耦与架构化部署的理论与工具链支撑，尤其是在优化与重构系统的时候，可以快速理清系统的基础逻辑关系并提供可预期的性能提升参考，并且在提供最小粒度原子化操作的同时还可以很好的支持到读写分离、中台化等理念的实际落地。

比方说我们举一个图书管理的例子，我们可以将每一种图书抽象为一个物联网终端设备，从定义标准的角度这本书就具备了下述的描述结构（k-:ID，p- 固有，c- 可配，r- 只读，f- 操作）：

book:
  k-isbn:ID 是 ISBN 版号
  p-name:书名
  p-author:作者
  c-loc:所在书架
  r-num:可借数量
  f-buy:采购
  f-borrow:借操作
  record:
    k-bid:借书业务号
    p-user:借书人
    p-num:借书数量
    r-stat:当前是否归还
    f-back:还操作

通过这样一组数据描述，我们基本就可以清晰简单的完成对所有图书状态的管理，而不需要再通过大量的文档、接口、数据库表等文件来说清这样一个系统是如何工作和运作的。对于接口服务的使用者来说，也可以清晰的知道可以查什么数据、可以做什么操作，而不需要每次都去询问相关的产品或研发同学当前系统的能力范围和数据格式及维度了。

总体上来讲仅仅通过这样几行描述性的文字，就可以大幅度的提高各研发与产品人员的沟通与协作效率，并且通过对这样一套定义模型进行扩充，就可以快速完成对新功能的扩展与支持。而且图书管理的底层实现通过这样一套数据模式的约束，也可以很轻松的做到与业务应用的完整隔离，再配合全被动埋点的实现，又进一步可以获取到所有的数据变更记录，大幅度的减轻系统的复杂度与缩短整体方案交付时间。

结束语

个人还是认为一个好的架构设计，是应该有一套清晰的理论描述框架来进行基础指导的。而抽象出来的理论往往是高度概括的，适用范围则也是远不止诞生地这一个地方。很多的应用其实都是相通的，如果各应用场景下的研发工程师能够频繁的沟通并且都及时且善于总结，是完全可以做到汲取他人整理出设计思想的优势，并且结合自己的经验与场景给出更加有力的进化的。而且架构依赖的是思想而不是技术本身，如果认为对一些特定技术的有意识应用就是架构设计的话，很容易会因为本末倒置而让一个本来很简单的问题演变的更复杂。

如果引入架构设计并不能够让问题变得更加清晰移动、让方向更加明朗甚至过程中看不到新的创新机会，那么架构设计很可能就会越过围墙变成完全对立面的过度设计了；走的越远，对人力、时间、资源的浪费也就会越发严重，甚至还会进一步推升项目的运行维护成本。当然，我本人也是在漫漫架构路上的探索阶段，所见所想也不敢说就是完美的，但是至少在现在走的这条路上，在各种复杂场景的应用和问题解决角度上确实达到了我认为一个好的架构设计应该能达到的目的的。