朱明超，宋 暉

(東華大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，上海 201620)

0 引言

近幾年，越來越多的學(xué)者將目光聚焦在認(rèn)知智能上，知識圖譜受到越來越廣泛的關(guān)注。隨著知識圖譜在各個(gè)領(lǐng)域中展現(xiàn)出價(jià)值，領(lǐng)域知識圖譜構(gòu)建成為智能應(yīng)用系統(tǒng)的重要組成部分。在領(lǐng)域知識圖譜構(gòu)建過程中面對的首要問題是：領(lǐng)域數(shù)據(jù)的及時(shí)采集。知識圖譜構(gòu)建最常用的數(shù)據(jù)采集方式是網(wǎng)絡(luò)數(shù)據(jù)采集。文獻(xiàn)[2]通過人工操作方式從網(wǎng)頁下載數(shù)據(jù)，文獻(xiàn)[3]通過解析相關(guān)網(wǎng)頁獲得企業(yè)股票代碼列表等企業(yè)信息。

領(lǐng)域數(shù)據(jù)通常有多個(gè)數(shù)據(jù)來源，獲取途徑相對分散，往往需要通過多渠道多次獲取，費(fèi)時(shí)費(fèi)力。而且采集的數(shù)據(jù)無法及時(shí)與數(shù)據(jù)源同步。針對不同的數(shù)據(jù)源，采集任務(wù)的執(zhí)行周期也不同，因此需要一個(gè)可從多數(shù)據(jù)源定時(shí)采集數(shù)據(jù)的系統(tǒng)。

本文針對領(lǐng)域數(shù)據(jù)采集問題，基于機(jī)器人流程自動化技術(shù)設(shè)計(jì)了支持?jǐn)?shù)據(jù)定時(shí)采集和多任務(wù)并發(fā)處理的數(shù)據(jù)采集系統(tǒng)。此系統(tǒng)結(jié)合數(shù)據(jù)采集腳本和Celery定時(shí)任務(wù)實(shí)現(xiàn)了數(shù)據(jù)的定時(shí)采集，實(shí)現(xiàn)了Celery配置文件的動態(tài)加載與更新，使默認(rèn)單線程的 Celery定時(shí)任務(wù)能夠支持多任務(wù)并行。該系統(tǒng)基于Django開發(fā)框架及Docker容器技術(shù)進(jìn)行開發(fā)和部署，提供了任務(wù)監(jiān)控和數(shù)據(jù)管理功能。

1 相關(guān)技術(shù)

本系統(tǒng)采用Django快速開發(fā)框架搭建，使用Docker進(jìn)行系統(tǒng)部署。數(shù)據(jù)采集最常使用的工具有Python爬蟲工具庫、爬蟲框架和Selenium[5]自動化工具。本系統(tǒng)采用Selenium自動化工具進(jìn)行數(shù)據(jù)采集。

已有的數(shù)據(jù)采集系統(tǒng)通常是單任務(wù)、面向特定需求的，如煤礦安全[6]、學(xué)科發(fā)展?fàn)顟B(tài)[10]和醫(yī)療數(shù)據(jù)等，可復(fù)用性弱。已有的面向多數(shù)據(jù)源的采集系統(tǒng)，不能保障多任務(wù)并行且無法保證數(shù)據(jù)的及時(shí)性。針對知識圖譜數(shù)據(jù)獲取的問題，本文參考分布式數(shù)據(jù)采集的實(shí)現(xiàn)思路[13]設(shè)計(jì)實(shí)現(xiàn)了多任務(wù)數(shù)據(jù)采集系統(tǒng)。

2 系統(tǒng)架構(gòu)設(shè)計(jì)

本系統(tǒng)基于Django框架開發(fā)實(shí)現(xiàn)。系統(tǒng)分為任務(wù)管理和數(shù)據(jù)采集兩大模塊。

任務(wù)管理模塊，將對特定數(shù)據(jù)源的采集腳本封裝為任務(wù)。系統(tǒng)提供對任務(wù)的管理，包括任務(wù)定義、定時(shí)執(zhí)行和多任務(wù)并發(fā)控制。

數(shù)據(jù)采集模塊，包括數(shù)據(jù)采集、采集容錯(cuò)機(jī)制和數(shù)據(jù)存儲。系統(tǒng)采用 MySQL和 Neo4j數(shù)據(jù)庫分別存放任務(wù)信息和知識圖譜的關(guān)系數(shù)據(jù)。系統(tǒng)架構(gòu)如圖1所示。

圖1 系統(tǒng)架構(gòu)Fig.1 System structure

3 系統(tǒng)核心功能設(shè)計(jì)

本系統(tǒng)使用Selenium自動化工具調(diào)用瀏覽器驅(qū)動，訪問數(shù)據(jù)源網(wǎng)頁，定位目標(biāo)數(shù)據(jù)在網(wǎng)頁結(jié)構(gòu)中的位置以采集所需數(shù)據(jù)。此方式可以準(zhǔn)確的采集頁面中的目標(biāo)數(shù)據(jù)。

系統(tǒng)的核心功能是定時(shí)任務(wù)、多任務(wù)并發(fā)控制、數(shù)據(jù)監(jiān)控和數(shù)據(jù)管理。在Django框架下通常將數(shù)據(jù)采集任務(wù)封裝為線性執(zhí)行的函數(shù)，這種執(zhí)行方式面臨3個(gè)問題：（1）任務(wù)開始執(zhí)行后，如果任務(wù)采集的數(shù)據(jù)太多或頻繁切換網(wǎng)頁會導(dǎo)致任務(wù)執(zhí)行時(shí)間過長。采用線性執(zhí)行方式會使系統(tǒng)前端頁面一直處于等待狀態(tài)，前端等待時(shí)間過長會導(dǎo)致頁面長時(shí)間卡頓甚至報(bào)錯(cuò)，使得用戶使用體驗(yàn)極差；（2）線性執(zhí)行方式無法保證采集的數(shù)據(jù)與數(shù)據(jù)源同步更新，需頻繁人工啟動任務(wù)執(zhí)行；（3）線性執(zhí)行方式?jīng)]有任務(wù)并發(fā)管理機(jī)制，多任務(wù)并行會導(dǎo)致采集報(bào)錯(cuò)。

為解決以上問題，本系統(tǒng)采用Django框架下最常用的定時(shí)任務(wù)實(shí)現(xiàn)工具 Celery。Celery中定時(shí)任務(wù)控制器Beat、中間件Broker和任務(wù)執(zhí)行單元Worker分別負(fù)責(zé)任務(wù)分發(fā)，路由管理，具體任務(wù)執(zhí)行。Celery定時(shí)任務(wù)流程為：Beat定時(shí)將任務(wù)派發(fā)給任務(wù)隊(duì)列，任務(wù)隊(duì)列和Worker的映射關(guān)系為路由，任務(wù)隊(duì)列根據(jù)路由將任務(wù)分配給相應(yīng)Worker執(zhí)行。Celery默認(rèn)只有一個(gè)隊(duì)列和Worker，即只有一組路由。本系統(tǒng)以Celery定時(shí)任務(wù)為基礎(chǔ)，設(shè)計(jì)實(shí)現(xiàn)了系統(tǒng)的核心功能。

3.1 數(shù)據(jù)定時(shí)采集

設(shè)置定時(shí)任務(wù)的關(guān)鍵步驟是任務(wù)注冊和任務(wù)綁定。在采集腳本前加上“@app（）”，將此采集腳本注冊為Celery可識別的Task。在定時(shí)任務(wù)綁定頁面從Celery已有Task列表中選擇對應(yīng)的采集腳本，設(shè)定執(zhí)行間隔，定時(shí)任務(wù)名等參數(shù)。點(diǎn)擊保存后將此Task的定時(shí)執(zhí)行信息添加在定時(shí)任務(wù)表。如圖2所示。

圖2 定時(shí)任務(wù)綁定頁Fig.2 Timed task binding page

基于Celery設(shè)計(jì)的定時(shí)采集任務(wù)，在任務(wù)執(zhí)行中還需添加數(shù)據(jù)采集容錯(cuò)機(jī)制，解決數(shù)據(jù)重復(fù)采集問題。采集腳本在網(wǎng)頁加載完成，網(wǎng)頁中各元素的相對位置確定后，才能成功定位目標(biāo)數(shù)據(jù)。當(dāng)采集任務(wù)數(shù)據(jù)源響應(yīng)慢或網(wǎng)絡(luò)延遲時(shí)會導(dǎo)致頁面數(shù)據(jù)定位失敗等問題，為此系統(tǒng)設(shè)計(jì)了對應(yīng)的容錯(cuò)機(jī)制，當(dāng)捕獲報(bào)錯(cuò)后，任務(wù)將主動等待一段時(shí)間后再次執(zhí)行。任務(wù)重試次數(shù)和等待時(shí)間可在任務(wù)配置文件中設(shè)置。

Celery定時(shí)任務(wù)中同一任務(wù)多次執(zhí)行時(shí)，如果每次執(zhí)行沒有標(biāo)識，將導(dǎo)致每次采集的數(shù)據(jù)重復(fù)。為解決重復(fù)采集問題，本系統(tǒng)以數(shù)據(jù)發(fā)布日期來區(qū)分同一任務(wù)的多次執(zhí)行。網(wǎng)頁數(shù)據(jù)帶有發(fā)布日期，在任務(wù)的配置文件中加入開始日期“start_date”和時(shí)間跨度“interval_time”兩個(gè)參數(shù)，分別表示開始采集的數(shù)據(jù)日期和單次采集任務(wù)的時(shí)間跨度。采集任務(wù)把數(shù)據(jù)發(fā)布日期作為標(biāo)識，本次任務(wù)執(zhí)行開始日期取上次任務(wù)執(zhí)行結(jié)束時(shí)的數(shù)據(jù)日期，若當(dāng)前為第一次執(zhí)行則取“start_date”。采集任務(wù)采集完一個(gè)日期的數(shù)據(jù)后，日期自增，任務(wù)采集下一日期數(shù)據(jù)，以上步驟循環(huán)“interval_time”次，完成此次采集任務(wù)。則每次采集任務(wù)是對上次采集任務(wù)的增量更新，數(shù)據(jù)源發(fā)布新數(shù)據(jù)時(shí)，新數(shù)據(jù)對應(yīng)最新日期，下次采集時(shí)可增量采集新數(shù)據(jù)。采集任務(wù)按任務(wù)日期的時(shí)序采集數(shù)據(jù)，可以避免重復(fù)采集和對新數(shù)據(jù)的查詢判斷，保證數(shù)據(jù)采集的及時(shí)和高效。

3.2 多任務(wù)并發(fā)

使用定時(shí)任務(wù)方式執(zhí)行采集腳本，Worker執(zhí)行任務(wù)時(shí)最終是執(zhí)行一個(gè)線性函數(shù)。當(dāng)多個(gè)采集任務(wù)同時(shí)執(zhí)行，默認(rèn)都在系統(tǒng)的主進(jìn)程執(zhí)行，系統(tǒng)會因多個(gè)任務(wù)爭用唯一的瀏覽器驅(qū)動而報(bào)錯(cuò)。同時(shí)Celery默認(rèn)只有一個(gè)任務(wù)隊(duì)列和一個(gè)Worker，多個(gè)任務(wù)并發(fā)會使任務(wù)隊(duì)列阻塞。

本系統(tǒng)采用新的定時(shí)任務(wù)執(zhí)行策略和新的Celery路由更新邏輯解決瀏覽器驅(qū)動爭用和任務(wù)隊(duì)列阻塞問題。

3.2.1 定時(shí)任務(wù)執(zhí)行策略

默認(rèn)的執(zhí)行方式是 Worker執(zhí)行任務(wù)時(shí)在系統(tǒng)的主進(jìn)程中執(zhí)行任務(wù)函數(shù)。新的策略是系統(tǒng)主進(jìn)程中不再執(zhí)行采集任務(wù)，采集任務(wù)在獨(dú)立的線程中執(zhí)行，每個(gè)線程有自己的上下文，互不影響。

3.2.2 Celery路由更新邏輯

Celery默認(rèn)所有任務(wù)發(fā)送給唯一的默認(rèn)任務(wù)隊(duì)列，交由默認(rèn)Worker執(zhí)行。為了解決多任務(wù)并行隊(duì)列阻塞問題，系統(tǒng)在新任務(wù)創(chuàng)建時(shí)為 Celery添加除默認(rèn)路由之外的新路由，使其可以同時(shí)執(zhí)行多個(gè)任務(wù)。Celery默認(rèn)的路由更新方式是在Celery配置文件“celeryconfig.py”中手動添加路由。此種方式用戶友好性很差，新的路由更新邏輯在新的定時(shí)任務(wù)創(chuàng)建時(shí)自動為此任務(wù)創(chuàng)建任務(wù)獨(dú)占的路由，將其和原有路由一并寫入新的路由字典，在配置文件“celeryconfig.py”中以文件讀取的方式訪問路由文件，讀取新的路由字典替換原有的路由信息。

3.3 任務(wù)監(jiān)控與數(shù)據(jù)管理

為了方便用戶了解任務(wù)的執(zhí)行情況，在系統(tǒng)主頁上展示任務(wù)執(zhí)行信息，并實(shí)時(shí)更新。系統(tǒng)調(diào)用Celery監(jiān)控工具Flower提供的API獲取每個(gè)任務(wù)狀態(tài)的信息，并返回給前端，并將任務(wù)執(zhí)行結(jié)果存入任務(wù)執(zhí)行日志表中。調(diào)用Flower獲取任務(wù)狀態(tài)數(shù)據(jù)的API如圖3所示。

圖3 任務(wù)狀態(tài)APIFig.3 T ask status api

不同任務(wù)采集的數(shù)據(jù)不同，格式難以統(tǒng)一，數(shù)據(jù)存儲時(shí)無法根據(jù)數(shù)據(jù)類型管理。為了統(tǒng)一管理，具體的數(shù)據(jù)如文字，pdf等作為附件以文件形式保存，不存入數(shù)據(jù)庫，將數(shù)據(jù)保存的路徑存入數(shù)據(jù)庫。

4 系統(tǒng)實(shí)現(xiàn)與部署

為了使系統(tǒng)具備功能調(diào)整和擴(kuò)展的能力，系統(tǒng)的功能修改和添加更加彈性化，本系統(tǒng)采用Docker容器技術(shù)在服務(wù)端進(jìn)行動態(tài)部署，并使用Nginx+Uwsgi替換 Django自帶的 Web服務(wù)。部署時(shí)根據(jù)系統(tǒng)包含的服務(wù)進(jìn)行了容器劃分，在docker-compose文件中編排容器。圖4展示了服務(wù)端的Docker容器劃分。（1）Web容器是主容器，運(yùn)行基于 Django項(xiàng)目構(gòu)建的Web鏡像，包含項(xiàng)目的主要邏輯代碼；（2）Nginx容器是Django自帶Web服務(wù)的替代容器，提供對外的Web服務(wù)；（3）Selenium容器是數(shù)據(jù)采集支持容器，用于屏蔽系統(tǒng)環(huán)境對采集腳本的影響；（4）MySQL和Neo4j是兩個(gè)數(shù)據(jù)庫，分別在不同容器，為系統(tǒng)提供數(shù)據(jù)存取服務(wù)。

圖4 容器劃分Fig.4 Container division

系統(tǒng)主要頁面包括主頁、任務(wù)添加頁、定時(shí)任務(wù)綁定頁和數(shù)據(jù)查詢展示頁。主頁如圖5所示。左邊三個(gè)板塊分別是任務(wù)相關(guān)頁面、數(shù)據(jù)相關(guān)頁面和數(shù)據(jù)查詢展示頁面。主頁中間是已有任務(wù)的信息及系統(tǒng)支持的對任務(wù)的操作，包括任務(wù)開始和停止、修改、刪除和數(shù)據(jù)展示。主頁下方是任務(wù)的執(zhí)行狀態(tài)信息。

圖5 主頁Fig.5 Homepage

5 總結(jié)

本文針對領(lǐng)域知識圖譜構(gòu)建過程中遇到的領(lǐng)域數(shù)據(jù)采集難點(diǎn)，設(shè)計(jì)實(shí)現(xiàn)了多任務(wù)數(shù)據(jù)采集系統(tǒng)，給出了系統(tǒng)的架構(gòu)設(shè)計(jì)和系統(tǒng)核心功能的設(shè)計(jì)與實(shí)現(xiàn)。最后展示了系統(tǒng)在服務(wù)端基于Docker容器的部署。