【项目总结】关于数据采集处理系统的抽象模型

为什么要写这一篇文档呢？最近刚刚参与了一个工业采集软件，不断的想怎么才能把这个工业软件写好，也得到了一些感悟和总结，希望这篇文档能够记录下来，和大家探讨，共同进步。

这个工业软件实际很简单，就是一个数据采集系统，有打印功能，也有显示功能。看上去一个简单的功能，要把每个小功能写好，考虑到各种场景和异常处理，其实也要费不少代码。代码一多，考虑到可维护性，就需要将代码细分成独立解耦的一些小模块，把问题聚焦在小模块内进行解决。这篇文章就是讲讲对这种数据采集系统解耦的一点总结

数据采集系统的模型一般分为数据输入（采集）子系统，数据存储子系统和数据显示（人机）子系统；说到这里，是不是有点像计算机的冯诺依曼的模型，我自己也吓一跳，感觉就是一回事，看来不总结不知道，一总结才知道伟人的抽象能力强大。

数据输入（采集）系统，主要目的是采集到外部的输入数据，这些数据如果是已经是处理好的，有明确含义的，那就照着存储；但是这些数据往往不是处理好的，是传感器直接生成的，含有干扰的数据，需要进行一些过滤处理；这个时候就需要在数据采集这个环节，有一道存储，存储的目标是能够将数据的干扰信息过滤。怎么过滤，这个跟采集的对象，和要过滤的算法有关，如果采集10个数据，就能够通过算法完成过滤，那就暂时存10个；如果需要存100个，那就存100个；或者要按照其它维度来存，只要能够达成过滤的要求即可。这个时候如果是固定数量，那么可以采用数据；如果数量不固定，那么可以采用链表。

数据显示系统，则是要考虑数据能够实时显示出来，这个时候应该显示采集过滤后的数据，这些数据才是真实，客户想看到的数据。根据业务（不是采集结果）是连续性数据还是离散数据，如果是连续性数据，则需要平滑掉采集的离散时间，显示的时候采用固定的频率，逐步的把采集的数据显示出来。当然这个需要根据采集系统的特点，有的采集系统实时性比较高，则可以直接在采集系统中直接触发显示。为了兼容性强，建议将显示的数据进行独立的管理：包括显示频率、显示了哪些数据，还有哪些数据未显示。数据本身可以和采集的结果数据共用一个临时数据存储系统，用于显示数据存储。

数据存储子系统，则是要考虑正式数据的存储，这个时候，也根据业务的需要分多级存储，有的是先暂时存储起来，在业务经过分析后，再确认进行永久存储。所以，这个时候，需要有个暂时存储结构和永久存储结构，暂时存储结构可以放在内存里面，也可以放在永久存储的数据库和文件中（这时需要和正式存储的内容区分开，在用户确认不用存储后，这部分数据就作废删掉）；另外就是永久存储，存储则是需要设计数据库或者设计文件格式来进行存储。

除了以上三个简单的划分，现在还有一个系统叫数据分析子系统，这个则是根据传入的数据进行数据分析，将业务的一些规则和数据算法结合起来，自动发现一些异常、判断数据质量或者联合业务提供其它的数据联合进行分析，给出业务一些建议。这部分考虑到有可能和上面的是三个是同步的，加上数据分析，根据复杂度不同，需要的计算能力和存储能力差异非常大，对于复杂的诉求建议独立的数据结构，独立的进程或者线程，甚至建议采用网络协同进行处理。

以上是我简单的总结。由于具体的系统涉及到具体企业的业务，暂不附上，大家如果有诉求，可以单独讨论。