购物搜索引擎架构的变与不变

一淘网 喜德

一淘搜索

• 全网购物搜索• 一站式购物体验• 发现

– 一淘发现

• 比较– 商品搜索– 比较

• 优惠– 优惠券

– 返利

一淘搜索的技术挑战

• 引擎功能变得越来越复杂和臃肿– 超过30个搜索应用– 业务增长带来的更多对引擎的功能需求– 搜索前端也面临逻辑冗余、复用度低的困难

• 集群运维变得越来越困难– 核心引擎超过10个，并还在增加– 运维大量小集群的难度更大– 节省备用服务器– 节省运维成本

• 一淘搜索的“不变”

引擎功能定制

一淘搜索业务的挑战

• 正排索引：定制化的过滤、统计、排序逻辑

• 数据混排

• 引擎数据关联• 动态数据计算• 外部数据关联

定制化的正排字段计算

• 正排定制化需求– 价格排序：price / price+postage

– 相关性特征计算：0.2*A+0.4*B+0.4*C

• 正排字段间的简单计算

• 与query有关的字段运算？区域缺货

• 简单按正排字段过滤、统计、排序

• 适合快速试错性demo

– 离线计算

– Hack核心引擎

定制化的正排字段计算

• 与query等因素有关的正排定制化需求– 缺货过滤：filter=!out_of_stock(stock_table, “北京”)

– 折扣价排序：sort=discount_price(price, discount_table)+postage

• 支持外部so插件扩展，通过query中“函数”名动态构建

• 由query参数+正排字段在线完成计算

• 适用于：个性化需求，快速产品demo

数据聚合层

• 问题：– 引擎间数据关联

– 关联非引擎服务

– 多路数据混排

– 搜索结果rerank

– 动态数据计算

– 前端逻辑冗余

数据聚合层• 异构服务聚合• 多粒度cache• Service Locator

• 通用关联逻辑• 通用排序逻辑• 应用逻辑插件化

数据聚合层功能

• 排序– 简单按分数排序

– 按比例混排

– 队列优先

– Rerank– 快速屏蔽 e.g. 商家屏蔽

• 数据分层– 优质商品

– 非优质商品

• 展示字段关联– 关联商家引擎

– 关联产品信息引擎

– 关联实时统计信息

– 关联外部服务

– e.g. mysql, http service

搜索运维平台

搜索运维平台的核心问题

• 自动恢复硬件故障– 降低运维参与度

• 在线多集群管理– 管理大集群– 管理大量集群

• 按需索引分发– 满足故障恢复、索引切换的需求

• 索引切换和更新– 切换过程中不间断服务

搜索架构与分布式容错

• 二维结构– 索引规模扩展

– 查询规模扩展

• master处理任务分配和恢复

• client与worker进行数据交互

搜索运维平台设计思路

• 逻辑拓扑– 与数据对应– 永不失效

• 物理拓扑– 与位置（进程）对应– 随时可能失效

Replica调度

拓扑生成

Replica调度

• 按配置调度指定数量的replica

• Searcher故障恢复

• 配置更改– Replica增减– Cluster增删

• Admin恢复– 热备

索引分发系统

• 以Block为单位传输• Pull模式• 链式拓扑

– 近似等于单节点分发时间

• Master故障– 状态持久化

• Node故障– 跳过坏点– 恢复后续传

心跳及拓扑生成

• 依赖zookeeper做心跳收集和通知

• 实时生成逻辑拓扑

• 通过命令在角色间建立父子关系

• 响应延迟200ms

• 客户端容错策略

• 问题：Zookeeper对硬

索引切换

• 逐partition更新

• 先加载新版本

• 旧版本在被遮挡后删除

• 动态修改partition数

• 不一致版本并存

• 不一致partition并存

增量索引分发

• Swift– 分布式实时数据队列– 通过HDFS持久化

• 普通增量– 间隔较长>30min– 由admin控制分发– 基于磁盘的持久化索引– 保证正确性– Hadoop build

• 实时增量– 间隔短<1s– Searcher主动pull

一淘搜索架构

•通用功能和性能•核心引擎平台

•规模问题•大规模集群运维•引擎运维平台

•产品需求定制•数据聚合层

一淘搜索发展思考

• 通用资源分配服务

• 异构硬件资源利用

• 通用心跳与服务定位服务

• 个性化搜索

• 定制化搜索

Q&A

23