分布式內(nèi)容聚合平臺的設(shè)計與實現(xiàn)

喬杰華　劉亞卓　翟曉寧

【摘 要】本文以一個定向新聞采集平臺的實現(xiàn)為例，詳細(xì)說明了分布式內(nèi)容聚合平臺結(jié)構(gòu)的設(shè)計方案，并針對分布式特點在具體開發(fā)實現(xiàn)過程中涉及的資源結(jié)構(gòu)、快照查重、標(biāo)識確定、消息同步、以及數(shù)據(jù)庫設(shè)計等技術(shù)要點進(jìn)行了闡述，對同類信息系統(tǒng)的研究開發(fā)有一定的借鑒參考作用。

【關(guān)鍵詞】聚合；采集；分布式；消息

1 架構(gòu)設(shè)計

聚合平臺的主體功能包括三項：一是，對已定義的新聞資源進(jìn)行采集，提取新聞的URL列表；二是，根據(jù)列表逐一采集新聞內(nèi)容頁，提取需要的信息數(shù)據(jù)（標(biāo)題、發(fā)布時間、正文）；三是，如果有需要，則對新聞相應(yīng)的圖片進(jìn)行采集。這里提到的新聞資源是指包含有多個新聞內(nèi)容頁鏈接的列表，比如新浪網(wǎng)的新聞頻道首頁。容易想到，平臺按照功能劃分可設(shè)計三類功能節(jié)點：資源采集、內(nèi)容采集和圖片采集，此外我們再加入資源產(chǎn)生和圖片服務(wù)兩種節(jié)點。嚴(yán)格來說，圖片服務(wù)不屬于新聞采集的范疇，它是為前端用戶提供圖片服務(wù)的，將其納入本文內(nèi)容是為了完整說明一個新聞生成的完整過程。

如圖1所示，生產(chǎn)運行過程中，資源產(chǎn)生節(jié)點從資源數(shù)據(jù)庫中取出已定義的資源并作為任務(wù)告知資源采集節(jié)點，內(nèi)容采集節(jié)點的任務(wù)來自資源采集節(jié)點在資源中提取的新聞鏈接列表，而圖片采集節(jié)點的需求驅(qū)動則來自內(nèi)容采集節(jié)點的在采集內(nèi)容時發(fā)現(xiàn)的圖片，最后圖片采集成功后會將圖片部署到圖片服務(wù)節(jié)點，任務(wù)數(shù)據(jù)（或事件）將依次在五種節(jié)點間單向傳遞。新聞的生成在內(nèi)容采集節(jié)點發(fā)生，并由其存入新聞數(shù)據(jù)庫，而新聞是否有圖片可用則由圖片服務(wù)節(jié)點來決定，這是因為只有圖片部署完成可用才能說明新聞的圖片是可用有效的，所以需要圖片服務(wù)節(jié)點完成部署后對新聞數(shù)據(jù)庫進(jìn)行“回寫”以標(biāo)識新聞的圖片可用性。

圖1 新聞聚合采集平臺拓?fù)浣Y(jié)構(gòu)圖

由于新聞采集本身并沒有快速實時響應(yīng)的要求，所以各節(jié)點間的通知傳遞選用異步的消息方式，與同步方式（如RPC）相比消息方式能夠方便實現(xiàn)每一類節(jié)點的集群式擴(kuò)展，即每節(jié)點功能可以實現(xiàn)集群化。這種分布式的結(jié)構(gòu)有三個明顯優(yōu)點：一是，功能分割實現(xiàn)了模塊或節(jié)點間的松耦合；二是，能過節(jié)點擴(kuò)展能夠應(yīng)對高負(fù)載需求；三是，避免單點故障。

2 實現(xiàn)要點

2.1 資源結(jié)構(gòu)

一個資源對象當(dāng)然包括有URL、分類、標(biāo)簽等要素，但更重要的是應(yīng)有如何提取新聞列表的信息。傳統(tǒng)搜索引擎會面對各式各樣的網(wǎng)頁內(nèi)容，所以通常會使用一些復(fù)雜的算法模型提取所需要的標(biāo)題內(nèi)容等信息，對無效信息（如廣告）進(jìn)行降噪處理。而定向采集的資源內(nèi)容結(jié)構(gòu)性穩(wěn)定，所以分析提取信息可以使用一些DOM工具來實現(xiàn)，可以將新聞列表的XPATH描述作為提取要素，采集以此來解析資源頁面中的新聞列表。

2.2 資源“快照”

為了將資源中最新發(fā)布的新聞采集同步到本地，通常每天會一次或多次采集資源，但對有些更新不頻繁的資源的采集就會造成節(jié)點的“空載”運行，這包括資源采集節(jié)點的掃描解析，內(nèi)容采集節(jié)點對新聞列表的逐一采集，而這些新聞實際上全是已采過的“舊聞”。因此設(shè)計資源“快照”，資源采集節(jié)點對從資源中的列表進(jìn)行“拍照”并與上一次的拍照結(jié)果進(jìn)行比較，如果未發(fā)生變化則表明列表無更新也就無需進(jìn)一步采集。

2.3 標(biāo)識問題

首先，如何識別新聞是否已被采集過。“快照”檢測只是資源列表級的，當(dāng)一個列表有部分更新時就需要有識別某個具體新聞是否已被采集過以避免復(fù)采，顯然新聞的URL是最好的標(biāo)識，可以對其進(jìn)行摘要（如HASH、MD5）取值建立索引快速檢查新聞是否已存在。其次，如何為新聞生成全局性ID。用URL的摘要值不適合做新聞的ID，畢竟摘要值有重復(fù)可能，再者如果后續(xù)需要使用Hadoop和Mahout等大數(shù)據(jù)工具進(jìn)行推薦等挖掘計算如用純數(shù)字的ID會更方便。容易想到用時間戳來設(shè)計ID，但在集群環(huán)境下多個節(jié)點產(chǎn)生ID也會有沖突可能，因而給每個節(jié)點配置一個ID前綴，節(jié)點產(chǎn)生的ID再冠以前綴可以避免ID沖突。

2.4 消息與同步

節(jié)點間的消息通信可以用rabbitmq、kafka等高效的消息平臺，值得提出的是資源產(chǎn)生、資源采集、內(nèi)容采集和圖片采集節(jié)點之間的消息應(yīng)該選用單隊列topic主題模式，因為一個采集任務(wù)被任意節(jié)點執(zhí)行都是無差別的，但圖片采集和圖片服務(wù)節(jié)點間則應(yīng)該用廣播方式傳遞消息，因為每一張圖片都需要被部署到所有圖片服務(wù)節(jié)點上。

2.5 數(shù)據(jù)庫設(shè)計

聚合采集平臺用于存放新聞的數(shù)據(jù)庫可以選用一些常規(guī)的數(shù)據(jù)庫（如Mysql），因為僅供挖掘或推薦平臺提供數(shù)據(jù)源而不是直接面向用戶服務(wù)。但如果采集的數(shù)據(jù)量或集群規(guī)模很大則可以考慮分庫，多個節(jié)點甚至單個節(jié)點使用一個數(shù)據(jù)庫。實際上，對于采集平臺直接以文本文件方式存放數(shù)據(jù)（以ID作為文件名）也是可行的，而且這樣還可以大幅提升存寫速度，只是在存放結(jié)構(gòu)上需要根據(jù)數(shù)據(jù)的使用需求進(jìn)行設(shè)計，比如可以選用多級散列目錄存放實現(xiàn)根據(jù)ID快速定位文件。

3 結(jié)論

本文限于篇幅原因還有較多采集中的細(xì)節(jié)未能提及，比如針對各種資源中不同的列表結(jié)構(gòu)（列表、相對、表格等形式）該如何定義XPATH以提取有效信息，又比如該如何設(shè)計消息的結(jié)構(gòu)以提升整個平臺的工作效能，再比如資源產(chǎn)生節(jié)點如何實現(xiàn)集群化以及對于一些“連續(xù)”性資源（比如有“下一頁”）又如何進(jìn)行自動翻頁采集歷史數(shù)據(jù)等技術(shù)點都沒能在文中說明。同時，對于一個完善的信息流處理平臺來說還有些應(yīng)該具備的功能還未考慮到，比如平臺運行的在線監(jiān)控以及對各類節(jié)點所產(chǎn)生日志的分析挖掘等等，這些有待于下一步進(jìn)行研究和實現(xiàn)。

【參考文獻(xiàn)】

[1]鄧勝利.信息聚合服務(wù)的發(fā)展與演變研究.情報資料工作，2012.

[2]Web3.0技術(shù).https：//baike.baidu.com/item/web%203.0/2587429？fr=aladdin.endprint