CN109492040A - 一种适用于数据中心海量短报文数据处理的系统 - Google Patents

Abstract

本发明提供了一种适用于数据中心海量短报文数据处理的系统，包括：插件式数据适配器及框架模块：包括数据采集、数据接收、数据导入功能；分布式消息中间件模块：包括数据分类、数据传输功能；数据转换器模块：包括数据转换、数据入库功能；数据存储模块；包括关系型数据库、非关系型数据库、高速缓存数据库、应用数据库；服务应用与管理模块：包括基础服务和服务管理框架。本发明具有以下优点：1、提供即插即用的快速化的数据采集能力；2、提供海量数据的高效传输；3、提供标准化的数据转存及入库一体化处理流程，提高数据入库效率；4、提供冷热双重数据库，提供百亿级数据的秒级响应；5、提供统一的对外服务接口及标准化基础数据服务。

Description

一种适用于数据中心海量短报文数据处理的系统

技术领域

本发明涉及数据处理技术领域，尤其涉及一种适用于数据中心海量短报文数据处理的系统。

背景技术

近年来，城市中越来越多的数据层出不穷，如何高效的利用城市数据成为许多城市管理者的业务难题，在这样的背景下，越来越多的城市提出建设新型化的智慧城市，以满足城市智慧管理的诉求。智慧城市核心点在于建设城市信息资源的融合平台，即城市数据中心，城市数据中心需要融合城市各种数据，但由于不同政府组织机构在信息化过程中，由于建设技术、方式、时间有所差异，以及近年来计算机科学技术高速发展，不同组织机构的信息管理系统存在区别，导致不同机构组织之间的信息不能共享，难以看到整体数据层面并进行决策。

为了解决城市数据全局性的问题，同时能够更好的使用城市数据，围绕城市数据中心，建设城市信息资源平台，对城市的数据进行充分的挖掘与分析，以多元化的方式展现数据，同时对各类应用提供支撑服务，对城市各方面信息资源进行全面的融合与多元化的集成。

短报文数据是一类具有短小、高频、繁多等特点的城市感知层数据，在城市数据采集的多个领域都有所涉及，包括但不限于：各类传感器数据、第三方位置数据、物联网数据等城市动态信息，还包括既有系统的历史数据库相关内容。

目前，行业上成熟的软件能够分阶段的解决数据中心相应的问题，但是在智慧城市领域内对于政府短报文类的需求解决尚有提升空间，例如：对于海量多源化的异构数据支持能力还存在提升空间；并且，在数据量上升到一定规模后(千亿级别)，数据的检索性能会遭遇瓶颈，不能够满足政府业务的性能需求，如：还不能够在秒级去响应一些位置轨迹信息的查询；另外，由于系统高度依赖于各个分离的业务模块，导致在部署过程中流程长，耗时多。

短报文数据处理系统的经济效益在于，在智慧城市领域项目初期对接时，经常会出现甲方希望提前看到演示系统的情况，甲方基于演示系统对项目立项阶段的工作进行推进，所以如何快速搭建智慧城市前期演示系统成为项目前期运作的一个重要环节，短报文数据处理系统能够提供城市感知层的传感器、车辆位置等数据的快速接入展示能力，对项目前期的快速落地有一定的促进作用。另一方面，在项目具体实施过程中，一般需要对接不同的第三方系统，并且各个系统的开发语言、数据传输协议均有所不同，如果采用个性化的对接方式，将会造成大量的重复性工作，短报文数据处理系统能够提供一种快速的对接方式，缩短系统之间对接时间，节约人员成本。最后，随着城市的不断发展，短报文类数据增长的速度会越来越快，当数据量不断增加的时候，不需要改变系统架构，只需要通过增加硬件的方式，就能够达到性能的线性提升，从而很大程度的降低了系统后期运维成本。

发明内容

为了提供海量的异构短报文类型的数据的异构存储、高速检索和提供高效的数据服务，本发明提出一种适用于数据中心海量短报文数据处理的系统。本发明具体通过如下技术方案实现：

一种适用于数据中心海量短报文数据处理的系统，所述系统包括插件式数据适配器及框架模块、分布式消息中间件模块、数据转换器模块、数据存储模块和数据存储模块；

其中，插件式数据适配器及框架模块包括数据采集、数据接收、数据导入功能；系统包括多种适配器模块，所述多种适配器模块集成在一起接受框架的管理，使用框架的服务接口进行交互，在框架的管理下各个适配器有序工作，所述框架提供适配器的认证和注册功能，并在运行时监控适配器的运行；

分布式消息中间件模块包括数据分类、数据传输功能；所述消息中间件主要起到两个作用：第一，消息路由，消息路由管理着消息的传递，通过一定的配置项分发将消息分发到不同的消息队列中，起到指挥调度的作用。第二，消息传输，消息队列接收到消息路由的指令后，按照消息路由的指令，执行消息传输；

数据转换器模块包括数据转换、数据入库功能；数据转存器主要负责将采集器中打包的数据进行格式转化，生产易于入库和读取的标准格式数据；所述数据转存模块位于分布式消息中间件模块和数据存储模块之间，主要作用是将订阅的消息转换为适合进入数据库的格式，按照指定的分片策略入库；

数据存储模块包括关系型数据库、非关系型数据库、高速缓存数据库、应用数据库；所述数据存储模块包含三个引擎模块：文档型数据库子模块、关系型数据库子模块和服务高速缓存子模块，其中，所述服务高速缓存数据库同样被设计为非结构化的数据库类型，并且为了追求速度最大化，使用了物理内存做为缓存的主存储体；

服务应用与管理模块包括基础服务和服务管理框架。

作为本发明的进一步改进，所述分布式消息中间件模块中的消息中间件独立于各个系统，是一种能在各个分、子系统模块和平台运行，支持在任意架构的系统中各个组件之间进行通讯的协议实现组件，负责在各个分、子系统模块之间实时高效传递消息；采用消息队列MQ支持同步传输和异步传输，保证数据报文不重复、不丢失、同顺序。

作为本发明的进一步改进，所述系统的用户仅需要通过互联网或政务内网通过防火墙连接核心交换机，然后由交换机连接至服务器，在服务器内部通过VLAN划分了内部数据层和外部数据层用于数据安全和外部服务的隔离，其中，数据库集群、消息中间件集群、转存器都存放在内部数据层，通过内部数据接口形成的服务统一暴露给外部数据层，供外部访问。

作为本发明的进一步改进，所述系统逻辑上为三层架构，分别是数据层、业务逻辑层、服务层。其中数据层用于业务数据、管理数据、任务数据、用户数据、协议库数据、日志数据等数据的存储，业务逻辑层包括数据采集、消息中间件、数据转存、数据存储、数据服务生产、数据服务管理，服务层主要是统一的服务管理框架对外提供数据调用服务接口。

作为本发明的进一步改进，所述系统采用MongoDB与Redis的组合来满足海量数据存储和高速查询的需求，采用PostgreSQL为关系数据库。

作为本发明的进一步改进，当前端调用查询服务时，首先先查看高速缓存Redis中是否有结果数据，如果有则直接反馈结果数据即可，如果高速缓存Redis中没有结果数据，则需要在Mongo数据库内查询，将结果返回前端，与此同时，同步将结果数据保存在高速缓存Redis中，当下一次有相同查询的时候，高速缓存Redis就可以直接返回前端数据；然后，通过日志服务器记录查询日志，通过对日志分析的结果预测后续请求，做到预先处理以提高未来可能产生的查询的效率；另外，数据更新会通过监控器监控，通过监控分析目前缓存中的数据是否过期，来进行缓存数据更新。

本发明的有益效果是：本发明的适用于数据中心海量短报文数据处理的系统，具有以下优点：1、提供即插即用的快速化的数据采集能力；2、提供海量数据的高效传输；3、提供标准化的数据转存及入库一体化处理流程，提高数据入库效率；4、提供“冷”、“热”双重数据库，提供百亿级数据的秒级响应；5、提供统一的对外服务接口及标准化基础数据服务。

附图说明

图1是本发明的短报文数据处理系统的功能模块框图；

图2是本发明的短报文数据处理系统的网络拓扑图；

图3是本发明的短报文数据处理系统的总体架构图；

图4是本发明的短报文数据处理系统的部署图；

图5是本发明的短报文数据处理系统的数据库架构示意图；

图6是MongoDB数据库集群示意图；

图7是动态数据协议适配器示意图；

图8是消息中间件集群示意图；

图9是并行查询支撑系统示意图。

具体实施方式

下面结合附图说明及具体实施方式对本发明进一步说明。

本发明的系统主要是一个数据服务端，从第三方数据对接到前端调用数据服务，根据不同的数据处理阶段设计出各自功能模块，并且需要细化每个模块的主要功能；然后对系统功能进行分层，规划出层级关系；同时从系统的网络层级考虑，设计相应的系统拓扑关系，并制定部署方案和数据库设计；最后，针对系统中涉及的关键技术进行讨论。通过对系统的整体设计，制定了系统的实现方向，对系统的实现打下了良好的基础。

[系统功能模块设计]

短报文数据处理系统的范围是从采集模块接收到数据开始，以提供给前端标准数据服务为结束，期间涵盖数据的采集、传输、转存、存储、服务提供等过程，通过对需求的详细分析，现将整个系统设计为5个模块，具体如下：

1.插件式数据适配器及框架模块，实现对海量多源异构数据的采集；

2.分布式消息中间件模块，实现对海量数据的分类、传输；

3.数据转存器模块，实现将海量数据的转存并向数据库提供标准格式存储；

4.数据存储模块，实现接收数据，按类型分片写入数据库，对数据进行基本的清洗，同时根据业务需要，抽象出数据应用层，供上层使用；

5.服务应用与管理模块，实现对海量数据服务的管理。

综上所述，整个系统分为5个模块，分别为插件式数据适配器及框架模块，包括数据采集、数据接收、数据导入功能；分布式消息中间件模块，包括数据分类、数据传输功能；数据转换器模块，包括数据转换、数据入库功能；数据存储模块，包括关系型数据库、非关系型数据库、高速缓存数据库、应用数据库；服务应用与管理模块，包括基础服务和服务管理框架。系统功能结构图如图1所示。

1.插件式数据适配器及框架模块

数据适配器是用微服务容器封装起来的软件模块，该模块是专门针对某一类型的传感器或者数据源进行数据采集的。每一种适配器模块适用于一种第三方的数据源，不同的适配器将与数据源的交互的专有协议翻译成系统内部标准数据结构，进行传输。数据

适配器本身并不具备业务属性，其业务属性是通过动态嵌入相应业务数据处理方法来实现的，这些业务处理方法是“动态信息服务分系统”中的相应位置、传感器模块中的组成部分，其嵌入方法是通过动态加载方式实现的。

多种适配器模块集成在一起，接受一个公共软件模块的管理，这个公共的模块称为框架。框架提供适配器的认证和注册功能，并在运行时监控适配器的运行。框架模块起到的作用是对适配器的管理，它们之间使用框架的服务接口进行交互，在框架的管理下各个适配器有序工作。

2.分布式消息中间件模块

消息中间件独立于各个系统，是一种能在各个分、子系统模块和平台运行，支持在任意架构的系统中各个组件之间进行通讯的协议实现组件，负责在各个分、子系统模块之间实时高效传递消息，是本发明的系统中重要的负责核心信息交换的组件。MQ支持同步传输和异步传输，保证数据报文不重复、不丢失、同顺序。

消息中间件主要起到两个作用：第一，消息路由，消息路由管理着消息的传递，通过一定的配置项分发将消息分发到不同的消息队列中，起到指挥调度的作用。第二，消息传输，消息队列接收到消息路由的指令后，按照消息路由的指令，执行消息传输。

3.数据转存器模块

数据转存器是位于消息中间件和数据库服务之间，主要作用是将订阅的消息转换为适合进入数据库的格式，按照指定的分片策略入库。数据转换器是中间件的一种，可以组成集群同时发起服务。

数据转存器主要负责将采集器中打包的数据进行格式转化，生产易于入库和读取的标准格式数据。

4.数据存储模块

数据存储模块包含三个引擎模块，具体如下：

1)文档型数据库模块

本模块主要是为了短报文系统中业务数据存储而设计的，由于城市短报文数据大多为弱关系型的数据，彼此之间并没有较强的关联关系，故可以采用“NoSQL”这类非关系型的数据库进行海量短报文业务数据存储。虽然数据去结构化可能会占用更多的空间，但目前存储空间并不是主要考虑因素，并且文档型数据库在另一方面也简化了存储过程，对数据使用灵活性上提供了更好的支持，同时文档型数据库在高并发、实时性、分布式方向上还有着不错的性能。

2)关系型数据库模块

本模块主要是为了短报文系统中高效的处理位置、空间类的数据而设计的。依据目前的业务看，短报文数据处理系统中，位置、空间数据占据较大的比例，此类数据一般还会带有强关系型的元数据，采用关系型数据库引擎能够更好的处理此类数据。

3)服务高速缓存模块

本模块主要是为了优化数据的查询速度而设计的。子系统所面向的查询场景是从数百亿的数据随机检索序列点状数据的要求，这种查询模式是具备关联性的，行为是可以预测的。因此，在查询服务框架和数据库之间，部署服务高速缓存模块，用于缓存查询的结果。本模块具有定制的算法模型，优化本模块所面向的服务查询。

根据本发明的系统所面对的数据类型，服务高速缓存数据库同样被设计为非结构化的数据库类型，并且为了追求速度最大化，使用了物理内存做为缓存的主存储体。当数据被淘汰算法置换进入数据库后，按照既定的配置，将数据进行整合和重新计算索引，并进行有针对性的优化操作，使之成为热数据，准备服务检索使用。

5.服务应用与管理模块

本模块是对系统默认自带的基础数据服务做生产及管理，设计为实现数据自动化生成标准化服务，以供前端调用。通过标准统一的服务URL、服务参数设置完成。本模块是对外提供数据检索的服务集合，重点提供针对短报文类性的数据的Restful服务和Socket-API。具体的服务会根据应用类型进行定制(基本数据API除外)，这些服务被封装在一个定制的Web框架中，以微服务的方式独立存在。

[系统网络拓扑设计]

为了满足系统部署的快捷性，用户仅需要通过互联网或政务内网通过防火墙连接核心交换机，然后由交换机连接至服务器，在服务器内部通过VLAN划分了内部数据层和外部数据层(如数据库集群、消息中间件集群、转存器等内部数据都存放在内部数据层，通过内部数据接口形成的服务统一暴露给外部数据层，供外部访问)，用于数据安全和外部服务的隔离，整体的系统网络架构是及简的，三台物理服务器内部通过万兆交换机互通数据，做集群备份，以达到对外提供高可用的整体服务。短报文数据处理系统的网络拓扑设计如图2所示。

[系统总体架构设计]

系统边界涉及三层架构，分别是数据层、业务逻辑层、服务层。数据层用于业务数据、管理数据、任务数据、用户数据、协议库数据、日志数据等数据的存储，业务逻辑层包括数据采集、消息中间件、数据转存、数据存储、数据服务生产、数据服务管理等，服务层主要是统一的服务管理框架对外提供数据调用服务接口。短报文数据处理系统设计的总体架构图如图3所示。

系统架构分为数据层，业务逻辑层、服务层三层，实现了数据存储模型、数据处理模型、数据服务模型，层与层之间界面划分清晰以实现软件解耦，将不同的业务逻辑控制在不同的组件内，同时通过Docker进行组件封装，实现系统高内聚低耦合，很大程度上提高了系统的灵活性。下面具体介绍每一层的架构：

1.数据层

数据层提供基础的数据存储服务，数据类型包含的业务数据、管理数据、任务数据、用户信息数据、协议库数据和操作日志等，根据其不同的数据属性，通过系统设计不同数据库来存储。

2.业务逻辑层

业务逻辑层是整个系统的逻辑运转层，提供基本的数据处理能力，包含数据采集、传输、转存、查询优化、服务生产等多个过程。数据采集包括采集器、同步器、导入工具、爬虫等功能，以及采集框架的日志管理、监控管理等功能；数据传输包括消息的发送与接收，消息的订阅和监控功能；数据转存包括数据的格式转换、数据写入功能；数据存储包括数据分片、负载均衡、淘汰机制、数据组合、数据备份功能；服务管理包括6项基本服务的生产、服务注册与发布功能。

3.服务层

服务层是对系统内部服务进行统一的管理，对外提供统一的数据接口，执行统一的服务监控、服务扩容等管理，给前端提供框架化的服务调用接口，从而降低系统外部接口的耦合性。

[系统部署设计]

根据系统功能模块的设计，系统包含插件式数据适配器框架模块、分布式消息中间件模块，数据转换器模块，数据存储模块，服务应用与管理模块5个模块，为了极大程度的降低部署周期，减少部署工作量，设计上采用极简单的部署模式，所以各个模块均放在一个物理服务器中；同时，为了满足系统的高可用性，需要设置主从备份的冗余模式，以三台服务器组成一个集群，将相同的模块分布在其他两台的服务器中，同时，三台物理服务器内部通过万兆交换机实时互换数据，做到内部数据的实时互通，当某个服务器出现故障时，其他服务器依旧可以满足业务正常运转。短报文数据处理系统部署图如图4所示。

[数据库设计]

数据库设计是本发明的系统的难点之一，系统需要提供一套对海量多源异构数据的分布式存储的解决方案，同时对于上层查询，数据库还有具有良好的查询支撑能力，通过对当前市面上常用的各种数据库进行分析，结合短报文系统的业务需求场景，我们在数据库设计上主要考虑以下指标：

持久性：不能丢失数据；

高可用性：支持数据库集群，再出现有节点故障时仍能够使用；

海量数据高数处理：对于百亿级别的数据处理时依然能够保证高性能；

数据存储多样性：可以存储不同的类型数据；

空间数据支持性：对空间数据提供较好的支撑；

易查询性：对于不同的查询支持较好；

可扩展性：可以横向扩展。

通过对比以上的指标，最终选择MongoDB作为持久性数据库，MongoDB的优势在于能够对大量数据进行处理，且支持多元化的数据存储，不局限于数据格式。但MongoDB对于高并发查询处理并不是强项，由此，还需要引入一种支持高速读写的数据库，则考虑引入Redis数据库。

Redis是内存型数据库，数据存在内存中，读写快，能够更好的支持高并发情景下的数据存取，可以支撑更大的查询吞吐量。通过对使用场景分析，本发明的系统设计MongoDB与Redis的组合来满足海量数据存储和高速查询的需求。

但仅仅设计MongoDB和Redis还不够，这两类数据库都是key-value型的数据库，他们适用于数据之间关系型不强的场景，而对于强关系型数据并不适用，而在业务场景中业务数据是弱关系型的，但大多数元数据是强关系型的，在这种情况下就需要再加入一种关系型数据库在补足这一块的短板。

通过对关系型数据库的对比选型，确定PostgreSQL为本发明的系统的关系数据库，目前选择主要是因为PostgreSQL支持存储JSON格式数据，并且能够对JSON数据进行索引；同时其PostGIS模块对于位置、空间等信息的存储和处理更有优势；并且更适合处理海量数据的处理。综上所述，我们加入Postgresql作为关系型数据库，提供强关联型数据和复杂的事务处理。

结合上面的论述，数据存储模块需要设计包含三个数据库，分别是关系数据库、非关系数据库和高速缓存，由于短报文数据的特点是“短、频、多”，且单条数据之间的关联关系很弱，我们将短报文具体的业务数据放在MongoDB中，将高并发的查询结果存在Redis中，二者之间可以交换数据，对于关系性较强的管理属性数据存在Postgresql中，故得出数据库架构示意图如图5所示。

由于采集和处理海量数据，对数据库储存有很大要求，同时，对外需要提供高吞吐量的查询接口，数据库集群是为了向短报文能够提供分布式的存储，要求满足分布式高并发的数据存储，保证数据存储后高可用性。通过对数据库进行配置，构建数据库集群，使其满足对海量数据存储的要求，能够提供不同主题的数据库分布式存储，以MongoDB为例的数据库分片集群主从模式如图6所示。

[关键技术]

1.多源异构数据协议的集成与plus-in的方式插拔

动态数据适配器从终端(传感器、车等)或者第三方的服务器被动接受或主动提取数据，内部采取统一的传输方式传输数据，主要负责完成数据的接收/采集、命令解析和通信连接，主要包括协议库、配置文件、监控模块、日志、转发器和容器管理模块，同时外联有监控平台、日志平台、Docker管理平台，负责协议适配器状态的监控、工作日志的存储、Docker的远程开关管理，最终将数据传递到MQ。动态数据协议适配器架构图如图7所示。

2.MQ集群的设置

MQ集群应用于将海量多远异构数据传输到目的地，负责在各个系统模块之间通过网络协议实时高效传递消息，支持同步传输和异步传输。多个MQ服务端通过局域网连接并建立集群，任意两个之间均可连接，消息按照队列形式存储在MQ服务端，消息接收按照先进先出顺序被接收。

MQ集群示意图如图8所示。MQ集群设计主要为了满足MQ的高可用性，包括负载均衡代理组件、MQ服务器集群和MQ服务，具体使用流程如下：

1.MQ消息调用者首先向负载均衡代理HAproxy提出调用申请；

2.HAProxy根据负载机制选举一组MQ服务器集群；

3.选中的MQ服务器调用MQServer执行消息传输的动作；

4.任意MQServer之间可以进行复制和替换。

3.上层大规模并行应用支撑

系统对上层系统提供统一自定义接口，接口设计原则：高效性、通用性、稳定性和可靠性、支持开发框架环境种类尽可能丰富，由于上方应用数量庞大，需要提供高性能秒级查询服务。

数据存储在数据库之后，最重要的就是给上层应用提供数据接口，设计上层大规模的应用支撑时，首先要明确上层应用的主要调用模式和调动需求，按照要求设计一套通用性强的接口来满足调用诉求。

当前端调用查询服务时，首先先查看高速缓存Redis中是否有结果数据，如果有则直接反馈结果数据即可，如果高速缓存Redis中没有结果数据，则需要在Mongo数据库内查询，将结果返回前端，与此同时，同步将结果数据保存在高速缓存Redis中，当下一次有相同查询的时候，高速缓存Redis就可以直接返回前端数据。然后，通过日志服务器记录查询日志，通过对日志分析的结果预测后续请求，做到预先处理以提高未来可能产生的查询的效率；另外，数据更新会通过监控器监控，通过监控分析目前缓存中的数据是否过期，来进行缓存数据更新。并行查询支撑系统示意图如图9所示。

数据服务需要包括六个基础服务，为了能够对Web、IOS、Android等不同端提供统一服务，需要设计一套统一的服务接口，本文采用RESTful(Resource RepresentationalState Transfer)。Resource：资源，即数据，比如type、id等；Representational：某种表现形式，比如用JSON，XML，JPEG等；State Transfer：状态变化，通过HTTP动词实现。HTTP动词主要分为四个：GET表示获取资源，POST表示新建或更新资源，PUT表示更新资源，DELETE表示删除资源。在进行RESTful服务设计时，应当满足下列要求：

■在URL中加入版本、对象信息等，名词信息用复数；

■尽量嵌套结构作为资源地址；

■提前估算返回值大小，如果较大需要考虑分页；

■返回的错误码需要加入注释；

■使用正确的HTTP Status Code表示访问状态。

这里定义出服务的名称和调用，六个基础服务的名称、调用参数及返回结果如表1所示。

表1服务调用说明表

以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (6)

1.一种适用于数据中心海量短报文数据处理的系统，其特征在于：所述系统包括插件式数据适配器及框架模块、分布式消息中间件模块、数据转换器模块、数据存储模块和数据存储模块；

其中，插件式数据适配器及框架模块包括数据采集、数据接收、数据导入功能；系统包括多种适配器模块，所述多种适配器模块集成在一起接受框架的管理，使用框架的服务接口进行交互，在框架的管理下各个适配器有序工作，所述框架提供适配器的认证和注册功能，并在运行时监控适配器的运行；

分布式消息中间件模块包括数据分类、数据传输功能；所述消息中间件主要起到两个作用：第一，消息路由，消息路由管理着消息的传递，通过一定的配置项分发将消息分发到不同的消息队列中，起到指挥调度的作用；第二，消息传输，消息队列接收到消息路由的指令后，按照消息路由的指令，执行消息传输；

数据转换器模块包括数据转换、数据入库功能；数据转存器主要负责将采集器中打包的数据进行格式转化，生产易于入库和读取的标准格式数据；所述数据转存模块位于分布式消息中间件模块和数据存储模块之间，主要作用是将订阅的消息转换为适合进入数据库的格式，按照指定的分片策略入库；

数据存储模块包括关系型数据库、非关系型数据库、高速缓存数据库、应用数据库；所述数据存储模块包含三个引擎模块：文档型数据库子模块、关系型数据库子模块和服务高速缓存子模块，其中，所述服务高速缓存数据库同样被设计为非结构化的数据库类型，并且为了追求速度最大化，使用了物理内存做为缓存的主存储体；

服务应用与管理模块包括基础服务和服务管理框架。

2.根据权利要求1所述的系统，其特征在于：所述分布式消息中间件模块中的消息中间件独立于各个系统，是一种能在各个分、子系统模块和平台运行，支持在任意架构的系统中各个组件之间进行通讯的协议实现组件，负责在各个分、子系统模块之间实时高效传递消息；采用消息队列MQ支持同步传输和异步传输，保证数据报文不重复、不丢失、同顺序。

3.根据权利要求1所述的系统，其特征在于：所述系统的用户仅需要通过互联网或政务内网通过防火墙连接核心交换机，然后由交换机连接至服务器，在服务器内部通过VLAN划分了内部数据层和外部数据层用于数据安全和外部服务的隔离，其中，数据库集群、消息中间件集群、转存器都存放在内部数据层，通过内部数据接口形成的服务统一暴露给外部数据层，供外部访问。

4.根据权利要求1所述的系统，其特征在于：所述系统逻辑上为三层架构，分别是数据层、业务逻辑层、服务层；其中数据层用于业务数据、管理数据、任务数据、用户数据、协议库数据、日志数据等数据的存储，业务逻辑层包括数据采集、消息中间件、数据转存、数据存储、数据服务生产、数据服务管理，服务层主要是统一的服务管理框架对外提供数据调用服务接口。

5.根据权利要求1所述的系统，其特征在于：所述系统采用MongoDB与Redis的组合来满足海量数据存储和高速查询的需求，采用PostgreSQL为关系数据库。

6.根据权利要求5所述的系统，其特征在于：当前端调用查询服务时，首先，先查看高速缓存Redis中是否有结果数据，如果有则直接反馈结果数据即可，如果高速缓存Redis中没有结果数据，则需要在Mongo数据库内查询，将结果返回前端，与此同时，同步将结果数据保存在高速缓存Redis中，当下一次有相同查询的时候，高速缓存Redis就能够直接返回前端数据；然后，通过日志服务器记录查询日志，通过对日志分析的结果预测后续请求，做到预先处理以提高查询的效率；另外，数据更新会通过监控器监控，通过监控分析目前缓存中的数据是否过期，来进行缓存数据更新。