面向结构化篇级科技文献数据治理的高性能分布式计算框架研究*

范 萌 常志军钱 力郭 丹

(1.中国科学院文献情报中心 北京 100190;2.中国科学院大学经济与管理学院信息资源管理系 北京 100190)

0 引 言

加强科技基础能力建设是加快建设世界技术强国的必然要求[1],为加强科技基础能力建设需要推动关键软件技术国产化,以应对科技脱钩,保障科技文献服务的战略安全。在科技图书文献数据中心建设过程中,数据治理、数据存储、数据检索是技术维度上要解决的主要问题,其中又以数据治理问题最为突出。

目前科技文献数据中心的数据体量达4亿篇,主要数据类型包括论文、专利、项目、图书、标准、政策、奖项、会议等10种,需要进行多样性数据治理的结构化数据都存储在Elasticsearch和Mysql中。在科技文献数据整体治理的架构中,数据治理包括数据的可获得性、可用性、完整性和安全性[2],多样化数据治理主要发生在基础数据治理、增值数据治理、精编数据加工、异质网络数据建设四个阶段。数据处理需求来源分为3种:a.数据资产组织结构要求;b.数据质量控制核对需求;c.业务应用需求。其中业务应用需求占较多的比例。比如很多数据处理需求是业务人员在撰写情报分析报告时,需要对多类数据进行临时处理和统计,这种计算只需要使用一次。

在上述背景下,本文提出一种高灵活、低门槛的高性能计算框架ArticleCF,其可有效规避MapReduce、Spark、Storm等计算框架研发周期长、技术门槛高的问题,同时还可以通过分布式形式,实现数据的高效处理,以满足数智驱动情报分析的文献情报数据治理需求。

1 相关研究

1.1 分布式数据治理

目前,数据治理已经成为企业治理和国家治理的重点领域和重要方式[3,4]。科技文献数据治理全流程如下图1所示。在科技文献智慧数据中心建设的协同治理阶段,源于业务的定制化处理需求是数据持续治理的关键环节,这就依赖于一种高效、易用的数据治理平台,其不仅实现可视化、模板化数据筛选、数据处理、数据输出等功能,还能使得业务人员直接参与数据治理任务,有效解决数据研发团队支持能力的瓶颈难题,为文献情报在数智时代的变革打好坚实的软件基础。

图1 科技文献数据治理全流程

ArticleCF在功能上针对科技文献数据特点进行多个维度的设计,以满足篇级结构化数据的处理需求,重点设计满足该业务场景的分布式任务分发策略、并行计算策略以及故障转移机制。同时为给用户提供任务执行信息,专门设计丰富的跟踪机制,全面报告任务的进展及可能存在的问题。设计要点包括:a.限定处理数据的格式为结构化数据,可简化算子函数的输入、输出设计。b.通过可视化在线编程技术,降低入门难度,用户通过简单拖拽即可实现串行数据处理流程的设计。c.提供丰富的函数库,类似SQL语法中的count、sum、distinct等函数,为功能实现节省研发成本,提升代码质量,提供新功能函数发布功能,提升用户体验,用户可以发布新函数,不断丰富函数库。d.控制用户资源使用量,对集群资源进行科学分配,尤其加强对空闲资源的利用率以及对用户资源的及时回收保障。e.增加权限管理机制,为任务安全、数据安全、代码安全做好保障。f.采用Sql、Python语言作为支撑语言用于处理数据子集筛选和功能编码。g.支持串行处理模块的热插拔功能,执行节点具有模块版本核对和动态加载Python模块的能力。h.集群具有弹性扩展能力,通过增加处理节点的数量,近线性提升数据处理能力。

本文以需求为导向、以场景为牵引,提出的ArticleCF是专门为结构化科技文献数据多样性协同治理研发的计算框架。通过设计调查问卷,向业务人员征求需求和意见,力求保证ArticleCF能够满足日常工作中常见的数据治理需求。为科技文献情报向数智驱动模式演化提供坚实的数据基础和高效的数据治理能力。

1.2 分布式计算框架

提高科技文献数据治理水平是提供高质量文献情报分析与服务的基础,而文献数据计算框架的性能高低直接影响科技文献数据治理水平。面对激增的海量数据,Huwe认为图书馆的科技文献数据治理需要依靠Hadoop与Spark计算框架[5];王海萍提出基于Spark内存计算框架的图书馆文献检索服务,从而提高目前图书馆在对大量文献数据进行检索的准确率和效率,提升文献数据治理能力,优化文献服务质量[6];蒙杰提出基于Hadoop的海量科技信息资源管理系统,实现对科技信息资源的安全存储与高效访问[7]。由此可见,目前面向结构化篇级文献数据的计算框架主要是以Mapreduce、Spark为代表的分布式计算框架。

1.2.1MapReduce计算框架

MapReduce是Hadoop生态圈的核心分布式计算框架[8], 其核心思想是分而治之的数据计算策略,将大数据切分为小的Block数据块,进而分别独立处理计算。该计算框架主要通过Map (映射)和 Reduce(归约/化简)两个阶段,实现各类业务的处理过程[9,10]。目前MapReduce被广泛应用于工业界的多种海量数据分析场景[11-13],除此以外还广泛应用于医疗临床大数据筛选[14]、关联规则挖掘[15]、水产农业[16]等领域。MapReduce属于离线计算框架,采用离线调度算法完成对全部任务的调度和管理[17]。MapReduce通过溢出写盘技术和故障自动转移技术降低对硬件资源的要求,因此MapReduce集群搭建成本低,只要有计算能力的服务器均可加入到集群中,进而发挥一定的计算能力。由此可见,MapReduce计算框架适用于数据存储在HDFS文件系统中,并且对时间响应耗时要求不高的大规模数据的计算场景。基于此,在设计ArticleCF的架构时,需要着重考虑作业启动与完成的耗时,克服Mapreduce延迟较高的问题,以提高计算框架的灵活性,满足对时间响应与耗时要求较高的任务场景。

1.2.2Spark内存计算框架

Spark是面向迭代机器学习算法的新框架[18],它支持交互式数据分析的同时还保持了MapReduce的可伸缩性和容错性。Spark在迭代机器学习作业中的表现可以超过Hadoop的 10倍,在ETL等数据处理任务中,两者相差不明显。Spark具有更丰富的算子,包括map、mapPartitions、flatMap、filter、reduceByKey、groupByKey、join、 reduce、aggregate、foreach等,支持更灵活的编程。Spark没有独立的存储系统,需要与其他的存储系统进行集成[19]。Spark适合具有大量迭代计算的场景,Spark在大规模图像处理[20]、工业网络安全[21]、心电信号数据挖掘[22]、电力系统监控[23]等领域得到广泛应用,在硬件资源充足的情况下,其在实现数据排重、知识图谱构建、主题标引等业务场景也具有出色表现。由此可见,Spark具有性能快速、算子丰富等计算优势,但是对于不熟悉分布式计算的开发人员而言,要想掌握其编程模型和调优技巧,需要很高的学习成本。因此,ArticleCF计算框架考虑设计可视化在线编程模块,对于那些晦涩难懂的程序函数,用户只需要进行点击拖拽,就能实现相应的功能,降低用户使用门槛。

1.2.3Storm流式计算框架

Apache Storm是一种低延迟分布式流处理框架[24],也被称为实时Hadoop。通过Zookeeper进行任务管理,具有较高集群容错能力,运行中模块处于无状态模式,随时宕机重启。Storm创新性提出的ack消息追踪框架和复杂的事务性处理,能够满足很多级别的数据处理需求。使用 Netty作为其通信组件,Netty是一个基于TCP/IP协议栈的异步服务器/客户端框架[25]。Topology是Storm的执行任务单位,每个Topology 由Spout和Bolt构成,Spout负责发出待处理的Tuple数据, Bolt通过订阅指定Spout或者Bolt发出的Tuple,并编写具体的处理逻辑完成任务目标。Apache Storm在电商领域用户分析[26]、大规模图像检索[27]、实时生理信号采集与分析[28]等方面都有广泛的应用。Storm在处理大规模实时数据流和低延迟需求方面都具有很高的价值,不过与Spark一样,学习成本很高,集群的部署和管理需要具备专业知识和经验,同时,其生态系统中可用的可视化和监控工具较少。因此,ArticleCF计划设计一个资源管理模块,实现Slave节点与服务器信息的实时监控,更好地管理计算集群。

1.3 篇级文献数据计算

科技文献大数据建设从国家“十三五”期间已经开始,并逐步实现从0到1的突破,基于Hadoop生态群分布技术建设了完备的数据汇聚、通用治理、数据索引及服务的平台和工具集。通过MapReduce实现多对亿级别文献数据的ETL处理,采用Hive作为数据仓库,基于Spark完成了100亿级知识图谱的构建,依托Elasticsearch搜索引擎实现知识检索服务,引入Spring cloud微服务架构,提升负载均衡和接口扩展能力,部署Redis作为高速缓存保证在线服务性能。同时,随着人工智能技术的发展,研究人员发现对数据的治理从基础的ETL开始迈向对细粒度知识的智能挖掘层面,对数据的应用也从知识维度开始向智慧维度发展。在新一代技术的驱动下,文献情报范式正在向数据驱动的方向转变。但是,当前的集群和技术明显已不能满足新阶段的数据治理的需求,需要在现有的基础上研发更符合数据治理要求的一套平台和工具。比如在MapReduce的map函数中,读取Elasticsearch中的数据,不能控制并行度,Spark通过组件实现对数据的读取,在程序段同样无法控制并行度,无法控制计算给Elasticsearch带来的压力。目前,尚未出现面向科技文献情报领域,支撑多情报分析、知识发现的多样性数据治理需求的灵活、易用的计算框架。

2 启发式思考

a.基于NoSQL数据Scroll读取速度明显高于写入速度。科技文献结构化数据的多样性处理,需要经过筛选读取、串行治理、结果写入三个基本阶段。通过实验可知,在实际应用中,结构化数据的读取速度比基础处理速度要快2倍。以知识产权数据为例,存储系统为Elasticsearch集群(15台服务器,服务器:惠普HPE DL380,配置:CentOS 6.8操作系统,RAID0 10*4T磁盘阵列,32核128GB内存),数据总量为66 297 744篇,索引有效数据总量为65 977 583篇,数据的读取和写入均为单线程,读取数据和写入数据的时间耗时(见表1)。

表1 知识产权数据读取、写入时间对比

基于此规律,ArticleCF的读取模块可以基于Scroll的数据读取以单节点的方式进行,以简化数据操作;写入模块则需要分布式模式进行,通过并行度提升ArticleCF的数据处理性能。

b.通常数据库数据都具有唯一ID,体量小,适合用于任务分配、跟踪。ID的数据容量与全字段数据体量具有很大的差距,以论文、专利元数据为例,ID的长度与全字段长度相比,达到1:20。因此ArticleCF的任务管理模块,可通过数据的唯一ID进行分组,构成任务分配的最小单元batch,管理处理任务的执行状态。各处理节点收到batch后,以分布式形式进行全量字段的数据获取。

c.建立数据写入权限控制机制,区分原表写入和临时表写入。数据串行处理得到结果数据,本架构仅支持写回系统为Elasticsearch和Mysql两种。为了区分原表写入与临时表写入,结果数据回填原表之前,ArticleCF会对其进行审核,保证操作不破坏原有数据整体设计;若每个用户处理的逻辑也表现多样性,则参考MapReduce的文件输出模式,存储为结果文件形式,但为了输出文件的管理,专门设计写出功能。

d.支撑函数级编程框架,构建常用操作函数库。本架构面向的是结构化数据处理,因此在数据规范性方面具有较大优势,对数据治理的操作也集中在对字段的规范化、合并、排重、拆分、映射等操作,这类操作具有很大的共性可挖掘。在结构化优势基础上,ArticleCF的可视化编程模块引入函数级编程,借鉴map、reduce思想,明确定义各类函数统一的输入、输出结构,通过规范的思路,降低编程门槛。常用函数库应该是开放、可溯源、多版本管理的在线函数库,通过检索形式可直接引入到处理代码中。除此以外,还可以构建函数库的应用评价机制,经过实际应用对函数质量进行选择,筛选出优质函数,为用户使用函数提供重要参考。

e.每个算子功能单一化,通过串行机制完成多种处理需求。算子名称格式为Operator_Function,算子通过调用功能函数,实现目标功能。在科技文献数据治理任务中,存在较多需要几个算子先后都执行,才能完成整体任务的情况。比如计算SCI文献的高被引数值,首先需要计算全部文献的被引情况,再根据高被引公式计算满足高被引条件的论文,最后将结果数据更新到数据库中,支持服务检索与展示。为此,新设计的ArticleCF的执行任务单元Flow能够一次性完成多个处理任务,为了降低处理任务的耦合度,需要满足每个算子的功能单一化,同时采用串行执行机制,通过Flow Python单文件形式保存串行代码,经过可视化拓展过程,完成算子的自动衔接,用户在线编辑SQL脚本和Python逻辑作为算子的具体实现代码。

3 篇级文献数据分布式计算框架设计

3.1 系统整体设计

篇级文献数据分布式计算框架以集群方式运行,本文对处理数据、Master/Slave进程、输入、输出以及执行任务单元Flow进行了整体架构设计。ArticleCF整体架构设计见图2。

图2 ArticleCF整体架构设计

为保证ArticleCF正常、高效地进行数据处理,对分布式计算框架所处理的数据格式提出以下要求:

a.处理数据类型为科技文献篇级结构化数据,并且必须已存储在NoSQL数据库中,比如Elasticsearch和Mysql等。

b.在算子处理中,一条数据可以产生0条或多条结果数据。每个算子的输入和输出都是List数据结构。

c.本计算框架原则上是面向单篇数据处理,不支持对多篇数据的统计等操作,但可以借助外部系统,如Redis等完成统计等需求。

d.每条篇级文献数据必须具有唯一性ID。该ID将作为数据质量控制和任务管理的唯一依据。

3.2 核心模块功能

Master是ArticleCF集群的管理者,是整个集群的“大脑”,每个运行时刻有且具仅有一个Master节点。集群启动后,Master以常驻进程形式执行,时刻管理整个集群的整体运行。Master负责整个集群的用户管理、资源管理、任务管理、可视化编程、执行管理5个方面的功能。用户管理功能主要实现对多用户的集中管理,其为每个用户分配资源总数量和执行任务的优先级。资源管理主要是对所有Slave进行管理,监控每个Slave节点上启动的工作线程数,并对所部署服务器的内存、磁盘、网络使用情况进行预警处理。任务管理主要完成对用户提交任务的分派与跟踪。可视化编程可提升ArticleCF的易用性,为用户提供丰富的函数库,其可通过创建算子实现处理功能。Master主要功能设计见图3。

图3 Master主要功能设计

Flow是ArticleCF的最小执行结构,Flow必须包括Input Data、Operators、Output Data三个处理阶段。Flow主要实现对多个操作算子的串行管理。Flow分为Flow-head、Flow-body、Flow-tail三部分,Flow-head实现Input Data,Flow-body实现算子串行执行,Flow-tail实现对结果数据的入库操作。其中Flow-head、Flow-tail两模块属于Master的特定功能,在Master执行,Flow-body在Slave端执行。Flow工作流功能设计见图4。

图4 Flow工作流功能设计

Slave是ArticleCF的任务执行者,一个集群中有多个Slave进程。每台服务器可以部署多个Slave,并配置独有SlaveID编码。每个Slave进程是一个可独立执行处理任务的最小单位,也是弹性扩展集群计算能力的部署单位。Slave的主要功能包括任务处理和对Flow文件的动态加载与执行。任务管理模块获取到任务batch后,根据数据ID批量检索NoSQL数据库以获取对应数据的完整信息,并更新数据缓冲池中的处理状态。动态加载技术基于Python解释性语言特性进行设计开发,实现在指定线程内动态加载py文件并执行。任务处理器流程图见图5。

图5 任务处理器流程

3.3 数据结构设计

ArticleCF所有的功能实现都由Master和Slave两个模块进行完成,两者具有相同的软件结构,在部署阶段通过配置文件区分承担角色,核心模块遵循“高内聚、低耦合”的软件设计原则。ArticleCF主要模块数据结构的核心字段见表2。

表2 ArticleCF主要模块数据结构

FlowCache是Master端的核心数据结构,其属于执行时数据结构,存储于内存中,集群重启将清空所有历史记录,并重新开始统计Flow的执行情况。SlaveManager数据结构主要用于存储集群中所有Slave信息,Slave通过心跳与Master进行周期汇报,并更新Slave管理数据结构信息,该数据结构为后续任务管理模块提供任务分配依据。Input Data数据结构主要用于对筛选数据的获取和缓存,该阶段只处理真实数据的UUID,用于任务管理。Input Data数据结构在Flow-head阶段完成赋值。Output Data数据结构主要用于对结果数据的存储,ArticleCF的数据存储只支持Elasticsearch和Mysql,简化存储也是为了更好的规范和提升通用性。用户可以基于结果数据表进行其他操作,比如导出、查询、修改等。Output Data数据结构在Flow-tail阶段完成。

4 实验分析

ArticleCF的研究与设计源于智慧数据中心建设中遇到的多样性数据治理难题,具有明显的领域特性。为论证本文提出的分布式计算框架能较好的满足结构化科技文献数据处理,本文设计了功能定性分析实验,参考知识产权数据处理任务,筛选出与科技文献处理具有较高相关性的对比指标,将本文提出的ArticleCF与MapReduce、Spark、Storm分析计算框架进行定性分析对比。分布式计算框架功能定性对比见表3。

表3 分布式计算框架功能定性对比

通过MapReduce、Spark、Storm与ArticleCF在21个指标的对比实验,可以看出,本文提出的分布式计算框架在编程模式、并行度控制、算法丰富程度、任务管理以及科技文献领域特性支持方面,具有明显优势。可视化在线编程是其他计算框架所不具备的,而这对降低分布式技术门槛,让数据分析人员直接参与数据治理起着关键作用。建立完备的函数发布功能,保存、共享用户的函数成果,不仅方便复用已有技术成果,还可以不断加强用户与ArticleCF的业务黏性。

5 结 语

本研究基于科技文献数据后期治理多样性的实际需求,简化数据处理对象、处理需求以及数据结果输出全链条中数据结构和功能需求,提出一种面向篇级数据的轻量级分布式计算框架。探讨了ArticleCF的整体系统架构,明确划分主要集群角色和功能设定。阐述了关键功能的设计方案,为原型系统的研发提供了可行性指导。分析了关键数据结构和核心模块的设计原则,形成ArticleCF研发的底层设计和目录结构。本文设计对比实验,定性分析ArticleCF功能特性,论证了其更适合用于海量结构化科技文献数据的多样化处理需求。在未来工作中,一方面,尽快完成对ArticleCF的研发,将其逐步应用到具体业务中,切实让数据业务人员从该系统中获益。另一方面,加强本框架对人工智能技术的支持,为数据治理扩展新能力。