化工材料配方的实验数据治理模块设计

郁毅明,洪语晨,王 晔,董启文

（华东师范大学 数据科学与工程学院,上海 200062）

0 引 言

化工材料研究所的主要业务是研发新型材料的配方,化学配方数据繁杂多样.随着信息化的发展,相关企业提出了新的需求,化工材料领域的信息化建设也越来越复杂[1].

基于项目的某航天科工领域的材料研究所在信息化过程中使用了大量的科学技术手段,研究所的当前业务系统已经集成了相关的工艺设计管理系统、数据交换系统等.在配方研发方面采购了各类专业性的计算仿真软件来提升和辅助配方的设计和分析效率.

但是面对来自不同公司的种类、数量繁多的工具软件和应用系统,该研究所尚未将这些不同职能的工作统一集中管理.图1 介绍了当前研发业务的流程.初始阶段会分解项目,不同平台各自独立运行,进行材料设计、仿真计算等.但是在引进数据中心前,它们之间的实验数据或配方共享存在壁垒.尤其是分布在不同科室和多个系统中的数据不能集中,使得大部分的数据衔接工作依赖于人工处理,并且难以从这些分散的数据中挖掘有用的知识来指导和优化配方设计.因此,首先需要解决如何将分散的、老旧的数据进行上传、存储及保障数据的质量.

图1 材料研发业务流程Fig.1 Material research and development process

当前,数据治理领域的理论研究已较丰富,但尚未有统一的标准.因此,本行业的实验数据治理模块的设计过程主要借鉴和参考一些已有的数据治理模型来指导架构设计,该内容会在后文中提到.

为了解决数据治理中普遍存在的一些问题,企业界在数据治理方面也有相当多比较成熟的数据治理产品.如睿智智能数据治理平台,其具有统一的数据安全、质量、生命周期管理;阿里出台的大数据开发治理平台Data Works,是基于DataX 数据交换框架的一个平台,能够为数据仓库、数据湖、湖仓一体等方案提供大数据开发治理支持.除了上述产品,还有国内外的其他产品,它们的主要问题都聚焦在解决数据标准不统一、数据质量问题严重和应对结构化数据的治理场景上[2].但是不同企业总会有自己特有的需求,必须在这些已有产品和技术的基础上进行需求改进.虽然化工材料行业也同样需要解决这些核心问题,但是特别的地方在于以下3 点.

首先,实验数据的存储和处理不规范.升级前数据和数据之间都是单独存在的,没有建立起应有的联系,甚至有一部分数据只是简单地以文档形式保存,打通数据壁垒并完整可靠地上传至数据中心是数据治理需要解决的一个问题[3].另外,材料研发行业具有一定的特殊性,实验所需的配方组合或者实验结果的产出具有高度的不确定性.而传统web 应用的表结构基本是固定的,不能很好地满足表结构频繁变动的需求,缺乏可迭代可扩展的能力[4].

其次,实验数据的质量无法得到保证.一方面,引进数据中心前数据可能存储在不同的介质中;另一方面,已经初步信息化的科室数据之间也有代差,如数据标准、数据格式、数据标识的要求各不相同.因此,需要对数据库的数据存储进行标准规范,如数据的唯一性规则、连续性规则、数据的最大最小值等.这样可以提高数据质量,为以后的数据资产共享打下坚实的基础[5].此外,在材料配方的研发方面,需要定制企业自身需要的数据标准和规范.因为在材料研发过程中,配方会经由不同的科室进行仿真、实验及安全老化分析,配方在流转过程中可能因现实问题而存在噪声和缺失值,在大量数据存储的时候必须统一进行处理[6].

最后,研究所当前的各工作环节基本上是离散的、孤立的.研发人员为了掌握配方在各科室的进展往往需要大量的会议来协调,这极大地制约了配方设计及第三方计算软件的应用效果.因此,为了协助研发人员和管理人员把控材料研发进度和掌握各配方性能,势必要将实验数据资源进行整合,而且发挥数据的价值,辅助相关人员进行决策[7].

1 数据治理框架设计

当前,对于数据治理还没有权威的标准定义.IBM 对数据治理的定义为数据治理是对质量控制的规程[8],具体框架如图2 中的4 个层次,层次之间并不是互相独立运行的.支撑域作为整个框架的支撑部分,需要为核心域提供可靠的数据保障和安全保障.数据保障指的是有统一的数据资源服务,如元数据和主数据等;安全保障指的是对系统业务操作的日志审核功能,或对系统内部的安全管控等.核心域在获得支撑域的支持后,便能在数据的全生命周期中把控数据质量.同时,为了能够制定符合公司业务需求的数据标准,增强数据质量管理的能力,公司和企业需要有合适的数据治理委员会或者专业的数据治理人员,这便是重要的促成因素.最后成果层是指数据治理要能够为企业规避相应的风险并创造价值,以此结果为导向会逆向督促核心域和支撑域的持续改进[9].

图2 IBM 提出的数据治理框架Fig.2 Data governance framework proposed by IBM

DGI (Data Governance Institute)[10]认为,数据治理是指在企业数据管理中分配决策权和相关职责,重在关注数据治理的责任范围和执行流程,需要解决什么时候、通过什么流程完成决策.举例来说,如果其他平台接入的数据字段需要修改,应该跟哪些部门商讨,最终的修改由谁来执行等问题.总而言之,当前国内外数据治理的目的就是将治理功能分模块化处理,提高数据管理整个过程中的数据质量.唯有保证较高的数据质量才能实现数据资产的最大化,以此辅助企业进行决策和降低风险.

在数据治理的实践探索中,国内外也产生了大量的实际应用.例如,在企业级应用上有构建了知识管理战略与数据治理相结合的概念框架.在高校的信息化平台中,有Ogier、Hall 和Bailey[11]等运用英国格拉斯哥大学人文高级技术与信息研究所开发的数据资产框架 (Data Asset Framework,DAF)来评估图书馆的电子资源.其实还有很多医疗、金融、公安等方面的数据治理框架,不过都集中在热门领域,化工材料这方面的特定场景目前还比较缺乏.

在化工材料企业的研发业务中,整个数据中心负责材料研发数据项目中的知识获取任务,基于配方数据、仿真数据和实验数据来构建专题数据库,然后对其进行数据分析和挖掘,根据挖掘出的知识,帮助配方设计优化以达到项目目标.数据中心由数据治理模块、数据交换模块、分析挖掘模块、业务应用模块、安全管控模块和平台管理模块组成.而这次的模块设计主要是介绍其中的数据治理模块.

数据治理是数据中心的重要部分,主要解决上述提到的化工材料企业内的3 个关键问题,以此保证数据的可用性、一致性、完整性、合法性、安全性.确保数据在生命周期中有较高的质量,为材料配方设计提供高效的服务.该模块主要包括元数据管理、数据标准管理、数据质量管理、主数据管理和数据资产管理功能,如图3 所示.

图3 数据治理模块架构Fig.3 Data govern system structure

元数据的一般定义是描述数据的数据,能够做到对所有数据的抽象总结.根据元数据模型,首先,我们可以提出一套基于表结构的元数据模型.其次,基于元数据可以抽象表的结构,针对该元数据进行修改,从而达到动态修改表结构的目的,而用户无须关心底层对表的代码实现,并且各类元数据表中存储着表结构、外键等信息,表的血缘分析、关联度分析等都基于此开发.数据标准是指企业为保障数据的内外部使用及交换的一致性和准确性而制定的规范性约束,这套标准详细介绍了材料配方研制中需要用到的所有数据存储都应当符合制定的规则.数据质量管理要能够做到对数据进行事前预防和事后诊断,并根据数据标准制定数据质量检测方案,所有数据的存储,如元数据的存储都需要经过质量检测.主数据管理主要是为了更好地满足跨部门或者跨科室之间的信息共享,是一种关键的、权威的大价值数据.数据资产便是整套流程的最后产出,达到数据价值利用最大化.

2 数据治理模块实现

2.1 元数据管理

2.1.1 基于表元数据的扩展存储

为了满足材料配方研制过程中频繁修改表结构的需求,提出了基于表元数据的扩展存储方案.元数据是关于数据的数据,是为了描述数据的相关信息而存在的数据.而基于表的元数据就是描述表的数据.在实际的生产操作过程中,系统还有其他的业务功能模块.以正在研制的推进剂配方进行仿真实验为例,图4 所示的是某科室的仿真计算表,该表将会存储其他业务部门对配方进行仿真计算后的结果.以往数据的表结构都是固定的,但此时因业务变化,为了能够额外展示相关配方性能的研究进度,需要增加室温强度、室温延伸率等配方属性.而当前的表中只有常规的常温、低温、高温这几种属性,业务人员在此情况下需要对表结构进行扩展,方便业务系统计算完数据后能有新的位置存储.

图4 仿真数据的表结构描述Fig.4 Table structure description of simulation data

为了做到能够对表进行修改,系统需要一个能够描述所有表结构的表,只需要修改该表,表中对应的业务表也会随之变化,故需要维护一个描述表结构的表.此时将会遇到几个关键的问题: 后端逻辑是根据表结构来写的,如何在不修改后端逻辑的基础上修改表结构;修改变动不能立即生效而是需要申请审批后再进行数据转移.

首先,需要建立一个field 表作为表的元数据表.所有修改都是先对field 表进行修改,如图5所示,field 表存储的就是元数据.field 表中直接存储了表名、表的列名、数值类型、是否是主键等信息.另外,因为数据中心的数据库持久化框架采用的是JPA (Java Persistence API),应用的数据层Repository 可以继承各类JPA 提供的仓库,如JpaRepository 等,他们封装了对数据库的操作,可以直接使用JPA 提供的接口对数据进行查询,即直接用方法名来查询,省去了编写SQL (Structure Query Language) 的任务.JPA 会根据不同的请求生成SQL 语句,然后调用数据库的服务来执行.

图5 Field 类图Fig.5 Field class diagram

当管理者希望更改仿真的数据特性时,可在前端页面选择相关业务表所对应的field 内容中的字段进行直接增删改查,而不需要像开发者一样写代码.所有对业务表的改动都应当先通过field来修改,如图6 所示,修改完内容后提交修改申请.不同级别的管理员会根据修改请求是否合法进行判断,如果需要删除部分数据也应当由更高级的管理员来判断是否合理.申请通过后,field 表的数据会更改,并且相对应的业务表结构也会动态更改.field 表的更改和业务表的更改会根据Spring 提供的@Transactional 注解做到原子化操作.该模块提供的对field 的操作有更改字段中文名称、字段的名称、字段数据类型、是否为主键、是否有外键等,并且会根据是否是数值类型进行判断,如果是数据类型则可以设置其最大最小值.这个在用户查询所有信息后,凡是拥有访问权限的用户,根据系统提供的相关提示可以自行管理field 表格,之后就不需要联系后端或者开发人员进行代码上的修改.

图6 根据元数据管理修改表结构Fig.6 Modifying the table structure according to metadata management

2.1.2 元数据模板服务

原有的数据在各自科室的研发过程中会以传统的文件格式保存下来,当前的数据中心还需要将这些单独的、以文件形式存在的数据上传至数据中心,所以需要为用户提供上传模板.但是因为表结构的频繁变动,上传要求也会随之改变.因此,需要设计一个模板上传服务.当前表结构基于表元数据的动态扩展,所以上传模板也按照表元数据进行动态修改.Apache POI 为java 提供了一系列针对微软产品的操作库,系统使用了XSSFWorkbook 实现类操作Excel.在使用表元数据对表动态扩展后,会调用元数据模板接口,该流程会扫描刚才修改或者创建的表结构,读取列信息,将信息写到一个工作簿对象,最终以输出流写到Excel 文件中,并将Excel 文件推送至前端以供用户下载.

2.2 数据质量

2.2.1 数据标准管理

当前企业存在自身特殊的数据质量要求,保证系统中存储的数据质量是数据治理面临的首要问题.目前对数据质量有不同的定义: 数据质量是数据适合使用的程度;数据质量是数据满足特定用户期望的程度;数据质量是指一个信息系统在多大程度上实现了模式 (schema) 和数据实例的一致性,以及模式和数据实例在多大程度上实现了正确性、一致性、完整性和最小性[12].

在数据质量模块中,根据研究所和材料配方研制的需求,模块将数据标准分为技术标准和元数据标准.技术标准主要根据业务需求而制定,更多的是以文档形式展现给业务人员查询.系统主要是为其开辟了一个存储的地方.而元数据标准又能够分为编码标准和性能标准两个小类.编码标准能够将企业中的部门或者项目中的各实验配方进行统一格式化的唯一编码.确保每一条数据能够对应唯一的编码,并且管理者或者系统在大批量处理这些数据时能够根据编码直接识别数据的分类和含义,如图7 所示.编码标准代表了该类数据的编码必须符合特定的规定.以实验室项目编码标准为例,在实际应用中大类代码规定范围为0—99,如果设定的数据库中大类编码最大值是7,那么系统中凡是大类代码大于7 的都是不符合数据标准的数据,实际含义就是不存在此大类的项目.性能标准则是用来描述实验特定性能的,为实验数据框定了表达的形式.例如,在推进剂的配方中有燃温属性,该属性的目标值是2 600 K,起始值是3 400 K,实验目的是希望燃温能够越小以接近目标值,因此,对于燃温的性能标准需要确定其数值类型—最大值、最小值和保留的小数位数.既然规定的起始值是3 400 K,那么数据产生后,如果大于3 400 K,就一定是个非法或者错误的数据.性能标准在之后的数据资产展示中也会用到,能够清晰地衡量配方数据的性能.

图7 编码标准示例Fig.7 Coding standard example

同样地,数据标准的修改和制定也需要进行审批,先提交相关申请,申请通过后才会执行逻辑.这保证了系统的可靠性和安全性.

2.2.2 数据质量检测

数据质量检测是对数据标准的执行和补充.对数据的质量检测应当在数据存储前和存储后都有检测,这样才尽可能地保证数据的质量.一类是从预防的角度而言,在数据的生命周期的任何一个阶段,都有严格的数据规划和约束来防止脏数据的产生;另一类就是事后诊断,由于数据的计算和演化过程中可能产生错误数据,应当需要由特定算法进行定时的检查来解决和填补这些数据.

在数据上传和存储的过程中就应当先对数据进行清洗.数据标准为使用者提供了上传模板,用户在上传数据前按照要求格式填写内容.对于结构化数据,模块会将其视为一个文件输入流,将输入流转换成一个Workbook 对象,该对象可以很容易地操作Excel 文件.而对于非结构化数据,模块只是检查它是否是一个完整的文件.

结构化数据文件上传到后端后作为输入流,封装成Workbook 对象.扫描文件的表头将其和数据库中表的字段名字对应.随后逐行进行合法性检测,根据数据标准判断,如判断字符是否为空,是否超过最大、最小值等.如果这一行没有错误,则会把这一行的数据添加到“correctRows”中,而有错误的行会标注错误信息添加到“errorRows”中.前者正确的数据将直接储存在数据库相应的表中,后者错误的数据会作为附件通知用户查看哪些数据出了错误,并进行修改后重新上传.

当数据已经存储后,用户可以根据相关的科室,制定针对表里具体行的数据质量检测规则.模块为用户提供了以下多种数据质量检测方案.

(1) 规范性检验: 主要检验各配方和业务部门的代码格式是否规范,会根据之前制定的正则表达式匹配相应的数据,如果有不符合标准的情况,会将该条数据存储在相应的错误表中,显示在前端,专业人员看到问题后进行手动修改.

(2) 正确性检验: 主要是检测数据中是否有异常值和离群值的产生,如果一个数据偏离其他数据且分布过多就会将这条数据同样记录到对应的错误表中,随后在前端被专业人员查询出来,专业人员对该条数据进行重新计算和纠正,或者忽略.

(3) 时效性检验: 主要是判断数据的录入时间和产生时间是否有矛盾的地方,不应当出现录入的时间早于数据产生的时间.

(4) 完整性检验: 主要是对空值的数据或者值为零的数据进行填充.如果检测发现多条数据都为空值,则需要考虑该列是否还有必要存在.另外,该模块提供了定时任务,对于特定的需求,后端使用了Quartz框架来执行定时任务.因为对数据填充值的算法由企业提供,后端会有一个类来实现Job 接口,需要实现execute 方法,该方法可以获得spring 传入的context 上下文参数,以此获取制定任务时编写好的任务详情,根据任务详情的参数执行具体的定时任务.例如,对于力学性能的检测会通过计算上一个月的平均值来填充某一条数据的缺失.

综上所述,数据的检测主要由系统来完成,并且基于实验室提出的特殊质量检测规则进行异常数据检测.但是仍有部分数据检测到异常,对此系统可能无法自行修正而是给出标准建议,需由业务人员手动修改提交;修改不是马上生效,而是生成相应的审批流,需要管理员审核通过后才能修改成功;而且数据修改前和修改后的内容都会显示出来,保证了数据的可溯源性和安全性.

2.3 数据资产管理

数据资产管理的核心是数据资产化[13].在材料配方研制过程中产生的数据经过标准化处理和质量提升后,能够为企业不断地创造价值的数据,便是数据资产.而在当前的企业中,如何将资源整合,并通过什么方式展现资产是本章需要讨论的问题.数据资产管理本身由主数据管理、数据资产目录、数据打分系统和数据大屏展示等部分组成.

2.3.1 主数据管理

主数据一般是系统间重要的共享数据[14].该功能主要是将主数据管理分为两个部分,分别是主数据模型管理和主数据查询.系统中一般已经预设了一些主数据,如人员信息模型、部门信息等.这些信息如果不进行整合,在各科室中极有可能重复保存,各自保存的数据一致性也无法确定,从而导致这类关键信息的唯一性、有效性和共享性无法得到保障.

一份主数据模型可以让登录系统的用户均能访问到,并提供下载功能.若部门或人员信息有变动,将会在主数据管理的功能下,对该主数据表进行修改,做到各科室的主数据保持一致性.如果有新的主数据需要新建,可以增加主数据表.生成主数据模型时,操作人员需要选择该模型隶属于哪一个科室,这将直接作为部门外键关联到部门信息.当新建主数据模型后,首先,后端会根据该模型的元数据信息,生成一个XSSFWorkbook 对象,将属性信息填充进此对象.其次,将该对象以输出流的形式保存在硬盘上.最后,操作人员在上传该主数据表的数据时会依据上传模板文件填充信息,避免导入数据时格式出错等不一致性问题.但随着业务的发展,这类数据也需要可扩展性,因此,主数据和元数据也有着很大的关系.对于主数据的管理需要充分依赖元数据的功能,前文中提到基于表元数据的扩展存储,在主数据管理中同样可以选择对应的主数据表来修改表的字段,增加扩展性.

另外,主数据还是各部门间共享的核心业务数据之一.在材料配方研制领域中,主数据除了上节提到的基本人员信息外,成熟配方也是材料研发的核心主数据.成熟配方是在实验过程中得到的实践证明有效的配方,各科室的成熟配方最终都会在数据中心进行保存.此类数据是各科室开展下一步实验的重要依据,具有权威性和共享性,同时也是数据资产管理的重点管理对象.数据治理模块为成熟配方建立了配方数据库,成熟配方产生的数据重复、字段错误等问题由主数据管理单独实现.

2.3.2 数据资产目录

数据资产目录的建立能将各数据表信息汇总,解决系统中有哪些资源的问题.现数据资产检索提供了在一个界面就能查询有多少表、表结构信息和业务数据内容的能力.数据资产目录会采集元数据的信息,进行分类后在选择栏集中展示,用户查看一目了然.该功能将各部门和各科室产生的数据统一集中管理.用户可以根据表的种类查询当前已有的数据,如图8 所示.在“选择表”中可以预览表,选择需要查询的字段.该功能是基于元数据和主数据管理来实现的,底层依然是维护一个field 表,因为频繁地改变表结构后,原有的对象关系映射的操作部分失效,需要通过元数据表进行连表查询.

图8 数据资产检索界面Fig.8 Data asset retrieval

2.3.3 数据稽核打分系统

打分系统是对数据资产评估的一个重要部分,在数据资产展示中,展示什么数据、展示依据均需要通过打分系统来提供.用户可以自定义选择需要查询的表,根据业务要求制定打分规则.在配方研制过程中,配方和仿真结果的数值应当处于一个合理范围内,用户选择需要打分的表,也就是对某一科室的某一类实验数据进行打分.选择具体计算的数值列,规定区间上下限和权重后,点击运行,如图9 所示.系统会自动为该科室某一项目的所有配方性能进行排序打分并打上标签,之后存储在相应的数据表中.打分可以让研究员了解当前配方排名靠前的性能如何,是否处于理想的区间内.标签的定义由研究员定义,之后的数据展示会有一部分以标签分类的方式展示.因为数据要成为数据资产必需经过评估和打分,能够归类于资产的必然是少部分,所以,要在数据资产大屏展示的指导企业决策的数据需要经过筛选.

图9 配方数据打分界面Fig.9 Recipe data scoring interface

2.3.4 数据资产大屏展示

对于数据资产大屏展示,最重要的就是依据数据稽核打分系统对各实验数据进行打分,然后建立打分表.数据资产大屏的部分数据会根据打分表来展示.一方面,相较传统的数据图表这样展示更美观和直接;另一方面,数据展示具有打分依据,而非直接地堆砌.

如图10 所示,用户可以在资产展示大屏配置需要展示的选项.一般展示方式有两种: 第一种,直接从后端经过的打分表中筛选出需要的数据,打包后转换成JSON 格式返回前端,根据Echarts 的属性配置,填充在相对应的位置来展示数据;第二种,后端会根据用户在前端的操作,直接在对应的实验数据库中选出数据库后实时计算,将计算结果打包后返回给前端显示.图10 显示的是推进剂配方的资产大屏,以左上角为例,展示的是各项目配方力学性能实际水平和目标水平的进度比较.此处展示的是先前根据打分系统后排名前六的标签 (科室要求),能够让研究员清晰地掌握当前配方的研究情况,因为需详细展示配方各性能离目标值的差距,故以进度条的形式展现,非常清晰.性能排名靠前的配方代表了项目当前的最高水平,可以让研究员把握总体项目方向.中间仪表盘风格展示了当前主要模型的预示进度.最右图展示的是DKH-AL 标签的月度增量和累计增量,体现了每个月该标签新产生的数量.首先,该功能对已有的数据和指标持续监控,保证业务的正常运行.其次,能够发现配方研制的发展趋势和捕捉到特异点,使研究员能快速了解科室配方的生产速率.

图10 数据资产展示大屏Fig.10 Screen of data assets display

3 实验和测试

3.1 系统功能测试

系统功能测试环境介绍: 系统后端使用的是当前最流行的SpringBoot 框架,使用MySQL8.0 作为数据库服务器,使用Tomcat7.0 作为Web 应用服务器,以实验室网络作为测试环境.处理器为AMD Ryzen 7 5800H,内存16 GB.

系统功能测试顺序将按照数据治理的基本顺序入手.从数据的导入开始,新增一张数据表,为该表新建数据规则,检验该表内的数据异常是否会被系统检测到;再对数据表进行变动,查看上传模板是否更新;数据质量检测定时任务启动是否正常;数据资产大屏展示的结果和数据打分系统的结果是否一致.具体测试用例见表1.

表1 系统基本功能测试用例表Tab.1 Basic function test cases

3.2 系统数据安全测试

SQL 注入攻击是目前web 应用网络攻击中最常见的手段之一,安全风险较高.它不是利用操作系统的bug 来实现攻击,而是针对程序员编程时的疏忽,通过SQL 语句,实现无账号登录,甚至篡改数据库等不良操作.因此,系统数据安全测试主要是为了检验防SQL 注入的能力.

本系统设计了基于表元数据的动态存储方案,在后端代码中会出现大量SQL 拼接的情况.编写代码时需要防止SQL 注入,因此,后端SQL 多采用预编译的方式如PreparedStatement 或者用#{}值占位符.具体步骤是假设了3 种注入方式,覆盖平台29 处表单的输入情况.每处输出填入3 种异常值和2 种正常值,判断返回情况的正确率.正确率=预期返回结果数/ (正常SQL 数+含注入SQL 数).

第一种是条件注入的方式,在正常输入中加入“or 1=1”.第二种是堆叠注入,在查询语句中嵌入更新语句,更新已知账户的密码,更改为简单密码.但是此类操作基本难以成功,因为大多持久化框架不支持同时执行多条语句.第三种是错误抛出检验,如果系统后台未对数据库操作的报错做封装处理,则报错信息极有可能返回到前端,从而被黑客了解到数据库表的具体信息.实验结果见表2.

表2 SQL 注入测试结果Tab.2 SQL injection test result

根据预设的填入值,实验表明当前系统未有异常情况出现.达到了预期的效果.

3.3 系统性能测试

本系统主要为企业内部人员开发,高并发等业务场景在本项目中并不多见,因此,主要测试系统的响应效率.测试的功能分别为登录、新建元数据、修改元数据和稽核打分这4 个较为复杂的业务场景,使用的测试工具为Postman 和JMeter.Postman 是谷歌开发的一款网页调试和接口测试工具;JMeter 是Apache 组织基于 Java 开发的压力测试工具,用于对软件做压力测试.Postman 填写需要测试的接口,打包成一个collections,软件便可以模拟并发访问collections 中的接口.

4 个功能的性能测试分别在10、20、40 的并发下循环访问20 次,取平均值作为实验结果.测试结果如图11 所示.从实验结果可以看出,在并发量不断增加的情况下,响应时间总体没有超过100 ms,对用户体验基本没有影响,可以满足研究所日常的使用需求.

图11 接口访问响应时间Fig.11 Interface access response time

4 总结

文章介绍了化工企业在实验数据配方方面的数据治理模块的执行流程和设计实现.从当前研究所面临的实际问题出发,分析业务需求,结合已经成熟的数据治理框架和理论,提出了一系列亟待解决的问题.其中包括要建立一套符合业务规范的元数据管理体系,并根据企业的特殊性制定相应的数据标准和规范,且用特定的方法去执行,从而提高数据质量.数据质量管理有效解决了当前化工企业数据标准的制定和对数据标准能否有效执行的问题,将数据按照用户希望的格式存储,并能预警数据在运行期间出现的问题.具体展开主要有以下几点.

首先,元数据管理部分除传统的创建和查看元数据管理以外,又为系统提供了一套基于表元数据动态存储的方案,能够应对化工材料中实验数据信息和种类的各种变化,增加灵活性.针对表结构的修改都已经实现了相关的接口,用户本身可以在前端界面对于表结构进行直接操作,而不需要借助后端开发人员的介入.

其次,数据标准部分讲述了系统如何依据化工领域的业务需求制定数据标准,并通过数据质量检测功能来执行数据标准.在业务中将数据标准划分为元数据标准和技术标准,系统对技术标准负责存储,而对元数据标准要负责执行.数据质量对数据标准的执行主要从事前预防和事后诊断两个角度来检测,并集成了已有的表格操作库和定时任务框架来完成数据质量模块的设计和实现.

最后,数据治理就是实现数据价值的过程,即数据资产化.先是数据资产目录的建立,允许数据资产检索能够在同一个地方预览到所有科室的建表情况和表结构信息,解决了数据资源有多少的问题.然后是设计了数据资产大屏的功能,配合数据稽核打分系统,基于业务要求对实验数据和配方进行打分排序.最终以用户需要的形式对数据进行可视化展示,使企业能够很好地掌握当前项目的进展情况,了解配方性能研究的进度以及实验数据产出的速率等,从而帮助企业进行辅助决策.