644
技術社區[雲棲]
學術分享搜索平台——中期報告
一、 項目概況
學術分享搜索引擎主要基於爬取的學術數據，提供搜索，可視化，推薦三大塊功能，並且支持用戶分享感興趣的學術資源，結合“眾包”來打造一個更社交化的學術搜索平台。相比於傳統的學術搜索，可視化和用戶的加入能讓平台幫助用戶發現更多的東西。
我的工作是整個平台的開發和搭建。從數據上說，涵蓋了數據爬取，數據處理，分布式存儲，建立索引等工作；從功能上說，涵蓋了網站搭建，搜索服務，可視化模塊，推薦功能，以及用戶的登錄、注冊、分享模塊的實現。
從底層數據，項目管理一直到上層功能，我的工作從爬取的大量元數據入手，打通並綜合了搜索，推薦，可視化幾大塊內容。從技術角度看，該平台整合了不少技術和必要的開源工具，工作量比較大，整體實現難度不低；從平台價值看，可視化和社交化，以及眾包的結合，具備一定創新性和前沿性；從工程角度看，這一個平台是一個實際可投入使用的項目，代碼管理依托Github，單點登錄又整合了企業級解決方案CAS，平台的開發具備專業性。
下圖是整個係統的架構圖，比較清晰地描述了底層數據，後台模塊，各塊服務之間的邏輯交互。我需要實現的模塊和功能也都涵蓋在了圖中。
圖0 係統總體架構圖
二、 工作成果及水平
1. 已完成工作
從著手開發到現在，目前已經實現的工作有：數據的爬取、存儲和處理，索引服務的建立，網站前後台的搭建，搜索功能的實現，可視化功能的實現，單點登錄服務，用戶注冊、登錄、收藏模塊的實現。
整個項目的代碼管理托管在Github上，所以項目開發情況和commit曆史都在我的Github項目地址(https://github.com/pelick/VerticleSearchEngine)上可以直接看到。
圖1 Github項目截圖
截至到5.3日，總共提交了52次commit，裏麵詳細記錄了每次提交的修改記錄和開發進度。
2. 數據爬取及存儲
我的數據主要從微軟學術搜索(https://academic.research.microsoft.com/)爬取，定製了python的開源爬蟲Scrapy來做數據的爬取。爬蟲主要通過XPath獲取指定的內容。爬取的數據存在自己搭建的MongoDB集群裏。目前爬取的學者數目為十萬，論文元數據五十四萬，並額外爬取了一萬多位學者的個人主頁和一萬多份帶有pdf下載url的論文。
圖2 爬取數據統計
學者的元數據主要包括了他的name，Homepage的url，研究領域field，工作地，具體publication獲取地址（會單獨爬取存在publications裏），從其發表的論文提取出來的關鍵詞集合tags。
圖3 學者的元數據存儲格式及內容
論文的元數據存儲主要包括了title，會議/期刊，作者，摘要以及它的可瀏覽或者可下載的url鏈接。
圖4 論文的元數據存儲格式及內容
這些數據都存儲在我的MongoDB集群裏，用Replica Set保證了單個分片上數據的容錯，用多個分片的部署保證了數據存取的負載均衡以及數據存儲的可擴展性，避免單個collection內數據量過大影響讀取性能。更多關於MongoDB單機，主從，分布式部署的內容詳細記錄在了我的一篇博文裏。
詳見(https://blog.csdn.net/zbf8441372/article/details/8644116)
圖5 MongoDB分片集群部署
我還額外批量下載了一部分帶有pdf鏈接的論文，存在本地文件係統內，通過Tika提取和分析pdf文本內容，一方麵建立了這些論文的全文索引，提供搜索；另一方麵可以粗糙地分割出論文裏標題、介紹、正文、總結、引用幾塊內容，而這樣的相對結構化的文本內容可以進一步提供基於論文全文的相關研究工作。
圖6 下載到本地文件係統的論文
3. 索引服務
我通過Lucene對MongoDB中爬取的數據建立索引，通過單獨開啟一個Tomcat容器 (端口為9080) 來搭建Solr搜索服務。平台後台通過Solrj訪問Solr Server，支撐幾乎所有搜索請求。Solr服務的配置是multicore的配置，即多份配置文件對應多份索引文件，提供不同的搜索服務，core0對應學者元數據，core1對應論文元數據，core2對應論文全文。具體的搜索結果就不截圖展示了。
圖7 Solr Admin
4. 平台展示
網站的前後台都由我一人完成。基於J2EE的一些網站開發技術，後台采用的是Struts2，前台主要采用的是Jquery，Bootstrap和D3這個可視化庫，也涉及到了CSS3和HTML5的技術。下麵具體展示一下目前各個頁麵。
主頁
圖8,9 主頁
搜索頁（學者）
左側展示的是搜索結果中學者的領域和工作地統計，方便用戶縮小檢索範圍。中欄展示了相關學者的基本信息，包括姓名，工作地，研究領域，個人主頁鏈接。
圖10 學者搜索
搜索頁（論文）
搜索結果裏展現了相關論文的標題，作者，摘要，會議/期刊，鏈接。
圖11 論文搜索
搜索頁（全文）
圖12 全文搜索
學者主頁
目前學者主頁主要展示三部分內容，最上麵一欄是學者相關信息：姓名、個人主頁、工作地、研究領域。中間一欄是標簽雲，內容源自於我爬取的所有他參與發表的論文的標題和摘要切分詞結果。下麵一欄是論文列表。
圖13 學者主頁：個人信息及標簽雲
圖14 學者主頁：論文列表
發現頁
發現頁借助可視化效果，提供了比較有趣的學者共生關係發現檢索。目的是通過不同維度的檢索方式，用可視化展現學者之間共同發表論文的共生關係。
現在主要提供四種發現檢索方式來得到Coauther集合。第一種是檢索學者姓名，係統會從底層數據中找到和該學者共同發表論文的其他學者；第二種是檢索論文標題，得到所有相關論文的相關作者集合；第三種是研究領域檢索，得到該領域的相關學者集合；第四種是工作地檢索，得到同一工作地的學者集合。
圖15 發現頁檢索示例
下圖以檢索學者姓名“Andrew Y. Ng”的可視化結果為例。左側是可視化中的力導向圖（Force-DirectedGraph）。每個點代表一位學者，點與點之間的連線代表兩位學者共同發表論文，且連線越粗，代表共同發表論文次數越多。右側是一個共生矩陣（co-occurrence matrix），著色塊代表兩位作者共同發表過論文，顏色越深表示發表次數越多，圖中顯示Andrew Y. Ng與Pieter Abbeel，J. Zico Kolter有至少兩次合作。此外，顏色還代表了工作地這一維度，比如Adam Coates，Andrew Y. Ng，Anna Petrovskaya在同一工作地工作。
圖16 可視化展示
分享頁（用戶主頁）
分享頁是需要登錄才能進入的用戶主頁。目前顯示了用戶注冊時候登記的基本信息，主要包括姓名，郵件，感興趣的領域，微博、Github、個人主頁地址。同時，兩個“Favor”欄裏展現了用戶在平台上的收藏曆史。其他一些搜索，發現，分享等曆史記錄後續也考慮適當呈現出來。
分享頁之後還會支持用戶分享功能，而這些用戶數據的記錄和呈現將為推薦功能提供數據支持和推薦依據。
圖17 用戶主頁
登錄注冊
用戶登錄模塊考慮到本係統與項目其他係統的無縫結合，采用了一個企業級的開源解決方案——CAS，來實現了單點登錄（SSO）。每次登錄和登出都會跳轉到CAS Server端做處理，校驗成功後會自動跳轉回跳轉源並在傳回來的session中保存已登錄用戶的基本信息。具體單點登錄的實現細節會在下一章節裏詳細說明。
圖18 提示登錄頁
圖19 注冊頁
圖20 單點登錄跳轉頁
三、 項目收獲
項目開發中，嚐試使用Scrapy+MongoDB來做數據的爬取和存儲，借用D3這個可視化庫，結合CSS3和HTML5的一些元素來實現了幾個可視化的demo，此外還使用CAS這個開源的企業級解決方案來實現了單點登錄。
1. 數據的爬取和存儲
第一次使用python的開源爬蟲Scrapy來做學術數據的爬取。Python程序比較簡短，而Scrapy基於優秀的twisted框架實現，多線程的問題也不需要開發者擔心，我所要做的就是借助Scrapy，通過XPath的解析來提取出我想要的數據。爬到的數據最後是以json的格式輸出的，考慮到學者，論文的元數據存儲格式，我選擇了更靈活的麵向文檔的NoSQL，即MongoDB來做爬蟲數據的存取工作。
MongoDB是最易用的NoSQL，提供pymongo-driver支持python程序的數據庫連接。MongoDB是麵向文檔的NoSQL，他的副本集和分片部署讓存儲更容錯並且負載均衡，可擴容。在實踐過程中，我搭建了MongoDB的分片集群，在Academic這個數據庫中建立了Researchers，Publications等collections（類似MySQL裏的table） 來存儲Scrapy爬取的數據。
Scrapy和MongoDB的結合，除了滿足我的需求外，很大一部分原因也是我興趣使然。能嚐試使用我感興趣的技術並解決實際問題的確一舉兩得。
2. 可視化的實現
基於爬取並處理之後的大量數據，我做了可視化效果，試圖通過更直觀的展示發現學術資源裏潛在的關係，例如學者和學者之間可以通過發表論文，工作地，研究領域產生一些共生關係或者合作關係。我使用了d3這個優秀的開源可視化庫。D3全稱為Data-Driven Documents，本質上還是js庫，結合了CSS3，HTML5裏的前端元素，把可視化效果做得比較炫比較酷。從他提供的example裏我挑選了下麵三個demo。
圖21 力導向圖
圖22 共生矩陣圖
圖23 詞雲
我使用力導向圖和共生矩陣來發現學者之間共同發表論文的關係，並額外結合了工作地這個維度。使用詞雲來給每位學者做一個類似tag的事情，詞提取自他所發表的論文的標題和摘要文本內容。
圖24 發現頁搜索"sparse"相關學者可視化結果
3. 單點登錄問題
整個平台始終是實驗室知識中心項目的一部分，需要考慮到和別的平台的整合。關於數據的存取，界麵的統一其實難度不大，關鍵是在用戶管理這塊上。因此，在項目開發過程中，我調研了OAuth和CAS兩個解決方案，最後決定使用CAS來解決SSO（Single Sign On）。
所謂單點登錄，就是要解決同一個係統中，不同模塊，不同開發者之間統一登錄，統一注銷的問題。我使用的是耶魯大學開源的CAS。解決思路是單獨啟動CASServer，讓客戶端（即各個其他模塊）所有用戶登錄登出相關的操作跳轉到這個server上，在完成登錄登出操作後，跳轉回跳轉源，且能獲得傳回來的session內的登錄用戶的相關信息。具體CAS的原理我不再闡述，下圖是知識中心解決單點登錄問題的一個架構思路。
圖25 知識中心單點登錄解決方案
圖中的SSO Server通過配置使其與MySQL裏存儲的用戶信息做登錄的校驗，然後把成功登錄的用戶信息存到session裏讓客戶端獲取，而我們的應用或者服務都是一個個獨立的CAS的客戶端，當要登錄登出的時候跳轉到CAS Server就可以了，其餘工作都一並交給Server完成。這樣的解決思路讓平台各個模塊和服務的用戶管理成功地無縫結合。
四、 存在問題
1. 數據問題
在體驗“發現”模塊的時候，我看到許多稀疏的點，兩兩之間的連線很少。一方麵可能的確，不是說同一領域，同一工作地的學者就會相互之間有合作發表論文的習慣；另一方麵也是由於我擁有的學者元數據相對於論文元數據來說是比較富裕的，很多學者的論文列表並沒有爬取完整，導致論文信息其實不夠齊全，學者數據相對比較充足。
2. 推薦功能
由於平台剛啟動時沒有用戶，推薦服務無法依賴於用戶之間的協同過濾，或者是基於用戶收藏記錄的論文之間的協同過濾。在推薦係統中這屬於一個冷啟動的問題。
冷啟動問題一般有一些常見的解決思路。一方麵，在用戶注冊的時候，需要用戶填寫感興趣的領域，幫助係統在初始階段給用戶進行簡單的基於內容類別的推薦。另一方麵，在用戶收藏感興趣的學者或者論文的時候，需要提供標簽，即做成UGC（User-generatedContent）來輔助係統推薦。
對於係統的推薦功能並不需要十分複雜，簡單可行的推薦方式就可滿足我的需求。我嚐試了使用PageRank來在一堆論文數據中遊走出一些我認為比較“主要”的論文排名。思路是基於論文之間的相似度計算，用哈希+餘弦距離的方式定義論文之間的初始pagerank值，進行若幹次迭代之後得到一個排序。實踐之後還沒有把它投入到係統排序模塊裏，還需要完善和進一步考慮。
針對推薦功能，我已經做了以下一些數據儲備：每位學者都建立了一個tag向量，向量裏的詞來自於論文集合的標題和摘要切分詞結果；每位用戶的搜索，收藏，發現，分享記錄都存在數據庫中，以備任何推薦需求；用戶注冊需要填寫感興趣的領域，用戶收藏需要為內容添加標簽。
最後更新：2017-04-03 18:51:45