传统的动环监控系统体系架构包含三个组成部分：监控对象(SO)、现场监控单元(FSU)、集中监控中心(SC)，体系结构如下图所示：
以上架构设计适合小规模的应用场景，难以解决大规模采集数据场景下的动环监控业务应用，本文提出一种集群大数据平台技术架构，以满足动环监控系统对大规模测点实时性采集和处理、大数据高效存储和查询、分布式容错处理等要求，同时为第三方SC、SC、大数据分析、其它应用提供共享服务。另外，还制定测点和设备编码规范、测点和设备命名规范、事件和转台字典规范以及服务接口标准化规范等。技术架构设计包括数据采集、分布式消息队列(Kafka集群)、在线实时处理(Storm集群)、数据存储中心、共享服务、配置管理等部分。技术架构如下图所示：
1、面向不同层次的数据采集。支持面向第三方集中监控中心(SC)和第三方现场监控单元(FSU)数据采集；同时，支持面向动力系统和环境系统的现场监控单元数据直采(一体式或主从式FSU)。依据不同的规约协议定制开发采集程序，底层采集数据统一汇聚至分布式消息队列(Kafka集群)。定制ETL单元采集数据推送至分布式消息队列(Kafka集群)，由在线实时处理(Storm集群)应用，基于配置管理预先定义的点表映射关系进行处理，转换成动环监控平台自定义编码；而现场监控单元，基于配置管理预先定义的点表映射关系，将底层动力和环境系统产生的测量数据，直接转换成动环监控平台自定义编码，无需在线实时处理(Storm集群)应用进行点表映射处理。
2、集群式消息队列。在支持各个子系统本身业务应用要求的前提下，采集数据集中汇总到消息中间件（Kafka）缓冲，每一个采集服务器在消息队列中采用唯一标识的主题（Topic）存储，消息中间件中的数据存储格式采用JSON格式；集中存储的优势在于：平台级应用方无须关注实现各个厂家不同的通讯方式和交互流程，在数据汇总的方式上基于互联网的公开标准进行了统一，数据格式可以不统一。传统做法是要求数据格式的统一，将复杂的数据格式处理转嫁给了数据采集方，增加了数据采集方的工作量，另外，所谓的统一格式，也不能得到广泛认可，消息队列的通讯方式是公认的技术。
3、实时高并发数据处理机制。统一业务数据格式（设备编号、测点编号、测点数值、测点类型、采集时间等），预先定义映射关系，将不同数据格式的底层采集数据，统一格式化成标准的业务数据；对于模拟量、计算量、开关量实时数据的处理和存储。
4、混合数据存储模式。针对不同类型数据，依据业务应用实际要求，选择合适的存储模式进行数据持久化处理，并对外提供数据。对于文件、图像、视频以文件方式存储；实时测点数据存储在内存数据库(Redis集群)，事件状态数据局域(Redis)的消息订阅机制，及时向外部应用推送；历史测点数据存储在时间序列数据库(OpenTSDB集群)，配置管理、基础信息、业务数据、主题分析数据存储在关系数据库(MySQL集群)。
5、开放式共享服务接口。事件、状态、告警等即时消息，通过消息队列订阅机制对外推送；提供RESTful Web服务共享接口，为远程控制操作、实时数据和历史数据查询提供应用基础；同时，平台对外开发时间序列数据库、内存数据库、消息队列访问方式。
6、可拓展业务应用。共享服务支持第三方集控中心(SC)、SC、大数据分析应用、其它应用等二次开发。
7、标准化、规范化。动环监控平台制定规范化和标准化的编码、命名、字典、接口定义，基于标准化、规范化基础，提供可视化的配置管理工具。
