题记：写这篇博客要主是加深自己对数据用户的认识和结总现实算法时的一些验经和训教，如果有错误请指出，万分感谢。

一、      目项概略

学术分享索搜引擎要主基于爬取的学术数据，供提索搜，可视化，推荐三大块能功，并且撑支用户分享感趣兴的学术资源，合结“众包”来打造一个更交社化的学术索搜平台。比相于传统的学术索搜，可视化和用户的入加能让平台帮助用户发明更多的货色。

我的作工是个整平台的发开和搭建。从数据上说，涵盖了数据爬取，数据理处，分布式存储，建立引索等作工；从能功上说，涵盖了网站搭建，索搜服务，可视化模块，推荐能功，以及用户的登录、注册、分享模块的现实。

从底层数据，目项管理一直到下层能功，我的作工从爬取的量大元数据手入，打通并综合了索搜，推荐，可视化几大块内容。从技巧角度看，该平台整合了不少技巧和须要的开源工具，作工量比拟大，体整现实难度不低；从平台代价看，可视化和交社化，以及众包的合结，备具定一创新性和前沿性；从工程角度看，这一个平台是一个现实可投入应用的目项，代码管理依靠Github，单点登录又整合了企业级理处方案CAS，平台的发开备具专业性。

下图是个整统系的构架图，比拟清晰地述描了底层数据，后台模块，各块服务之间的逻辑交互。我要需现实的模块和能功也都涵盖在了图中。

图0 统系整体构架图

二、       作工成果及平水

1.  已实现作工

从动手发开到在现，前目经已现实的作工有：数据的爬取、存储和理处，引索服务的建立，网站前后台的搭建，索搜能功的现实，可视化能功的现实，单点登录服务，用户注册、登录、藏收模块的现实。

个整目项的代码管理托管在Github上，所以目项发开情况和commit史历都在我的Github目项地址(https://github.com/pelick/VerticleSearchEngine)上可以直接看到。

图1 Github目项截图

截至到5.3日，统共提交了52次commit，里头细详录记了每次提交的修改录记和发开进度。

2.   数据爬取及存储

我的数据要主从微软学术索搜(http://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单机，主从，分布式部署的内容细详录记在了我的一篇博文里。

详见(http://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的情事，词提取自他所宣布的论文的标题和要摘本文内容。

3.  单点登录问题

个整平台始终是实验室知识中央目项的一部分，要需斟酌到和别的平台的整合。关于数据的取存，面界的同一其实难度不大，关键是在用户管理这块上。因此，在目项发开中程过，我调研了OAuth和CAS两个理处方案，最后决议应用CAS来理处SSO（Single Sign On）。

所谓单点登录，就是要理处同一个统系中，不同模块，不同发开者之间同一登录，同一销注的问题。我应用的是耶鲁大学开源的CAS。理处思绪是独单启动CASServer，让客户端（即各个其他模块）有所用户登录登出相干的操纵跳转到这个server上，在实现登录登出操纵后，跳转回跳转源，且能得获传返来的session内的登录用户的相干息信。细详CAS的理原我不再述阐，下图是知识中央理处单点登录问题的一个构架思绪。

图24 知识中央单点登录理处方案

图中的SSO Server通过置配使其与MySQL里存储的用户息信做登录的校验，然后把胜利登录的用户息信存到session里让客户端得获，而我们的应用或者服务都是一个个独立的CAS的客户端，当要登录登出的时候跳转到CAS Server便可以了，其余作工都一并交给Server实现。这样的理处思绪让平台各个模块和服务的用户管理胜利地无缝合结。

四、        存在问题

1.  数据问题

在休会“发明”模块的时候，我看到很多疏稀的点，两两之间的连线很少。一方面可能的确，不是说同一域领，同一作工地的学者就会相互之间有作合宣布论文的惯习；另一方面也是由于我具有的学者元数据对相于论文元数据来说是比拟裕富的，很多学者的论文列表并没有爬取完全，致使论文息信其实够不齐全，学者数据对比相拟充分。

2.  推荐能功

由于平台刚启动时没有用户，推荐服务法无依赖于用户之间的协同过滤，或者是基于用户藏收录记的论文之间的协同过滤。在推荐统系中这属于一个冷启动的问题。

冷启动问题一般有一些罕见的理处思绪。一方面，在用户注册的时候，要需用户填写感趣兴的域领，帮助统系在初始阶段给用户停止简略的基于内容类别的推荐。另一方面，在用户藏收感趣兴的学者或者论文的时候，要需供提标签，即做成UGC（User-generatedContent）来助辅统系推荐。

对于统系的推荐能功并不要需十分复杂，简略可行的推荐方法便可足满我的求需。我实验了应用PageRank来在一堆论文数据中游走出一些我以为比拟“要主”的论文排名。思绪是基于论文之间的相似度算计，用哈希+余弦距离的方法义定论文之间的初始pagerank值，停止干若次迭代后之到得一个序排。践实后之还没有把它投入到统系序排模块里，还要需善完和进一步斟酌。

针对推荐能功，我经已做了以下一些数据贮备：每位学者都建立了一个tag量向，量向里的词来自于论文集合的标题和要摘切词分结果；每位用户的索搜，藏收，发明，分享录记都存在数据库中，以备任何推荐求需；用户注册要需填写感趣兴的域领，用户藏收要需为内容添加标签。

文章结束给大家分享下程序员的一些笑话语录： 手机终究会变成PC，所以ip会比wm更加畅销，但是有一天手机强大到一定程度了就会发现只有wm的支持才能完美享受。就好比树和草，草长得再高也是草，时间到了条件成熟了树就会窜天高了。www.ishuo.cn