面向結構化篇級科技文獻數據治理的高性能分布式計算框架研究*

范 萌 常志軍錢 力郭 丹

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

0 引 言

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

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

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

1 相關研究

1.1 分布式數據治理

目前,數據治理已經成為企業治理和國家治理的重點領域和重要方式[3,4]?？萍嘉墨I數據治理全流程如下圖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讀取速度明顯高于寫入速度?？萍嘉墨I結構化數據的多樣性處理,需要經過篩選讀取、串行治理、結果寫入三個基本階段。通過實驗可知,在實際應用中,結構化數據的讀取速度比基礎處理速度要快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節點上啟動的工作線程數,并對所部署服務器的內存、磁盤、網絡使用情況進行預警處理。任務管理主要完成對用戶提交任務的分派與跟蹤?？梢暬幊炭商嵘鼳rticleCF的易用性,為用戶提供豐富的函數庫,其可通過創建算子實現處理功能。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的研發,將其逐步應用到具體業務中,切實讓數據業務人員從該系統中獲益。另一方面,加強本框架對人工智能技術的支持,為數據治理擴展新能力。