Talk is Cheap, Show me the Code! <<网站首页文章列表

快速预览不管处于什么年龄阶段，我个人在学习新事物的时候总会有一个迫切的诉求，那就是希望新事物能以旧方式呈现。所以，我也希望在搭建好ElasticSearch之后，它能像其它数据存储引擎一样，让我快速的进行数据的预览、查询、新增。不知道是不是我的思想过于陈旧了，总觉得熟悉的面貌能让我快速进入角色，开始学习。好在我也找到了一款Chrome插件，让我们对ElasticSearch数据进行预览等操作。 Dejavu The Missing Data Browser and Web UI for Elasticsearch.它是一款ElasticSearch专用的浏览器插件，支持ES的查询、数据导入、语句分析等功能：+ 导入数据的方式支持在线JSON，JSON文件、CSV文件+ 在线进行数据查询、过滤、数据统计+ 进行数据的CRUD操作上图就是插件打开之后的主页面，需要输入ES的地址，以及我们需要预览的index的名称，这里是position，截图中的数据都是在我通过json文件导入之后的。当然，我们可以使用官方推荐的Kibana。 Import Data点击Upload File按钮边上的问号，可以看下格式说明。简单来说，Json格式就是一个Java对象的Json字符串。准备好文件直接上传就行了，不过建议文件大小不要过大，几十兆就行了，否则浏览器容易卡死。其它功能，我也没做过多的使用，这里就不展开介绍了，大伙自己个儿去试试看吧。 查询SearchElasticSearch提供的RESTful

地转天旋，万事开头难。 斗霜傲雪二十年，堂堂剑气尚寒。 戎马倥偬一生，多少失败成功？ 试看大千世界，依旧海阔天空。其实吧，启动一个单机的Elasticsearch（下文称ES）节点，非常简单。之所以会有这么一首诗，完全是为了装，贱笑，贱笑了！ Elasticsearch简介ES是应用非常广泛的分布式搜索引擎和分析引擎。著名的ELK中的E就是ES，L指的是Logstah，它用于收集数据（日志），K指的是Kibana，它是一个可视化的操作和分析工具。ES可以为几乎所有类型的数据提供实时搜索和分析功能。无论是结构化数据、非结构化数据、数值型数据、甚至是空间地理数据，ES都能以支持快速搜索为前提，有效的对其进行存储和索引。通过它，我们不进行可以进行快速搜索，还能通过聚合、统计等功能来发现数据中隐藏的趋势。ES的分布式特性可以很轻松的进行集群扩展，以解决数据量和查询量快速增长带来的问题。ES解决的不仅仅是搜索的问题：+ 给我们的网址添加一个搜索框，当然这解决的是基础的搜索问题+ 储存和分析海量数据，比如访问日志、性能指标或其它案例数据+ 可以实时的通过机器学习为用户行为数据进行建模+ 作为业务上自动化工作流的存储引擎+ 作为空间地理信息管理系统（GIS），为空间数据进行管理、集成和分析+ 为其它场景的海量数据查询、分析提供基本能力使用ES的场景千变万化，但是其基本的索引和查询方式都是一样的。 数据输入作为一个分布式的文档存储引擎，ES不会按行（一行包含多列）来存储数据，取而代之的是更为复杂的且序列化过的JSON文本。如果你运行的是一个多节的ES集群，那么索引数据将会分布在各个节点，而且可以通过任意节点访问到所有数据。 为什么这里是JSON，应该是ES进行了封装，屏蔽了Lucene层面的D

人生天地之间,若白驹之过隙,忽然而已。 感慨刚毕业与同学合租打网游的场景仿佛还在眼前，现在参加工作都已经九年了，这时间流逝的速度一点不亚于“过隙白驹”啊！九年时间，我工作过三家公司，包括现在这家，三家公司的工作时间分别是一年、四年、4年。像我这个跳槽频率，应该可以算低了，特别是我们这一行。而且，其中有八年时间我都专注于Java领域的搜索引擎开发；往细节说，就是专注于垂直领域的基于Solr的搜索引擎开发。所以，在“Solr应用于垂直搜索”这个领域，我应该可以算得上专家了，至少时间上差不多够到专家门槛了。来现在这家公司之前，面试过几个公司，对我的技术和业务能力还算认可，不过他们都要求我转ElasticSearch。关于这个ES，我也是听说过，只是没用过。所以我问他们，为什么选这个框架而不是Solr（之所以这么问，有一部原因是我一直使用的Solr居然被人看不起）？是基于数据量考量还是基于功能考量。大部分人都没有颇具说服力的理由，主要的原因有以下几条：1. ElasticSearch 是一个分布式搜索引擎框架，分布式又是互联网热门词汇2. ElasticSearch 实时性比较好3. ElasticSearch 支持的数据量更大4. ElasticSearch 查询性能更高，尤其是大数据量的时候但是一问具体有测试报告或者自己做过测试没有，都说没有。问号脸？？？没有调查就么有发言权。当时针对这几个理由，我也无力反驳，谁叫我不懂ElasticSearch呢。----- 理性分析不过话说回来，为什么我遇到的公司的技术负责人选技术这么随意呢？ElasticSearch 能搭上分布式的船就选它？分布式自带大数据属性，所以就是一个互联网公司了？而且部署了支持大数据的分布式搜索引擎的互联网公司？暂且不纠结是不是面试官不屑于跟我说明具体

什么是分词分词就是将连续的字序列，按照一定的规范重新拆分、组合成词序列的过程。通常字序列是无意义或者弱意义的，而词序列是具有完整意义表达的最小单元，它比字序列饱满但比短语简练。所以分词的直接目的就是将一段文本，提取出一系列最符合文本本意的词序列。我们知道，在英文的行文中，单词之间是以空格作为自然分界符的，而中文只是字、句和段能通过明显的分界符来简单划界，但是词之间是没有形式上的分界符的，所以中文分词大多借助词库字典来进行分词。比如一句话：我是一个年过半甲的程序员，比较合理的分词结果就是我、是、一个、年过半甲、的、程序员。不过，分词的最终结果受应用场景、分词技术综合影响，具体的结果会稍有不同。比如，垂直领域的搜索引擎大多行业相关，所以其停用词（stopword）范围也不一样。上面例子中的我、是、的都被看做停用词，不会被索引，因为搜索这些关键字会被认为是无意义搜索。而对于年过半甲这个词，由于不是一个通用的词语，所以在基于词库的分词器中可能也不会被分出。 停用词（stopword）人类语言包含很多功能词。与其他词相比，功能词没有什么实际含义。最普遍的功能词比如限定词（“这”、“那”、“个”、“啊”等），这些词帮助在文本中描述名词和表达概念，如地点或数量。介词如：“下”，“上” 等表示两个词的相对位置。这些功能词的两个特征促使在搜索引擎的文本处理过程中对其特殊对待。第一，这些功能词极其普遍（词的文档频率很高）。记录这些词在每一个文档中的数量需要很大的磁盘空间。第二，由于它们的普遍性和功能，这些词很少单独表达文档相关程度的信息。如果在检索过程中考虑每一个词而不是短语，这些功能词基本没有什么帮助。在信息检

零、前言经过文章[《搜索引擎入门——启动第一个Solr应用 》](https://oomabc.com/articledetail?atclidf9b37293ec184ab6ad4d672327057dd7)的介绍，我们已经成功搭建了一个搜索引擎服务。通过使用Solr提供的rest接口，我们已经能够完成索引重建、更新以及查询的功能。本章主要介绍以下几个方面的内容：+ 查询界面的基本使用：基本关键字查询、二次查询、排序、分页、默认查询字段、返回字段设置等等。+ 查询语句的调试：主要是进行关键字查询得分的调试，可以清楚的看到每一个结果所匹配的条件以及详细得分计算情况。+ 关键字高亮与摘要：搜索引擎常见的功能，对命中的关键字进行高亮展示。+ 高级自定义查询：主要是借助solr封装的一些函数进行字段的简单计算，最终干预文档得分。------ 一、基本查询上图是我们项目中使用的一个职位索引的查询页面，这是Solr启动之后我们所要重点关注的查询页面。 普通查询语句 q这个参数可以直接输入关键字，那么它查询的字段就是schema.xml中配置的默认查询字段keyword。关于schema.xml的相关配置可以参考另一篇文章[《搜索引擎入门——聊聊schema.xml配置》](https://oomabc.com/articledetail?atclidadb7b81f31ca4b45b1315b3af89a9c23)。那么，qjava的查询结果与qkeyword:java的查询结果是一样的。这个q里面可以设置任意多组查询条件，比如qpositiontitle:java cityname:上海 functionname:技术，就是搜索上海的技术职能下的java岗位。多组条件可以用AND符号连接，如果都是AND可以用空格代替，系统自动使用defaultOperator配置的连接符。当然我们也可以进行

前言Lucene中一个很重要的概念就是文档（Document），它代表一条建立索引的独立且完整的数据。可以对标到我们关系数据库的一条记录。一个Document包含很多个域（Field），对标数据库的字段Column。Field的一些属性配置对标字段的属性。本身Lucene对Document的Field是开放式的，不同Field的Document可以索引到一起，有点类似于noSQL的概念，属于schema-free的。但是这种开放式结构会造成“开发一时爽，维护骂爹娘”的情况，所以Solr在封装Lucene的时候通过schema.xml文件来规范Document的Field定义。类似于MongoDB的一些ORM框架（Morephia、spring-data-mongo）做的事，其实就是定义一个标准、做个存根，方便排查。所以，schema.xml配置的内容就出来了：+ Field Type 定义：定义了字段类型，string、int、double、text等等，名字是自取的。+ Field 定义：字段，比如positionid、name、age等等。------ schema.xml的大致结构XML -- -- -- positionid keyword 从实际的配置文件也可以发现，schema中确实主要包含两个内容，types和fields。+ types：定义Field类型的元数据。+ fields：表示这个索引的每条

零、关于Solr摘自维基百科： Solr（读作“solar”）是[Apache Lucene](https://zh.wikipedia.org/wiki/Lucene)项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如Word、PDF）的处理。Solr是高度可扩展的，并提供了分布式搜索和索引复制。Solr是最流行的企业级搜索引擎，Solr 4还增加了NoSQL支持。 Solr是用Java编写、运行在Servlet容器（如[Apache Tomcat](https://zh.wikipedia.org/wiki/ApacheTomcat)或Jetty）的一个独立的全文搜索服务器。 Solr采用了[Lucene](https://zh.wikipedia.org/wiki/Lucene) Java搜索库为核心的全文索引和搜索，并具有类似REST的HTTP/XML和JSON的API。 Solr强大的外部配置功能使得无需进行Java编码，便可对其进行调整以适应多种类型的应用程序。Solr有一个插件架构，以支持更多的高级定制。 因为2010年Apache Lucene和Apache Solr项目合并，两个项目是由同一个[Apache软件基金会](https://zh.wikipedia.org/wiki/Apache%E8%BD%AF%E4%BB%B6%E5%9F%BA%E9%87%91%E4%BC%9A)开发团队制作实现的。提到技术或产品时，Lucene/Solr或Solr/Lucene是一样的。 Solr的历史2004年，Solr作为CNET Networks为公司网站添加搜索功能的一个内部项目，由Yonik Seeley创建。 后来Yonik Seeley随Grant Ingersoll和Erik Hatcher创建了LucidWorks（原名Lucid Imagination），公司提供商业支持、咨询和Apache Solr搜索技术的培训。2006年1月，CNET Networks决定捐赠其到Apache软件基金会顶级项目Lucene，公开发布其源代码。像在Apache软件基金会的任何新项目一样，其进入了一个潜伏期，以助于解决组织、法律和金融问题。2007年1月，Solr结束

前言在搜索引擎的两个阶段会用到分词功能，分别是索引和查询。先说一下个人在垂直搜索引擎常用的索引分词设置（针对IK分词器）。无论采用何种分词设置，都会有一定的局限性或者说缺陷。因此在合适的阶段选择适合业务场景的分词方式才是最重要的。 索引阶段IK分词器提供了两种分词模式，通过布尔变量useSmart来设置。我在索引阶段设置useSmartfalse，其含义就是采用最小粒度分词，即会分出最多的可能的词汇（包括分词歧义词汇）。比如短语“中华人民共和国”的分词结果就是：中华人民共和国、中华人民、中华、华人、人民共和国、人民、共和国、共和、国。可以看出来，这个模式下分词器会将词库中有的词全部分出来。其中“华人”这个词在短语中属于歧义词，在这个语境中是不合适的。之所以选择这个模式，是因为在索引的时候尽可能的建立更多分词的倒排索引关系链，这与全文检索的“一次索引，多次查询”的特点有关。对于这个短语来说，除了“华人”之外的其它分词能搜索到这个短语，都是合理的场景。 查询阶段我在查询阶段（也就是用户输入关键字查询结果中的分词阶段），设置了useSmarttrue。其含义是IK分词器会用其智能分词功能给你最合适的分词结果，一般来说是词语最少的结果，但是它能最大程度保留原短语的语境含义。比如短语“中华人民共和国”的分词结果就是：中华、人民共和国。这两个词就最大程度保留了语境含义，而且其输入能完美映射到索引阶段。对于，索引中出现“中华”和“人民共和国”两个词语相距很远的情况，可以通过设置查询跨度来过滤。"中华人民共和国"~2，这里的2是指两个双引号之间的短语，各个分词的起始位置之间的最大允许间隔。 在Solr的schema.xml的配置xml

前言 搜索引擎的出现，整合了众多网站信息，恰恰起到了信息导航的作用。通用搜索引擎就如同互联网第一次出现的门户网站一样，大量的信息整合导航，极快的查询，将所有网站上的信息整理在一个平台上供网民使用，于是信息的价值第一次普遍的被众多商家认可，迅速成为互联网中最有价值的领域。互联网的低谷由此演变为第二次高峰。大家熟知的搜索引擎Google、百度、雅虎等是通用搜索引擎现如今的杰出代表，他们为互联网的发展做出了重要的贡献。然而，搜索引擎行业也不是一家公司就可以独撑天下的，从百度的上市、yahoo中国的并购一系列动作表明，如今的搜索引擎大战如同门户网站初期的竞争一样激烈。相信，通用搜索引擎在经历过一段时间的角逐后，也将会继续维持几大服务商各自分控一部分市场的局面。通用搜索引擎的性质，决定了其不能满足特殊领域、特殊人群的精准化信息需求服务。市场需求多元化决定了搜索引擎的服务模式必将出现细分，针对不同行业提供更加精确的行业服务模式。可以说通用搜索引擎的发展为垂直搜索引擎的出现提供了良好的市场空间，势必将出现垂直搜索引擎在互联网中占据部分市场的趋势，也是搜索引擎行业细分化的必然趋势。 垂直搜索引擎是针对某一个行业的专业搜索引擎，是搜索引擎的细分和延伸，是对网页库中的某类专门的信息进行一次整合，定向分字段抽取出需要的数据进行处理后再以某种形式返回给用户。垂直搜索是相对通用搜索引擎的信息量大、查询不准确、深度不够等提出来的新的搜索引擎服务模式，通过针对某一特定领域、某一特定人群或某一特定需求提供的有一定价值的信息和相关服务。其特点就是“专、精、深”，且具有行业色彩，相比较通用搜索引擎的海量信息无序化，垂直搜索引

说到搜索引擎，大家都不会陌生，尤其是互联网从业者更是如此。而大部分程序员都能对其基本原理说个七七八八，比如分词、倒排链表、空间向量模型、余弦定理、Top-N......。而且对于全文检索的两个过程索引和查询也都知道个大概。+ 索引：对数据进行分词，然后按照分词结果生成倒排链表（包含词频、位置等信息），最后生成索引文件。+ 查询：对查询语句进行分词，综合其他查询条件生成查询树并优化；对查询树进行倒排链表匹配，将匹配到的链表按照查询语义进行操作（交集、并集、差集等）；最后按照打分规则进行排序并分页返回结果。当然真正的实现细节会复杂许多，比如数据结构、数据类型定义、索引存储、数据压缩、相关链表操作算法、跳跃表、打分模型、内存索引切换等等，都是需要考虑的地方。 链表操作前面介绍的那些内容中，有一个是非常重要而且相对来说比较容易看懂和说明白的就是链表操作。何为链表操作？每个Term后面都挂有一个链表，链表的元素主要包含的内容有元素的DocId（这是Lucene给每个文档的自增编号）、Frequency（这是分词在对应文档中出现的频率）。实际上，每个链表元素就对应一篇当初索引的文档，所以链表操作就是对这些文档进行交集、差集、并集的操作。例，有如下几篇文档： A：机器学习最通俗的解释就是让机器学会决策。 B：支持向量机(SVM)是90年代中期发展起来的基于统计学习理论的一种机器学习方法。 C：随机森林的基本单元是决策树。 D：分类和回归是机器学习解决的两大主要问题。 E：古典决策理论盛行于20世纪初到50年代期间。 F：分类树（决策树）是一种十分常用的分类方法，是一种有监督的机器学习方法。现在我们只考虑其中几个分词，而且暂时忽略分词的歧义性，那么简易

本章要介绍的内容是solr中的自定义排序规则，或者说自定义得分函数。看懂本章内容，最好了解过以下知识点：1. solr的基本查询功能2. solr的edismax高级复合查询3. edismax中bf的作用关于solr内置function的用法可以参考官方文档《[Function Queries][solrLink]》，后续如果有机会，我会另出一篇文章加以阐述。---- 需求背景本来搜索服务提供的是一个职位搜索功能，面向的用户是猎头。所以，有一个需求就是按照猎头对每个职位的一个偏好预测值（记为V）进行职位综合排序。每个猎头对于不同的职位都有一个偏好预测值，记为H1V1。这个值由AI团队根据猎头所有行为记录进行统计计算，然后搜索团队要在猎头某一次搜索的结果内进行偏好预测值排序。几万猎头和几万职位的预测值是一个非常庞大的数据集。功能实现方式：1. 在职位索引增加一个动态字段，然后在建索引的时候猎头ID命名动态字段，对应的值就是这个猎头对当前职位的偏好预测值。dmdouble10002100，表示猎头10002对当前职位的偏好预测值为100。然后在搜索的时候，通过猎头id指定字段进行sort即可。2. 自定义一个function，通过solr提供的功能，在搜索时进行实时预测值查询，然后内置排序。方法1确实是一个最简单的方式，非常好理解，就是增加一个动态排序字段，然后sort即可。但是问题是数据量会非常大，而且意义不大。如果有10000个职位，30000个猎头，那么笛卡尔积就是3亿的偏好预测值，平均每个职位上要大约增加30000个动态字段，一个document会变得非常臃肿。当然，可以进行无效数据的预处理等方式进行优化，但是最后的数据依旧会庞大无比，关键是大部分都是无效数据。所以，我采用的是方法2。![图片](https://oomabc.com/staticsrc/img/201812/18/15

零、应用场景最早接触这个算法，是在看Lucene实现原理相关代码的时候。搜索返回查询结果就是一个很典型的TopN算法应用，获取综合分数最高的前N个结果。搜索场景，通常数据量会在百万级、千万级甚至更多，因此，获取分数最高的前N个结果的性能好坏直接影响搜索体验。获取前N个得分最高的结果，可以有不同的方法：1. 直接对数据（Item）集进行排序，然后截取前N个Item；那么，排序算法会对性能有较大影响。例如快排的时间复杂度在O(n)到O(nn)之间，平均复杂度是O(nlog(n))。2. 对所有Item进行一次遍历，对于遍历每个Item的时候，始终有一个临时结果集来保存当前情况下的可能结果集，当遍历结束时，临时结果集就是最终结果，只要按顺序输出即可。本身遍历比较简单，那么选择临时结果集的数据结构就是算法的关键。我们对临时结果集的数据结构有几个要求： 1. 数据结构本身可以有序输出Item。 2. 可以快速新增一个Item，而且可以保持i中的特性。 3. 可以快速判断是否需要替换Item，且替换之后可以保持i中的特性。--- 一、算法简介Lucene中使用的最小二叉堆，就是满足了上面第二点中提出的要求（堆特性）。 最小二叉堆：父节点不大于其两个子节点，两个子节点直接的大小比较没有要求。堆顶是所有节点中最小的，但是最终整个堆返回的就是前N个最大值。解释： 堆顶最小的目的是，在遍历时，如果发现某个Item的值大于堆顶（找出前N个最大的要求就是，用某个Item替换掉临时结果集中最小的，堆顶始终最小的话就可以很方便判断Item是否可以入堆，而且直接删除被替换的堆顶），则可以替换掉当前堆顶，然后执行节点沉降，以便保持特性。它的时间复杂度为 O(nlog(n))。 主要过程1. 遍历目标集，每次遍历的数据节

前言 IKAnalyzer是一个开源的,基于java语言开发的轻量级的中文分词工具包。他最初是由林良益老师团队开发并维护的。 IK对应Lucene版本为4.7.2，其实IK针对不同版本的Lucene可以进行定制化的修改以达到适用的目的。 词库动态加载的关键类是org.apache.lucene.analysis.Tokenizer和org.apache.lucene.analysis.util.TokenizerFactory。 同义词扩展的关键类是org.apache.lucene.analysis.synonym.SynonymFilter和org.apache.lucene.analysis.util.TokenFilterFactory。--- -------- 必要信息解释Term是一个最小搜索单元，Lucene中有个Term和对应的TermQuery；Token应该是分词过程中记录一些分词信息的对象。 然后我特意下载lucene-core-4.7.1进行查看，看到Token这类上面是这么写的： 我用非常蹩脚的英语水平，大致翻译一下主要内容就是：Token是一种在对文本进行分词时产生的对象，包含分词对象（Term）的词语内容，词语在文本中的开始、结束位置，和一个词语类型（关键字、停用词）字符串。开始、结束位置这两个参数，可以在做文本高亮或者摘要高亮的时候使用。从Lucene的2.9版本开始，Token这个类就不再建议使用了，推荐用Attuibutes这个接口对应的实现类代替。新版本取得分词信息方式如下：javaAnalyzer analyzer new StandardAnalyzer(Version.LUCENE47);String text "利用 Lucene 进行搜索就像建立索引一样也是非常方便的。";TokenStream tokenStream analyzer.tokenStre