白话 IT 之 聊聊搜索

文/朱赟

Square 是一家很神奇的技术驱动的公司。这个公司的文化很独特，就工程师文化来说，早期 Square 在技术上还是比较大胆和激进的。

为什么这么说呢？举几个例子。虽然 Square 的核心产品是信用卡读卡器，但 Square 尝试开发过的产品真的很多，虽然不是每一个产品都长久地活了下来。比如电商平台、电子钱包、Payroll 系统，等等等等。另外 Square 早期有一批很 Nerdy 的技术人，包括 Rails 的 Contributor、Java Guice 的发明者等等。并且 Square 从不打怵使用新技术，比如 ElasticSearch、Kafka 等，在版本还没有稳定的时候，Square 已经在产品上使用了。而且因为我们是自己的 Data Center，没有使用 Amazon。所有的配套服务，包括 Deploy 以及 Production 的工具和环境，一套套系统全部都是 Build in House。以上种种，可能和我们创始人 Jack 本身是技术出身有一定的关系。

虽然说这些对于一个公司的发展不一定完全都是好事，但是对于工程师来说，却是一个绝佳的成长环境。一来有机会接触到新技术、或者技术的最前沿。二来因为不停的做新产品，所以早期的时候几乎每个项目都是两三个人从头到尾完全自己搭建。

我在 Square 做过两个大项目，一个就是和前 Google 员工 Ken 两个人一起搭建了 Square 的搜索后端。另一个就是和 Eric 一起做了 Square Store 这个电商平台，主要处理所有 Square 软硬件销售的支付流程。

虽然后来在支付这条路上走了下去，当时一年左右做搜索的经历，还是蛮有意思的。所以想整理一下，分享给大家。当然，一年的经验离资深还差得很远，所以可能说的东西就入不了专家的法眼，因此本文称为 “白话”。

基本概念

搜索说白了就是从已有的数据和信息里找到满足用户条件的一些匹配。

拿最简单的数据库来说，完成用户对数据库的搜索，不外乎这样几个概念：数据存储格式，也就是 Table Schema；新数据的写入；对 Table 的查询；其中又包括 Indexing 来对部分查询的 Pattern 进行性能上的优化；另外可以根据某些 Column 的值对查询结果进行排序。

搜索引擎从基本概念上来说，也是极类似的。例如常见的 Apache Solr 和 Elasticsearch（以下简称 ES），这两者都是建立于 Lucene 之上的，且最核心的功能很类似。（Lucene 其实就是一个搜索引擎 Library，有一堆 Jar 文件，并提供一个 Lucene API 接口。）因为直接用 Lucene API 相对来说更灵活，但是需要更多的 Engineering Effort 才能使用，所以很多地方都是使用 Solr 或者 ES，两者都是基于 Lucene 之上添加了很多可用 Feature 的一个封装。

Indexing

Solr 和 ES 的 Schema 也可以看成定义数据的存储格式和 Structure。这样，当你有新的数据需要存到你的可搜索数据集的时候，就需要把原始数据转化为 Solr 和 ES 文档定义的数据格式。这个过程通常称为 Indexing，或者 ETL。ETL 是 Extract - Transform - Load 的简称。实际应用中，很多时候，搜索的数据源来自于多个系统或 Service，格式和数据结构也就都不相同。Extract 就是从这多种多样的数据源中解析出相关的 Field 和 Value，并可能对数据进行一定的校验。Transfer 就是把 Extract 出来的数据信息转化成搜索引擎的文档存储格式。可能会对一些数据进行组合或聚合，也可能进行一定的转换或计算。最后处理好的文档就可以按照 API 可以接受的格式 Load 到搜索引擎的文档中。

ETL 的过程虽然说起来简单，也就是搭建数据 Pipeline，但是实际中会有很多细节需要考虑和实现。就拿 Extract 来说，怎么从数据源拿数据呢？作为数据源的 Service 可能会实时地 Publish 一些数据更新，这个时候，需要一些类似于 Trigger 或者 Feed Publisher 的机制来保证这样的数据更新可以被搜索引擎的捕捉到。最常见的有三种方式。一是通过加 Trigger，数据变动时直接触发 API Call；一是 Feed 模式；一是使用 Kafka 这样的 Log 机制。而后两种都可以使用 Pull 或者 Push 的方式来触发 Indexing。

这说的是实时 Indexing。而搜索中，因为各种各样的原因（例如早期 ES 的 Re-sharding），往往需要从 0 开始重新 Index 所有的数据。这样，所有的数据源就需要一定的 Persist 机制，把所有数据变动的历史存储下来。Full  Reindex 的时候，就可以从这些 Persisted 数据中，重新通过 ETL 产生搜索引擎的文档。

Transform 主要是数据转换，通常比较简单。Load 也就是 API Call，通常是固定的处理方式。但是很多系统需要考虑负载、一致性、和扩展性，因此从 Infra 的角度来说，也需要一定的 Tuning 来保证实时无错的 Load 数据到搜索后端。

Querying

Query 其实最重要的两个概念，我觉得就是 Match 和 Score。Match 就是找到所有满足 Query 条件的数据。Score 就是根据应用的需求，制定一个对结果排序的规则。

Matching 的过程有的时候也称为 Analyze 的过程。通常的做法是 Tokenizing 加 Filtering。Tokenizing 就是把数据划分成一个个不可分割的小单元，然后通过对这些小单元的组合和 Filtering，找到适合需求的所有数据。

Score 常见的也有两种，一种是搜索前静态 Score，也就是和 Query 无关，数据的不同 Field 预先制定一个权重。一种是搜索后 Score，通常和 Query 的具体内容相关。各种不同的 Score 机制可以相互组合使用。而如何调整 Score 函数，让期望的搜索结果出现在比较靠前的地方，则是很多产品的搜索开发中需要致力的地方。很多时候会使用机器学习等方法帮助调整 Score 函数的参数。

Performance and Scalability

除了上面说的两个最基本的功能：Indexing 和 Querying，搜索在实际应用中随着数据的不断增加和 Query 的逐渐复杂化，对于 Performance 和 Scalability 的要求往往也是不断提升。

不同的搜索引擎如 Solr 和 ES 会提供不同的机制用于方便定制不同的 Query。两者对于 Scalability 如分布式搜索的处理也不尽相同。还有一些对灵活性或性能要求更高的地方，往往又会基于底层 Lucene，撇开 Solr 或者 ES，定制自己的搜索系统。下面几个部分将进一步细化对其的讨论。

Solr 和 ElasticSearch 的对比

历史背景

Solr 问世于 2004 年，但是一开始只是某公司的内部项目。2006 年公开发布其源代码，2007 开始应用于一些高流量的网站。2008 年 1.3 版本的问世增加了一定的分布式搜索功能，例如可以做 Sharding。但是有很多功能和特征上的局限性。2010 年，ES 问世。ES 早期在各种搜索功能、社区、品牌、成熟度上都远远不及 Solr。但是因为它是针对分布式搜索而设计的，并且很快吸引了很多用户且不断迭代，因此很快在该领域成为 Solr 的有力的对手。虽然 2012 年 Solr 发布了 SolrCloud 对分布式搜索有了更好的支持，但是一来这时候 ES 已经在市场上站住脚，二来 ES 后起却在设计上致力于解决分布式搜索，因此很多需要分布式搜索的地方 ES 依然成为首选。

主要区别

（编辑：PHP编程网 - 钦州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!