708
學術分享搜索平台——設計方案
項目背景
有兩類和我們大學生息息相關的產品。一類是微博，人人，豆瓣這些偏SNS的社交平台，推薦同學朋友的信息，幫助我們找到可能認識的人，可能喜歡的書，可能愛看的電影等等。另一類是學術相關的搜索引擎，比如Google Scholar，Microsoft Academic Search Engine，通過搜索關鍵字，提供一些匹配度最高的學術論文，提供很多便利。
然而，學術搜索引擎是一個比較通用的工具，每個人搜索同一個詞，給出的都是相同的Ranking List，不會像亞馬遜一樣根據用戶的瀏覽和購書記錄進行個性化推薦。基於這點，我的畢設內容是做一個帶有用戶個性化推薦性質的知識分享平台，在搜索到可能想要的結果之外，推薦給用戶相關的學者，論文。同時，知識分享平台集成“眾包”的理念，讓用戶去添加和分享自己感興趣，想分享的知識，讓平台更加社交化。
學術分享搜索引擎作為“知識中心”的一部分，為自動綜述編寫提供豐富的論文資源。基於論文內容的分析和推薦，可以在這一個數據源下找到各領域，學者的論文，構成一個知識網絡。這個知識網絡為知識中心提供學術方麵的知識搜索和挖掘，結合“眾包”的理念，讓用戶分享知識，傳遞知識，同時平台為用戶推薦相關的論文列表和全文內容，把學術的搜索，推薦和“眾包”結合在一起，打造實用，便利的“知識中心”。
目標任務
目標是搭建一個知識分享平台，提供計算機科學方麵的垂直搜索，具體內容，一方麵是著名的專家學者的個人信息，也包括他的publications，個人主頁等；另一方麵是論文搜索結果，包括標題，全文等各個維度的檢索功能。平台還允許並鼓勵用戶自己上傳想要分享的論文，學者個人主頁，並將獲得這些數據，集成進平台底層數據中。在“眾包”的效果下，用戶還會發現與自己關注同相同領域，有著相似興趣的其他用戶，依照用戶自己的搜索記錄，收藏記錄和分享記錄，平台會為用戶進行推薦，有相關領域著名學者的推薦，論文的推薦，個人主頁的推薦和興趣相似的用戶群推薦。
下圖為整個平台需要實現的模塊架構圖：
問題分析
- 平台的初始數據（學者和論文）需要自己爬取，並且具備一定的數據量。論文的全文需要處理和分析，為搜索和推薦做好準備。
- 在抓取和分析用戶上傳的學者個人主頁時，要分析處理有效信息，得到論文列表，為個人主頁的推薦做基礎。
- 需要為大規模的數據建立高效的索引。索引具備增量，近實時等特點。設計索引文檔的結構，支持各維度的檢索需求。
- 平台以網站的方式呈現，支持用戶注冊登錄，為每位用戶展現一個收藏，分享記錄的頁麵。提供快速的搜索體驗，保證一定的搜索準確度。
- 相關學者，論文和個人主頁的推薦和挖掘需要做到盡可能好的效果。
- 利用數據可視化，直觀展示學術知識網絡。可以嚐試簡單地展示學者的研究領域，用戶興趣，論文之間引用關係等更深入的知識。
初步技術方案
數據爬取
需求分析
數據需求是計算機科學方麵的學者和論文元數據，所以我的爬取需求是定向的網絡爬取，而不是通用的爬取。在調研，使用和對比了Nutch，Heritrix，Scrapy這些爬蟲工具之後，決定采用Scrapy來做數據的爬取。
解決方案
Scrapy是一個Python寫的爬蟲框架，高效簡單，代碼量少，定製方便，而且是一個企業級的開源爬蟲。相對於Nutch，Heritrix要輕量級很多，基本沒有配置。它使用Python庫中Twisted這個優秀的異步網絡庫來處理網絡通訊，架構清晰，並且包含了各種中間件接口，可以靈活完成各種需求。
在爬數據的過程中，有兩點還需要考慮。第一點是頻繁的爬取會被目標站點發現，以至封掉爬蟲機器的IP，簡單的解決方案是在每兩次頁麵抓取過程中加上適當的時間停頓，模擬人的瀏覽方式。第二點是數據的存儲。Scrapy支持以json形式存儲和讀取爬取到的內容，我將把json對象存入MongoDB內，下麵會具體介紹。
數據存儲
需求分析
“學者”的數據大致包含以下一些字段：全名，工作地，個人主頁，研究領域（多字段），論文列表（多字段）。“論文”的元數據信息大致包含：題目，摘要，作者（多字段），期刊，下載鏈接。如果讓傳統的麵向行的關係型數據庫，如MySQL，來存取數據，多字段會需要多張表之間的join操作，表之間需要外鍵關聯，會影響查詢性能。此外，可以適當放寬數據查詢的一致性，隻要滿足CAP中的A和P。所以理想的存取方式是非結構化的存儲，並且具備可用性和分布式可擴展性，達到最終一致性。
解決方案
MongoDB是當下比較熱門的NoSQL之一。MongoDB是麵向文檔的NoSQL，也是易用性最高的。選擇MongoDB，在解決以下幾個問題中具備優勢：
1. MongoDB的存儲模型是嵌套型的K/V對模型，稱為BSON。通過pymongo驅動能和Scrapy輕鬆連接，並直接將json形式的數據存入數據庫中。對於“學者”和“論文”，隻要各自一個collection（相當於MySQL中的一張表）就能完成存儲和查詢需求。
2. MongoDB有主從，分片的部署方式。主從集群中，從節點會自動備份當前活躍節點的數據，任何集群中的節點都有可能成為主節點，所以集群容錯性強，且具備故障恢複的能力，這樣的集群稱為Replica Set。分片部署類似分布式部署，路由服務器會將多個分片節點與配置服務器相關聯，且分片節點可簡單增刪，讓集群具備高可擴展性，數據庫的容量也得到了擴充。分片服務器還能根據指定的片鍵對指定數據庫的collection讀寫做負載均衡。我將搭建一個健壯的MongoDB集群部署。
3. MongoDB自帶的GridFS用於存儲較大的文件，“視覺中國”就利用該功能存儲海量的圖片。我將利用GridFS存儲pdf格式的論文。
4. MongoDB相比MySQL，還有更簡潔的查詢語言（實現在自帶的js環境中），強大的基於MapReduce的查詢等等。
索引
需求分析
搜索是平台提供的最主要服務，需要對學者，論文兩塊的元數據，以及論文的全文數據建立高效的索引，提供各個維度的搜索需求。考慮到論文也是結構比較清晰的一類全文數據，對於論文內部的各個章節的數據也需要工具來定向提取和分析處理，然後建立到索引內提供搜索。索引內可以存儲部分數據，而大量的全文內容還是要存儲在數據庫內，所以索引和數據庫之間也存在連結和交互。
解決方案
Lucene是一個java語言的搜索引擎庫，為開發者提供了索引建立，搜索兩塊搜索引擎需要具備的基本功能。使用Lucene來自己定製索引塊內的文檔結構，為學者和論文定製索引，使用lucene的排序，高亮等功能，能搭建一套搜索原型了。
Solr兼容Lucene，將Lucene庫進行了包裝，封裝成了一個可用的配置型搜索服務。在servlet容器（Tomcat，或者更輕量級的Jetty）中啟動即可成為一個Http接口的搜索服務，能讓搜索模塊與網站隔離並且方便調用。Solr除了具備Lucene提供的一些搜索功能外，還提供批量的數據導入和自動建立索引，這裏不涉及這塊內容，因為索引的具體建立是由我利用Lucene自己建立的。我需要Solr的主要原因還是把它當作一個獨立的搜索服務層。
除此之外，Apache Tika是一個內容抽取工具，我將使用Tika來抽取pdf內的論文全文內容，並進行處理和分析，將全文內容建立索引並存入MongoDB內，這些全文內容還可以服務於進一步挖掘論文之間的關係，涉及到相關推薦模塊。
推薦/挖掘
需求分析
其實是基於研究方向，感興趣領域的推薦，推薦內容可以是用戶群，學者，論文。具體推薦這塊如何做，用什麼做還沒有想好。也可能是一些關係的挖掘。
參考這裏：文本相似度計算基本方法小結
網站搭建
需求分析
網站的需求分析是相對簡單的，能提供用戶注冊登陸，提供搜索框和搜索結果界麵，提供用戶上傳和分享pdf或者url鏈接的頁麵。在整個工程中，網站搭建這塊並不是重點，隻是一個呈現形式。當然如果有時間盡量把他做得更簡潔，更geek一點。
解決方案
在體驗了一下Django之後，雖然他層次很清楚，開發便捷，可是考慮到我上述有比較多的java模塊銜接，除了搜索可以作為服務外，別的小的模塊還是需要融入到整個平台的代碼裏，所以暫時還是決定采用Spring+Struts2的框架來搭建這個平台。前台的技術和庫基本上還是bootstrap，帶上一些CSS3的東西。
結束語
最後更新：2017-04-03 22:15:45