11_动手搭建一套垂直搜索系统

内容简介：前面已经讲了10个方面的技术，要构建一个自己的搜索，是否已经条件具备了呢？这节课我们就聊聊，怎么有机地搭配上述技术，实现一个面向垂直行业的搜索系统。今天，我想只谈思路，技术上的细枝末节就不在重复了。因为能看到这里的，想必也是通关打怪一路，趟过坑的经验人士。那我们就简短点！

最近看到了一篇关于许倬云的专访，老先生说了一句话，让我印象颇深。他说：“现在的知识分子不是思考者,是检索机器。”听了我挺扎心的，老先生是历史学家，见识和眼界当然是我们无法企及的，其实做科学确实需要独立思考，但是思考后的技术实现也还需要投入大量的精力，本专辑就是期望通过我们的实践，减少遇到同样问题的科研人员时间投入。但是这句话还是挺扎心，说白了就是说我们这些人没文化嘛，小哥马上买了许老先生的两本书《万古江河》《中国文化的发展过程》，决定更新完这篇就闭门不出，好好的读历史。

1、垂直搜索内容

要实现一个特定领域的信息检索，如果还是使用通用搜索引擎，用户总会觉得搜索结果差点意思。这也是为什么百度、谷歌、bing有专门的学术搜索、图片搜索等等。这类搜索都可以归结为一类，即垂直搜索引擎（Vertical Search Engines），或专业搜索引擎（Specialty Search Engines）、专题搜索引擎（Topical Search Engines）。越是小众专业，特定行业越需要对内容进行专业和深入的分析挖掘、过滤筛选。这些信息定位为更精准的专业搜索，实际上是搜索引擎的细分和延伸。

垂直搜索引擎的价值在于其占有信息资源的数量，能否提供全面权威的行业信息，能否最大限度拥有行业资源是垂直搜索引擎发展的关键。从某种意义上讲，行业门户网站是垂直搜索引擎嫡亲的父母，同时也是往往不能分割的有机整体。

在地震研究领域，很多时候需要对历史震例进行回溯性研究，中国地震局每年都会修订出版《中国震例》，通过专家们精心编撰，一个个围绕震例前后的异常特征、性质和可能相互关联的前兆异常都被整理出来。但问题来了，震例越来越多，要检索起来挺费劲，也不利于新工作的青年人学习。

哪为什么不做一个围绕地震主题的垂直搜索系统呢？

其实前边一大堆所谓的技术，也是在为今天的想法实现做铺垫。因为只要掌握了这些技术，自己也可以动手实现。小哥算了一下1970年以来，中国大陆M3以上的地震事件有5万多个，把这些地震前后的信息给整理出来，录入搜索引擎，这就是我们现在打算干的事。每次地震震中位置、周边构造、相关的序列类型，周边地震事件等等，这些都可以统计出来，每个地震事件用一个报告来总结，通过搜索系统，可以快速找到用户期望深入了解的地震信息。

2、后台设计（ElasticSearch）

搜索系统的后台在选型方面，ES具备你想要的一切。在技术成熟度，可扩展性和性能方面，ES都有技术优势。作为日志分析与监控起家的产品，产品线发展的越来越完善。图1是一个可能的地震行业系统后台数据库结构概念图。

图1 系统构建过程和关键技术

欣慰的是我们刚走出第一步。

后面还有很多内容，如何设计检索和文档结构，如何提取相关性，采集数据入库，专业分词库的建立，评分系统，针对用户的推荐系统等等...

3、监控设计（Kibana）

系统在云上部署都是分布式的，资源的运行状态监控，Kibana是理想的工具之一，结合Uptime等工具，可以方便监控资源运行情况，为了让监控更加智能，当然异常监测与监控是必要的，这是让系统智能化的关键。

监控除了看好服务是否正常之外，对异常的自动判断也是必要功能之一。一个突发事件，可能会瞬间流量暴增，高负荷下不马上提升负载均衡能力，再好的系统服务肯定也会被拖垮。

学术界对异常（anomaly detection）的定义有很多种，不同的算法适合不同类型的异常检测，概要讲可将异常定义为“容易被孤立的离群点 (more likely to be separated)”——可以理解为分布稀疏且离密度高的群体较远的点。

用统计学来解释，在数据空间里面，分布稀疏的区域表示数据发生在此区域的概率很低，因而可以认为落在这些区域里的数据是异常的。下面是异常检测领域的几类算法：

1. Density-Based Approaches

• RKDE:Robust kernel denisty estimation
• EGMM: Ensemble guassian mixture model

2. Quantile-Based Methods

• OCSVM: One-class SVM
• SVDD: Support vector data description

3. Neighbor-Based Methods

• LOF: Local outlier factor
• ABOD: kNN angle-based outlier detector

4. Projection-Based Methods

• IFOR: Isolation Forest
• LODA: Lightweight online detector of anomalies

当然，具体实现上还有很多工具和API可用，不管方法是什么，最后还要靠实践去检验。

4、前台设计（React+Searchkit）

前端或前台是用户直接接触的，在技术选型上React+searchkit是理想的解决方案之一。我调研过美国USGS的Eventpage实现技术是使用Angular设计的，Angular与React都是当今最流行的JavaScript框架，它们之间的对比有很多文章讨论了，我看中的主要还是学习难度，毕竟React简单些。

图2 React vs Angular对比

选择上述技术的好处是在各自的生态阵营中都有非常多的优秀项目可以借鉴，结合开源项目我们可以学到很多。说了这么多，我们还是在纸上谈兵，做了这么多调研和探索，最终目的还是要做出可用的东西来。

我经常用一个比喻：假设你想造一辆车卖给用户，只有一个发动机是不够的，还需要配套各种辅助的设施。而你了解的专业知识或者模型算法，即便写成论文、变成专利，这也就好比一个发动机。对于用户来讲他们是没有获得感的。

千万别把发动机造完就扔到哪里，把期望寄托在别人身上去用你的发动机造车或发扬光大，这也就是当今为何很多科研成果锁在抽屉里的的关键问题，最了解技术细节的你自己都不愿意去推动应用，试问谁还比你更了解你设计的发动机呢？

为什么说科研成果转化很难！如果你想造车，在有了一个理念之后，首先是游说投资人，这在科研领域就是申请项目；

之后，你要去了解当前主流技术的进展，你是用三元锂电池、还是磷酸铁锂电池、甚至用核能电池，你要足够了解技术细节，将每个不确定性风险降到最低才行，这就好比是阅读国内外文献，好技术你hold不住也不成；

之后，你要动手做，现在的行业分工很细，懂得使用全球产业链资源才行，除了买买买，我想还涉及到团队和协作等问题，不同知识背景的人，要合作到一起需要解决很多问题，领导团队首要的是领导者本身要学会与各种背景的人怎么去交流，这步走不好往往结果就是团队一盘散沙，人心散，队伍也不好带啊！

之后，经过反复的测试失败，再去换技术，趟坑...

最后，怎么集成到一起，给用户一个可用的产品，这往往是最难的部分，因为这涉及到价格和体验的问题，预算往往是有限的，这要求一个产品设计者在用料、功能和产品体验之间做出折衷和最优的抉择才行，当然最后效果如何，还是用户说的算！

如果你读到这里，明白我写这些偏技术类文集的目的了吗

一句话总结：今天完成了本文集最后一篇还写完的文章，也是三年前小哥期望结合地震行业特点，打造一个基于云的垂直搜索引擎的探索，当然，今天不是句号，我想就当这是一个即将踏出第一步的开始吧。