近年来，物联网IoT(Internet of Things)技术的研究和发展引起了人们极大的关注，物联网被认为是继计算机、互联网、移动通信网之后信息产业的又一重大里程碑^[1]。物联网技术已经应用到各行各业，在生态环境监测领域中也被广泛应用^[2,3,4,5]。在生态监测方面，基于物联网的生态监测系统能与已有监测网络有机集成形成天地一体化的综合监测系统，实现遥感—地面同步、大范围、多方位、全天候持续地监测，增强生态监测的立体化、自动化、智能化水平^[6]。

对于生态监测物联网而言，其数据感知采集设备能够实时获取其所部署区域内的监测目标的各种生态信息，这大大提高了生态系统关键参量获取的科学性和时效性。但其数据感知采集设备目前缺乏统一技术标准的约束，不同厂商的数采仪，或同一厂商的不同型号的数采仪，在数据接收、存储、无线传输协议、服务器端数据管理方式等多个方面都各不相同，这使得生态监测物联网多源异构数据的自动获取和自动汇总入库成为一个复杂的过程。在2012年开展的黑河流域生态—水文过程综合遥感观测联合试验HiWATER(Heihe Watershed Allied Telemetry Experimental Research)^[7]中,采用无线传感器网络采集数据也面对类似的问题。异源WSN(Wireless Sensor Networks)观测仪器归一化数据接口和自动入库系统^[8]初步解决了这一问题，并在野外观测数据自动综汇系统^[9]中起着重要作用。但是上述面向WSN观测系统的归一化数据接口和自动入库系统存在一些瓶颈，并且不再适合将其应用于生态监测物联网。首先该系统采用Perl语言研发，由于Perl语言对面向对象特性的支持不够，设计的程序扩展性不佳，这对后期的系统迁移、运行维护、功能升级，以及新设备加入后系统的扩展造成了不利的影响。其次该系统调用Windows API的相关函数，依赖Windows平台相关功能。软件模块间的通信采用Windows命名管道（命名管道是一种简单的进程间通信机制），需要服务器和客户机，同时也需要创建、等待、连接、发送数据、接收数据、关闭等一系列操作。这不但降低了该系统迁移和使用以及方便性、灵活性，也降低了稳定性、兼容性和运行性能。

基于以上分析和研究结论，将生态监测物联网多源异构数据全自动采汇业务流程独立出来，设计成一款通用的数据自动采汇中间件，并且以Python面向对象的理念设计实现。该中间件为一个能够紧密衔接野外硬件观测网络与后端观测数据管理平台的数据自动采集综汇组件。其放弃了进程间通信的命名管道技术，使其完全实现跨平台，能够运行在目前主流的操作系统之上。设计实现的中间件具有良好的性能、稳定性、兼容性、跨平台性和可扩展性，能够实时获取数采仪采集的各种类型的监测数据，并且将这些监测数据归一化后自动存入监测数据库。

面向生态监测物联网的逻辑架构设计为5层：数据感知采集层、传输接收层、数据自动采汇中间件层、数据管理层和用户交互层，如图1所示。

(1)数据感知采集层：数据感知采集层主要是在野外部署的获取多种生态环境要素的各种类型的传感器，以及与其相连接的数据自动采集仪。这些设备负责感知、获取生态环境信号并转换成真实观测数据。

(2)传输接收层 ：传输接收层主要是对获取的监测数据，采用可行的通信手段(GPRS、3G、4G、微波、有线等)传输到指定的数据接收服务器，并被服务器上部署的硬件厂商提供的数据接收软件定时接收，然后以一定的形式（文本文件、Excel文件、专用数据库等）保存。

(3)数据自动采汇中间件：数据自动采汇中间件主要完成数据自动获取，把获取的多源异构数据自动汇总存入数据库和存入FTP(File Transfer Protocol)文件夹。该中间件首先轮询获取监测数据，然后将获取到的数据发送给数据解析处理模块，由该模块解析处理后实时存入FTP数据文件夹和数据序列，自动入库模块的入库进程持续读取数据序列并把监测数据存入数据库管理系统。

(4)数据管理层：数据管理层主要采用数据库和文件系统。FTP服务器中的数据文件和备份数据文件大多是以异构文本文件的形式存在的，这类数据的管理主要采用文件系统，对解析处理之后的监测数据主要采用关系型数据库管理系统。

(5)用户交互层：用户交互层包括在线信息平台、Web前端、FTP客户端等。Web前端应用主要向用户提供数据查询浏览、数据多维可视化、数据报表^[10]，以及其他的应用功能；同时用户也可以通过FTP客户端软件访问FTP服务器，下载监测数据的原始备份数据。

在上述的生态监测物联网架构中，数据自动采汇中间件起着重要的作用，是数据感知采集和数据存储之间实时监测数据流的自动传输通道，保证了野外生态监测物联网系统的数据采集、解析、传输过程是一个高实时、无需人为干预的全自动过程。因此设计开发高性能、稳定，易于扩展、迁移、维护的数据自动采汇中间件具有重要意义。

根据高内聚，低耦合的模块化设计原理^[11]，数据自动采汇中间件从监测数据的获取解析到入库，按照功能划分为数据自动获取模块、数据自动解析处理模块和数据自动入库模块。

数据自动获取模块的主要功能是实时获取数采仪采集的各种类型的生态监测数据流，并将数据流发送给数据自动解析处理模块。

数据自动解析处理模块的主要功能是将数据自动获取模块发送过来的实时监测数据流解析处理，归一化后应用于构建特定格式的数据序列、存入FTP数据文件夹、写入备份文件夹。

数据自动入库模块的主要功能是读取数据序列中暂存的实时监测数据流，然后将这些流式监测数据存入数据库。

上述的3个模块以实时数据流为纽带，与生态监测物联网中的数据感知采集设备协作，完成了大规模实时监测数据流全自动化获取解析入库的流程。

此前研发的异源WSN观测仪器归一化数据接口主要通过调用Windows API的相关函数监控数据文件的变化获取新的监测数据^[8]。该系统依赖Windows平台，测试发现Windows命名管道存在稳定性问题，而且对于数据文件变化事件的响应速度慢。与其单一的数据获取方式相比较，本文设计的数据自动获取模块有多种数据获取方式。新增加了通过解析数据传输协议获取数据和通过厂商提供的API/SDK获取数据两种方式。重新设计实现了监控数据文件变化获取数据的方式，由当前调用Windows API的方式变更为通过文件指针和轮询进程相结合的方式，完全脱离对操作系统的依赖。因此具有很高的稳定性和兼容性，也能够满足数据实时获取的应用需求。

数据自动获取模块的设计原理如图2所示，目前已经实现的3种数据获取方式如下所述。

(1)第一种方式基于文件指针和轮询进程，主要是与厂商数据接收软件协作，共同完成监测数据的获取。这种方式主要是数采仪采集的各种类型的监测数据通过网络发送到指定的服务器，并被服务器上部署的厂商提供的数据接收软件定时接收到数据缓存池。此时数据自动获取模块的监控进程实时监控数据缓存池获取最新的监测数据。此前的异源WSN观测仪器归一化数据接口，通过Windows API的相关函数监控数据文件变化，并且获取到最新监测数据之后，把该数据写入命名管道，这个过程中需要创建命名管道，并且向该管道发送数据，这种操作比较繁琐，会影响监控模块的工作性能和稳定性。本文设计的基于文件指针和轮询进程相结合的方式获取到新的监测数据后，直接发送给后端的数据自动解析处理模块直接处理，这个过程中无需通信机制和数据缓存。

(2)第二种方式通过解析数据传输协议传输的数据包获取数据。这种方式主要是数采仪以一定的频率采集监测数据，然后通过数据传输协议将新的监测数据传输到服务器。此时自动获取数据模块的数据包解析进程通过解析数据传输协议传输的数据包就能够获得新的监测数据。相比于监控数据文件缓存池获取数据的方式，这种数据获取方式实时性较强，但是要依赖特定厂商的数据传输协议。

(3)第三种方式通过厂商提供的API或者SDK获取数据。这种方式主要是调用API或者SDK中的数采仪操作函数，读取数采仪中存储的数据或者读取数采仪采集的实时监测数据。

对于数据自动获取模块，必须保持向后的兼容性，即无论是采用上述哪一种数据获取方式获取数据，其获取的数据都必须符合数据自动解析处理模块能够接收解析的格式。这样无论采用上述的哪一种方式获取数据，后续的解析处理模块，都不需要做任何修改就可以直接解析处理获取到的新监测数据。

此前研发的异源WSN观测仪器归一化数据接口的数据处理模块的工作模式是首先连接Windows命名管道，如果连接成功，会调用相关函数读取文件^[8]。这些对Windows平台的深度依赖导致这种设计原生的不足。命名管道的创建、等待、连接、接收数据以及关闭等一系列操作，严重影响了该模块的性能和稳定性。本文重新设计和实现了数据自动解析处理模块，新模块直接采用文件操作函数对原始监测数据按行解析处理。对于数据自动获取模块获取的数据也直接按行解析处理，无需命名管道或者类似的通信机制传递数据，该模块的设计原理和数据解析处理流程如图3所示。

数据自动解析处理模块的数据解析处理方式分为批量解析处理和单行解析处理，为统一数据解析处理单元，本文设计的模块主要采用单行解析处理的方式。数据解析处理的流程是首先解析处理原始监测数据获取监测数据表头，运用这个表头信息作为数据自动解析处理模块的全局监测变量信息，然后将获取到的监测数据解析处理后发送向3个目的地^[8]。主要分为2组，其中一组运用于数据共享和数据恢复，这些数据以类似于原始数据的格式做备份和处理后写入FTP数据文件夹中；另一组则运用于构建数据序列，这部分监测数据主要是为了存入数据库，供其他的应用系统访问。同时每一条监测数据缓存到数据序列中时都会在本地创建时间戳文件，该文件作为监测数据缓存到数据序列中的标记，在数据库入库的过程中应用该时间戳文件做校验，避免了监测数据的重复入库。

本文设计开发的数据自动入库模块与此前研发的异源WSN观测数据自动入库系统基本类似^[8]，都采用一种类似数据序列的缓存机制去实现异步入库，两者都选用消息队列。在数据库连接的复用性方面，WSN观测数据自动入库系统采用自己设计开发的连接池类，主要是创建一些连接，然后采用队列数据结构调度这些连接。数据自动入库模块采用Python语言官方提供的数据库连接池模块。该模块是一套可以线程化Python 程序，同时安全和高效地访问数据库的程序包。本文设计的新入库模块的设计原理和数据入库流程如图4所示。

监测数据存入数据库的方式可以分为同步存入数据库和异步存入数据库^[9]。由于监测数据在数据自动解析处理模块中解析处理的速度较快，而监测数据存入数据库中的速度较慢。为了解决监测数据解析处理和自动入库之间速度不匹配的问题，本文设计的数据自动入库模块采用数据异步入库方式，采用消息队列作为数据序列的缓存容器是实现数据异步入库的主要策略。

在数据自动入库模块中，数据库的连接是宝贵的资源，频繁的建立、关闭连接，会极大的降低数据自动采汇中间件的性能。如果消息队列中没有消息，此时若数据库一直连接会造成资源浪费，因此通过建立一个数据库连接池以及一套连接使用管理策略，使得数据库连接可以得到高效、安全的复用，避免频繁建立连接、关闭的开销。因此本文设计了线程共享的、线程安全的、有缓存的、可复用的数据库连接池。

数据自动入库模块的工作原理是自动入库进程持续读取消息队列中的消息，并把该消息解析后自动存入数据库。如果消息队列中没有消息，自动入库进程就处于等待状态，只要消息队列中新增监测数据，就会立刻激活入库进程，将该监测数据存入数据库，如果存入数据库失败，则写入缓存文件。

本文设计的数据自动采汇中间件采用简洁高效的Python语言实现，完全采用面向对象编程思想，遵循单一职责原则，保证了设计程序的继承和扩展性，对整体数据自动综汇系统后期的迁移、维护和升级带来极大的便利。与Perl语言开发的异源WSN观测仪器归一化数据接口和自动入库系统相比较，该中间件考虑到了所有可能出现异常的情况并做了相应的异常处理。全面的异常处理使得该中间件具有很高的稳定性，并且在运行的过程中会实时输出运行状态日志，根据实时输出日志可以监控的运行状态和排查运行过程中出现的错误。

到目前为止，本文设计和实现的数据自动采汇中间件从2018年11月开始已经持续在线运行，主要服务于部署在我国西南地区的生态监测物联网，该系统包括5个监测站点、15台自动数据采集仪。目前已经累计解析处理入库各种传感器获取的各种类型的数据几千万条。测试表明该中间件运行稳定，性能良好，完全能够满足现有生态监测系统数据解析处理的业务需求，可以在后续的其他同类项目中得到应用。

本文设计实现的数据自动采汇中间件虽然能够满足目前业务需求，但是随着生态监测物联网需要监测的生态关键参量的增加，不同的数据感知采集设备加入物联网系统后，数据获取模块不一定能够做到完全兼容，这会导致数据丢失或者中间件不能正常运行。因此未来需要强化该数据采汇中间件的兼容性研究，以做到支持更多的硬件设备。同时也可以设计开发设备异常检测、数据异常检测，设备远程控制等相关功能。一款好的数据采汇中间件应该具有自顶向下的抽象接口，这样就能够具有更高的兼容性，也可以适应未来不同监测场景的需求。

对于遥感—地面同步、大范围、全天候持续生态监测物联网，大量的数据感知采集设备会持续产生海量实时数据，处理这些海量实时数据可能会成为本文设计的中间件的瓶颈，因此海量数据处理业务需要设计高并发的分布式中间件。本文设计和实现数据自动采汇中间件可以基于Spark、Flink等分布式实时计算框架实现，以应对将来大规模设备接入和海量数据采集综汇的业务场景。

针对目前生态监测物联网中数据采集综汇的应用需求，通过分析生态监测物联网系统的数据感知采集设备在数据接收、存储格式、无线传输协议、服务器端管理方式等方面存在的问题。参考了异源WSN观测仪器归一化数据接口和自动入库系统，并分析了其原生的不足之处，重新设计和实现了这一业务模块，并将其以面向生态监测物联网中的多源异构监测数据的自动采汇中间件的形式发布。该中间件已经投入使用中，对于生态监测物联网的多源异构数据采汇具有重要的应用价值。

该数据自动采汇中间件具有模块化结构，有多种数据获取方式，能够将获取的多源异构监测数据解析汇总并归一化后存入数据库。对于野外地理环境和生态环境的监测，只要是涉及类似的数据采集处理流程，即采用传感器感知数据，数采仪采集数据，然后需要把采集的监测数据归一化后存入中心数据库的场景，本文设计和实现的自动采汇中间件都具有一定的参考意义和应用价值。