分布式內容聚合平臺的設計與實現

喬杰華　劉亞卓　翟曉寧

【摘 要】本文以一個定向新聞采集平臺的實現為例，詳細說明了分布式內容聚合平臺結構的設計方案，并針對分布式特點在具體開發實現過程中涉及的資源結構、快照查重、標識確定、消息同步、以及數據庫設計等技術要點進行了闡述，對同類信息系統的研究開發有一定的借鑒參考作用。

【關鍵詞】聚合；采集；分布式；消息

1 架構設計

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

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

圖1 新聞聚合采集平臺拓撲結構圖

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

2 實現要點

2.1 資源結構

一個資源對象當然包括有URL、分類、標簽等要素，但更重要的是應有如何提取新聞列表的信息。傳統搜索引擎會面對各式各樣的網頁內容，所以通常會使用一些復雜的算法模型提取所需要的標題內容等信息，對無效信息（如廣告）進行降噪處理。而定向采集的資源內容結構性穩定，所以分析提取信息可以使用一些DOM工具來實現，可以將新聞列表的XPATH描述作為提取要素，采集以此來解析資源頁面中的新聞列表。

2.2 資源“快照”

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

2.3 標識問題

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

2.4 消息與同步

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

2.5 數據庫設計

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

3 結論

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

【參考文獻】

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

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