面向結(jié)構(gòu)化篇級科技文獻數(shù)據(jù)治理的高性能分布式計算框架研究*

范 萌 常志軍錢 力郭 丹

(1.中國科學(xué)院文獻情報中心 北京 100190;2.中國科學(xué)院大學(xué)經(jīng)濟與管理學(xué)院信息資源管理系 北京 100190)

0 引 言

加強科技基礎(chǔ)能力建設(shè)是加快建設(shè)世界技術(shù)強國的必然要求[1],為加強科技基礎(chǔ)能力建設(shè)需要推動關(guān)鍵軟件技術(shù)國產(chǎn)化,以應(yīng)對科技脫鉤,保障科技文獻服務(wù)的戰(zhàn)略安全。在科技圖書文獻數(shù)據(jù)中心建設(shè)過程中,數(shù)據(jù)治理、數(shù)據(jù)存儲、數(shù)據(jù)檢索是技術(shù)維度上要解決的主要問題,其中又以數(shù)據(jù)治理問題最為突出。

目前科技文獻數(shù)據(jù)中心的數(shù)據(jù)體量達4億篇,主要數(shù)據(jù)類型包括論文、專利、項目、圖書、標準、政策、獎項、會議等10種,需要進行多樣性數(shù)據(jù)治理的結(jié)構(gòu)化數(shù)據(jù)都存儲在Elasticsearch和Mysql中。在科技文獻數(shù)據(jù)整體治理的架構(gòu)中,數(shù)據(jù)治理包括數(shù)據(jù)的可獲得性、可用性、完整性和安全性[2],多樣化數(shù)據(jù)治理主要發(fā)生在基礎(chǔ)數(shù)據(jù)治理、增值數(shù)據(jù)治理、精編數(shù)據(jù)加工、異質(zhì)網(wǎng)絡(luò)數(shù)據(jù)建設(shè)四個階段。數(shù)據(jù)處理需求來源分為3種:a.數(shù)據(jù)資產(chǎn)組織結(jié)構(gòu)要求;b.數(shù)據(jù)質(zhì)量控制核對需求;c.業(yè)務(wù)應(yīng)用需求。其中業(yè)務(wù)應(yīng)用需求占較多的比例。比如很多數(shù)據(jù)處理需求是業(yè)務(wù)人員在撰寫情報分析報告時,需要對多類數(shù)據(jù)進行臨時處理和統(tǒng)計,這種計算只需要使用一次。

在上述背景下,本文提出一種高靈活、低門檻的高性能計算框架ArticleCF,其可有效規(guī)避MapReduce、Spark、Storm等計算框架研發(fā)周期長、技術(shù)門檻高的問題,同時還可以通過分布式形式,實現(xiàn)數(shù)據(jù)的高效處理,以滿足數(shù)智驅(qū)動情報分析的文獻情報數(shù)據(jù)治理需求。

1 相關(guān)研究

1.1 分布式數(shù)據(jù)治理

目前,數(shù)據(jù)治理已經(jīng)成為企業(yè)治理和國家治理的重點領(lǐng)域和重要方式[3,4]?？萍嘉墨I數(shù)據(jù)治理全流程如下圖1所示。在科技文獻智慧數(shù)據(jù)中心建設(shè)的協(xié)同治理階段,源于業(yè)務(wù)的定制化處理需求是數(shù)據(jù)持續(xù)治理的關(guān)鍵環(huán)節(jié),這就依賴于一種高效、易用的數(shù)據(jù)治理平臺,其不僅實現(xiàn)可視化、模板化數(shù)據(jù)篩選、數(shù)據(jù)處理、數(shù)據(jù)輸出等功能,還能使得業(yè)務(wù)人員直接參與數(shù)據(jù)治理任務(wù),有效解決數(shù)據(jù)研發(fā)團隊支持能力的瓶頸難題,為文獻情報在數(shù)智時代的變革打好堅實的軟件基礎(chǔ)。

圖1 科技文獻數(shù)據(jù)治理全流程

ArticleCF在功能上針對科技文獻數(shù)據(jù)特點進行多個維度的設(shè)計,以滿足篇級結(jié)構(gòu)化數(shù)據(jù)的處理需求,重點設(shè)計滿足該業(yè)務(wù)場景的分布式任務(wù)分發(fā)策略、并行計算策略以及故障轉(zhuǎn)移機制。同時為給用戶提供任務(wù)執(zhí)行信息,專門設(shè)計豐富的跟蹤機制,全面報告任務(wù)的進展及可能存在的問題。設(shè)計要點包括:a.限定處理數(shù)據(jù)的格式為結(jié)構(gòu)化數(shù)據(jù),可簡化算子函數(shù)的輸入、輸出設(shè)計。b.通過可視化在線編程技術(shù),降低入門難度,用戶通過簡單拖拽即可實現(xiàn)串行數(shù)據(jù)處理流程的設(shè)計。c.提供豐富的函數(shù)庫,類似SQL語法中的count、sum、distinct等函數(shù),為功能實現(xiàn)節(jié)省研發(fā)成本,提升代碼質(zhì)量,提供新功能函數(shù)發(fā)布功能,提升用戶體驗,用戶可以發(fā)布新函數(shù),不斷豐富函數(shù)庫。d.控制用戶資源使用量,對集群資源進行科學(xué)分配,尤其加強對空閑資源的利用率以及對用戶資源的及時回收保障。e.增加權(quán)限管理機制,為任務(wù)安全、數(shù)據(jù)安全、代碼安全做好保障。f.采用Sql、Python語言作為支撐語言用于處理數(shù)據(jù)子集篩選和功能編碼。g.支持串行處理模塊的熱插拔功能,執(zhí)行節(jié)點具有模塊版本核對和動態(tài)加載Python模塊的能力。h.集群具有彈性擴展能力,通過增加處理節(jié)點的數(shù)量,近線性提升數(shù)據(jù)處理能力。

本文以需求為導(dǎo)向、以場景為牽引,提出的ArticleCF是專門為結(jié)構(gòu)化科技文獻數(shù)據(jù)多樣性協(xié)同治理研發(fā)的計算框架。通過設(shè)計調(diào)查問卷,向業(yè)務(wù)人員征求需求和意見,力求保證ArticleCF能夠滿足日常工作中常見的數(shù)據(jù)治理需求。為科技文獻情報向數(shù)智驅(qū)動模式演化提供堅實的數(shù)據(jù)基礎(chǔ)和高效的數(shù)據(jù)治理能力。

1.2 分布式計算框架

提高科技文獻數(shù)據(jù)治理水平是提供高質(zhì)量文獻情報分析與服務(wù)的基礎(chǔ),而文獻數(shù)據(jù)計算框架的性能高低直接影響科技文獻數(shù)據(jù)治理水平。面對激增的海量數(shù)據(jù),Huwe認為圖書館的科技文獻數(shù)據(jù)治理需要依靠Hadoop與Spark計算框架[5];王海萍提出基于Spark內(nèi)存計算框架的圖書館文獻檢索服務(wù),從而提高目前圖書館在對大量文獻數(shù)據(jù)進行檢索的準確率和效率,提升文獻數(shù)據(jù)治理能力,優(yōu)化文獻服務(wù)質(zhì)量[6];蒙杰提出基于Hadoop的海量科技信息資源管理系統(tǒng),實現(xiàn)對科技信息資源的安全存儲與高效訪問[7]。由此可見,目前面向結(jié)構(gòu)化篇級文獻數(shù)據(jù)的計算框架主要是以Mapreduce、Spark為代表的分布式計算框架。

1.2.1MapReduce計算框架

MapReduce是Hadoop生態(tài)圈的核心分布式計算框架[8], 其核心思想是分而治之的數(shù)據(jù)計算策略,將大數(shù)據(jù)切分為小的Block數(shù)據(jù)塊,進而分別獨立處理計算。該計算框架主要通過Map (映射)和 Reduce(歸約/化簡)兩個階段,實現(xiàn)各類業(yè)務(wù)的處理過程[9,10]。目前MapReduce被廣泛應(yīng)用于工業(yè)界的多種海量數(shù)據(jù)分析場景[11-13],除此以外還廣泛應(yīng)用于醫(yī)療臨床大數(shù)據(jù)篩選[14]、關(guān)聯(lián)規(guī)則挖掘[15]、水產(chǎn)農(nóng)業(yè)[16]等領(lǐng)域。MapReduce屬于離線計算框架,采用離線調(diào)度算法完成對全部任務(wù)的調(diào)度和管理[17]。MapReduce通過溢出寫盤技術(shù)和故障自動轉(zhuǎn)移技術(shù)降低對硬件資源的要求,因此MapReduce集群搭建成本低,只要有計算能力的服務(wù)器均可加入到集群中,進而發(fā)揮一定的計算能力。由此可見,MapReduce計算框架適用于數(shù)據(jù)存儲在HDFS文件系統(tǒng)中,并且對時間響應(yīng)耗時要求不高的大規(guī)模數(shù)據(jù)的計算場景?；诖?在設(shè)計ArticleCF的架構(gòu)時,需要著重考慮作業(yè)啟動與完成的耗時,克服Mapreduce延遲較高的問題,以提高計算框架的靈活性,滿足對時間響應(yīng)與耗時要求較高的任務(wù)場景。

1.2.2Spark內(nèi)存計算框架

Spark是面向迭代機器學(xué)習(xí)算法的新框架[18],它支持交互式數(shù)據(jù)分析的同時還保持了MapReduce的可伸縮性和容錯性。Spark在迭代機器學(xué)習(xí)作業(yè)中的表現(xiàn)可以超過Hadoop的 10倍,在ETL等數(shù)據(jù)處理任務(wù)中,兩者相差不明顯。Spark具有更豐富的算子,包括map、mapPartitions、flatMap、filter、reduceByKey、groupByKey、join、 reduce、aggregate、foreach等,支持更靈活的編程。Spark沒有獨立的存儲系統(tǒng),需要與其他的存儲系統(tǒng)進行集成[19]。Spark適合具有大量迭代計算的場景,Spark在大規(guī)模圖像處理[20]、工業(yè)網(wǎng)絡(luò)安全[21]、心電信號數(shù)據(jù)挖掘[22]、電力系統(tǒng)監(jiān)控[23]等領(lǐng)域得到廣泛應(yīng)用,在硬件資源充足的情況下,其在實現(xiàn)數(shù)據(jù)排重、知識圖譜構(gòu)建、主題標引等業(yè)務(wù)場景也具有出色表現(xiàn)。由此可見,Spark具有性能快速、算子豐富等計算優(yōu)勢,但是對于不熟悉分布式計算的開發(fā)人員而言,要想掌握其編程模型和調(diào)優(yōu)技巧,需要很高的學(xué)習(xí)成本。因此,ArticleCF計算框架考慮設(shè)計可視化在線編程模塊,對于那些晦澀難懂的程序函數(shù),用戶只需要進行點擊拖拽,就能實現(xiàn)相應(yīng)的功能,降低用戶使用門檻。

1.2.3Storm流式計算框架

Apache Storm是一種低延遲分布式流處理框架[24],也被稱為實時Hadoop。通過Zookeeper進行任務(wù)管理,具有較高集群容錯能力,運行中模塊處于無狀態(tài)模式,隨時宕機重啟。Storm創(chuàng)新性提出的ack消息追蹤框架和復(fù)雜的事務(wù)性處理,能夠滿足很多級別的數(shù)據(jù)處理需求。使用 Netty作為其通信組件,Netty是一個基于TCP/IP協(xié)議棧的異步服務(wù)器/客戶端框架[25]。Topology是Storm的執(zhí)行任務(wù)單位,每個Topology 由Spout和Bolt構(gòu)成,Spout負責發(fā)出待處理的Tuple數(shù)據(jù), Bolt通過訂閱指定Spout或者Bolt發(fā)出的Tuple,并編寫具體的處理邏輯完成任務(wù)目標。Apache Storm在電商領(lǐng)域用戶分析[26]、大規(guī)模圖像檢索[27]、實時生理信號采集與分析[28]等方面都有廣泛的應(yīng)用。Storm在處理大規(guī)模實時數(shù)據(jù)流和低延遲需求方面都具有很高的價值,不過與Spark一樣,學(xué)習(xí)成本很高,集群的部署和管理需要具備專業(yè)知識和經(jīng)驗,同時,其生態(tài)系統(tǒng)中可用的可視化和監(jiān)控工具較少。因此,ArticleCF計劃設(shè)計一個資源管理模塊,實現(xiàn)Slave節(jié)點與服務(wù)器信息的實時監(jiān)控,更好地管理計算集群。

1.3 篇級文獻數(shù)據(jù)計算

科技文獻大數(shù)據(jù)建設(shè)從國家“十三五”期間已經(jīng)開始,并逐步實現(xiàn)從0到1的突破,基于Hadoop生態(tài)群分布技術(shù)建設(shè)了完備的數(shù)據(jù)匯聚、通用治理、數(shù)據(jù)索引及服務(wù)的平臺和工具集。通過MapReduce實現(xiàn)多對億級別文獻數(shù)據(jù)的ETL處理,采用Hive作為數(shù)據(jù)倉庫,基于Spark完成了100億級知識圖譜的構(gòu)建,依托Elasticsearch搜索引擎實現(xiàn)知識檢索服務(wù),引入Spring cloud微服務(wù)架構(gòu),提升負載均衡和接口擴展能力,部署Redis作為高速緩存保證在線服務(wù)性能。同時,隨著人工智能技術(shù)的發(fā)展,研究人員發(fā)現(xiàn)對數(shù)據(jù)的治理從基礎(chǔ)的ETL開始邁向?qū)毩６戎R的智能挖掘?qū)用?對數(shù)據(jù)的應(yīng)用也從知識維度開始向智慧維度發(fā)展。在新一代技術(shù)的驅(qū)動下,文獻情報范式正在向數(shù)據(jù)驅(qū)動的方向轉(zhuǎn)變。但是,當前的集群和技術(shù)明顯已不能滿足新階段的數(shù)據(jù)治理的需求,需要在現(xiàn)有的基礎(chǔ)上研發(fā)更符合數(shù)據(jù)治理要求的一套平臺和工具。比如在MapReduce的map函數(shù)中,讀取Elasticsearch中的數(shù)據(jù),不能控制并行度,Spark通過組件實現(xiàn)對數(shù)據(jù)的讀取,在程序段同樣無法控制并行度,無法控制計算給Elasticsearch帶來的壓力。目前,尚未出現(xiàn)面向科技文獻情報領(lǐng)域,支撐多情報分析、知識發(fā)現(xiàn)的多樣性數(shù)據(jù)治理需求的靈活、易用的計算框架。

2 啟發(fā)式思考

a.基于NoSQL數(shù)據(jù)Scroll讀取速度明顯高于寫入速度。科技文獻結(jié)構(gòu)化數(shù)據(jù)的多樣性處理,需要經(jīng)過篩選讀取、串行治理、結(jié)果寫入三個基本階段。通過實驗可知,在實際應(yīng)用中,結(jié)構(gòu)化數(shù)據(jù)的讀取速度比基礎(chǔ)處理速度要快2倍。以知識產(chǎn)權(quán)數(shù)據(jù)為例,存儲系統(tǒng)為Elasticsearch集群(15臺服務(wù)器,服務(wù)器:惠普HPE DL380,配置:CentOS 6.8操作系統(tǒng),RAID0 10*4T磁盤陣列,32核128GB內(nèi)存),數(shù)據(jù)總量為66 297 744篇,索引有效數(shù)據(jù)總量為65 977 583篇,數(shù)據(jù)的讀取和寫入均為單線程,讀取數(shù)據(jù)和寫入數(shù)據(jù)的時間耗時(見表1)。

表1 知識產(chǎn)權(quán)數(shù)據(jù)讀取、寫入時間對比

基于此規(guī)律,ArticleCF的讀取模塊可以基于Scroll的數(shù)據(jù)讀取以單節(jié)點的方式進行,以簡化數(shù)據(jù)操作;寫入模塊則需要分布式模式進行,通過并行度提升ArticleCF的數(shù)據(jù)處理性能。

b.通常數(shù)據(jù)庫數(shù)據(jù)都具有唯一ID,體量小,適合用于任務(wù)分配、跟蹤。ID的數(shù)據(jù)容量與全字段數(shù)據(jù)體量具有很大的差距,以論文、專利元數(shù)據(jù)為例,ID的長度與全字段長度相比,達到1:20。因此ArticleCF的任務(wù)管理模塊,可通過數(shù)據(jù)的唯一ID進行分組,構(gòu)成任務(wù)分配的最小單元batch,管理處理任務(wù)的執(zhí)行狀態(tài)。各處理節(jié)點收到batch后,以分布式形式進行全量字段的數(shù)據(jù)獲取。

c.建立數(shù)據(jù)寫入權(quán)限控制機制,區(qū)分原表寫入和臨時表寫入。數(shù)據(jù)串行處理得到結(jié)果數(shù)據(jù),本架構(gòu)僅支持寫回系統(tǒng)為Elasticsearch和Mysql兩種。為了區(qū)分原表寫入與臨時表寫入,結(jié)果數(shù)據(jù)回填原表之前,ArticleCF會對其進行審核,保證操作不破壞原有數(shù)據(jù)整體設(shè)計;若每個用戶處理的邏輯也表現(xiàn)多樣性,則參考MapReduce的文件輸出模式,存儲為結(jié)果文件形式,但為了輸出文件的管理,專門設(shè)計寫出功能。

d.支撐函數(shù)級編程框架,構(gòu)建常用操作函數(shù)庫。本架構(gòu)面向的是結(jié)構(gòu)化數(shù)據(jù)處理,因此在數(shù)據(jù)規(guī)范性方面具有較大優(yōu)勢,對數(shù)據(jù)治理的操作也集中在對字段的規(guī)范化、合并、排重、拆分、映射等操作,這類操作具有很大的共性可挖掘。在結(jié)構(gòu)化優(yōu)勢基礎(chǔ)上,ArticleCF的可視化編程模塊引入函數(shù)級編程,借鑒map、reduce思想,明確定義各類函數(shù)統(tǒng)一的輸入、輸出結(jié)構(gòu),通過規(guī)范的思路,降低編程門檻。常用函數(shù)庫應(yīng)該是開放、可溯源、多版本管理的在線函數(shù)庫,通過檢索形式可直接引入到處理代碼中。除此以外,還可以構(gòu)建函數(shù)庫的應(yīng)用評價機制,經(jīng)過實際應(yīng)用對函數(shù)質(zhì)量進行選擇,篩選出優(yōu)質(zhì)函數(shù),為用戶使用函數(shù)提供重要參考。

e.每個算子功能單一化,通過串行機制完成多種處理需求。算子名稱格式為Operator_Function,算子通過調(diào)用功能函數(shù),實現(xiàn)目標功能。在科技文獻數(shù)據(jù)治理任務(wù)中,存在較多需要幾個算子先后都執(zhí)行,才能完成整體任務(wù)的情況。比如計算SCI文獻的高被引數(shù)值,首先需要計算全部文獻的被引情況,再根據(jù)高被引公式計算滿足高被引條件的論文,最后將結(jié)果數(shù)據(jù)更新到數(shù)據(jù)庫中,支持服務(wù)檢索與展示。為此,新設(shè)計的ArticleCF的執(zhí)行任務(wù)單元Flow能夠一次性完成多個處理任務(wù),為了降低處理任務(wù)的耦合度,需要滿足每個算子的功能單一化,同時采用串行執(zhí)行機制,通過Flow Python單文件形式保存串行代碼,經(jīng)過可視化拓展過程,完成算子的自動銜接,用戶在線編輯SQL腳本和Python邏輯作為算子的具體實現(xiàn)代碼。

3 篇級文獻數(shù)據(jù)分布式計算框架設(shè)計

3.1 系統(tǒng)整體設(shè)計

篇級文獻數(shù)據(jù)分布式計算框架以集群方式運行,本文對處理數(shù)據(jù)、Master/Slave進程、輸入、輸出以及執(zhí)行任務(wù)單元Flow進行了整體架構(gòu)設(shè)計。ArticleCF整體架構(gòu)設(shè)計見圖2。

圖2 ArticleCF整體架構(gòu)設(shè)計

為保證ArticleCF正常、高效地進行數(shù)據(jù)處理,對分布式計算框架所處理的數(shù)據(jù)格式提出以下要求:

a.處理數(shù)據(jù)類型為科技文獻篇級結(jié)構(gòu)化數(shù)據(jù),并且必須已存儲在NoSQL數(shù)據(jù)庫中,比如Elasticsearch和Mysql等。

b.在算子處理中,一條數(shù)據(jù)可以產(chǎn)生0條或多條結(jié)果數(shù)據(jù)。每個算子的輸入和輸出都是List數(shù)據(jù)結(jié)構(gòu)。

c.本計算框架原則上是面向單篇數(shù)據(jù)處理,不支持對多篇數(shù)據(jù)的統(tǒng)計等操作,但可以借助外部系統(tǒng),如Redis等完成統(tǒng)計等需求。

d.每條篇級文獻數(shù)據(jù)必須具有唯一性ID。該ID將作為數(shù)據(jù)質(zhì)量控制和任務(wù)管理的唯一依據(jù)。

3.2 核心模塊功能

Master是ArticleCF集群的管理者,是整個集群的“大腦”,每個運行時刻有且具僅有一個Master節(jié)點。集群啟動后,Master以常駐進程形式執(zhí)行,時刻管理整個集群的整體運行。Master負責整個集群的用戶管理、資源管理、任務(wù)管理、可視化編程、執(zhí)行管理5個方面的功能。用戶管理功能主要實現(xiàn)對多用戶的集中管理,其為每個用戶分配資源總數(shù)量和執(zhí)行任務(wù)的優(yōu)先級。資源管理主要是對所有Slave進行管理,監(jiān)控每個Slave節(jié)點上啟動的工作線程數(shù),并對所部署服務(wù)器的內(nèi)存、磁盤、網(wǎng)絡(luò)使用情況進行預(yù)警處理。任務(wù)管理主要完成對用戶提交任務(wù)的分派與跟蹤?？梢暬幊炭商嵘鼳rticleCF的易用性,為用戶提供豐富的函數(shù)庫,其可通過創(chuàng)建算子實現(xiàn)處理功能。Master主要功能設(shè)計見圖3。

圖3 Master主要功能設(shè)計

Flow是ArticleCF的最小執(zhí)行結(jié)構(gòu),Flow必須包括Input Data、Operators、Output Data三個處理階段。Flow主要實現(xiàn)對多個操作算子的串行管理。Flow分為Flow-head、Flow-body、Flow-tail三部分,Flow-head實現(xiàn)Input Data,Flow-body實現(xiàn)算子串行執(zhí)行,Flow-tail實現(xiàn)對結(jié)果數(shù)據(jù)的入庫操作。其中Flow-head、Flow-tail兩模塊屬于Master的特定功能,在Master執(zhí)行,Flow-body在Slave端執(zhí)行。Flow工作流功能設(shè)計見圖4。

圖4 Flow工作流功能設(shè)計

Slave是ArticleCF的任務(wù)執(zhí)行者,一個集群中有多個Slave進程。每臺服務(wù)器可以部署多個Slave,并配置獨有SlaveID編碼。每個Slave進程是一個可獨立執(zhí)行處理任務(wù)的最小單位,也是彈性擴展集群計算能力的部署單位。Slave的主要功能包括任務(wù)處理和對Flow文件的動態(tài)加載與執(zhí)行。任務(wù)管理模塊獲取到任務(wù)batch后,根據(jù)數(shù)據(jù)ID批量檢索NoSQL數(shù)據(jù)庫以獲取對應(yīng)數(shù)據(jù)的完整信息,并更新數(shù)據(jù)緩沖池中的處理狀態(tài)。動態(tài)加載技術(shù)基于Python解釋性語言特性進行設(shè)計開發(fā),實現(xiàn)在指定線程內(nèi)動態(tài)加載py文件并執(zhí)行。任務(wù)處理器流程圖見圖5。

圖5 任務(wù)處理器流程

3.3 數(shù)據(jù)結(jié)構(gòu)設(shè)計

ArticleCF所有的功能實現(xiàn)都由Master和Slave兩個模塊進行完成,兩者具有相同的軟件結(jié)構(gòu),在部署階段通過配置文件區(qū)分承擔角色,核心模塊遵循“高內(nèi)聚、低耦合”的軟件設(shè)計原則。ArticleCF主要模塊數(shù)據(jù)結(jié)構(gòu)的核心字段見表2。

表2 ArticleCF主要模塊數(shù)據(jù)結(jié)構(gòu)

FlowCache是Master端的核心數(shù)據(jù)結(jié)構(gòu),其屬于執(zhí)行時數(shù)據(jù)結(jié)構(gòu),存儲于內(nèi)存中,集群重啟將清空所有歷史記錄,并重新開始統(tǒng)計Flow的執(zhí)行情況。SlaveManager數(shù)據(jù)結(jié)構(gòu)主要用于存儲集群中所有Slave信息,Slave通過心跳與Master進行周期匯報,并更新Slave管理數(shù)據(jù)結(jié)構(gòu)信息,該數(shù)據(jù)結(jié)構(gòu)為后續(xù)任務(wù)管理模塊提供任務(wù)分配依據(jù)。Input Data數(shù)據(jù)結(jié)構(gòu)主要用于對篩選數(shù)據(jù)的獲取和緩存,該階段只處理真實數(shù)據(jù)的UUID,用于任務(wù)管理。Input Data數(shù)據(jù)結(jié)構(gòu)在Flow-head階段完成賦值。Output Data數(shù)據(jù)結(jié)構(gòu)主要用于對結(jié)果數(shù)據(jù)的存儲,ArticleCF的數(shù)據(jù)存儲只支持Elasticsearch和Mysql,簡化存儲也是為了更好的規(guī)范和提升通用性。用戶可以基于結(jié)果數(shù)據(jù)表進行其他操作,比如導(dǎo)出、查詢、修改等。Output Data數(shù)據(jù)結(jié)構(gòu)在Flow-tail階段完成。

4 實驗分析

ArticleCF的研究與設(shè)計源于智慧數(shù)據(jù)中心建設(shè)中遇到的多樣性數(shù)據(jù)治理難題,具有明顯的領(lǐng)域特性。為論證本文提出的分布式計算框架能較好的滿足結(jié)構(gòu)化科技文獻數(shù)據(jù)處理,本文設(shè)計了功能定性分析實驗,參考知識產(chǎn)權(quán)數(shù)據(jù)處理任務(wù),篩選出與科技文獻處理具有較高相關(guān)性的對比指標,將本文提出的ArticleCF與MapReduce、Spark、Storm分析計算框架進行定性分析對比。分布式計算框架功能定性對比見表3。

表3 分布式計算框架功能定性對比

通過MapReduce、Spark、Storm與ArticleCF在21個指標的對比實驗,可以看出,本文提出的分布式計算框架在編程模式、并行度控制、算法豐富程度、任務(wù)管理以及科技文獻領(lǐng)域特性支持方面,具有明顯優(yōu)勢?？梢暬诰€編程是其他計算框架所不具備的,而這對降低分布式技術(shù)門檻,讓數(shù)據(jù)分析人員直接參與數(shù)據(jù)治理起著關(guān)鍵作用。建立完備的函數(shù)發(fā)布功能,保存、共享用戶的函數(shù)成果,不僅方便復(fù)用已有技術(shù)成果,還可以不斷加強用戶與ArticleCF的業(yè)務(wù)黏性。

5 結(jié) 語

本研究基于科技文獻數(shù)據(jù)后期治理多樣性的實際需求,簡化數(shù)據(jù)處理對象、處理需求以及數(shù)據(jù)結(jié)果輸出全鏈條中數(shù)據(jù)結(jié)構(gòu)和功能需求,提出一種面向篇級數(shù)據(jù)的輕量級分布式計算框架。探討了ArticleCF的整體系統(tǒng)架構(gòu),明確劃分主要集群角色和功能設(shè)定。闡述了關(guān)鍵功能的設(shè)計方案,為原型系統(tǒng)的研發(fā)提供了可行性指導(dǎo)。分析了關(guān)鍵數(shù)據(jù)結(jié)構(gòu)和核心模塊的設(shè)計原則,形成ArticleCF研發(fā)的底層設(shè)計和目錄結(jié)構(gòu)。本文設(shè)計對比實驗,定性分析ArticleCF功能特性,論證了其更適合用于海量結(jié)構(gòu)化科技文獻數(shù)據(jù)的多樣化處理需求。在未來工作中,一方面,盡快完成對ArticleCF的研發(fā),將其逐步應(yīng)用到具體業(yè)務(wù)中,切實讓數(shù)據(jù)業(yè)務(wù)人員從該系統(tǒng)中獲益。另一方面,加強本框架對人工智能技術(shù)的支持,為數(shù)據(jù)治理擴展新能力。