科技评估数据的信息平台架构

今日荐文

今日荐文的作者为科技部科技评估中心专家杨治安，韩勇，宋雨奇。本篇节选自论文《一种面向科技评估数据的信息平台架构研究》，发表于《中国电子科学研究院学报》第14卷第8期。

摘 要：对比传统的互联网数据，科技评估数据在数据量、数据类型、数据价值密度、数据处理效率和数据真实性上，都具有不同的特点。针对数据特点，设计具有针对性的信息平台才能更好的适应数据特点，满足业务的需求。有鉴于此，本文在深入研究评估业务和评估数据特点的基础上，提出了一种面向科技评估数据的信息平台架构，协调了分布式架构和松耦合架构的平衡，提高了信息平台的效率和可扩展性。文章还设计了信息平台的业务流程引擎和平台运维体系。

关键词:科技评估；信息平台；架构；流程引擎；平台运维

《中国电子科学研究院学报》更多精彩文章

请移步中国知网下载阅读，或持续关注本号更新

论文全文摘编如下

仅供学术交流与参考

1. 引言

“十三五”国家科技创新规划，提出深入实施创新驱动发展战略，大力推进以科技创新为核心的全面创新，确保如期进入创新型国家行列。科技部科技评估中心围绕科技改革发展中心工作，加强专业建设和信息化支撑能力，积极推动科技评估体系建设，充分发挥评估工作的决策支撑、管理服务和监督保障作用。

对比传统互联网数据，科技评估数据主要是面向科技活动评价所需要收集整理的数据，包括科技管理活动中产生的数据，如科技规划、科技计划管理、科技奖励等，也包括科技活动实际开展中所产生的研究数据，如科技论文、科研专利、科研成果等。

科技评估数据的特征如下：

一是数据量大。科研活动中产生的数据较多，包含科研实践的原始数据、中间过程数据以及结果数据。部分研究领域，如原子对撞、天体探测、分子生物等，一次实验产生的原始数据及其衍生数据最高可达TB级，具有显著的海量特征。

二是数据类型多。科技评估面向不同的科技领域做出评价，而不同科研领域的数据类型多样，在数据格式、数据处理、数据应用、数据表现方面千差万别。

三是数据价值密度低。科技评估需要对各种科研活动及成果进行深入采集分析，才能形成全面客观的结论。而这样大规模的数据体量中往往混杂有大量无效的低质数据。

四是数据处理效率要求高。科技评估工作具有时效性，对于作为评估依据的数据支撑在时效上提出了更高的要求。

五是数据真实性要求高。

科技评估数据的特点，对处理数据的信息平台[1][2][3][4]提出了新的要求。

2. 信息平台技术需求

面向科技评估数据的信息平台，技术架构设计需要满足高可用、易扩展、低成本、安全、高效的业务需求。使用分布式加速、缓存加速、数据库分库分表、高效编码的方式提高系统速度，使用负载均衡、自动容错的方式保障系统稳定运行，使用降低耦合度、弹性扩展的方式增强系统的扩展性，使用自动化部署、自动化测试的方式达到高效开发部署的目的，使用数字加密、数据加密、入侵监控、HTTPS等的方式提高系统的安全性。从而使系统在速度、扩展、稳定、高效、安全等方面达到最优，形成最佳平衡。

图1 平台技术需求平衡图

3.信息平台体系规划

根据科技评估数据的特点，本文设计提出一种面向评估数据处理需求的信息平台，平台逻辑总体上划分为三层：业务应用层、大数据分析服务层、基础设施层。

（1）业务应用层

业务应用层，是信息平台规划建设最重要的部分，是面向评估的业务需求，为其直接提供科技评估业务支撑系统，解决业务部门评估业务管理的软件应用系统。业务部门在规划建设符合自身业务模式和需求的业务系统，需按照根据统一规划、统一标准进行建设。

业务应用层的建设需要遵从信息化建设的客观次序，先建基础的优先级高的业务应用系统，进而逐渐增加和扩建新的业务系统。

首先，需要建设基础的数据共享开放平台、科技项目评估系统、科技成果评价系统、和视频会议系统，提供科技评估的专有的分析软件、评估方法和工具。其次，需要建立第三方（外部系统）数据采集服务，能够接入权威机构统计数据、文献和年鉴等数据等。通过持续的迭代升级，建立符合评估中心每个业务部门所需要的业务系统、应用软件、以及相关工具等。

图2 信息平台体系逻辑架构图

（2）大数据分析服务层

大数据分析服务层作为数据资产最为核心的部分，划分成逻辑关联紧密的三个层次或部分：数据服务资源层、业务数据资产层、数据分析服务层。

数据服务资源层，规划设计了两种类型的数据存储的技术产品系，这些数据服务产品为上层应用提供最为便捷和有效的数据存储服务，是业务系统管理数据资产最佳的数据资源服务。第一类是结构化的数据，属于传统数据存储服务；第二类是以非结构化数据和非关系型数据为主的新型数据存储服务。数据服务资源可选择的产品非常多，上图中列举了当前主流的传统数据库产品、新型数据库产品，包括诸多国产数据库系列。

业务数据资产层，业务系统的处理的数据资产，尤其是科技与创新项目的评估数据，主要以非结构化数据为主，如：各类参与评审的项目资料、文档、文献等，评估过程的音视频数据档案资料等。所有这些数据会占据海量的存储空间，同时具有极为重要的价值和重要性。数据往往依靠数据库产品管理和存储数据，而数据本身是评估中心重要的资产。这些资产的价值，需要分析挖掘才能发挥更大的作用。

数据分析服务层，为业务应用取得数据分析提供了基础的计算框架，成为海量数据分布式的、并行计算、数据挖掘分析的最有效的技术方案。大数据分析层，满足了评估中心对数据挖掘分析的基本需求，同时满足业务智能化建设的总体规划的要求。

目前，数据分析服务层，提供新的大数据并行计算分析框架，包括经典的数据挖掘分析服务、商业智能分析服务、以及数据仓库服务等。大数据分析根据其特点可以选择不同的技术框架，对于海量的分布式的结构化数据，选择MPP技术框架进行分析处理；对于海量的分布式的非结构化数据，优先选择Hadoop技术框架进行分析处理。事实上，大数据分析与业务系统应用场景是深度融合的，大数据分析都需要深入到业务应用场景中心，方可显示出其价值。

根据信息平台发展规划要求，会在大数据分析的基础上，持续新增智能分析的理论方法和技术方案，如：深度学习、机器学习、数据挖掘、预测分析等技术；同时，在特定领域数据分析引进专有数据分析处理方法和应用软件，例如：音视频的数据分析处理软件，包含音频、图像、视频等的模式识别技术等。

（3）基础设施层

包含评估演示中心和数据中心，视频会议设备（包括LED大屏）、服务器设备、网络设备、存储设备等。为了更好的实现统一管理硬件设备，建立了虚拟化资源层，实现对计算资源、网络资源、存储资源的统一管理，为上层中间件或系统提供服务。

4.业务流程引擎设计

在本文提出的面向科技评估数据的信息平台体系规范基础上，我们设计了面向科技评估数据特点的基于平台的业务流程引擎，如下：

图3 业务流程引擎架构图

业务流程引擎采用开源的轻量工作流引擎ACT开发。基于国际通用的工作流规范，支持拖拽式的流程调度设计，并通过API进行流程调度。有较好的易用性、可嵌入性和可扩展性，同时更加强调面向业务人员。

业务流程引擎核心组件图如下所示：

图4 业务流程引擎核心组件图

架构特点：

（1）数据持久化

流程引擎的设计思想是简洁、快速。使用MyBatis，解决了应用和数据库交换数据的瓶颈，从而可以应用通过最优的SQL语句执行命令，这样就能让引擎在速度上保持最高的性能。

（2）流程设计器

流程引擎具有基于Web的ACT Modeler可视化流程设计器，可以让业务人员把需求转换为规范流程定义，支持拖拽，同时还可以将设计的流程定义文件导入到ACT Designer，将其进一步加工成为可以运行的流程定义。

（3）原生支持Spring

基于ACT设计的流程引擎原生就可以支持Spring，通过集成，进行事物和解析的表达。

（4）松耦运行和历史数据

这种流程引擎设计继承了BPM一贯的设计习惯。表结构设计的思想，也体现在松耦合运行状态下，应用运行时，不与历史数据做紧耦合。只在需要的时候，才会去历史数据表中读取。这样以来，运行时读取数据的速度更快，而且当数据随应用运行而进行大量累积的时候也不会影响应用本身的运行效率。

5. 平台运维体系设计

建立一个全局统一的评估业务管理和运行信息资源库，还需要建立规范化、标准化、制度化的集中管理的运行维护体系，对整个信息系统的运行进行全面监控，对系统运行中出现的问题及时响应，保障应用系统的安全持续运行，并且维持稳定和高效。

全局统一的运维监控管理系统、运维监控管理制度以及运维监控技术支持队伍的建设，实现运行维护工作的智能化和高效率，提高整体的运行维护水平，培养一批业务精通、作风优良的运行维护管理人才。

基于信息平台构建的运维体系，需要具备以下特性：

（1）统一性

本文设计的运维监控管理系统基于Browser/Server架构，实现对信息系统软硬件资源的全面管理与监控。硬件资源不仅包括数据中心的服务器、交换机、安全设备、环境监测设备，还包括操作与运行信息系统的业务终端；软件资源不仅包含业务应用、数据库，还包含数据调用与处理的中间态以及信息系统运行的全流程日志。

（2）开放性

全局统一的运维监控管理系统，面向全局业务资源提供统一的标准管理接口用以集成。在底层数据与基础资源之上，建立统一的http开放接口，不仅屏蔽了应用对数据的直接接触，API的方式也通过标准格式方便了其他应用与管理系统的接入。

（3）安全性

管理系统自身的安全性是保证管理工作正常进行的关键因素，因此在搭建运维服务管理平台时，也要充分考虑管理自身系统的安全，如：

（a）登录安全认证和登录及权限限制。

（b）登录所需关键信息密文另机存取。

（c）设立用户、角色、权限三级分离措施，根据管理制度及系统管理方式的变更，定期重更。

（4）扩展性

随着信息平台的持续建设，运维管理规模会随着应用的不断扩展而扩展，因此管理平台的扩展性对保护投资至关重要。统一运维监控系统的扩展性包括如下：

（a）管理资源可扩展。统一的运维监控系统支持软硬件资源的新增，包括硬件基础设施和软件应用系统。

（b）管理范围可扩展。统一的运维监控系统支持新平台集成和加入，支持分布式部署和管理。

（c）管理功能可扩展。统一的运维监控系统支持新的管理功能和模块以标准格式接入系统，纳入管理系统统一运行与调度。

图5 平台运维管理体系架构图

运维管理体系的架构包含以下各层：

（1）数据源层：数据源层位于整个统一运维系统的底层，覆盖了评估中所有被管对象，包括评

估业务现有的常规网络资源和虚拟化环境、机房设备、云设备等。

（2）数据采集层：数据采集层负责对评估业务所有资源的数据采集，同时根据下发的告警策略进行指标数据的匹配。数据采集到平台后，进行汇总和分类，形成告警数据、性能数据、配置数据等。

（3）功能层：系统对数据库的不同数据进行调用、整合，形成监控数据、服务管理数据、业务服务数据。同时不同评估业务视图中也能看到属于自己管辖范围内的运维数据。

（4）展现层：统一运维平台将处理后的数据从数据库中进行调用，展现到门户网站模块中。同时根据人员权限不同，评估人员可通过门户网站看到不同的运维数据、业务数据和应用系统等数据。系统可针对不同的角色比如工程师、部门管理者、高层领导，设置不同的页面展现。个人也可以根据喜好设置不同的个人门户页面。

结 论

本文针对科技评估数据的特点，提出了一种面向科技评估数据的信息平台架构设计，建立一套信息平台体系规划，在此基础上，设计了信息平台的业务流程引擎和平台的统一运维体系。

在下一步的研究中，我们将继续平台体系研究进行深化，并针对不同类型的科技评估数据，对平台处理数据的时效性进行比对，根据平台对不同数据的适应性进行相应的优化设计。

【参考文献】

[1] Wiener P, Simko V, Nimis J. Taming the Evolution of Big Data and its Technologies in BigGIS: A Conceptual Architectural Framework for Spatio -Temporal Analytics at Scale [C]. International Conference on Geographical Information Systems Theory, Applications and Management, 2017.

[2] Rebelo C, Rodrigues A M, Tenedório J A, et al. Building 3D City Models: Testing and Comparing Laser Scanning and Low-Cost UAV Data Using FOSS Technologies[C]. International Conference on Computational Science and Its Applications. Springer, Cham, 2015:367-379.

[3] Viktor Mayer-Schonberger，Cukier K.Big Data：A Revolution That Will Transform How We Live，Work and Think. Boston：Houghton Mifflin Harcourt，2013.

[4] Gartner. Service-oriented Architecture Scenario [Z]. 2003-4-16.

声明：版权归《中国电子科学研究院学报》所有。转载请务必注明出处，违者必究。文章观点不代表本机构立场。