技术干货丨丢失的数据，理性的选择
【摘要】：
数据采集和数据传输是工业互联网的起点，没有最初从设备上采集到的数据以及将数据传输到对应的平台，也就谈不上后续对数据的分析和应用。但是在真正的工业现场，可能会遇到传输网络故障等问题导致的数据发送失败，对这些未能成功发送的数据该如何处理呢？
数据采集和数据传输是工业互联网的起点，没有最初从设备上采集到的数据以及将数据传输到对应的平台，也就谈不上后续对数据的分析和应用。但是在真正的工业现场，可能会遇到传输网络故障等问题导致的数据发送失败，对这些未能成功发送的数据该如何处理呢？有人说，可以把它们在采集终端存储下来，等传输网络恢复正常后再发送出去，单纯从技术上来讲这没有问题，但一般情况下，智物联并不会这样做，而是任由这些数据“丢失”，这是为什么呢？
首先，是采集终端需要预留的存储空间难以确定。原本数据从采集到整理再到发送，是一个线性的过程，如果要求留存未能发送成功的数据就需要增加采集终端的存储空间，而这又取决于我们想保存多长时间的数据。十分钟？一个小时？还是一天？无论我们如何去设定，总会存在突破预设上限的可能，超出预设存储空间的数据依然会丢失，这个问题并没有得到彻底解决。
其次，是会增加采集终端的工作量，进而影响效率。假设我们通过增加存储保留了发送失败的数据，当传输网络恢复后要进行这些数据的发送，那么是打断现有正常的数据发送进程优先发送它们，还是等到采集终端“有空”时再发送，或者采用其他的方式？无论怎样，都需要对采集终端的程序进行相应的调整来完成数据发送的调度，这既增加了采集终端的程序逻辑，也可能因为需要额外把时间花在之前发送失败的数据上而影响其工作效率。
▲ 工业现场设备物联网方案示意图
最重要的是，如果采用数据暂存再补发的方式，会因为采集终端与MixIOT平台对数据的时间处理方式不同而带来巨大的算力成本。这里我们要引入两个概念：
“时间戳”（Time Stamp）和“时间序列”(Time Series)。
◆时间戳是根据每个数据采集到的精确时间所做的标记；
◆时间序列是根据数据产生的先后顺序排列而成的数列，并不关注数据的精确时间。
假如现在发送失败的数据需要进行补发，那么就需要在采集终端对这些数据打上时间戳，让MixIOT知道这些数据是什么时候采集的，并对采集终端和MixIOT进行同步时间校准。而MixIOT是以时间序列方式来处理数据，之前发送过来的数据已经按先后顺序保存到了数据库，如果现在再接收到补发的数据，MixIOT就要根据这些数据的时间戳，分别找到对应的时间位置，挨个儿“放入”这些数据，原有的数据也要相应地向后挪动，这需要消耗极大的算力，这种算力成本最终也会反映在智物联产品的终端价格上，自然也提高了客户的采购成本。这些发送失败的数据值不值得我们付出这样的成本呢？根据我们的经验，在实际工业互联网解决方案中，这种付出绝大多数时候是得不偿失的。
综上所述，对于发送失败的数据进行暂存处理并补发的方式，对于智物联来说不是“做不到”，而是“没必要”，让这些数据丢失是在综合考量下做出的理性选择。至于为什么MixIOT要采用时间序列而不是时间戳的方式来处理数据，这同样是一个“没必要”而不是“做不到”的问题，这里不多赘述。
要更好地理解上面这些论述，我们可以设想一个场景：
一场全球直播的大型运动会开幕式，各国队伍应该按顺序入场，其中某国有几个队员迟到了，这个时候是让所有人都停下来等待(等多久还不知道)？是重新调整所有队伍的入场顺序？还是先让各支队伍按原有顺序行进着，等那几个队员赶到后再在全球观众众目睽睽之下从后面跑到自己的队伍里去？我们肯定会说这些方式都不合适，应该让这几个队员放弃参加开幕式，因为开幕式的入场不像阅兵式，对每个人位置有那么严格的要求，几个队员的缺席并不会对活动的成功造成多大影响，但是开幕式也涉及上上下下多个部门、多个环节，为了这几个队员而进行流程的调整却会造成相当的损失，此时，这几个队员就可以被视为这场开幕式中“丢失的数据”。
当然，在现实中有可能会有某些重要时刻的数据不能丢失的情况，也可能会有数据完全不能丢失的情况，对前者我们可以采用“插值”的处理方式（通过计算确定某些重要时刻的数据，并不是对数据的时序进行重排，针对连续变化数据、开关量变化数据以及两者关联变化的数据又有不同的插值计算方法），对后者我们也可以把MixIOT做成时间戳机制的，只要客户能够承担这些处理方式所对应的额外成本，对智物联来说也不是什么难事。
所以，在很多时候，我们不应该追求解决所有问题，而是在平衡各种因素后找到一个最优解，放弃一些无关大局的细枝末节，或者通过其他方式回避掉一些枝节问题的处理。就像火箭发射，我们没必要给火箭一层层加上防雨罩、防雪罩、防沙罩，从而提高对发射动力的要求，加大火箭发射的复杂性，只需要找个晴空万里的时间窗口，点火，搞定。
如有疑问或想了解更多，请咨询：0755-23740592
