⽤Elasticsearch构建电商搜索平台（有赞） 随着互联⽹数据规模的爆炸式增长，如何从海量的历史，实时数据中快速获取有⽤的信息，变得越来越有挑战性。
电商数据系统主要类型
⼀个中等的电商平台，每天都要产⽣百万条原始数据，上亿条⽤户⾏为数据。⼀般来说，电商数据⼀般有3种主要类型的数据系统：
1. 关系型数据库 ，⼤多数互联⽹公司会选⽤mysql作为关数据库的主选，⽤于存储商品，⽤户信息等数据。 关系型数据库对于事务性⾮ 常⾼的OLTP操作(⽐如订单，结算等)⽀持良好。
2. hadoop⽣态 ，hadoop是数据仓库主要的载体，除了备份关系型数据库的所有版本，还存储⽤户⾏为，点击，曝光，互动等海量⽇志
数据，hadoop对于数据分析，数据挖掘等OLAP⽀持⽐关系型数据库更加具有扩展性和稳定性。
3. 搜索引擎 ，以elasticsearch和solr为代表。搜索引擎是获取信息最⾼效的途径，⼏乎成为各类⽹站，应⽤的基础标配设施(地位仅次 于数据库)。
⽬前搜索引擎技术已经有⾮常成熟的开源解决⽅案，最出名的ElasticSearch和Solr都是基于lucence的。很多中⼩型互联⽹公司搜索引擎都是基于这两个开源系统搭建的，但是即便如此，⼀个搜索引擎团队想把搜索引擎质量做到商⽤标准，从系统熟悉，服务搭建，功能定制，通常需要花费较长时间。竹炭工艺品
通⽤搜索引擎应⽤在互联⽹商⽤搜索 通常会遇到如下⼏个问题 ：
搜索引擎与公司现有数据系统的集成。mysql 和 hadoop是电商的两个主要数据载体，搜索引擎在全量和增量建索引过程中必须和mysql或hadoop⽆缝集成，才能发挥搜索引擎⾃⾝的实时性，⽔平扩展性(性能与容量和机器数量成正⽐)等优势。
商⽤搜索⾼度定制化与通⽤搜索引擎的⽭盾。商⽤搜索的问题有时候超越了搜索引擎本⾝解决的范围，⽐如商品的去重，店铺的去重需要很专业的搜索引擎使⽤技巧; 商品的权重，⽤户意图的识别需要算法和模型的⽀持。
在不了解搜索引擎专业知识的前提下，很难创建对性能友好的索引。结果造成了通⽤搜索性能很差的假象。
笔者是有赞⼤数据架构师，从⾃⾝的搜索实践出发，分享搜索引擎实际的架构和解决的问题。
搜索引擎架构
有赞搜索引擎实践，上半部分主要介绍搜索引擎的架构和性能优化⽅⾯的经验；下半部分是算法篇，介绍有赞实际需要的搜索算法的问题和解决⽅案。⽂章仅仅介绍⼀个中型电商公司实际的使⽤现状和笔者个⼈的经验，不代表搜索引擎最佳实践⽅法，也不代表可以适⽤所有的场景。
1.技术架构
有赞搜索引擎基于分布式实时引擎elasticsearch(ES)。ES构建在开源社区最稳定成熟的索引库lucence上，⽀持多⽤户租⽤，⾼可⽤，可⽔平扩展；并有⾃动容错和⾃动伸缩的机制。我们同事还实现了es与mysql和hadoop的⽆缝集成；我们⾃主开发了⾼级搜索模块提供灵活的相关性计算框架等功能。
2.索引构建
互联⽹索引的特点是实时性⾼，数据量⼤。时效性要求⽤户和客户的各种⾏为能够第⼀时间进⼊索引；数据量⼤要求⼀个有效分布式⽅案可以在常数时间内创建不断增长的TB数量级索引。
实时索引我们采⽤ ⾯向队列的架构 ，数据⾸先写⼊DB(或⽂件)，然后通过数据库同步机制将数据流写⼊kafka队列。这种同步机制和数据库主从同步的原理相同，主要的开源产品有mypipe和阿⾥推出的canal。es通过订阅相应的topic实现实时建⽴索引。
如果数据源是⽂件，则使⽤flume实时写⼊Kafka。
另外⼀个索引问题是全量索引。有如下⼏个场景让 全量索引是⼀个必要过程 ：
实时更新有可能会丢数据，每次很少的丢失时间长了降低搜索引擎的质量。 周期性的全量更新是解决这个问题的最直接的⽅法；
即使能够保证实时更新，业务的发展有可能有重新建索引的需求(⽐如增加字段，修改属性，修改分词算法等)。
很多搜索引擎是在业务开始后很久才搭建的，冷启动必须全量创建索引。
我们采⽤ Hadoop-es 利⽤hadoop分布式的特性来创建索引。hadoop-es让分布式索引对⽤户透明，就像单机更新索引⼀样。⼀个是分布式的数据平台，⼀个是分布式搜索引擎，如果能把这两个结合就能够实现分布式的全量索引过程。Hadoop-es正式我们想要的⼯具。
我们给出⼀个通过Hive sql创建索引的栗⼦ ：
drop ds_index;
CREATE EXTERNAL ds_index (
is_virtual int,甲基丙烯酸烯丙酯
疑难件created_time string,
update_time string,
title string,
tag_ids array
) STORED BY ‘org.elasticsearch.hadoop.hive.EsStorageHandler’ TBLPROPERTIES (
‘es.batch.size.bytes’=’1mb’,
‘es.ies’=’0’,
‘es.fresh’=’false’,
‘es.count’=’3’,
‘es.mapping.id’=’id’,
‘es.write.operation’=’index’,
‘es.nodes’=’192.168.1.10:9200’,
‘es.resource’=’goods/goods’);
系统把es映射成hive的⼀个外部表，更新索引就像是写⼊⼀个hive表⼀样。实际上所有分布式问题都被系统透明了。
不建议从数据库或⽂件系统来全量索引。⼀⽅⾯这会对业务系统造成很⼤的压⼒，另⼀⽅⾯因为数据库和⽂件系统都不是真正分布式系统，⾃⼰写程序保证全量索引的⽔平扩展性很容易出问题，也没有必要这么做。
全量索引和增量索引的架构如下图所⽰。另外⼀点是hadoop也是订阅kafka备份数据库和⽇志的。我个⼈建议⼀个公司所有DB和⽂件都存储在hadoop上，这样做起码有⼆个 好处 ：
1. hadoop上使⽤hive或者spark创建的数据仓库为⼤数据提供统⼀的操作接⼝。
2. hadoop数据相对于线上更加稳定，可以作为数据恢复的最后⼀个防线。
数据仓库的话题不在本篇⽂章的讨论范围，这⾥只是简单提⼀下。
为什么我们选择Kafka？Kafka 是⼀个以⾼吞吐著名的消息系统。Kafka开启了⽇志合并(log compaction)功能后，可以永久保存每条消息。每⼀条消息都有⼀个key，正好对应数据库的主键，Kafka始终保存⼀个key最新的⼀条消息，历史版本会被垃圾回收掉。有了这个特性，Kafka不仅可以保存数据库最新的快照，⽽且可以实现实时更新的消息系统。
第⼀次同步的时候，数据表中每⾏记录都转化成以主键为key的消息进⼊Kafka，并且可以被任意数量
的broker消费。之后数据库的每次更新(insert，updated，delete)都会被转化成Kafka的消息。如果⼀⾏记录频繁被更改，Kafka会识别这些重复的消息，把旧的消息回收掉。
Kafka既保存数据库最新的全量数据，⼜提供实时数据流的这个特性为架构的可维护性提供极⼤便捷。如果你想从零扫描整个数据库，你只需要从开始消费这个Kafka的topic即可完成，当读到topic末端，⾃动获得实时更新的特性。
Kakfa的另⼀个特性是 ⽀持从任意断点读取数据 ，⽐如我们全量索引是从HDFS中读取，我们可以根据HDFS保存的数据的最后⼀条的时间戳，直接切换到Kafka读取之后的数据。
⾼级搜索：超越ES功能限制
地震的模拟实验
⾼级搜索模块(AS)在商业搜索引擎起到⾄关重要的作⽤。在各⼤商业搜索引擎公司⾥⾯AS已经成为标配，也是变更最为频繁的模块。
AS在商业搜索引擎中主要起到如下作⽤：
装饰扣
1. 反向代理，实现基于分⽚的分布式搜索(实际上es有这个功能); 提供必要的容灾⽀持
2. 提供插件化的相关性计算框架
3. 提供丰富的相关性库，⽐如query分析库，query改写库，排序库，过滤库等。
4. 管理不同的搜索业务
剩余污泥泵AS ⼀个主要的功 能 是通过⼀个个业务插件来代表相应的搜索。⼀个最简单的插件只需要包含对应的ES search API，它实际上就是⼀个配置项，说明es的地址。 这样AS就是⼀个纯代理。但是商业搜索的需求都是不是ES本⾝能够⽀持的，所以就需要根据需求写相应的Query rewriter，rerank等算法插件。这样就实现了框架和业务分离，AS具有极强的扩展性和复⽤性。
AS 另⼀个功能 是提供通⽤算法库，实际上它只为每种算法提供编程框架。 算法也是通过插件的⽅式加⼊算法库的。这种⽅法可以让算法
⼯程师抽象公共算法库供业务⽅使⽤，避免重新造轮⼦。⼀个具体业务要么使⽤已经存在的算法(并修改参数)，要么⾃⼰实现算法。
上图是⼀个 实例 。商品搜索和分销搜索各⾃实现⼀个rerank的的算法，同时都调⽤了系统提供的rerank1的算法库，并加⼊了⾃⼰特有的逻辑。
AS除了基本proxy功能外，还提供基于query的cache功能⽤于应⽤级别的缓存。内部有⼀个缓冲队列，防⽌出现雪崩现象。下⼀节性能优
化中会详细说明。
ES性能优化
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议