多源数据辅助材料研发的数据应用系统

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

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

0 引 言

随着计算机技术的飞速发展,以及数据被国家列为生产要素,数据应用的重要性已受到了企业的重视,数据应用成为推动企业高速发展、提高企业工作效能的重要手段[1].在当下的大数据时代,数字化显然已成为各行各业新商业模式的“标配”,数字化转型也是各个企业的首要战略目标[2-3].材料领域的信息化建设起步较晚,同时,相关的数据也更为复杂,涉及研发、生产、管理、运维、服务等多个环节.材料行业需要一个集工业数据采集、汇聚、流通、分析、应用于一体的数据应用系统,实现“内增效、外增值”的数据内外双循环,推动应用的创新发展.

现阶段材料领域数据管理手段相对落后,多以纸质或单独的文件存放数据,同时存在多个相互隔离的系统,面临严重的数据孤岛问题,并且各个系统产生的数据类型多样.同时,研发数据存储在不同部门系统和书面材料中,使用者需要跨多个平台进行数据收集,该流程复杂且需要人工进行审批汇总,工作效率难以提升,数据资产的价值得不到充分利用.

本文针对材料研发单位现阶段面临的数据难以采集以及数据价值难以得到充分利用的问题,构建了数据应用系统,从材料研发业务出发,采取“管理材料研发数据、汇聚各系统数据、实现数据流通”的三步方针,打造集数据采集、数据流通、数据挖掘为一体的数据管理系统,推动产业的创新变革.

本文的组织结构包括研究现状、材料研发数据应用系统设计、材料研发数据应用系统实现、数据应用实例和总结5 个部分.其中研究现状介绍了目前材料研发部门数据应用的现状,系统设计章节介绍了数据应用系统的业务流程设计以及软件架构设计,系统实现章节从数据采集、数据处理和日志管理部分介绍了数据应用系统的具体实现方案,数据应用实例章节介绍了在此平台框架下实现的数据应用工具与实例.

1 材料研发数据应用现状分析

随着材料研发试验任务的不断增多,数据规模不断增大,试验系统不同,数据格式各异,过去大量的试验数据、实测数据分开存放在不同系统或以纸质形式存储备份,难以应用到实际的材料设计研发上,难以对历史数据进行整理分析,严重缺乏对各个系统的数据收集和管理应用能力.企业过去一直采用完成试验后,负责人员对单次试验数据进行记录与整理,项目完成后,进行项目数据的整理与归档,数据多以纸质文件或电子文档的形式进行存储,该过程需要消耗大量的人力和时间.数据存储分散,数据难以收集整理,导致了数据价值无法得到充分利用的缺陷.

目前,对材料研发数据的采集、处理、分析进行“一站式”的处理方案,已有的工作主要是针对材料编码映射功能进行系统设计[4],或是针对某一特定材料领域进行具体的数据库设计以及数据应用实现[5].现有的数据采集工具,如sqoop[6]、DataX[7]等,适用于大数据量下异构数据的采集同步,与目前缺乏多个数据系统数据采集方式的需求匹配度较低;现有的机器学习、数据分析系统,如H2O[8],是将各模型参数以可视化界面提供给用户进行设置,数据分析学习门槛较高,且数据来源单一,无法解决目前数据分析的需求.

数据应用系统建设的目标是汇集整合各类业务系统数据,有效解决各业务系统间存在的信息孤岛、信息壁垒等问题,构建形成一套上下级联合、横向贯通、逻辑一体化的数据服务体系[9].

现阶段各材料研发部门仅仅实现了单个业务部门各项目数据的统一管理,数据间蕴含的价值无法体现;各种类型数据间关系无法进行关联,整个数据循环无法达到闭环传输利用的效果;缺乏从海量数据中快速、可配置化挖掘有效信息,以及利用已有数据提高材料研发效率的能力.基于上述情况,本文提出了材料研发数据管理系统的设计方案,希望对解决材料领域数据管理中存在的诸多问题能起到借鉴作用.

2 材料研发数据应用系统的设计

2.1 业务流程框架

根据材料研发行业的业务需要,数据应用系统需要汇集各类业务系统的数据,涉及性能计算数据、仿真模拟数据、试验数据、试验流程、人员管理、材料库存价格管理、系统日志信息等各类数据.

为满足材料研发行业对数据的应用需求,将材料研发数据应用系统分为4 个主要模块,分别为数据采集、数据处理、数据存储及数据应用(图1).数据采集模块用于汇集各类业务系统的数据,提供日志采集、数据全量抽取、数据增量抽取、数据接口导入,以及文件上传等方式导入数据.数据处理模块负责将采集的数据进行清洗、标记、分类及过滤等预处理流程,并最终汇入数据资源池中.数据存储模块负责存储数据资源池中的数据,并向用户提供分类分级的功能,根据不同数据的类型和特征以及业务的需求,将其存储在分布式文件系统或数据库中.最终整合得到的数据,通过数据应用模块,为用户提供数据挖掘、数据统计、专题数据归档、预测分析、可视化展示等业务功能.

图1 数据应用系统业务流程框架Fig.1 Framework of data application system business process

2.2 软件架构

数据应用系统的软件设计模式采用广泛使用的 Model-View-Controller (MVC) 模型,即业务模型、用户界面和控制器[10].MVC 设计模式的目的是将业务逻辑和用户界面的实现进行分离,从而使得应用该程序可以有不同的表现形式.当需要改变交互界面时,只需要关注用户界面模块的代码,而不用修改业务模型.

基于MVC 模型,数据应用系统的软件架构采用3 层架构(图2),即客户端表示层 (Web 层)、业务逻辑服务层 (Service 层)、数据访问层 (dao 层)[11-12].各层包含的模块描述作如下描述.

图2 数据应用系统软件架构Fig.2 Framework of data application system software architecture

表示层: 用户看到的主界面,数据应用系统中主要包括日志展示页面、数据接入页面、数据处理页面、数据挖掘页面、专题库页面、数据可视化页面.

服务层: 根据业务模型实现的各类服务功能,通常调用数据库来实现数据的获取.根据材料研发系统的具体业务需求,数据应用系统中实现了9 种主要的服务逻辑,包括日志获取、日志分析、数据采集、数据处理、数据共享、数据清洗、专题库、数据挖掘和配方预测.

数据访问层: 存放实体类并支持对实体的访问,也就是对数据库的增、删、改、查等操作.数据应用系统的实体包括材料研发库、专题仓库、数据信息库、日志操作库.根据数据实体的数据量及其业务模型,将这些数据存储在关系型数据库系统或者Hadoop[13]的分布式存储中.数据处理流进行数据跨系统、跨平台的操作流处理.

3 材料研发数据应用系统的实现

由于数据的指数增长趋势,多个已有系统间的数据难以流通和集中管理处理,材料研发企业面临着数据孤岛、数据价值难以充分利用的问题.本章将介绍数据采集、数据处理、数据挖掘、日志管理在当前业务场景下的实现.

3.1 数据采集模块

数据采集模块的目的是将不同数据来源、不同数据格式的数据汇集到数据湖中,打通数据系统之间的数据链路,实现跨系统的数据融合,并最终为上层的应用业务提供统一的数据服务,是数据应用系统中数据集成的重要部分,是数据管理的基础.

数据采集模块的设计主要面临以下挑战: 首先,数据应用系统包括各式各样的数据来源,例如用户直接通过业务应用系统上传的文件数据、业务数据系统定期产生的生产数据等,因此,数据采集模块需要支持从各种数据源获取数据;其次,不同场景的数据采集任务具有不同的性能需求,例如在线的业务系统需要低延迟的数据同步,而从现有系统迁移历史数据时则需要高吞吐的数据拷贝,因此,数据采集模块需要为不同应用场景提供不同的数据采集方式.

为了解决以上问题,如图3 所示,数据采集模块提供了以全量抽取、增量抽取、接口接入及文件上传4 种形式为主的多种数据采集方式,满足不同数据源、不同应用场景的数据采集.目前在材料应用系统中,全量抽取方式主要用于对已有的存放在不同系统中的数据进行采集时,一次性批量收集到大量历史数据,实现高吞吐的数据拷贝,如外部新接入系统的数据收集;增量抽取方式用于数据实时性要求不高的场景,对数据进行定期收集,如性能模拟平台所产生的模拟数据;文件上传适用于用户加工筛选后的数据进行数据汇总,以及需要批量上传本地非结构化文件(如图片、文档)的情况;接口接入主要提供给其他正在开发中的系统,提供其主动进行数据汇集上传的功能,实现低延迟的数据同步,如外部的协同平台产生的科室、项目人员分配数据,以及材料应用系统中新录入的材料数据.这4 种接入方式彼此互补,适用不同来源与不同性能需求的场景.

图3 数据采集流程Fig.3 Workflow of data acquisition

全量抽取是通过数据库全量同步的方式,将现有系统中数据库的数据保存到统一平台中的方法,目前主流数据库都提供了数据批量导入导出的功能,因此,在功能实现中主要是提供数据备份传输的工具.全量抽取涉及的数据量通常都较大,对整个表乃至整个库的拷贝需要操作的时间较长,采用的方法往往是通过批处理操作.即在对方服务器上建立 Shell 脚本,将所需数据库数据通过SQL(Structured Query Language)备份,并进行压缩后,通过SFTP (Secure File Transfer Protocol)将数据批量打包发回到集成平台,集成平台收到数据后,将数据解压,并存储到数据湖中.

增量抽取是不同于全量抽取的一种数据采集方式,通过对原有数据的增加、删除、修改,保持和最新数据的同步.框架通过使用定时程序获取日志的方式,对目标数据库进行Binlog 获取[14-15],获取后的Binlog 进行压缩后,将其发送到集成平台,同时在目标数据库所在节点,保存日志读取起点偏移量.集成平台中一个线程负责接收不同目标数据库发送的同步数据,并将其保存在本地文件中,另一个线程将本地的日志文件加载到数据库中.通过规定每隔一定时间将操作发送到集成平台,并在集成平台执行,以保证集成平台中数据库与目标数据库保持同步.通过对全量抽取和增量抽取的实现,可以看出对目标数据库进行数据采集的原则,即不干扰原有数据库的运行、不对原有系统运行逻辑进行修改.

接口接入是通过让数据采集模块开放一定格式的接口,对方系统在完成业务逻辑或需要对数据进行同步时,对对应接口进行调用,以传递最新的数据.其中接口需要包含目标导入数据库、数据表,按照预先定义好的数据格式进行数据传输.数据采集模块完成对请求参数的解析,并将其转换成对应的文件系统或者数据库的操作.接口接入的方式主要是提供给仍有程序员维护或者还未实现的系统进行调用的.

文件上传方式则是通过构建一个文件上传服务,用户将文件发送到系统,然后数据应用系统通过对文件进行解析,将数据保存到数据库中.其中,针对结构化数据及存储在数据库中的数据,数据应用系统根据已有的数据表生成对应的模板文件,完善模板文件内容后,根据表结构对文件进行解析,批量进行数据库添加操作.同时,支持通过文件上传的方式采集非结构化数据,如音频、图片等,将非结构化数据存放在文件系统或分布式文件系统中.

3.2 数据处理模块

数据应用系统中收集的数据来自多个外部系统,包含结构化数据、半结构化数据和非结构化数据,数据的规范性难以保证,且存在不同数据源数据编号编码不统一等问题.因此,在数据采集后,需要提供统一的数据检查与处理模块,最后将处理好的数据存入数据湖中.针对接口导入的数据和以文件上传、增量或批量获取的半结构化与非结构化数据,分别采用了消息队列和文件系统对数据进行存储.针对数据量大、数据批量获取的场景,提供了定时任务进行数据处理;针对数据量小、数据流式进入平台的场景,采用流式任务进行数据处理.

数据处理模块功能的基本架构如图4 所示,主要包括数据获取、数据处理、数据存储3 个部分.

图4 数据处理模块架构Fig.4 Architecture of data processing module

数据获取途径主要分为接口接入和文件上传两种方式,其中文件上传包含数据库增量、全量数据变更,以及通过API (Application Programming Interface)批量导入数据.

通过文件上传的数据会根据对应的具体模块,将数据库变更文件以及用户上传的文件保存在相应的目录下.大量数据的存放使得数据的查看以及检索效率低,因此采用数据索引来加速数据查询,常见有的Elastic Search 及Solr[16]工具.其中,Solr 能够对更多格式的数据、文件建立索引,而不仅仅是json 格式,且提供了查询语句,因此选用了Solr 来加速数据查询.而半结构化的数据主要为从数据库中抽取得到的数据及批量上传的csv、Excel 数据,以及从其他系统中获取的json、xml 等格式的历史数据,这些数据获取后存放在对应模块的文件目录下,为后续数据处理做准备.

通过接口导入的数据主要来自其他内部系统,在接收到接口导入的数据后,将数据放到Kafka[17]中对应的topic 内,等待后续进行数据处理.

文件上传的数据保存在本地后,通过定时任务去执行对应的数据解析、数据过滤、数据转换操作,处理完成后的数据存放至hive[18]中,而没有对应数据处理操作的数据,以文件的形式存储在底层文件系统中.

对于接口导入的数据,通过事件通知的模式,当对应队列不为空时,唤醒相应的数据处理服务进行处理.

数据处理时采用Airflow[19]作为数据流处理的调度和监控工具,根据各个任务的流量不同,设置相应的任务时间间隔,批量将数据进行处理后存入底层数据存储系统中.如果在处理过程中发现数据不符合预先规定的格式,则记录错误日志,并将数据归档至输入错误的数据中.

针对材料研发部门的具体需求,数据应用系统提供了一系列数据处理功能,包括: 配方类别编号、成药编号和试验编号是否符合规范;采集到的数据是否符合对应类型与阈值;根据测试性能、试验性能等数据对配方进行预分类;自动对缺失数据值进行填充;将计算软件、仿真软件的数据进行聚合,筛选过滤不符合要求的数据等.

3.3 日志管理模块

针对数据应用系统中包含多个子系统,数据库日志、应用日志、网关日志分散存储在不同机器和不同地址下,用户和运维人员难以通过零散大量的数据进行系统使用情况、系统出错原因诊断,因此提供了日志管理模块,对系统中的日志进行收集、处理,和相应的展示功能.

日志管理模块的基本架构如图5 所示,主要包括日志数据源、日志采集、日志处理和日志展示.

图5 日志管理模块架构Fig.5 Architecture of log management module

日志数据来源主要有系统日志、网关日志、应用日志、数据库日志.日志采集支持对Windows和Linux 系统日志进行采集,采用了Filebeat 和Winlogbeat 进行数据采集,两个工具都是elastic[20]社区提供的轻量级日志收集工具.其中,winlogbeat 通过windows API 获取事件日志,如硬件日志、安全日志、系统日志,并进行过滤.Filebeat 能从系统中收集日志,并将其进行上报,同时具备资源占用少,侵入性小的优点.

在日志采集至日志存储到日志服务器的过程中,为了支持海量日志收集处理的高并发场景,以及做到日志来源与不同类型日志处理服务器的解耦,在日志采集与日志处理之间,添加了消息中间件Kafka,使用消息中间件将相同类型的日志流交给不同日志处理器进行处理[21].同时,Kafka 集群所支持的高吞吐及可持久化的特性,降低了数据丢失及高并发量下日志处理的压力.

日志清洗部分采用了Logstash.Logstash 包含input、filter、output 三部分.其中,input 是Logstash可以通过过滤器解析各个事件,识别已命名的字段以构建结构,并将它们转换成通用格式,以便后续对日志进行分析和可视化等.

日志存储在ElasticSearch (ES)集群中.ES 是一个基于Apache Lucene 的全文搜索引擎,提供了分布式的实时文件存储,支持应用通过RESTful API 等多种方式进行交互.

采用Kibana 和Zabbix 向用户提供日志查看分析和可视化功能.Kibana[22]支持通过Lucene 语句或Query DSL (Domain Specific Language)语句检索ES 中的数据来进行数据可视化构建,并且内置柱状图、饼图、条形图、热力地图等多种类型的图表,用户容易上手,可以配置数据展示大盘,能够进行分时段的数据展示.Zabbix 是一个能够监控各种网络参数以及服务器健康性和完整性的软件,Zabbix 使用灵活的通知机制,允许用户为几乎任何事件配置基于邮件的告警.通过配置被动监控项以及对应的触发器,将Logstash 处理中包含报错信息的数据发送至Zabbix,通过Zabbix 分析报错信息并提供报警机制.

4 数据应用实例

数据采集和数据处理模块解决了数据孤岛、数据彼此独立和无法关联的问题,在此基础上需要进一步对整合的数据提供数据应用方法,充分利用数据辅助决策,挖掘数据价值.在数据整合的基础上,提供了专题数据库、配方综合排序、数据挖掘3 个数据应用实例.

4.1 专题数据库功能

针对数据规模大,数据列多,研究人员对数据的分析、查看等操作,多基于课题、科室等对数据进行划分的问题,提供了专题数据库功能.

专题数据库构建功能提供查看多个相关联的数据表,以及只查看部分列,并且能对数据进行简单的筛选.方便不同的课题组和科室,构建不同的专题数据库来更好地进行数据分析、数据可视化等工作.

专题数据库中提供用户选择多个表进行连接的功能,支持用户选择一个表的指定列作为连接列,选择另一个表时,能够自动过滤,显示出与连接列类型相同的属性列.完成设置后,专题数据库服务进行数据表创建,提供用户根据专题数据库表名进行数据分析处理的功能.

根据用户提供的表名、列名、待显示列、待连接的表名、连接的列名信息,生成多表连接语句,并在提供可连接列时,自动筛选符合条件的列信息,最后根据表名、列名进行去重,避免因为重复选择导致一个列出现多次.专题数据库的实现流程如图6 所示.

图6 专题数据库流程Fig.6 Workflow of thematic database

4.2 配方综合排序功能

材料配方数据多为列数多的稀疏矩阵,包含重要信息的属性分散,难以通过传统的数据处理工具快速进行多功能排序,数据应用系统提供了对数据中可枚举、可数值计算的属性设置加权打分的功能,计算输出各属性列的得分情况以及根据规则加权计算后的综合得分.具体综合排序规则定义方式参见表1.

表1 排序规则定义Tab.1 Definition of collation

用户提交打分规则后,将打分规则存储到数据库中,然后逐行对该表的数据进行处理,对每一行数据,对规则表中的每条规则进行遍历,符合要求的则按照该规则的分类和计算方式对该行数据的总分进行累加.最后根据得分由高到低进行输出,同时支持导出功能.

该功能的流程如图7 所示,在用户提交一个打分规则后,将所有行的得分初始化,并逐行处理数据表,然后判断是否满足制定的规则.如果满足,则对得分进行更新,直到所有规则都处理完成,将最终得分进行排序后返回给用户.用户也可以选择完排序规则后,将排序规则进行保存,再次访问同一个配方表的排序界面时能在已有保存规则的基础上进行修改.

图7 配方综合排序流程Fig.7 Flowchart of formula comprehensive sorting

4.3 数据挖掘功能

材料研发领域的历史研究数据量大,数据间的关系难以通过传统的观察、推测的方式总结出来,且相关从业人员缺乏运用机器学习等工具进行数据分析的经验.数据应用系统提供了部分数据挖掘功能,辅助科研人员决策.

数据应用系统提供了标签系统、配方组分推荐、配方性能预测、相关性分析、大小规模预测等功能,帮助用户进行数据分析.

根据数据应用系统收集到的配方数据、实验数据、模拟数据和实测数据,提供用户对配方、性能数据进行批量设置标签的功能,方便用户对数据进行筛选.在标签系统的支撑下,能够对数据进行多种分析.其中,配方组分推荐功能为: 根据性能数据,预测配方的类型标签,辅助进行得到目标性能的材料组成判断.配方性能预测功能为: 根据配方组分信息,预测其对应的性能数据.大小规模预测功能为: 根据小规模的实验数据,预测更改数据量后的配方性能数据.这些功能的具体实现结构见图8.

图8 数据挖掘模块架构Fig.8 Architecture of data mining module

5 应用效果与分析

本文所搭建的多数据源数据采集、数据处理与数据应用为一体的系统,解决了目前材料研发单位的现有数据使用问题,该数据应用平台有如下优点.

5.1 系统功能测试

数据采集: 提供了4 种采集方式,用于不同场景下的数据采集,包括数据全量抽取、增量抽取、接口接入、文件上传,能够针对数据来源不同,使用相应的解决方案进行数据采集.

数据处理: 数据收集后需要进行处理和索引,且提供了定时任务和流式任务方式,对数据进行处理,包括数据缺失值填充、数据过滤、数据格式转换等,并将半结构化和非结构化数据进行统一存储和构建索引,加速查询.

日志收集: 不同系统日志和应用日志收集,辅助使用人员和运维人员快速定位错误,以及实时了解系统运行情况.

数据应用: 针对材料研发的具体需求,提供了专题数据库、数据综合排序、数据挖掘等一系列功能,屏蔽了底层模型、数据处理的复杂问题,降低数据应用的难度.

系统功能测试主要是从用户的角度出发,对数据应用系统相关的各项功能进行测试,从而确保每个功能的可用性.本次功能测试采用等价类划分法和边界值分析法设计测试用例.表2 展示了系统基本功能测试的部分典型用例.

表2 系统功能测试用例表Tab.2 System function test case

5.2 性能测试

系统在数据应用实例中提供了多种数据挖掘功能辅助研发,相关功能的时延对用户系统使用体验影响较大.本文对常用的数据应用功能性能,包括配方性能预测和配方组分推荐及相关性分析功能等,相应时长进行了测试与统计.统计结果如表3 所示,各个功能在数据量1 000 左右时,都能保证在1 s 内完成模型训练,能够满足日常材料研发人员根据已有样本数据对新材料配方快速模拟测试的需求.

表3 数据应用性能测试结果Tab.3 Data application test results

6 总结

本文以国内某材料研发单位的内部数据平台项目为背景,设计开发了适用于该单位的数据应用系统.该系统整体框架灵活、支持跨平台,提高了数据管理、数据收集流程的效率,能以较少的人工和时间成本完成数据管理.该数据应用系统提供了数据采集、数据处理、数据分析、日志管理等功能,解决了传统材料研发单位数据孤岛及数据价值难以充分挖掘的问题,提高了材料研发信息化发展水平.

本文所使用的数据应用系统架构以及系统收集数据、处理数据、数据挖掘的技术,主要针对于材料研发单位所面临的数据难以收集、材料研发配方性能数据量大、数据价值难以充分利用的场景.增强系统数据的安全性、可靠性,以及数据管理系统所采集的大量日志数据的利用,将成为后续数据管理系统的研究重心.