互联网数据规模的爆炸式增长,如何从海量的历史,实时数据中快速获取有用的信息,

　　互联网数据规模的爆炸式增长,如何从海量的历史,实时数据中快速获取有用的信息,

　　随着互联网数据的爆炸式增长，如何从海量的历史和实时数据中快速获取有用的信息变得越来越具有挑战性。一个中型电商平台每天产生数百万条原创数据，数亿条用户行为数据。一般来说，电子商务数据的数据系统主要有以下三种：

　　关系型数据库，大部分互联网公司都会选择mysql作为数据库的主要选择，用于存储商品、用户信息等数据。关系型数据库支持非常事务性的 OLTP 操作（例如订单、结算等），很好。

　　hadoop生态，hadoop是数据仓库的主要载体。除了备份所有版本的关系型数据库外，还存储了海量的用户行为、点击、曝光、互动等日志数据，hadoop支持OLAP进行数据分析、数据挖掘等，数据库更具扩展性和稳定性.

　　搜索引擎，以elasticsearch和solr为代表。搜索引擎是获取信息最有效的方式。它们几乎已经成为各种网站应用（仅次于数据库）的基本标准设施。

　　目前，搜索引擎技术已经有非常成熟的开源解决方案。最著名的 ElasticSearch 和 Solr 都是基于 lucence 的。很多中小型互联网公司的搜索引擎都是基于这两个开源系统，但即便如此，A搜索引擎团队想要达到搜索引擎质量的商业标准。通常从系统熟悉、服务构建、功能定制需要很长时间。一般的搜索引擎应用在互联网商业搜索中通常会遇到以下问题：

　　搜索引擎与公司现有数据系统的整合。 MySQL和Hadoop是电子商务的两大数据载体。搜索引擎必须在全量和增量索引过程中与mysql或Hadoop无缝集成，才能实现搜索引擎自身的实时性、横向扩展性（性能与容量和机器数量成正比）等优势。

　　商业搜索的高度定制化与通用搜索引擎之间的矛盾。商业搜索的问题有时会超出搜索引擎本身的范围，比如产品的去重，店铺的去重需要非常专业的搜索引擎技能；产品对用户意图的识别需要算法和模型的支持。

　　在不了解搜索引擎专业知识的情况下，很难创建性能友好的索引。结果是总体搜索性能不佳的错觉。

　　作者是有赞大数据架构师，从自己的搜索实践出发，分享搜索引擎的实际结构和解决的问题。

　　有赞的搜索引擎实践分为2章。第一个是工程章节，主要介绍搜索引擎架构和性能优化的经验；第二个是算法章节，介绍了有赞实际需要解决的搜索算法的问题和问题。 文章 仅介绍一家中型电商公司的实际使用情况和笔者的亲身体验。它不代表搜索引擎的最佳实践方法，也不意味着它可以应用于所有方案。读者如有疑问，请与作者联系。一起讨论。

　　1. 技术架构

　　有赞搜索引擎基于分布式实时引擎elasticsearch (ES)。 ES建立在开源社区最稳定、最成熟的索引库lucence之上，支持多用户租用、高可用、横向扩展；并具有自动容错和自动伸缩机制。我们同事也实现了es与mysql、hadoop的无缝集成；我们独立开发了一个高级搜索模块，以提供诸如灵活的相关性计算框架之类的功能。

　　

　　2. 索引构建

　　互联网索引的特点是实时性高，数据量大。时效性要求用户和客户的各种行为都能在第一时间进入索引；大量数据需要在恒定时间段内创建有效的分布式解决方案。 TB 数量级指数。

　　对于实时索引，我们采用了面向队列的架构。数据首先写入DB（或文件），然后通过数据库同步机制将数据流写入Kafka队列。这种同步机制和数据库主从同步的原理是一样的。主要的开源产品包括阿里推出的mypipe和canal。 es通过订阅相应主题实现实时索引。

　　如果数据源是文件，使用flume实时写入Kafka。

　　另一个索引问题是完整索引。有几种场景需要全索引： 1. 实时更新可能会丢失数据，而且每次都很少丢失很长时间，降低了搜索引擎的质量。定期全量更新是解决这个问题最直接的方法； 2. 即使可以保证实时更新，业务发展也可能需要重新索引（如添加字段、修改属性、修改分词算法等）。

　　3. 很多搜索引擎都是在创业之后很久才建立起来的。冷启动必须完全索引。

　　我们使用 Hadoop-es 来利用 Hadoop 的分布式特性来创建索引。 Hadoop-es 使分布式索引对用户透明，就像独立的更新索引一样。一个是分布式数据平台，一个是分布式搜索引擎，如果能把这两者结合起来，就可以实现一个分布式全索引过程。 Hadoop-es 是我们想要的官方工具。

　　

　　我们举一个通过Hive sql创建索引的例子：

　　

　　系统将es映射到hive的外部表。更新索引就像写入配置单元表。事实上，所有分布式问题对系统都是透明的。

　　不建议从数据库或文件系统完全索引。一方面，这会给业务系统造成很大的压力，另一方面，因为数据库和文件系统都不是真正的分布式系统，自己编写程序，保证全索引级别的可扩展性好走错了，没有必要这样做。

　　全索引和增量索引的结构如下图所示。还有一点就是Hadoop还订阅了Kafka来备份数据库和日志。我个人推荐一个公司所有的DB和文件都存储在Hadoop上，这种方式至少有两个。好处：1.由hive或spark在hadoop上创建的数据仓库为大数据提供了统一的操作界面。

　　2. Hadoop 数据比在线更稳定，可以作为数据恢复的最后一道防线。

　　数据仓库的话题超出了本文的范围文章，这里只是简单提一下。

　　

　　我们为什么选择卡夫卡？ Kafka 是一种以高吞吐量着称的消息传递系统。 Kafka启用日志压缩后，每条消息都可以永久存储。每条消息都有一个key，对应数据库的主键，Kafka总是保存一个key的最新消息，历史版本会被垃圾回收。有了这个特性，Kafka 不仅可以保存数据库的最新快照，还可以实现实时更新消息系统。第一次同步时，数据表中的每一行记录都转换成一条以主键为键的消息进入Kafka，可以被任意数量的broker消费。之后，数据库的每一次更新（插入、更新、删除）都会被转换成来自Kafka的消息。如果某一行 Records 频繁更改，Kafka 会识别这些重复消息并回收旧消息。

　　Kafka 不仅在数据库中保存了最新的全量数据，还提供了实时数据流。该特性为架构的可维护性提供了极大的便利。如果你想从头开始扫描整个数据库，你只需要从头开始消费这个Kafka主题就可以完成。阅读主题结尾，自动获取实时更新功能。

　　Kakfa 的另一个特点是支持从任意断点读取数据。例如，我们的完整索引是从 HDFS 读取的。我们可以根据存储在 HDFS 中的最后一项数据的时间戳直接切换到 Kafka。数据。

　　3. 高级搜索：超越 ES 功能限制

　　高级搜索模块 (AS) 在商业搜索引擎中起着至关重要的作用。 AS已经成为各大商业搜索引擎公司的标准配置，也是改动最频繁的模块。

　　AS 在商业搜索引擎中主要起到以下作用：

　　1. 反向代理，实现基于分片的分布式搜索（其实es有这个功能）；提供必要的容灾支持

　　2. 提供插件相关计算框架

　　3. 提供丰富的关联库，如查询分析库、查询重写库、排序库、过滤库等

　　4. 管理不同的搜索服务

　　

　　AS的主要功能之一是通过一个业务插件表示相应的搜索。最简单的插件只需要收录对应的ES搜索API，其实就是一个配置项，表示es的地址。所以AS是一个纯代理。但是商业搜索的需求是ES本身不支持的，所以需要根据自己的需要编写相应的Query rewriter、rerank等算法插件。这样就实现了框架和业务的分离，AS具有很强的可扩展性和复用性。

　　AS的另一个功能是提供通用的算法库。实际上，它只是为每个算法提供了一个编程框架。算法也通过插件添加到算法库中。这种方法允许算法工程师为业务方抽象公共算法库。使用，避免重新发明轮子。具体的业务要么使用现有的算法（并修改参数），要么自己实现算法。

　　

　　上图是一个例子。商品搜索和分销搜索都实现了rerank算法，都调用了系统提供的rerank1算法库，并添加了自己独特的逻辑。

　　除了基本的代理功能，AS还提供了基于查询的缓存功能，用于应用级缓存。内部有一个缓冲队列以防止雪崩。下一节性能优化会详细讲解。

　　4. ES 性能优化

　　在下面的总结中，我们写了一些我们遇到的性能优化场景。

　　4.1 使用应用级队列防止雪崩

　　ES的一个问题是雪崩在高峰期极易发生。 ES具有完善的线程池系统，可确保并发性和稳定性问题。但是在流量突然变化的情况下（比如双十一），还是很容易出现瘫痪的情况，主要原因如下：

　　ES 为几乎所有类型的操作都配置了一个线程池；只能保证每个线程池的资源使用合理。当两个或多个线程池竞争资源时，很容易导致资源无法响应。

　　ES没有考虑由网络负载引起的稳定性问题。

　　在 AS 中，我们实现了面向请求的全局队列以确保稳定性。它主要做三件事。

　　请求根据业务分为幻灯片，每张幻灯片对应一个队列。默认情况下，一个应用程序是一张幻灯片，一个应用程序也可以区分不同的幻灯片，可以保护应用程序内的重要查询。

　　为每个队列配置一个队列长度，默认为50.

　　为每个队列计算这个队列的平均响应时间。当队列平均响应时间超过200ms时，停止工作1s，如果请求溢出，则写入溢出日志保存数据进行恢复。连续10次队列平均响应时间超过500ms报警，工程师第一时间处理。

　　4.2 自动降级

　　应用级队列解决雪崩问题有点粗鲁。如果一个应用本身查询很慢，很容易让一个应用长时间持续超时。我们根据搜索引擎的特点编写了自动降级功能。

　　以产品搜索为例，产品搜索最基本的功能是布尔查询，但还需要按相关度和质量排序，甚至个性化需求等功能。完成一个简单的布尔查询，ES使用bitsets来操作是可以做到的，但是如果需要相关分数，就必须使用倒排索引，计算分数的CPU消耗很大。 ES 的位集比倒排索引快 50 倍左右。

　　对于有降级计划的幻灯片，当队列响应太慢时，AS直接使用降级查询而不是普通查询。这种方法可以让我们在双十一流量突然增加的情况下，不扩容，顺利度过难关。

　　p>

　　4.3 善用过滤查询

　　了解lucence filter的工作原理对于编写高性能查询语句至关重要。许多搜索性能优化都与过滤器的使用有关。过滤器使用位集进行布尔运算，而 quey 使用倒排索引进行计算。这比查询更好。速度的原因。 bitset的优势主要体现在：

　　1. bitsetcache位于内存中，并且永远不会消失（除非它是LRU）。

　　2. 位集利用 CPU 本身支持的位操作，这比倒排索引快几个数量级

　　3. 多个bitset的AND运算也很快（一个64位的CPU可以同时计算64个DOC的AND运算）

　　4.位集在内存中的存储与查询无关，并且具有很强的可重用性

　　5. 如果一个 bitset 分片全为 0，计算会自动跳过这些分片，使得 bitset 在数据稀疏的情况下也比倒排索引表现更好。

　　例如：

　　

　　lucence 处理这个查询的方式是在倒排索引中找到这三个词的倒排链，并使用跳转指针技术找到交点。在计算过程中，每个文档都需要进行评分。实际上，tag 和 Region 对分数计算没有影响，它们起到过滤器的作用。

　　这是过滤器使用场景，它只存储存在和不存在两种状态。如果我们使用bitsets来存储tags和regions，这两个filter总是可以缓存在内存中，这样会更快很多。另外，tag和region的交集非常快，因为64位机器可以在一个CPU周期内同时处理doc的64位操作。

　　一个 lucence 黄金法则是：如果你可以使用过滤器，就使用过滤器，除非你必须使用查询（当且仅当你需要计算点数）。

　　正确的写法是：

　　

　　Lucence的过滤查询将首先智能地计算过滤语句，然后再计算查询语句，以尽可能减少复杂的反演算法之前的计算空间。

　　4.3 其他性能优化

　　在线集群关闭自动分片平衡。自动分片平衡的主要目的是防止更新导致每个分片中的数据分布不均匀。但是，如果某个在线节点挂了，很容易触发自动平衡，并且一次集群内的数据移动占用了所有带宽。建议采用空闲时间均衡策略，保证数据的一致性。

　　尽可能延长刷新间隔。为了保证实时索引es的索引刷新间隔默认为1秒，索引刷新会影响查询性能。在保证业务及时性的基础上，可以适当延长刷新间隔，保证查询性能。

　　除非有必要删除所有字段。除了索引每个字段之外，索引默认创建一个 all 字段来保存所有文本。删除该字段可以减少 50% 的索引大小。

　　在创建索引时，尽可能将慢索引与快索引物理分离。

　　5. 总结

　　本文介绍了有赞搜索引擎的架构，重点介绍了索引创建机制和高级搜索模块的功能。最后，列举了几种常见的性能优化场景。关于es本身的优化，这篇文章不多写。 ,由于es官网等博客对es的优化意见较多，本文就不一一列举了。本文的主要目的是给读者一个构建商业电商搜索引擎的总体建议。另外，它给商业搜索带来麻烦。引擎最常见的问题是排序和算法问题。如果读者感兴趣，可以关注作者的另一篇文章文章《搜索引擎的实践与赞美（算法）》。