物联网的数据方案.pdfVIP

物联⽹的数据⽅案 ⼀、前⾔ 经常可以在科幻电影/CG中看到，某个指挥官，对着前⾯⼀个超⼤的数据⼤屏，指点江⼭。那个数据⼤屏，上⾯有着各项指标，以及汇总数 据，通过各⾊各样的图形展⽰出来。 从产品⾓度，指标与汇总条⽬的确定，决定了该数据⼤屏的价值。当然也可以⽀持⾃定义指标管理等。这不是本次的重点。 从前端⾓度，如何利⽤最少的系统资源，将众多数据渲染出各个图表，则是重中之重。技术上，可以采⽤阿⾥AntV那⼀套等。这同样不是 本次的重点。 从后端⾓度，如何在满⾜数据请求内容的前提下，保证数据请求的⾼性能（低延迟，⼤吞吐量、⾼频次等），就是该场景下的要点。这才是 本次的重点。 ⼆、背景 作为物联⽹公司，需要向多个电⼒公司，进⾏数据⼤屏展⽰。其中数据⼤屏需要展⽰电⼒公司上百台风⼒发电机的状态，以及各项监控指 标。其中监控指标中包含倾斜值、震动波形、结构应⼒等。⽽其中震动属于⾼频采集，频次都是上千Hz的。即使⽤于计算倾斜值的倾斜传 感器，最低也是10/s。⽽监控⼤屏的数据，要求保证实时性。产品的要求是最好实时同步，最慢的指标也要保证5s⼀次的刷新率。最坑爹 的，各个监控指标都需要可以查看历史数据，以及实时数据。 如果按照震动数据来看，⼀条震动数据在数据库中的记录约为100字节，⼀个震动传感器每秒1000条记录，⼀台风机有4个震动传感器， ⼀个电⼒公司当前最多有100台左右风机。这样⼀来，⼀家电⼒公司每秒有震动数据40W条记录，约为40M。震动是记录数最多的传感 器，但不是带宽占⽤最⼤的类型，⾳视频占据的带宽更多。 当然，这是没有任何处理的情况，所以看起来⾮常糟糕，前端完全⽆法处理。光震动就得每秒渲染40W数据，前端开发会杀了你的。尤其 在历史数据的情况下，简直⽆法想象。 别说这能不能渲染了。我都得怀疑数据库和带宽是否可以承受了。毕竟还有别的公司，别的场景，以及别的传感器。 三、数据写⼊ 1.数据清洗 ⾸先，将⼀些明显不合规的数据，给清理掉。⽐如由于⼈为触碰导致的倾斜值跳动，⼈为作业导致的震动波动等。这部分过滤⽐例是很低 的，主要是为了降噪。 2.边缘计算 风机的某项指标，往往是由多个传感器计算得到的。⽐如倾斜值，往往是通过⼀组（⾄少三个）传感器，计算得到的。 所以，我们先需要在风机的边缘⽹关，进⾏协议解析，初始指标计算。 这部分的处理，往往会将多个数据，转为⼀个数据记录。过滤效果还是不错的。 PS：边缘计算，还应⽤在边缘⽹关的即时报警，以及机器关闭等操作。 3.采样上传 传感器的原始数据指标，是⾮常多的，⼀不留神就把硬盘打爆了，甚⾄是带宽。 ⽽其实往往我们并不需要这么多的原始数据指标。毕竟如果风⼒发电机要倒塌，也不会前⼀秒很正常，后⼀秒突然倒塌了。 所以，我们需要对原始数据指标进⾏采样上传。并且需要对传感器采集频率进⾏确定。 经过和业务、算法多⽅沟通&协商后，倾斜传感器的采样率定在了5%，应⼒传感器的采样率定在1%等。 那么，传感器的采集频率和数据上传的采样率，有什么区别&联系呢？ 前者表⽰数据采集了，⽽且可能落盘了。后者表⽰对采集到的数据，抽取⼀部分，上传到物联⽹平台。 那么，为什么不直接降低采集频率呢？ ⼀⽅⾯，部分传感器的采集频率是有其上下限的，不⼀定满⾜上传需求。另⼀⽅⾯，合理频率的原始数据，便于在发现问题后，进⼀步确定 问题。 所以，我们当时的处理，是原始采集数据直接本地磁盘顺序保存。并对原始数据进⾏采样，进⾏本地数据库保存，以及上传。 4.特征值提取 在某些垂直场景，我们需要计算出某些指标的特征值（平均值、⽅差），经过算法的计算，得出有关⽬标实体的结论。 ⽐如根据⼗分钟内的倾斜值平均值和⽅差，我就可以知道当前风机倾斜状况，并且通过⽅差，可以确定倾斜数据的稳定性。 5.分级采集 上⾯这⼀系列操作下来，数据已经过滤了七七⼋⼋。那么还有没有节省资源（功耗、存储、带宽等）的办法呢？ 正如上⾯提到的，风机就算要倒塌，也不会是⼀下⼦就倒塌了。所谓冰冻三尺，⾮⼀⽇之寒。咳咳，扯远了。也就是说，我们⽇常采集的监 控数据⼤多数是⽆效的。所以为了提⾼资源利⽤率。在经过与业务、算法的沟通后，我这边提出采集等级概念。即风机所属传感器平时只保 持低频采集状态，只有指标出现可疑情况，才会进⼊全功率状态。 ⽐如，震动传感器，由于⽆法降频与连续采样 （因为震动的信息隐藏在连续的⾼频数据中），故其采集成本最⾼，所以设定为每天随机时间 段连续采集10分钟。倾斜传感器每⼩时采集1分钟数据。当检测到可疑情况，如倾斜值超出⽬标阈值，则全功率状态。直到连续监测1⼩ 时，未出现可疑状况，则重新回归低频状态。 其